Integração de pedidos: como não perder vendas quando o ERP ou o marketplace sai do ar

Na integração de pedidos, falhar é rotina: o ERP entra em manutenção, o marketplace fica instável, um token vence no fim de semana, um produto é vendido antes de ser cadastrado. Para não perder pedidos, a integração precisa de quatro coisas: uma fila que guarda o que não foi entregue, nova tentativa automática na ordem certa, proteção contra duplicidade e alertas que digam o que fazer. Este guia explica cada uma e termina com um roteiro para o dia em que o ERP cair.

Por que a integração de pedidos falha?

Vale separar as falhas pelo que elas exigem. Quase todas cabem em três grupos.

Sistema indisponível

O ERP, o canal ou a rede não respondem. É o tipo mais comum e, em geral, se resolve sozinho: o sistema volta. O que ele pede é paciência organizada — guardar o envio e tentar de novo.

Credencial vencida ou revogada

Um token de acesso expirou, uma senha foi trocada, uma permissão foi retirada no painel do canal. Tentar de novo não adianta: cada tentativa vai falhar igual até alguém renovar o acesso.

Cadastro faltando ou inconsistente

O pedido chega com um SKU que não existe no ERP, uma filial sem código correspondente, um tamanho sem correspondência no outro sistema. Também não se resolve sozinho: alguém precisa completar o cadastro.

Tipo	Exemplo	Resolve sozinho?	Quem age
Indisponibilidade	ERP em manutenção	Em geral, sim	Ninguém, se a nova tentativa funcionar
Credencial	Token expirado	Não	Quem administra a integração
Cadastro	SKU sem correspondência	Não	Quem cuida do catálogo

Tratar tudo igual gera alerta demais para o que se resolve sozinho e alerta de menos para o que precisa de gente.

O que fazer quando o ERP ou o marketplace sai do ar?

A regra número um é simples: um pedido que não pôde ser entregue nunca é descartado. Ele vai para uma fila e espera a próxima tentativa.

Algumas práticas tornam a nova tentativa segura:

• Espaçar as tentativas. Tentar de novo a cada segundo sobrecarrega um sistema que já está com problema. O comum é aumentar o intervalo a cada falha.
• Respeitar a ordem. Se o pedido foi criado e depois cancelado, o ERP precisa receber as duas coisas nessa sequência. Um cancelamento que chega antes da criação vira erro — ou, pior, um pedido que nunca é cancelado. O mesmo vale para saldos de estoque: aplicar uma atualização antiga depois de uma nova deixa o número errado.
• Saber quando parar de tentar sozinho. Depois de algumas tentativas, ou quando o erro indica credencial ou cadastro, a falha precisa virar alerta. A fila continua guardando o registro.

Como evitar pedido duplicado na nova tentativa?

Toda nova tentativa traz um risco: e se a primeira tinha dado certo, mas a resposta se perdeu? Sem cuidado, o ERP recebe o mesmo pedido duas vezes — e a mercadoria pode ser enviada em dobro.

A proteção se chama idempotência: processar a mesma mensagem várias vezes tem o mesmo efeito que processar uma vez. Na prática:

• Cada registro tem uma chave estável — por exemplo, o canal de origem mais o código do pedido no canal, ou a chave de acesso da nota fiscal.
• Antes de criar, o sistema verifica se aquela chave já existe. Se existe, atualiza ou ignora.
• O próprio canal pode reenviar o mesmo pedido, por exemplo quando um aviso não recebe confirmação. A mesma chave protege contra isso.

É ela que permite que a nova tentativa seja automática sem medo.

Como criar alertas que alguém consegue resolver?

Um alerta só é útil se a pessoa que o lê sabe o que fazer. Bons alertas têm três coisas:

1. O motivo, em linguagem clara: “SKU CAM-AZ-M não encontrado no ERP”, e não “erro 500”.
2. O endereço: qual pedido, qual nota, qual produto, em qual filial.
3. Um fim: quando o problema é resolvido e a nova tentativa funciona, o alerta se fecha sozinho.

Evite o excesso: se toda instabilidade de um minuto vira notificação, a equipe aprende a ignorar alertas. Alerte o que precisa de gente; deixe a nova tentativa cuidar do resto.

Como rastrear o caminho de cada pedido na integração?

Quando um cliente pergunta pelo pedido, alguém precisa reconstruir o que aconteceu. Para isso, cada pedido deveria guardar o seu caminho: quando entrou, quando o estoque foi reservado, quando a nota foi autorizada, quantas vezes o envio ao ERP falhou e por quê, quando deu certo.

Do lado técnico, um identificador por requisição — o traceId — permite achar nos logs a chamada que falhou. Do lado do negócio, um histórico de quem alterou o quê, com o valor anterior, responde às perguntas que surgem depois.

Roteiro de integração de pedidos para quando o ERP cai

Imagine uma operação hipotética em que o ERP fica fora do ar das 14h às 15h de uma segunda-feira. Com as práticas acima, a hora seria assim:

1. 1

   Os pedidos continuam entrando

   Os canais seguem enviando pedidos, que ficam guardados na fila com tudo o que chegou.

2. 2

   O estoque continua reservado

   Se o hub controla o saldo, a reserva acontece na entrada do pedido e os canais seguem atualizados mesmo sem o ERP.

3. 3

   Os envios ao ERP são reagendados

   Cada tentativa que falha é refeita mais tarde, com intervalos crescentes, sem ninguém intervir.

4. 4

   A equipe é avisada se demorar

   Se a indisponibilidade passa do esperado, um alerta informa o motivo e quais pedidos aguardam.

5. 5

   O ERP volta e a fila anda

   Os envios são refeitos na ordem em que aconteceram, sem duplicar nenhum pedido.

6. 6

   Os alertas se fecham

   Com os envios concluídos, os alertas se encerram sozinhos e o histórico mostra o que aconteceu.

Ninguém reenviou pedido à mão nem montou planilha do que faltou.

Como o Axiom connect trata falhas

No Axiom connect, se o ERP ou o canal não responde, o envio fica guardado e é refeito sozinho, na ordem em que aconteceu. O que depende de alguém — credencial vencida, cadastro faltando — vira alerta com o motivo e o pedido afetado, e o alerta se fecha quando a nova tentativa dá certo. Cada pedido guarda o caminho que fez entre os sistemas, cada alteração de cadastro guarda quem mudou e o valor anterior, e na API todo erro volta com um código estável e um traceId. Veja os detalhes em reprocessamento e alertas e pedidos.

Quer ver como isso funcionaria com os seus sistemas? Fale com a gente.