O pedido 88214 foi faturado duas vezes. Mesma quantidade, mesmo cliente, mesma data — dois documentos. Ninguém digitou duas vezes, ninguém errou de tela. A integração com a transportadora respondeu duas vezes, e o sistema acreditou nas duas.

Esse é o defeito mais chato da operação de distribuição, porque ele não quebra nada. O processo segue, o caminhão sai, a nota é emitida. O erro aparece depois — na conciliação, no estoque negativo, ou no telefonema do cliente perguntando por que recebeu cobrança dobrada.

Por que a mensagem chega duas vezes

Não é defeito exótico. É o comportamento normal de qualquer transporte que não pode garantir entrega exatamente uma vez.

O tempo limite que não é fim. A transportadora manda a confirmação, sua API demora a responder, o tempo limite estoura do lado dela. Ela reenvia. Mas a primeira chegou e foi processada — só a resposta se perdeu no caminho.

A repetição automática. Toda fila séria repete em caso de falha. Se a falha é na resposta e não no processamento, a repetição vira duplicata.

O reprocessamento manual. Alguém vê a mensagem em erro, corrige e manda de novo — sem saber que a original tinha passado.

Os dois canais. A mesma informação chegando por arquivo e por API, cada uma com seu horário, porque a migração de um para o outro nunca foi concluída.

A solução tem nome e é mais simples do que parece

Chama-se chave de idempotência: um identificador que a origem gera e repete em toda reenvio da mesma operação. Quem recebe guarda a chave, e quando ela volta, responde “já processei” em vez de processar de novo.

A parte difícil não é o conceito. É acordar com o parceiro qual campo é a chave — e essa conversa quase nunca acontece.

Uma verificação que costuma render no dia seguinte, direto na base:

-- mesma remessa, mesmo parceiro, mensagens diferentes
SELECT a.docnum, b.docnum, a.mestyp, a.rcvprn,
       a.credat, a.cretim, b.credat, b.cretim
  FROM edidc AS a
  JOIN edidc AS b ON  b.mestyp = a.mestyp
                  AND b.rcvprn = a.rcvprn
                  AND b.docnum > a.docnum
 WHERE a.status = '53'
   AND b.status = '53'
   AND a.credat >= '20260801'
 ORDER BY a.credat, a.cretim;

O resultado quase nunca é vazio, e boa parte é legítima — o mesmo tipo de mensagem para o mesmo parceiro acontece o tempo todo. O que interessa são os pares com poucos segundos ou minutos de diferença, porque duplicata de repetição tem assinatura temporal: ela chega colada.

O que dá errado, com nome

Deduplicar pelo campo errado. Usar número do pedido como chave falha quando o mesmo pedido tem, legitimamente, duas remessas parciais. A chave precisa identificar a operação, não o documento de negócio.

Deduplicar só na janela curta. Guardar as chaves das últimas duas horas resolve a repetição imediata e não resolve o reprocessamento manual, que acontece no dia seguinte. A janela precisa cobrir o comportamento humano, não só o da fila.

Tratar como erro em vez de estado. Mensagem repetida não é falha — é o esperado. Se ela cai na fila de erro, alguém vai reprocessá-la e criar a terceira cópia.

Descobrir pela reclamação do cliente. É o custo mais alto e o mais comum. A duplicata existe há semanas, encostada, e a primeira pessoa a notar está do lado de fora.

Onde a IA ajuda de verdade aqui

A deduplicação em si é regra determinística e deve continuar sendo — ninguém quer um modelo decidindo se dois pedidos são o mesmo. Mas três partes caras do trabalho são leitura e comparação.

Achar os pares suspeitos no histórico. Varrer meses de mensagens e propor quais pares têm assinatura de duplicata é comparação em volume, com critério observável.

Ler o layout do parceiro e apontar o candidato a chave. Documentação de integração é longa e a parte que interessa são dois campos. É o mesmo raciocínio que aplicamos em observar o ciclo bancário antes de automatizar.

Explicar por que aquela mensagem específica falhou. Cruzar o erro com o histórico do parceiro encurta a investigação.

Onde ela não entra: cancelar documento, estornar faturamento e decidir o que fazer com a carga que já saiu. Essas três continuam com gente.

O limite honesto

Idempotência bem feita elimina a duplicata técnica. Ela não elimina a duplicata de negócio — o cliente que realmente pediu duas vezes, o vendedor que lançou o mesmo pedido em dois canais. Esses casos são idênticos aos olhos do sistema e diferentes aos olhos da operação, e nenhuma regra automática resolve sozinha.

E há um limite de fronteira: se o parceiro não gera chave estável, você não tem o que guardar. Dá para contornar com impressão digital do conteúdo, mas é aproximação — duas remessas legitimamente idênticas existem, e a aproximação vai bloquear uma delas em algum momento.

O que muda é onde o problema é encontrado. Com o ciclo observado, a duplicata aparece em minutos, no painel, antes de virar nota fiscal. Sem isso, aparece na conciliação do mês — ou no telefone.

Se o ponto de partida é entender o que existe hoje antes de mexer, comece pelo diagnóstico de TI. Para o panorama do setor, veja TI para serviços e distribuição. E se o volume de documentos chegando é a dor imediata, o caminho é ler o XML e classificar dentro do SAP.

Perguntas frequentes