Vou dar o veredito logo de cara: quando os números de pedido não batem entre os seus sistemas, a integração quase nunca está quebrada. O que está quebrado é a tabela de mapeamento que ninguém possui.
Outono de 2023: um 3PL de vestuário de mais de 60.000 pés quadrados nos arredores de Ontario, Califórnia. A chefe de atendimento ao cliente me chamou: a equipe dela estava se afogando em tickets de «onde está meu pedido?». A loja mostrava todos os pedidos como enviados, mas ao clicar no número de rastreamento aparecia «envio inexistente» — ou pior, o pacote de outra pessoa. A TI passou uma semana nos logs e todas as interfaces estavam verdes: OMS, WMS, APIs das transportadoras, zero erros.
Três meses antes, um upgrade do WMS havia mudado a forma de gerar os números de pedido filho após uma divisão. Ninguém avisou o lado do OMS, que continuou montando os IDs do jeito antigo. Quando os números de rastreamento voltaram da transportadora, a lógica de write-back os associava aos pedidos adivinhando pela cadeia do ID: adivinhou errado, e um número de rastreamento caía no pedido errado. Os canos estavam bem; o que quebrou foi a suposição de que um ID num sistema significa a mesma coisa em outro.
Vi esse filme pelo menos dez vezes em vinte anos, e o momento da descoberta em Ontario mostra por que os logs verdes mentem. O líder de TI pegou um pedido problemático e percorremos juntos, tela por tela: o OMS dizia pedido 88412, enviado, com número de rastreamento anexado. O WMS dizia que o pedido 88412 havia sido dividido em duas separações filhas — mas as filhas estavam numeradas no novo esquema, 88412-A e 88412-B, enquanto o write-back do OMS continuava associando pelo padrão antigo, 88412-01 e 88412-02. Os números de rastreamento tinham voltado para casa direitinho — pendurados em números de pedido que não existiam mais em lugar nenhum. Cada API tinha feito seu trabalho; o contrato sobre a aparência de um ID tinha sido reescrito de um lado e nunca reasssinado do outro.
A cadeia se rompe em três pontos previsíveis
A jornada de um pedido tem quatro paradas — o pedido pai no OMS, as separações e os pacotes no WMS, as etiquetas e o rastreamento no TMS e na transportadora, o write-back de status para o OMS — e três costuras previsíveis.
Primeiro, os envios divididos. No OMS, um pedido é um número. Dentro do WMS ele se divide em duas ondas e três pacotes conforme a localização do estoque — e esses números filho vivem apenas no WMS. O OMS nem sabe que os filhos existem. Os números de rastreamento voltam endereçados ao pai, e quem busca pelo número do filho não encontra nada. A variante mais perversa é o envio parcial: três pacotes, duas transportadoras, o terceiro sem estoque. O OMS marca o pai inteiro como «concluído» — o cliente recebe duas caixas, e o terceiro número de rastreamento vira órfão.
Segunda costura: o write-back do rastreamento. A transportadora emite o número de rastreamento, o TMS o captura — e então o write-back o aponta para o pedido errado. O clássico: uma etiqueta sai mal impressa, alguém a reimprime, o número de rastreamento antigo nunca é anulado — agora dois números ativos apontam para um mesmo pacote. O cliente e o atendente rastreiam cada um o seu. Todos estão certos e todos estão errados.
Terceira costura: os lotes e os paletes, e esta pertence ao público B2B. Os varejistas exigem um aviso antecipado de envio 856, e o número de série SSCC-18 do palete físico precisa coincidir caractere por caractere com o número em nível de pacote no ASN — um dígito errado e o palete inteiro é rejeitado. Já vi um armazém gerar os IDs de palete automaticamente no WMS enquanto o aviso de envio 945 era digitado à mão. Esses dois números nunca foram a mesma coisa. Explodiu três meses depois na conciliação, e os chargebacks teriam comprado uma bela empilhadeira.
As integrações movem dados; as tabelas de mapeamento fazem os dados concordar — e o segundo trabalho é onde os corpos estão enterrados.
Também há uma armadilha no fluxo de devoluções: um pacote é recebido no armazém contra um número de RMA, mas o reembolso no OMS pendura-se no número do pedido original. Sem um mapeamento de RMA para pedido, o financeiro termina com reembolsos órfãos. O pior caso que vi: centenas de reembolsos sem conciliação num único mês, a operação passando uma semana inteira conciliando à mão.
Torne a tabela de mapeamento monótona
Meu método de rastreamento é um único movimento: percorrer a cadeia, sem pular. Primeiro descubra se o ID é pai ou filho, e qual sistema o gerou. Caminhe para frente um salto de cada vez; o salto em que o ID deixa de se conectar é a sua ruptura. Nove em cada dez vezes, você a encontra no segundo salto.
Antes de corrigir os dados, três perguntas. Este mapeamento foi escrito por um sistema ou digitado por uma pessoa? Alguma regra mudou recentemente? Quantos mais estão quebrados do mesmo jeito? Corrigir um registro é apagar incêndio. Corrigir o lote é diagnosticar. Naquele caso de Ontario escrevemos um script que pendurou de volta cada número de rastreamento mal mapeado dos três meses anteriores — mais de quatro mil pedidos numa única passada. Clicar um por um teria mantido o atendimento ocupado até o ano que vem.
Depois, o endurecimento. Cinco regras, cada uma paga com mensalidade.
Uma tabela canônica. De pedido para filho, de filho para pacote, de pacote para etiqueta, de etiqueta para número de rastreamento, dali para lote e palete — tudo numa única tabela de mapeamento, dentro de um sistema, com um responsável nomeado e um registro de alterações. Toda tabela de mapeamento que vi apodrecer tinha o mesmo problema de organograma: a equipe do OMS achava que a equipe do WMS era dona, a equipe do WMS achava que o analista EDI do 3PL era dono, e o analista achava que era «só uma referência». Ponha um nome nela — alguém que revise o registro de alterações todo mês e participe de cada upgrade, onboarding de transportadora e mudança de especificação de varejista. O incidente de Ontario aconteceu porque um upgrade do WMS chegou com uma nota de release que ninguém do lado do OMS leu — um responsável teria pego numa revisão de diff de cinco minutos.
Dê namespace aos seus IDs. Prefixe cada ID com seu sistema de origem para que um número nascido no WMS nunca possa colidir com um nascido no OMS. Soa tosco; já me salvou três vezes. Dois sistemas adoram inteiros autoincrementais simples, e sem prefixos eles vão colidir — já vi os pedidos de dois clientes 3PL fluírem para um mesmo WMS, ambos começando em 10001, e o sistema pendurar os pacotes do cliente A nos pedidos do cliente B. Um palete inteiro enviado para o cliente errado.
Devolva o ID do pacote em eco. Quando um número de rastreamento volta para casa, ele precisa carregar o ID do pacote com que saiu. Uma cadeia de rastreamento pelada não se rastreia para trás — reimprima uma etiqueta duas vezes e boa sorte adivinhando a qual pedido do OMS pertence o número de rastreamento. O 856 já tem a estrutura para isso — segmentos REF carregando o número de rastreamento como referência de conhecimento de embarque junto com o da própria transportadora. Use-a.
Concilie diariamente. Rode um job agendado: enviado no WMS, pendente de atualização no OMS, com eventos de rastreamento da transportadora. Compare os três conjuntos — o que cair no fosso é pelo que o atendimento vai levar bronca amanhã. Três baldes: enviado no WMS mas nunca atualizado no OMS — write-back perdido; atualizado no OMS mas sem eventos da transportadora — etiqueta impressa, mercadoria nunca se moveu; eventos da transportadora sem registro de nenhum lado — geralmente etiquetas de teste ou números obsoletos de reimpressões. Classifique primeiro, aja depois.
Versione sua lógica de divisão: teste cada mudança de regra de divisão contra o mapeamento primeiro num ambiente de testes. Uma verificação de dois minutos, atrasada três meses.
Um trade-off para decidir logo de cara: callbacks da transportadora em tempo real versus conciliação em lote para o write-back do rastreamento. O tempo real é rápido, mas custa mais e os callbacks caem. O lote chega com meio dia de atraso e é sólido como rocha. Operações pequenas deveriam rodar em lote sem vergonha e ligar o tempo real duas semanas antes da alta temporada. O que você economizar não vai cobrir a hora extra do incêndio das 2 da manhã.
E mais um «descompasso» que não é problema de ID nenhum: o tempo. O WMS carimba os envios em horário do Pacífico, o OMS interpreta em UTC, e o mesmo pedido cai em dias diferentes de cada lado. Os atendentes buscam os «envios de hoje», não encontram nada e assumem que o ID se perdeu. Armazéns que atravessam fusos horários pisam nessa constantemente: confira os relógios antes de conferir os IDs.
Então aqui vai minha pergunta para você: vá perguntar à sua equipe de TI quando foi a última vez que alguém abriu a tabela de mapeamento de ID. Se a resposta for «na última vez que algo quebrou», a próxima ruptura já está a caminho.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
