A conclusão vai direto ao ponto: quando os números de rastreamento somem entre o seu WMS e o sistema de etiquetas da transportadora (um clássico falha de sincronização de números de rastreamento do WMS), 90% das vezes a culpa não é do sistema de etiquetas. É o seu WMS que os perde. Já vi esse buraco exato três vezes em mais de 30 implantações de WMS. Durante a alta temporada de 2024, um armazém 3PL em Los Angeles que expedía cerca de 3,000 pedidos por dia atingiu uma taxa de perda de números de rastreamento de 2%. O atendimento ao cliente estava afogado. O sistema de etiquetas estava perfeitamente saudável. Os três vazamentos estavam todos do lado do WMS, sempre nos mesmos três pontos de ruptura: a etiqueta imprimia, mas o número nunca voltava; o número voltava, mas era associado ao pedido errado; o número estava correto no WMS, mas nunca chegava aos sistemas downstream. Este artigo mostra como encontrar e corrigir cada ponto de ruptura e fecha com um checklist para a noite de go-live que você pode copiar na íntegra.
Ponto de ruptura 1: a etiqueta imprime, o número de rastreamento nunca volta
Quando a perda é intermitente, olhe primeiro se o callback da etiqueta e a escrita de retorno ao WMS são assíncronos. Nove em cada dez vezes, aí está a resposta.
Naquele armazém 3PL, as perdas se concentravam entre 14h e 16h todos os dias: sumiam nos horários calmos e voltavam no pico. Os logs contaram a história: o sistema de etiquetas devolvia primeiro o PDF da etiqueta, e o número de rastreamento chegava depois por um callback assíncrono separado com timeout de 5 segundos. Nos horários de pico o sistema de etiquetas ficava lento, o callback chegava atrasado, e o WMS já tinha registrado "etiqueta criada". As etiquetas imprimiam bem, os pacotes saíam bem, e esses pedidos ficavam no WMS como "aguardando expedição" para sempre enquanto o atendimento não tinha nenhum número de rastreamento para dar.
A correção tem três passos, e nenhum é opcional. Primeiro, confirme separadamente a criação da etiqueta e a escrita de retorno do número: a chegada do PDF da etiqueta significa "etiqueta criada", mas só uma linha na tabela de expedições com número de rastreamento significa "número recebido". Guarde-os como dois campos de status separados, nunca um só. Segundo, torne os callbacks idempotentes com retentativas: o lado da etiqueta vai redisparar um callback quando a rede falhar, então o WMS precisa reconhecer duplicados; e quando um callback nunca chega, o WMS precisa ir buscar o número por conta própria em vez de esperar. Terceiro, adicione um job de polling de rede de segurança: a cada 15 minutos, varra todos os pedidos que têm etiqueta mas não têm número de rastreamento e consulte cada um contra o sistema de etiquetas. Esse job de polling é um salva-vidas — mais sobre ele abaixo.
Ponto de ruptura 2: o número volta, mas cai no pedido errado
Este ponto de ruptura é especialista em pedidos de múltiplos pacotes. O sistema de etiquetas devolve um array de números de rastreamento no nível do pacote: um pedido dividido em dois pacotes significa dois números de rastreamento. Mas muitas tabelas de expedição do WMS são no nível do pedido, uma linha por pedido, e o desenvolvedor pegou um atalho: agarrou o primeiro número do array, enfiou no cabeçalho do pedido e jogou o resto fora.
Em março de 2025, um armazém de e-commerce de artigos para casa caiu exatamente nesse buraco. Um cliente recebeu o primeiro pacote; o número de rastreamento do segundo pacote não existia em lugar nenhum do WMS. O atendimento consultou o número do primeiro pacote no site da transportadora, viu "entregue", e o cliente insistia que metade do pedido estava faltando. Depois de uma semana de discussão, descobriram que o segundo pacote ainda estava em trânsito — ninguém conhecia seu número de rastreamento. A correção é direta: a tabela de expedições precisa ser no nível do pacote. Um pedido com três itens em dois pacotes recebe dois registros de expedição, cada número de rastreamento ligado um a um ao seu pacote. Há um item do checklist para isso na noite de go-live: rode um pedido de teste de três itens em dois pacotes de ponta a ponta, e os dois números de rastreamento precisam ser recuperáveis no WMS.
Há um passo complementar na estação de embalagem: depois que a etiqueta vai para o pacote, o operador escaneia o código de barras da etiqueta com um scanner de mão, e o WMS verifica na hora se o número escaneado confere com o guardado no sistema. Três segundos por pacote. Ele pega o erro humilde mas fatal de etiquetas nos pacotes errados. Não pule para economizar tempo — uma troca custa mais em horas de atendimento do que um ano de escaneamento.
Ponto de ruptura 3: o WMS tem o número, mas o downstream nunca recebe
O WMS mostra todos os números de rastreamento presentes, mas o OMS e os canais de venda continuam mostrando brancos. Já vi esse buraco três vezes, e a causa raiz é idêntica toda vez: a API de push retornou HTTP 200, e o desenvolvedor tratou como sucesso.
Um 200 significa apenas "a requisição foi recebida", não "foi processada com sucesso". Num armazém, o WMS fazia push para o OMS, o OMS retornava 200, e o WMS marcava o pedido como "enviado". Mas a escrita no banco de dados do OMS tinha falhado — o erro estava no corpo da resposta, que o WMS nunca analisou. A taxa de perda era baixa, algumas dezenas de pedidos por mês, todos "falsos sucessos" desse tipo. Como encontrar: guarde o corpo completo da resposta de cada push nos logs, e varra semanalmente em busca de corpos contendo palavras-chave de erro. Como corrigir: o sucesso precisa ser julgado pelo status de negócio do outro lado — ou chame a API de consulta dele para uma segunda confirmação ou exija um comprovante de recebimento. Se uma segunda confirmação não for possível, no mínimo analise o corpo e dispare um alerta nas palavras-chave de erro.
A parte contraintuitiva: pare de adorar a sincronização em tempo real
Muitas equipes acreditam que a escrita de retorno via API em tempo real é a opção mais confiável — quanto mais em tempo real a cadeia, melhor. Depois de mais de 30 implantações, meu julgamento é o oposto: quanto mais elos uma cadeia em tempo real tem, maior a superfície de falha, e a falha de sincronização de números de rastreamento do WMS quase sempre nasce da crença de que "tempo real significa à prova de balas".
O trade-off é claro. Tempo real puro: baixa latência, mas qualquer tropeço no lado da etiqueta, na rede ou no WMS perde números, e você fica totalmente dependente da lógica de retentativa — que é exatamente o que tem mais chance de ser cortado antes do go-live. Tempo real mais reconciliação agendada: rode um job de reconciliação completa duas vezes ao dia, comparando cada pedido etiquetado no WMS com os registros de números de rastreamento do sistema de etiquetas, e preencha o que estiver faltando. A reconciliação fica algumas horas atrasada, mas a taxa de perda cai para quase zero. Minha recomendação é as duas: mantenha a escrita de retorno em tempo real e torne o job de reconciliação obrigatório. Leva cerca de dois dias-desenvolvedor para construir, e é a única coisa que deixa você dormir à noite.
A matemática deixa ainda mais claro. Com 3,000 pedidos por dia e uma taxa de perda de 2%, cerca de 60 pedidos por dia precisam de intervenção manual. Cada um — localizar o pedido, contatar o cliente, reemitir o número de rastreamento — leva cerca de 5 minutos. São cerca de 150 horas por mês, aproximadamente um terço de um atendente de customer service em tempo integral. Do outro lado: um job de reconciliação, dois dias-desenvolvedor, rodando automaticamente todo dia, empurrando as perdas para abaixo de 0.1%. A aritmética fala por si.
Checklist para a noite de go-live
| Verificação | Como | Critério de aprovação |
|---|---|---|
| Etiqueta criada e número recebido guardados separadamente | Inspecione os campos de status da tabela de expedições | Dois campos independentes, ambos obrigatórios |
| Idempotência do callback | Faça push do mesmo número de rastreamento duas vezes | O segundo push é reconhecido como duplicado, sem dados sujos |
| Busca ativa no timeout do callback | Corte os callbacks por 10 minutos | O WMS busca os números por conta própria, sem trabalho manual |
| Escrita de retorno completa para pedidos de múltiplos pacotes | Pedido de teste: 3 itens, 2 pacotes | Os dois números de rastreamento recuperáveis no WMS |
| Verificação por escaneamento na estação de embalagem | Observe o operador no local | O escaneamento do código de barras é o passo padrão |
| Pushes de falso sucesso | Leia os corpos de resposta do log de pushes | Palavras-chave de erro disparam alertas |
| Job de reconciliação agendado | Confira a configuração do agendador | Roda pelo menos duas vezes ao dia, comparação completa |
| Linha de base da taxa de perda | Meça diariamente na primeira semana | Acima de 0.5% significa análise de causa raiz no mesmo dia |
Já vi esse buraco três vezes, e toda vez a equipe pensou "as etiquetas estão imprimindo, terminamos" antes do go-live — depois a escrita de retorno dos números de rastreamento ensinou o contrário após o go-live. Lembre-se de uma frase: uma etiqueta impressa é só metade da integração. A integração termina quando o número de rastreamento pousa em segurança de volta no WMS e depois chega em segurança a cada sistema downstream.
Por Lin Xiao, Consultor de Implementação WMS
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
