Vendas diárias por loja e vendedor no ERP

Fonte

Cupons e notas do ERP ou PDV

Regra

Dia comercial, chave loja + nota e tipo de operação

Resultado

Venda líquida e ticket por loja, dia e vendedor

Ativação

Dashboard, relatório diário e agente de IA

O que resolve

O faturamento de cada loja cai no dia comercial certo, sem dia zerado ou deslocado por fuso.
Venda bruta, líquida, devolução e venda futura têm regra única e batem com o ERP.
Cada venda fica com a loja e o vendedor de quando ela aconteceu.

Perguntas de negócio que responde

Faça estas perguntas ao seu agente quando o caso estiver pronto.

Quanto cada loja vendeu ontem, líquido?

Qual o ticket médio por loja nesta semana e como está contra a semana passada?

Quanto foi de devolução e de cancelamento no mês, por loja?

Qual o faturamento por loja e vendedor nos últimos 14 meses?

Qual loja está em risco de não bater a meta do mês e quanto precisa vender por dia?

O que você precisa

O ERP ou PDV conectado na Nekt (base Oracle, SAP ou ERP em nuvem)
Os códigos de operação do ERP: venda, venda futura, devolução, remessa
As metas por loja ou produto, se quiser meta x realizado

O que você recebe

Uma tabela por loja e dia com bruta, líquida, tickets e cancelamentos
Uma tabela por item de nota com vendedor e produto
Dashboard da rede com meta, realizado e projeção por loja
Relatório diário de ontem por loja, no WhatsApp ou e-mail

Onde ativar

Dashboard da rede

Venda líquida, ticket e meta x realizado por loja, com projeção de fechamento e semáforo.

Relatório diário

Às 8h, a venda de ontem por loja e vendedor no WhatsApp ou e-mail da gestão.

Alertas

Loja que vende e ficou zerada, ou carga do ERP que não chegou até o horário esperado.

Quer construir?

Uma fonte, mas com regras de data, chave de nota e tipo de operação que precisam ser confirmadas com o financeiro antes do primeiro painel. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.

Ver detalhado

O problema

O ERP guarda a data da venda como meia-noite UTC e quem converte fuso joga a venda para o dia anterior ou zera o dia. O número da nota se repete entre lojas e o cruzamento só por ele mistura vendas de lojas e vendedores diferentes. Na mesma tabela convivem venda, venda futura, devolução negativa, cancelamento e remessa, e cada relatório soma de um jeito.

Como costuma ser feito, e a regra

Cada linha é um erro que já aconteceu na prática.

O jeito comumA regra

Aplicar AT TIME ZONE 'America/Sao_Paulo' no campo de data da venda.

A data do ERP é o dia comercial

Em muitos ERPs e PDVs o campo de data da venda é gravado como meia-noite UTC representando a data comercial, e a hora real fica em outro campo. Calcule hoje e ontem no fuso America/Sao_Paulo e compare direto com essa data, sem converter o campo. Converter para BRT joga meia-noite UTC para as 21h do dia anterior.

Mandar o TIMESTAMP do ERP para o Postgres do BI e confiar no fuso do servidor.

Grave DATE, não TIMESTAMP, no destino

Bancos de destino e ferramentas de BI reinterpretam um TIMESTAMP meia-noite UTC no fuso local e mostram o dia anterior. Converta para DATE antes de enviar. Confira fonte a fonte: algumas trazem data pura, outras trazem hora real em UTC (e-commerce costuma ter hora real e aí sim converte para BRT).

JOIN apenas pelo número da nota.

A nota é loja + número

O número da nota é reutilizado entre estabelecimentos: o mesmo número em duas lojas são documentos diferentes. Todo cruzamento de nota com itens, carrinho, devolução ou comissão usa a chave composta (loja, número da nota). Conte notas com contagem distinta do par, não com contagem de linhas de item.

Uma coluna "venda" sem dizer se é bruta ou líquida.

Diga se é bruta ou líquida

Venda bruta é o valor dos cupons antes de desconto e cancelamento. Venda líquida = bruta menos descontos menos cancelamentos. As duas podem diferir em seis dígitos num único dia de uma loja. Todo número publicado diz qual é, e a pergunta "quanto vendeu" é respondida com a líquida.

Filtrar só venda direta e perder a venda futura, ou excluir devolução do líquido.

Cada tipo de operação tem um sinal

Venda direta soma. Venda futura (faturada para entrega posterior) é faturamento válido e soma. Devolução vem com valor negativo e entra somada, reduzindo o total na data da devolução. Remessa, transferência e bonificação ficam fora: filtre pelos CFOPs de venda. Confirme a lista de códigos de operação com o financeiro.

Dividir pela contagem de linhas de item ou tirar a média dos tickets de cada loja.

Ticket médio usa cupons válidos

Ticket médio = venda líquida / tickets válidos. Ticket válido é cupom distinto (loja, PDV, número) que não foi cancelado. Ticket médio não é somável: o da rede e o do mês são recalculados a partir das somas, nunca média dos tickets diários.

Juntar vendedor à loja pelo cadastro atual e reescrever o histórico.

Vendedor com a loja da época

Vendedores mudam de loja ou apoiam outras unidades. A loja da venda é a do documento, e a relação vendedor x loja tem período de vigência; a loja atual do vendedor nunca é aplicada retroativamente. Normalize o nome (o ERP pode trazer sufixo " - 123" com o código) e mantenha vendedor nulo como "sem vendedor", sem descartar a venda.

Merge por loja e mês numa tabela que recebe linhas diárias.

O grão está no nome e na chave de upsert

A tabela diária tem uma linha por loja, por dia, e o nome diz isso. A chave de upsert é exatamente o grão (loja + dia). Cada execução reprocessa hoje e ontem para pegar ajustes tardios. Tabela mensal não recebe dado diário.

Recarregar a planilha inteira e apagar metas de meses anteriores.

Meta x realizado com projeção

Metas vêm de planilha por loja ou produto e competência. A carga substitui só os itens presentes na planilha para aquele mês e preserva os demais. Realizado é a venda líquida do mês. Gap = meta menos realizado; média diária necessária = gap / dias restantes; projeção = realizado / dias decorridos x dias do mês.

Como cada operação entra no faturamento

Confirme os códigos do seu ERP com o financeiro.

Venda diretaSomavalor positivo

Venda futura (entrega posterior)Soma, é faturamento válidovalor positivo

DevoluçãoSoma o valor negativovalor negativo, data da devolução

DescontoSubtrai da brutabruta - descontos

Cupom canceladoSubtrai da bruta e sai dos tickets válidosbruta - cancelamentos

Remessa, transferência, bonificaçãoFora do faturamentoCFOP fora da lista de venda

Matriz ou CD sem venda diretaSem venda é esperadonão alertar

Definições

Venda bruta

soma do valor bruto dos cupons e notas de venda, por loja e dia comercial

Venda líquida

venda bruta menos descontos menos cancelamentos, com venda futura somada e devolução negativa, por loja e dia comercial

Tickets válidos

contagem distinta de cupons (loja, PDV, número) não cancelados, por loja e dia

Ticket médio

venda líquida / tickets válidos no recorte pedido; não somável, recalculado em cada agregação

Devoluções

soma do valor das operações de devolução (negativo), pela data da devolução, por loja e mês

Taxa de cancelamento

cupons cancelados / cupons totais, por loja e período

Notas emitidas

contagem distinta do par (loja, número da nota) no período

% de atingimento

venda líquida do mês / meta do mês, por loja ou produto

Média diária necessária

(meta menos realizado) / dias restantes do mês

Armadilhas que já aconteceram

Dia de venda alta zerado

Uma consulta converteu para BRT o campo de data gravado como meia-noite UTC e respondeu zero venda para um dia que teve centenas de milhares de reais.

Não converta o campo de data comercial; calcule só o hoje em BRT.

Dia deslocado no BI

O TIMESTAMP meia-noite UTC enviado ao Postgres do BI foi lido no fuso de São Paulo e todas as vendas apareceram no dia anterior.

CAST para DATE antes do destino.

Margem negativa por nota repetida

O cruzamento só pelo número da nota casou um carrinho de uma loja com a nota de outra loja, com outro vendedor e outro cliente. Saíram margens negativas e acima de 100%.

Chave composta (loja, número da nota) em todo JOIN.

Matriz sem venda vira alerta

A matriz ou o CD não tem venda direta e aparecia como loja zerada, levantando suspeita de falha de sincronização.

Marque lojas sem venda direta na dimensão de loja e exclua do alerta de zero.

Duplicação silenciosa

Uma tabela com grão mensal no nome passou a receber linhas diárias, e uma merge key diferente do grão duplicou registros sem erro.

Nome, grão e merge key iguais; teste de unicidade por loja e dia.

Relatório acumulado do mês

Algumas fontes exportam o acumulado do mês a cada dia. Somar os arquivos multiplicou a venda.

Deduplique pelo dia inteiro e fique com o último arquivo de cada data.

Teste de aceitação

O caso está pronto quando todos os itens passam.

Para três lojas e um dia fechado, venda bruta e líquida batem com o fechamento de caixa do ERP (diferença zero).
A soma das lojas é o total da rede do dia, e a soma dos dias de cada loja é igual ao valor da tabela mensal.
A tabela diária tem exatamente uma linha por loja e dia.
"Ontem" consultado às 22h e às 23h59 em São Paulo retorna o mesmo dia comercial e o mesmo valor.
A contagem de notas distintas por (loja, número) no mês é igual ao total de notas de venda emitidas no ERP.

Pacote para o agente

Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.

Markdown completo

Vendas diárias por loja (ERP)
- Grão: uma linha por loja, por dia comercial. Detalhe por vendedor e produto na tabela por item de nota.
- A data da venda é gravada como meia-noite UTC e representa o dia comercial. Não aplique conversão de fuso nesse campo. Calcule hoje e ontem em America/Sao_Paulo e compare direto.
- A nota fiscal é identificada por (loja, número da nota). Nunca faça JOIN só pelo número.
- Venda líquida = bruta menos descontos menos cancelamentos. Quando perguntarem "quanto vendeu", responda a líquida e diga que é líquida.
- Venda direta e venda futura somam. Devolução vem negativa e soma. Remessa e transferência ficam fora (CFOP de venda).
- Ticket médio = venda líquida / cupons válidos (não cancelados). Não some nem tire média de ticket médio.
- A loja da venda é a do documento. A loja atual do vendedor não é aplicada ao histórico.
- A matriz e o CD não têm venda direta: ausência de venda neles é esperada.
- Meta: % atingimento = líquida do mês / meta; média diária necessária = gap / dias restantes.
Exceções por cliente:
- <cliente>: códigos de operação de venda <lista>; venda futura = <código>; devolução = <código>.
- <cliente>: lojas sem venda direta <lista>.
- <cliente>: fonte <país ou canal> traz hora real em UTC e precisa de conversão para o fuso local.

Construa no meu workspace Nekt o caso "Vendas diárias por loja e vendedor no ERP" seguindo as regras em https://academy.nekt.com/industrias/varejo/vendas-diarias-loja-erp.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.

Variações

Uma instância de ERP por loja

Mesma regra em cada instância, unificada com a coluna de loja antes de agregar.

Rede em vários países

Câmbio diário com repetição do último valor em fins de semana e regra de fuso por país.

Histórico de ajustes

Guardar versões do diário (SCD tipo 2) para saber quando um dia fechado foi alterado.