Como integrar TMS, WMS e ERP ao Power BI

O dado da operação existe, mas ninguém confia nele#

Quem gerencia uma operação logística conhece a cena: o TMS diz uma coisa sobre o custo de frete, o WMS mostra outro número de ocupação de armazém e o ERP fecha o mês com um valor que não bate com nenhum dos dois. Cada sistema tem sua verdade e o resultado é reunião de conciliação em vez de decisão. Integrar TMS, WMS e ERP ao Power BI resolve esse problema: em vez de três relatórios que discordam, você constrói um modelo único de supply chain onde frete, estoque e financeiro conversam com as mesmas chaves e regras.

A questão raramente é o Power BI em si, que conecta em praticamente tudo. O problema é a camada que fica embaixo: como extrair dados de sistemas que muitas vezes rodam on-premises, como tratar EDI e documentos fiscais como o CTe, e como montar uma arquitetura que aguente o volume de uma operação real. Este artigo trata dessa engenharia, com honestidade sobre o que dá trabalho.

Por que logística é um caso difícil de integração#

Antes de falar de conector, vale entender por que o setor logístico é mais espinhoso que a média. Três características se somam.

Primeiro, a fragmentação de sistemas. É comum rodar um TMS de um fornecedor, um WMS de outro e um ERP de um terceiro, cada um com seu banco e seu modelo de dados. Nenhum foi desenhado para conversar com os outros.

Segundo, o volume transacional. Uma operação de distribuição gera milhões de linhas de movimentação, rastreamento e apontamento de entrega por mês. Isso muda a estratégia técnica: o que funciona para um dashboard financeiro de mil linhas quebra com cem milhões.

Terceiro, o dado externo obrigatório. Logística vive de troca eletrônica de documentos: EDI com embarcadores e clientes, e no Brasil o CTe (Conhecimento de Transporte eletrônico, modelo 57) e o MDFe. Esses dados chegam em XML ou em layouts posicionais, não em tabelas limpas. Ignorar qualquer um desses pontos trava o projeto depois do primeiro dashboard bonito.

Conectores nativos para integrar TMS, WMS e ERP ao Power BI#

O Power BI traz mais de uma centena de conectores nativos, e alguns caminhos cobrem a maioria dos cenários logísticos.

Se o TMS, WMS ou ERP usa banco SQL Server, Oracle, PostgreSQL ou MySQL, o conector nativo do respectivo banco é o caminho direto e preferido. Você lê da base ou, melhor ainda, de views desenhadas para consumo analítico. ERPs conhecidos no Brasil, como SAP, TOTVS Protheus e Oracle, expõem dados por banco, por API REST ou por camadas específicas como o conector de SAP HANA e o de SAP BW. Quando o sistema é SaaS e oferece API REST, o conector Web resolve, com a ressalva de que APIs paginadas e com OAuth exigem cuidado com performance e renovação de token.

O ponto honesto: conector nativo é ótimo para leitura, mas Power Query não é ferramenta de ETL pesado. Junção de milhões de linhas de três sistemas dentro do Power Query é lenta, frágil e difícil de manter. Conector resolve a extração; a transformação pesada precisa morar em outro lugar, e é aí que entra a camada de dados que veremos adiante.

O gateway on-premises é o que conecta a operação ao serviço#

A maioria dos TMS e WMS em operação no Brasil ainda roda em servidor local ou nuvem privada sem exposição pública, e o Power BI Service, que é nuvem, não enxerga esse banco sozinho. O componente que faz a ponte é o On-premises data gateway.

O gateway é um serviço instalado em um servidor dentro da rede do cliente. Ele mantém uma conexão de saída com o serviço da Microsoft, executa a consulta contra o banco local e devolve o resultado, sem abrir porta de entrada no firewall. Existe em modo standard, para uso corporativo compartilhado, e modo pessoal, para um único usuário.

Alguns pontos que decidem sucesso ou fracasso do gateway:

• Dimensionamento da máquina. O gateway consome CPU e memória para comprimir e transferir dados. Máquina subdimensionada é a causa número um de atualização lenta.
• Alta disponibilidade. Agrupar gateways em cluster evita depender de uma única instância. Em operação que roda 24 por 7, isso deixa de ser luxo.
• Localização. Instalar o gateway perto do banco, na mesma rede, reduz latência de forma expressiva.

Cenário da fonte	Componente indicado	Observação
Banco em servidor local (TMS/WMS on-premises)	On-premises data gateway (standard)	Cluster para alta disponibilidade
Fonte em rede virtual do Azure	VNet data gateway	Sem máquina para gerenciar
SaaS com API pública	Conector Web/REST, sem gateway	Cuidar de OAuth e paginação
Um único analista, prova de conceito	Gateway pessoal	Não usar em produção compartilhada

Tratar o gateway como peça de infraestrutura, com monitoramento e responsável definido, é parte de uma boa sustentação de BI, não um detalhe de instalação.

EDI e CTe: o dado que não vem pronto#

Aqui está a parte que os fornecedores de BI costumam esconder. EDI e documentos fiscais eletrônicos não chegam em formato analítico, e sim em XML ou em layout posicional definido por padrões como o EDIFACT.

No caso do CTe, cada documento é um XML assinado digitalmente, com dezenas de campos: emitente, tomador, valor da prestação, ICMS, peso, chave de acesso de 44 dígitos. Uma operação emite ou recebe milhares desses por dia, e transformar isso em tabela de fatos exige um passo de parsing antes de qualquer análise.

Existem três abordagens, em ordem crescente de robustez:

1. Parsing dentro do Power Query. Lê XML nativamente. Funciona para volume baixo, mas degrada rápido quando o número de documentos cresce.
2. Parsing em uma camada de processamento. Um pipeline no Azure lê os XML, extrai os campos relevantes e grava tabelas limpas. É a abordagem que escala.
3. Integração via ERP ou middleware fiscal. Muitas empresas já têm um sistema que recebe, valida e armazena CTe e NFe. Nesse caso, o BI lê do banco desse middleware e você evita reprocessar XML.

A recomendação de consultor é clara: se já existe um repositório fiscal confiável, leia dele. Reprocessar XML no BI só se justifica sem alternativa, e o parsing pesado deve sempre ficar na camada de dados, nunca no relatório.

A camada de dados no Azure ou no Fabric é o que sustenta tudo#

Conectar direto os três sistemas no Power BI funciona na demonstração e falha na operação. O padrão maduro é interpor uma camada de dados entre as fontes e o relatório, com três funções: consolidar as extrações, aplicar as transformações pesadas e servir um modelo limpo e único.

Há dois caminhos principais no ecossistema Microsoft, e eles não são excludentes. O caminho Azure clássico usa Azure Data Factory ou Synapse para orquestrar a extração, Azure Data Lake Storage para guardar os dados brutos e tratados, e um Azure SQL como camada de servir. É maduro, flexível e bem documentado. O caminho Microsoft Fabric, plataforma de dados unificada anunciada pela Microsoft em 2023, junta ingestão, armazenamento no OneLake, transformação e Power BI sob uma mesma capacidade. Para quem está começando a arquitetura agora, o Fabric reduz o número de peças a integrar. Vale entender melhor antes de decidir se o Fabric compensa no seu caso.

Uma organização em camadas, no estilo medalhão, ajuda a manter ordem em qualquer dos caminhos:

Camada	Conteúdo	Papel na logística
Bronze	Dados brutos, como vêm do TMS, WMS, ERP e dos XML de CTe	Histórico fiel, sem transformação
Prata	Dados limpos, tipados, com chaves conciliadas	Junção de frete, estoque e financeiro
Ouro	Modelo dimensional pronto para consumo	Tabelas de fato e dimensão do supply chain

O Power BI conecta na camada ouro. Com o Fabric, o modo Direct Lake permite que o Power BI leia as tabelas diretamente do OneLake, sem importar nem fazer DirectQuery tradicional, combinando desempenho de importação com dado atualizado. É um recurso específico do Fabric e depende de as tabelas estarem no formato adequado. Montar essa camada é trabalho de engenharia de dados, não de quem faz o dashboard. Confundir os dois papéis é outra fonte clássica de projeto que não sustenta.

O modelo único de supply chain: onde a integração vira decisão#

Extrair e servir os dados só tem valor se o modelo final for coerente. O objetivo é um esquema estrela onde as três origens compartilham dimensões conformadas: tempo, cliente, produto, filial e transportadora, ligadas a tabelas de fato distintas. Fato de frete do TMS, fato de movimentação e ocupação do WMS, fato financeiro e de faturamento do ERP. Quando o cliente é o mesmo em todas, uma única dimensão de cliente conecta as três, e aí você responde perguntas que nenhum sistema isolado responde: custo de frete por real faturado, ou giro de estoque cruzado com prazo médio de entrega.

Dois pontos técnicos merecem atenção. O motor VertiPaq, que roda por trás do Power BI, comprime os dados coluna a coluna, e a taxa de compressão depende fortemente da cardinalidade de cada coluna. Colunas de altíssima cardinalidade, como a chave de acesso de 44 dígitos do CTe ou timestamps com segundos, incham o modelo. A boa prática é separar data e hora, evitar identificadores que não serão usados em análise e reduzir cardinalidade sempre que possível. O segundo ponto são as medidas: custo por entrega, ocupação média, OTIF e prazo médio precisam ser medidas em DAX bem escritas, seguindo boas práticas de modelagem, não colunas calculadas espalhadas.

Licenciamento e capacidade: o que realmente pesa na conta#

Vale ser honesto sobre custo. O Power BI tem licenças por usuário, Pro e Premium Per User (PPU), e capacidades dedicadas. As capacidades Premium tradicionais aparecem como SKUs P1 a P5, e o Fabric mede consumo em Capacity Units, com SKUs de F2 a F2048. Quanto maior o número, maior a capacidade e o custo.

Para operação com volume alto e muitos consumidores, capacidade dedicada costuma sair mais barata e previsível que licenciar Pro para centenas de pessoas, além de habilitar o Direct Lake. Preços mudam com frequência e variam por contrato e região, então trate qualquer valor como faixa aproximada e confirme na fonte oficial da Microsoft. Um discovery e assessment bem feito evita tanto o subdimensionamento que trava a operação quanto o superdimensionamento que queima orçamento.

Governança e LGPD não são etapa final#

Dado logístico carrega informação pessoal: nome e endereço de destinatário, CPF em notas, dados de motorista. Isso coloca o projeto sob a Lei nº 13.709/2018, a LGPD. Definir quem acessa o quê, aplicar segurança em nível de linha quando necessário e manter trilha de auditoria não são opcionais, são requisito, e parte central de qualquer trabalho de governança de dados.

Um roteiro realista de implantação#

Para fechar a parte técnica, a sequência que costuma dar certo:

1. Mapear as fontes: qual banco, onde roda cada sistema, qual o volume real.
2. Definir a arquitetura da camada de dados, Azure clássico ou Fabric, em bronze, prata e ouro.
3. Instalar e dimensionar o gateway para as fontes on-premises.
4. Resolver EDI e CTe, lendo do repositório fiscal quando existir.
5. Construir o modelo dimensional único com dimensões conformadas.
6. Escrever as medidas DAX e publicar sobre capacidade adequada.
7. Aplicar governança, segurança de linha e monitoramento antes de liberar.

Pular etapas para entregar um dashboard rápido quase sempre cobra a conta depois, na forma de números que não batem e retrabalho.

Perguntas frequentes#

Preciso de Microsoft Fabric para integrar TMS, WMS e ERP ao Power BI?

Não. Dá para integrar com Azure Data Factory, Data Lake e Azure SQL, uma arquitetura madura. O Fabric simplifica por unir as peças numa capacidade só e habilita o Direct Lake, mas é uma escolha de arquitetura, não um pré-requisito.

O gateway on-premises é seguro?

Sim. O gateway não abre porta de entrada no firewall: estabelece uma conexão de saída com o serviço da Microsoft, com tráfego criptografado, e as credenciais das fontes ficam cifradas. O cuidado maior é operacional: dimensionar a máquina, manter atualizado e usar cluster para operações críticas.

Consigo trazer CTe e EDI direto para o Power BI?

Tecnicamente sim, porque o Power Query lê XML. Na prática, para volume real, isso fica lento e frágil. O recomendado é ler de um repositório fiscal que já processou os documentos, ou fazer o parsing numa camada de dados no Azure ou Fabric.

Por que meu modelo fica lento mesmo com poucos usuários?

Geralmente por causa da cardinalidade. O VertiPaq comprime por coluna, e colunas de altíssima cardinalidade, como chaves de CTe de 44 dígitos e timestamps completos, incham o modelo. Reduzir cardinalidade, remover colunas não usadas e separar data de hora resolve boa parte do problema.

Quanto tempo leva um projeto desses?

Varia com a quantidade de fontes, o estado dos dados e a maturidade da infraestrutura. Um piloto com uma origem principal costuma andar em poucas semanas. A integração completa das três origens, com EDI, CTe e governança, é um projeto maior. Um discovery inicial dá a estimativa realista.

Onde isso te leva#

Integrar TMS, WMS e ERP ao Power BI é menos sobre conectar caixinhas e mais sobre construir uma fundação de dados confiável embaixo do relatório. Conector, gateway, tratamento de EDI e CTe, camada no Azure ou Fabric e um modelo único de supply chain: cada peça existe para que a operação pare de discutir de quem é o número certo e comece a decidir com base nele. Se a sua vive de conciliar planilhas entre sistemas, a fundação está faltando. Fale com a gente e vamos desenhar a arquitetura certa para o seu caso.