Relatório de vendas do WinThor: como levar para o Power BI sem pesar na operação

Por que o relatório nativo cansa

O WinThor entrega relatório pronto para a rotina operacional, e faz isso bem. O problema aparece quando a pergunta muda. Margem por cliente, comparação entre representantes, venda por hora do dia, mix por categoria: cada corte novo vira uma exportação e um trabalho manual de consolidação. No fim da semana alguém passou horas montando o que o sistema já tinha.

Há ainda um efeito silencioso. Quando o número circula em planilha, ele se descola da fonte. Duas áreas apresentam valores diferentes para a mesma pergunta, e a reunião vira discussão sobre qual planilha está certa em vez de sobre o resultado.

Onde a venda mora no WinThor

O WinThor roda sobre Oracle, e a venda está espalhada em poucas tabelas centrais. Conhecer essa estrutura é o que separa um painel que fecha com o ERP de um que quase fecha:

• PCPEDC — cabeçalho do pedido: cliente, data, representante, filial, condição de pagamento e situação.
• PCPEDI — itens do pedido: produto, quantidade, preço praticado e valores de desconto.
• PCCLIENT — cadastro de clientes, com praça, rede e classificação.
• PCPRODUT — cadastro de produtos, com departamento, seção e marca.
• PCEST — posição de estoque por filial, necessária para cruzar venda com disponibilidade.

Ler sem pesar na produção

A objeção mais comum — e ela é legítima — é que consultar a base vai deixar o ERP lento no horário de pico. Quatro cuidados resolvem a maior parte do risco:

• Usuário somente-leitura, criado só para isso. Nada é escrito na base de produção.
• Buscar apenas as colunas necessárias, em vez de varrer a tabela inteira.
• Filtrar por período na origem, e não trazer o histórico completo a cada carga.
• Rodar a carga em janela combinada com quem administra o ambiente, fora do horário crítico.

Com volume grande, o passo seguinte é a carga incremental: em vez de reprocessar tudo, trazer apenas o que mudou desde a última execução. O ganho é grande e o custo para o banco cai junto.

O que o painel precisa responder

Um painel de vendas que substitui o relatório não é um gráfico de faturamento. Ele precisa responder às perguntas que hoje geram exportação manual:

• Faturamento e margem por cliente, produto, representante e filial.
• Positivação: quantos clientes da carteira compraram no período, e quais deixaram de comprar.
• Mix: quantos itens diferentes entraram em cada pedido.
• Comparação com o mesmo período anterior, sem alguém montar a coluna à mão.
• Venda cruzada com estoque, para separar queda de demanda de falta de produto.

Margem merece atenção especial. Calculada só com preço de venda menos custo de tabela, ela mostra um lucro que não existe. Precisa considerar custo de reposição, imposto e desconto concedido — e essa regra tem que ficar escrita no modelo, não na cabeça de uma pessoa.

Quando o painel passa a ser usado de verdade

Painel morre por dois motivos. O primeiro é número que não bate com o ERP: basta acontecer uma vez para a confiança ir embora. O segundo é falta de documentação — quando quem construiu sai, ninguém sabe de onde vem cada valor nem como corrigir uma carga que falhou.

Por isso vale registrar, desde o começo, qual tabela alimenta cada indicador, qual filtro foi aplicado e o que fazer quando a atualização não concluir. É trabalho chato e é o que mantém o painel vivo depois do terceiro mês.