Power BI com TOTVS Protheus: como integrar compras, estoque e financeiro

Como integrar Power BI com TOTVS Protheus para acompanhar compras, estoque e financeiro em um único painel? O caminho mais confiável é extrair os dados diretamente do banco do Protheus, via ODBC, DirectQuery ou uma camada intermediária, e construir um modelo semântico que cruze as três áreas pelas mesmas chaves: filial, produto e fornecedor. O desafio raramente é conectar o Power BI ao ERP, a ferramenta suporta isso nativamente. O desafio é modelar dados de três módulos que nasceram para registrar transações, não para responder perguntas de gestão.

Quais caminhos existem para conectar o Power BI ao Protheus?

• Conexão direta ao banco de dados: via ODBC ou DirectQuery, lendo as tabelas nativas do Protheus. É o método mais rápido de implementar e o que melhor sustenta atualização automática, mas exige que o time de TI libere acesso de leitura e que a base transacional aguente as consultas do painel.
• API REST ou rotina TLPP customizada: o Protheus pode expor endpoints próprios ou ser customizado para publicar dados já tratados. Faz sentido quando o time de TI não libera acesso direto ao banco ou quando é preciso aplicar regra de negócio antes da extração.
• Camada intermediária, data warehouse ou data lake: os dados do Protheus são replicados para um ambiente próprio antes de chegar ao Power BI. É o caminho mais robusto para empresas com múltiplos ERPs, várias filiais ou alto volume, porque tira a carga de consulta do banco transacional.

Na maioria dos projetos de médio porte, a conexão direta ao banco resolve compras, estoque e financeiro sem custo adicional de infraestrutura. A camada intermediária só se justifica quando o volume de dados ou o número de sistemas de origem cresce além do que uma consulta direta sustenta com performance aceitável.

Por que compras, estoque e financeiro pedem um modelo único, não três painéis soltos?

Cada módulo do Protheus registra a mesma operação sob um ângulo diferente. O pedido nasce em Compras, gera o saldo de entrada em Estoque e, mais adiante, o título a pagar em Financeiro. Analisados separadamente, cada painel parece consistente, e os três juntos contam histórias diferentes sobre a mesma compra, porque cada área herda variação cambial, arredondamento de imposto e prazo de conciliação em momentos distintos do fluxo. Uma chave única entre pedido, item recebido e título financeiro é o que evita esse tipo de divergência; sem ela, cada painel responde uma pergunta diferente com a mesma etiqueta.

Um cenário ilustrativo, e não um case real, dá escala ao problema. Imagine uma distribuidora com Protheus, três filiais e um time de dois compradores. Premissas: 1.200 pedidos de compra por mês, cruzados com saldo de estoque por filial e título a pagar por fornecedor. Sem chave única entre as três tabelas, o financeiro reportava R$ 340 mil em contas a pagar do mês, enquanto compras via R$ 355 mil em pedidos emitidos no mesmo período, uma diferença de 4,4%, explicada por pedidos ainda em trânsito e por desconto financeiro aplicado só na baixa do título. Depois de modelar os três módulos por um identificador comum de pedido e fornecedor, a diferença passou a ser rastreável linha a linha, em vez de virar discussão em reunião.

Quais tabelas do Protheus costumam entrar nesse tipo de projeto?

• SB1 e SB2: cadastro de produtos e saldo de estoque por filial e armazém, a base do painel de estoque.
• SC7: pedidos de compra, com quantidade solicitada, recebida e saldo em aberto.
• SA2: cadastro de fornecedores, usado para cruzar desempenho de entrega e concentração de compra.
• SE2 e SF1/SD1: títulos a pagar e notas fiscais de entrada, que fecham o ciclo financeiro do pedido.

A nomenclatura exata varia conforme a versão do Protheus e as customizações de cada empresa, por isso o mapeamento das tabelas é sempre uma etapa de diagnóstico, não um dicionário genérico aplicado de cabeça.

O que costuma travar essa integração na prática?

• Performance no banco transacional: consultas pesadas direto na base de produção podem concorrer com a operação do Protheus em horário de pico, por isso é comum agendar a atualização fora do horário comercial ou usar uma réplica.
• Multiempresa e multifilial mal configurados: quando o código de filial não é tratado como chave em todas as tabelas, o mesmo produto aparece duplicado ou o saldo de uma filial soma na outra.
• Campos customizados: implantações antigas de Protheus acumulam colunas e tabelas próprias criadas ao longo dos anos, que não aparecem em documentação padrão e só são descobertas ao validar os números com a área.
• Arredondamento e moeda: diferenças de centavos entre o valor do pedido, da nota fiscal e do título a pagar são normais no fluxo operacional, mas quebram uma conciliação automática se não forem tratadas com tolerância.

Esses pontos custam menos tempo quando mapeados antes da modelagem do que quando descobertos depois do painel publicado. Já detalhamos os blocos de custo desse tipo de projeto em Quanto custa implementar Power BI em compras e estoque, e o racional vale também para um painel que cruza financeiro: o investimento varia com o número de fontes e a complexidade das regras validadas com a área, não com o tamanho do ERP em si.

Se a sua operação já roda em TOTVS Protheus e a dúvida é por onde abrir esse acesso e quais tabelas priorizar primeiro, o caminho mais direto é avaliar o cenário do ERP com quem já mapeou esse tipo de ambiente antes. É o que fazemos no diagnóstico gratuito de Engenharia de Dados: levantamos as tabelas e módulos disponíveis, os acessos que precisam ser liberados, e devolvemos um escopo com prazo e investimento estimado antes de qualquer contratação.