Leonardo Peron3 min de leitura
A integração entre loja e ERP parece simples de fora: o pedido entra no site e precisa aparecer no ERP. Na prática, é onde mais vemos operação perdendo dinheiro em silêncio — pedido duplicado, estoque vendido que não existe, repasse feito em cima de venda estornada.
Os quatro pontos abaixo concentram quase todas as falhas.
1. O pedido que entra duas vezes
A plataforma de e-commerce avisa o ERP por webhook: "pedido 1234 foi pago". Essa notificação é reenviada — por política do provedor, por instabilidade de rede, por reprocessamento manual. Se o ERP tratar cada chegada como um evento novo, o pedido 1234 entra duas vezes.
A solução não é filtrar por proximidade de horário, que é o contorno que aparece primeiro e falha na primeira fila acumulada. É idempotência: cada pedido carrega um identificador estável da origem, e a operação de criação usa esse identificador como chave única. Chegando dez vezes, cria uma vez.
O teste que confirma: reenviar manualmente o mesmo webhook três vezes e verificar que o ERP continua com um pedido só.
2. O estoque que vende o que não tem
Quase toda integração começa sincronizando estoque por rotina agendada — a cada trinta minutos, a cada hora. Funciona enquanto o volume é baixo. Em campanha, trinta minutos é tempo suficiente para vender cem unidades de um item com dez em estoque.
Há dois caminhos, e a escolha é de negócio:
Reserva no momento da venda. A loja consulta e reserva no ERP na hora do checkout. Mais correto e mais caro: exige que o ERP aguente a carga e responda rápido, e cria a necessidade de liberar reservas abandonadas.
Colchão de segurança. Mantém-se um saldo de proteção por item, calculado a partir da velocidade de venda. Mais barato, e aceita conviver com uma margem de erro conhecida. Para a maioria das operações, é o suficiente.
O erro é não escolher — deixar a rotina agendada e descobrir a decisão na primeira Black Friday.
3. O cadastro que vira dois clientes
O mesmo comprador aparece no site com e-mail pessoal e no ERP com o CNPJ da empresa. Sem uma regra explícita de identidade, a integração cria um cliente novo a cada pedido, e em seis meses o ERP tem quatro mil cadastros para mil pessoas.
A regra precisa ser decidida antes, não inferida: documento é a chave, e-mail é secundário, e o que fazer quando o documento vem em branco. Cadastro duplicado não quebra nada de imediato — só destrói qualquer análise de recompra e faz o comercial ligar duas vezes para o mesmo cliente.
4. O estorno que chega depois do repasse
Em marketplace ou operação com split, esta é a que dói no caixa. O pedido é pago, o valor é repassado ao vendedor, e semanas depois vem o estorno ou o chargeback. Se o modelo de dados tratou o repasse como fato consumado, não há de onde tirar o dinheiro de volta.
O desenho que resolve é tratar todo movimento como lançamento reversível, com um período de retenção antes do repasse efetivo. Isso é decisão de modelagem financeira, e é muito mais barato tomá-la no começo do que descobrir a necessidade depois de trezentos repasses feitos.
O que checar antes de fechar a integração
Uma lista curta, que roda em uma tarde e evita a maior parte dos problemas:
- Reenviar o mesmo webhook três vezes e confirmar que nada duplica
- Derrubar o ERP de propósito por vinte minutos e verificar se os pedidos entram depois, na ordem certa, sem perder nenhum
- Fazer um pedido com cliente sem documento e ver o que acontece
- Estornar um pedido já repassado e conferir o saldo resultante
- Confirmar que existe alerta quando a fila para — e que o alerta chega em algum canal que alguém lê
O último item é o mais negligenciado. Integração que falha em silêncio é pior que integração inexistente: a operação segue confiando num dado que parou de chegar, e a descoberta acontece pelo cliente reclamando.