O mesmo pedido aparece duas vezes no ERP. A equipe confere os itens, tenta descobrir qual registro deve seguir para separação e precisa verificar se o estoque também foi movimentado em duplicidade. Antes de corrigir o cadastro, vale responder a uma pergunta: houve duas compras ou a mesma compra foi processada novamente?
Integrações precisam lidar com falhas de comunicação. Uma resposta pode demorar, uma notificação pode ser reenviada e uma rotina pode repetir uma tentativa depois de perder a conexão. O problema surge quando cada recebimento é interpretado como uma nova operação. A solução exige reconhecer a compra original e controlar os efeitos de cada processamento.
1. Diferencie uma compra repetida de um pedido duplicado
Um cliente pode fazer duas compras legítimas com os mesmos produtos, endereço e valor. Bloquear pedidos apenas porque os dados se parecem pode impedir uma venda real. A identificação deve partir da referência da compra no sistema de origem, considerando também a conta e o canal aos quais ela pertence.
Por exemplo, o pedido externo 7842 da conta LOJA-01 no CANAL-A representa uma compra específica. Outra conta pode ter um pedido com o mesmo número. Já um novo pedido do mesmo cliente deve ter identidade própria, mesmo que repita os itens. Esses identificadores são ilustrativos; a estrutura efetiva depende dos sistemas integrados.
Essa distinção deve ser entendida pela equipe e pelo software. O nome do cliente ajuda na conferência humana, mas não substitui uma chave de identificação do pedido. Também não se deve usar o SKU como identidade da compra: o mesmo produto pode participar de inúmeros pedidos diferentes.
2. Entenda como um reenvio vira duplicidade
Imagine uma sequência ilustrativa: às 10:00:01, a integração solicita a criação do pedido no ERP. O ERP conclui a gravação, mas a conexão cai antes de entregar a resposta. Às 10:00:02, a integração ainda não sabe se a operação foi concluída e tenta novamente.
Se o destino tratar a segunda solicitação como uma nova compra, surgirão dois registros. Se reconhecer a mesma operação, poderá devolver a referência já criada. Uma falha percebida por quem envia, portanto, não comprova que nada aconteceu em quem recebe.
Notificações e tarefas agendadas também podem se repetir. É necessário saber se o reenvio veio do canal, de uma fila, de uma tentativa manual ou de duas rotinas que atuam sobre o mesmo fluxo. Desativar todas as novas tentativas pode apenas trocar pedidos duplicados por pedidos que deixam de chegar.
3. Separe pedido, evento e ação executada
Três referências diferentes ajudam a explicar o processamento:
- Pedido: identifica a compra no canal e na conta de origem.
- Evento: identifica uma notificação recebida, quando o provedor fornece esse identificador.
- Ação: identifica o efeito aplicado, como criar o pedido no destino ou registrar uma mudança de estado.
Receber duas vezes o mesmo evento é uma situação. Receber dois eventos diferentes relacionados ao mesmo pedido é outra. A integração precisa reconhecer ambos sem impedir atualizações legítimas, como a passagem de pagamento pendente para pagamento confirmado.
Um controle baseado somente no identificador da notificação pode deixar passar duas notificações distintas que provocam a mesma criação. Por outro lado, ignorar tudo o que chega para um pedido já conhecido impede que ele evolua. A regra deve descrever qual ação pode ocorrer uma vez e quais alterações posteriores continuam permitidas.
4. Torne o processamento seguro para repetição
Idempotência é a propriedade que permite repetir uma operação sem repetir indevidamente seu efeito. Para criação de pedidos, isso costuma envolver uma referência estável da operação, um vínculo entre pedido externo e registro interno e proteção contra execuções concorrentes.
Apenas consultar se o pedido existe antes de gravar pode ser insuficiente: dois processos podem fazer a consulta ao mesmo tempo e ambos concluir que ele ainda não existe. A implementação deve proteger a unicidade no ponto de gravação e coordenar a marcação do processamento com a alteração dos dados, conforme a arquitetura utilizada.
Quando há dois sistemas separados, uma transação local não torna toda a comunicação uma operação única. Se a chamada ao ERP ficar sem resposta, será necessário consultar o resultado por uma referência confiável ou usar o mecanismo de idempotência do destino, quando disponível. Reenviar com uma referência nova a cada tentativa elimina justamente o vínculo que permitiria reconhecer a repetição.
5. Confira os efeitos sobre estoque e separação
Corrigir a lista de pedidos não garante que todos os efeitos foram corrigidos. É preciso conferir o que cada registro provocou: reserva, baixa de estoque, geração de documentos, envio para separação ou atualização em outro sistema.
Defina qual sistema controla o estoque e em que etapa cada movimentação acontece. Se o ERP é a origem oficial do saldo, os demais componentes precisam respeitar esse desenho. Reservas, baixas e devoluções de disponibilidade devem ter regras próprias, sem permitir que a mesma transição seja aplicada novamente por um reenvio.
Uma duplicidade já ocorrida exige conciliação. Antes de cancelar um registro, confirme qual representa a compra válida e quais ações já aconteceram. Apagar um pedido ou alterar o saldo manualmente sem essa conferência pode esconder a causa e criar uma nova divergência. A correção precisa deixar um histórico compreensível.
6. Investigue com referências que possam ser comparadas
Para localizar o problema, reúna o canal e a conta de origem, a referência externa, os registros criados no destino, os horários, o resultado das tentativas e as ações executadas. Inclua o fuso usado nos registros: horários apresentados em fusos diferentes podem sugerir uma sequência incorreta.
Compare as evidências nos dois lados da integração. Uma mensagem de erro isolada não mostra se o pedido foi criado, e um registro no ERP não explica por que houve uma segunda tentativa. Registre também se alguém acionou um reprocessamento manual enquanto a rotina automática ainda estava tentando concluir a operação.
Compartilhe somente os dados necessários à análise. O suporte geralmente precisa de identificadores e contexto, não de senhas, chaves de acesso ou uma cópia irrestrita dos dados dos clientes.
7. Teste repetições e falhas antes de liberar o fluxo
Uma compra que percorre o caminho normal não testa a proteção contra duplicidade. Em ambiente de testes, inclua pelo menos estes cenários:
| Situação | Resultado a verificar |
|---|---|
| Mesma solicitação enviada novamente | Um único pedido no destino |
| Duas tentativas simultâneas | Nenhuma segunda criação |
| Destino grava, mas a resposta se perde | A tentativa seguinte identifica o resultado anterior |
| Eventos relacionados chegam fora de ordem | O estado final permanece coerente |
| Mesma referência chega com dados incompatíveis | O conflito é identificado, sem alteração silenciosa |
| Cliente faz uma segunda compra legítima | O novo pedido é aceito normalmente |
Verifique também se um reprocessamento autorizado repete apenas a etapa pendente. Um botão de tentar novamente não deve refazer indiscriminadamente tudo o que já foi concluído.
8. Transforme a correção em uma rotina controlada
Depois do ajuste, mantenha visibilidade sobre falhas pendentes e reprocessamentos. A equipe deve conseguir responder se um pedido está aguardando envio, em processamento, concluído ou em análise, e saber quem pode autorizar uma nova tentativa quando houver dúvida.
Documente a identidade usada para reconhecer a compra, a origem oficial do estoque e o procedimento de conciliação. O objetivo é permitir que a operação continue funcionando durante falhas de comunicação, com rastreabilidade e sem depender de descobrir duplicidades depois da separação.
Se sua loja enfrenta esse tipo de retrabalho, a AGTI pode avaliar o fluxo entre os sistemas e ajudar a identificar onde a proteção está faltando. Conheça os serviços da AGTI.
Referências técnicas
- Novas tentativas seguras com APIs idempotentes — AWS Builders’ Library.
- Comportamento de webhooks e tratamento de eventos repetidos — documentação Stripe.
- Requisições idempotentes — referência de API Stripe.
Fontes verificadas em 19/10/2026. Os exemplos de identificação e operação são ilustrativos; a implementação depende dos contratos das APIs e das regras da loja.