ERP, WMS e TMS: como integrar os dados para acompanhar o pedido até a entrega

Acompanhar um pedido até a entrega com dados do ERP, do WMS e do TMS exige três coisas: uma lista comum de eventos (pedido criado, liberado, separado, conferido, faturado, embarcado e entregue), identificadores que liguem o mesmo pedido nos três sistemas (número do pedido, chave de acesso da NF-e, número da carga e conhecimento de transporte) e pontos de conciliação que confiram se quantidades e datas batem na passagem de um sistema para o outro. Cada sistema enxerga só um trecho do caminho. A integração ERP WMS TMS junta esses trechos em uma linha do tempo única por pedido, e é essa linha do tempo que permite dizer onde o pedido está agora e em qual etapa ele perdeu tempo.

Por que juntar os dados dos três sistemas não é trivial?

Cada sistema trabalha com o próprio documento e a própria granularidade. O ERP pensa em pedidos e linhas de pedido. O WMS pensa em ondas e tarefas de separação, e uma onda pode reunir dezenas de pedidos, assim como um pedido grande pode virar várias tarefas em endereços diferentes. O TMS pensa em cargas e paradas, e uma carga leva notas de vários clientes. A relação entre os documentos raramente é de um para um: um pedido faturado em duas vezes gera duas notas, e cada nota pode sair em uma carga diferente. Quem tenta juntar tudo pelo número do pedido costuma descobrir que o TMS nem recebe esse número.

Quais eventos registrar do pedido até a entrega?

1. 1.Pedido criado (ERP): data e hora de entrada e data prometida ao cliente.
2. 2.Pedido liberado (ERP): fim da análise de crédito e da aprovação comercial.
3. 3.Pedido recebido pelo WMS: o momento em que a ordem chega ao armazém. É o evento que mais falta nos projetos, e é justamente onde muitos pedidos ficam parados sem que ninguém perceba.
4. 4.Separação iniciada e concluída (WMS): com a quantidade separada por linha e eventuais cortes por falta de saldo no endereço.
5. 5.Conferência e embalagem (WMS): volumes, peso e divergências encontradas.
6. 6.Faturamento (ERP): emissão da NF-e, com número e chave de acesso.
7. 7.Embarque (TMS ou WMS): carga montada, transportadora e saída do veículo.
8. 8.Entrega ou ocorrência (TMS): data e hora do comprovante, ou o motivo da falha, como cliente ausente, recusa ou avaria.

Cada evento precisa de data e hora completas, do sistema de origem e do número do documento naquele sistema. A forma mais robusta de guardar isso é uma tabela de eventos, com uma linha por evento, em vez de uma tabela de pedidos com uma coluna para cada data. A tabela de eventos aceita sem esforço o que a outra não comporta: faturamento parcial, segunda tentativa de entrega, pedido que volta para a separação depois de uma divergência na conferência.

Quais identificadores ligam o mesmo pedido nos três sistemas?

• Número do pedido de venda: nasce no ERP e deve acompanhar toda ordem enviada ao WMS. Se o WMS gera um número próprio, o de-para entre os dois precisa ficar gravado.
• Número da onda ou ordem de separação: liga as tarefas do armazém aos pedidos que elas atendem.
• Chave de acesso da NF-e: tem 44 dígitos e é única no país. ERP e TMS costumam conhecê-la, o que faz dela a melhor ponte entre faturamento e transporte.
• Número da carga ou romaneio: agrupa as notas que saíram no mesmo veículo.
• CT-e: o conhecimento de transporte eletrônico emitido pela transportadora referencia as chaves das notas transportadas e liga o frete cobrado às entregas.
• Código do cliente e do local de entrega: necessário para conferir paradas e janelas de recebimento.

Na prática, a cadeia mais estável é pedido para nota, dentro do ERP, e nota para carga e entrega, dentro do TMS, usando a chave da NF-e como elo. O trecho mais frágil costuma ser o anterior ao faturamento: WMS que não guarda a linha do pedido original, ajustes manuais de quantidade que não voltam ao ERP, pedidos reenviados ao armazém com número novo.

Em que pontos conferir se os sistemas concordam?

• ERP x WMS na liberação: todo pedido liberado no ERP chegou ao WMS? Pedido liberado há mais de duas horas sem ordem no armazém indica falha na integração ou fila parada.
• WMS x ERP na quantidade: a quantidade separada e conferida é igual à faturada, linha a linha? Diferenças apontam corte de separação não comunicado ao ERP ou nota emitida para item que não saiu.
• ERP x TMS no faturamento: toda NF-e com entrega prevista entrou em uma carga? Nota sem carga depois de um prazo combinado está parada na doca, esquecida ou foi retirada pelo cliente sem registro.
• TMS x ERP no frete: o valor do CT-e bate com o frete previsto na venda ou na tabela da transportadora?
• Fechamento da entrega: notas entregues no TMS e ainda abertas no ERP, ou com ocorrência e sem nova tentativa programada.

Cada conciliação deve gerar uma lista de exceções com responsável, e não apenas um percentual no painel. Um indicador de 98% de pedidos integrados parece bom até alguém perguntar quais são os 2% e quanto tempo eles estão parados.

Como isso aparece em números?

Os números a seguir descrevem uma operação hipotética, montada para ilustrar o raciocínio. Não vêm de nenhum cliente nem de projeto da Insight Pro. Uma distribuidora liberou 1.200 pedidos em uma semana, e 90 deles chegaram ao cliente depois da data prometida. O relatório de entregas, que só cruzava a data de faturamento com a data de entrega informada pela transportadora, atribuía quase todos os atrasos ao transporte.

Com a linha do tempo de eventos montada, a leitura muda. Dos 90 pedidos atrasados, 24 ficaram mais de um dia entre a liberação no ERP e a chegada ao WMS, porque traziam itens cadastrados sem endereço de armazenagem, e a integração rejeitava a ordem sem avisar ninguém. Outros 7 esperaram a liberação de crédito. Mais 22 foram faturados e passaram mais de 24 horas sem carga montada no TMS. Os 37 restantes atrasaram de fato no transporte. O transporte responde por 41% dos atrasos, e não pela quase totalidade. Os 24 pedidos presos na integração teriam aparecido na conciliação ERP x WMS duas horas depois da liberação, e não quando o cliente ligou reclamando.

Com os eventos e as conciliações no lugar, o OTIF pode ser aberto por etapa, como descrevemos em OTIF: como calcular corretamente e descobrir por que as entregas falham. Sem a integração, a análise por etapa fica limitada ao trecho que um único sistema enxerga.

Como montar a integração na prática?

1. 1.Mapear onde cada evento já existe: tabelas do ERP, logs do WMS, API ou banco do TMS, portal ou arquivos da transportadora. Às vezes o evento simplesmente não é registrado, como a hora de saída do veículo anotada só no papel da portaria.
2. 2.Definir as chaves e corrigir a origem: exigir o número do pedido nas ordens do WMS e a chave da NF-e nas cargas do TMS resolve mais do que qualquer regra de cruzamento aproximado feita depois.
3. 3.Extrair em carga incremental: levar os dados de cada sistema para uma camada central (data warehouse ou lakehouse), guardando o dado bruto como veio.
4. 4.Padronizar a tabela de eventos: pedido, documento, tipo de evento, data e hora, sistema de origem. Cuidado com fusos horários: sistemas de transportadoras às vezes gravam em UTC enquanto o ERP grava no horário local.
5. 5.Programar as conciliações: regras que rodam a cada carga de dados e gravam as exceções com data de detecção.
6. 6.Publicar painel e alertas: acompanhamento por pedido, cliente e transportadora no Power BI, e alertas para as exceções que vencem o prazo.

Para acompanhamento operacional, atualizar a cada 15 ou 30 minutos costuma ser suficiente. Integração em tempo real tem custo maior e só se justifica quando alguém vai agir no mesmo minuto, como numa central de monitoramento de entregas.

O que costuma travar esse tipo de projeto?

• Transportadoras sem integração: o evento de entrega depende de cada transportadora enviar o status, por API, arquivo EDI no padrão Proceda (como o OCOREN, de ocorrências de entrega) ou até planilha. Vale começar pelas que levam a maior parte do volume.
• Datas sobrescritas: sistemas que atualizam o status sempre no mesmo campo apagam a data do evento anterior. Sem log ou fotografia diária, o histórico se perde.
• Hora do evento x hora do registro: a entrega feita às 16h e baixada pelo motorista no dia seguinte precisa guardar as duas datas, ou o atraso aparece onde não existiu.
• Cadastros desalinhados: produto, cliente e endereço com códigos diferentes no ERP e no WMS impedem o cruzamento antes mesmo de chegar às datas.
• Exceção sem dono: conciliação que gera lista e ninguém trata vira mais um relatório ignorado em poucas semanas.

Se hoje responder "onde está o pedido?" exige abrir três sistemas e ligar para a transportadora, a lacuna está na integração dos dados, e um painel novo sozinho não resolve. No diagnóstico gratuito de integração de dados da Insight Pro, parte do serviço de Engenharia de Dados, localizamos em quais tabelas e arquivos do seu ERP, WMS e TMS estão os eventos do pedido, testamos as chaves que ligam os três sistemas com uma amostra real de pedidos e apontamos quais conciliações já são possíveis e quais lacunas precisam ser corrigidas na origem. O mapa de eventos e chaves que sai desse trabalho fica com a sua equipe, siga ou não para um projeto.