ERP, e-commerce e marketplace estão integrados. Então por que os dados não batem?
Uma venda entra por um marketplace, chega ao ERP e passa a aparecer também no estoque, na expedição, no financeiro e nos demais sistemas da operação. Três dias depois, alguém investiga uma reclamação de cliente e abre o ERP, o painel do marketplace e o sistema de expedição ao mesmo tempo. As três telas contam histórias diferentes: o ERP mostra estoque baixado, o marketplace mostra o pedido como pago, a expedição ainda mostra como pendente de envio. Nenhum deles precisa estar quebrado. Cada um pode estar exibindo o último estado que conseguiu registrar.
O diagnóstico mais comum para esse tipo de situação é "a integração falhou". Às vezes foi exatamente isso: uma chamada que não voltou, um webhook que não chegou, um token que expirou no meio do caminho. O problema é parar aí. Esses sistemas trocam dados o tempo inteiro e, na maior parte do tempo, a integração funciona. Mesmo assim, podem discordar sobre o que aconteceu com o mesmo pedido, o mesmo item de estoque ou o mesmo pagamento.
Esse caso fica mais claro quando separamos duas coisas que parecem iguais, mas não são: estar conectado e estar de acordo. Integração move dado de um lugar para o outro. Isso não faz com que os dois lados cheguem à mesma conclusão no mesmo instante. ERP, plataforma de e-commerce e marketplace continuam sendo programas separados, cada um com seu banco de dados, seu ritmo de atualização e seu histórico do que já processou. Eles passam mudanças de estado uns aos outros. Não existe, por trás disso, um único banco compartilhado onde a resposta fica instantaneamente óbvia para todo mundo.
Trocar de fornecedor não resolve todos esses casos. Há falhas de implementação, claro, mas também existe uma característica do próprio desenho: cada sistema administra uma parte diferente da operação. O ERP cuida de nota fiscal, custo e saldo contábil de estoque. A plataforma de e-commerce cuida do carrinho, do pagamento e da experiência de compra. O marketplace cuida do anúncio, do repasse e das regras daquele canal. Nenhum deles foi feito para ser dono de tudo. Quando cada um mantém seu próprio estado e recebe atualizações dos outros, perguntas simples como "esse pedido está confirmado?" ou "esse item ainda está disponível?" podem ter respostas diferentes por algum tempo.
Os sintomas mais comuns não são bugs isolados
Na prática, esse mesmo problema estrutural aparece sob motivos diferentes:
- O mesmo pedido é criado duas vezes. Isso costuma acontecer depois de uma tentativa que pareceu falhar, embora já tivesse sido processada.
- O estoque diverge entre canais. Um item continua disponível no marketplace depois de ser vendido na loja própria, ou aparece esgotado quando ainda existe fisicamente.
- O status de um pedido não se propaga. Um cancelamento ou reembolso acontece em um sistema e demora a chegar, ou nunca chega, aos outros.
- O fechamento financeiro não bate. O valor esperado pela operação não corresponde ao que a adquirente ou o marketplace efetivamente repassaram.
O fio comum é simples: mais de um sistema tenta responder à mesma pergunta sobre o mesmo fato, sem uma regra clara sobre qual resposta deve prevalecer.
Quando a duplicidade nasce de uma confirmação que não veio
Pedido duplicado é o caso mais fácil de reproduzir. Uma resposta de sucesso confirma que o outro lado recebeu a solicitação dentro do combinado para aquele fluxo. Ela não prova que o efeito de negócio aconteceu uma única vez em todos os sistemas envolvidos. Em avisos automáticos entre sistemas, a própria Stripe recomenda confirmar rapidamente o recebimento e deixar o processamento mais demorado para depois, em segundo plano. Ver a orientação sobre separar confirmação de execução.
O mecanismo típico começa assim: um sistema manda criar o pedido 8472 no ERP. O ERP recebe a solicitação, cria o pedido e começa a responder. A comunicação cai antes de a resposta voltar. Quem enviou fica sem saber se o pedido foi perdido ou se já existe do outro lado. A Microsoft documenta esse tipo de situação em seus sistemas de mensageria e recomenda que o identificador de cada aviso seja definido por quem envia, justamente para que a operação possa ser reconhecida depois de uma falha. Ver a documentação sobre como evitar avisos repetidos.
Tentar novamente costuma ser a decisão correta. Se a primeira tentativa não chegou, desistir cria outro problema. A duplicidade aparece quando a nova tentativa chega sem algo que permita reconhecê-la como a repetição da anterior.
A Stripe usa um identificador para representar uma tentativa lógica única. Se a conexão falhar, quem enviou repete a chamada com o mesmo identificador, e o sistema devolve o resultado da primeira tentativa em vez de criar um segundo registro. Essa proteção tem prazo: a documentação informa que esses identificadores podem ser descartados depois de pelo menos 24 horas. Ver o comportamento documentado para solicitações que reconhecem tentativas repetidas.
A mesma lacuna aparece um passo depois, quando o pedido precisa avisar estoque, CRM ou faturamento. O pedido pode ser salvo e o aviso falhar. Também pode acontecer o inverso. A AWS recomenda gravar o estado e o registro do que ainda precisa ser comunicado na mesma escrita, deixando o envio para depois. Mesmo assim, quem recebe precisa reconhecer avisos repetidos, porque alguns sistemas de mensagens garantem a entrega sem garantir que ela aconteça uma única vez. Ver a recomendação da AWS sobre gravação e envio; ver por que filas como o SQS Standard podem entregar o mesmo aviso mais de uma vez.
A Microsoft trata essa proteção no recebimento como um problema próprio. Quando um aviso cria um registro, baixa estoque ou dispara outra ação, quem recebe precisa guardar quais identificadores já processou para não aplicar o mesmo efeito de novo. Ver o padrão de consumidor idempotente.
Quando o estoque diverge entre canais
Estoque pode divergir mesmo sem pedido duplicado. Aqui o problema costuma ser outro: atraso de atualização e mais de um sistema escrevendo sobre o mesmo saldo. Quando uma loja vende o mesmo SKU no site próprio, em marketplace e na loja física, cada canal precisa saber rapidamente quanto ainda existe disponível. Uma venda em qualquer canal precisa chegar aos outros antes que alguém tente vender a mesma unidade de novo.
O Shopify documenta esse desenho diretamente: uma loja pode ter até mil locais diferentes, cada um com sua própria contagem de estoque, e os canais ligados à loja precisam saber de qual local ou regra de consolidação puxar o número exibido ao comprador. Ver a documentação do Shopify sobre estoque em múltiplos locais.
Na prática, "o estoque" deixa de ser um número único. A resposta depende de qual sistema está perguntando e em que momento. Dois canais podem agir sobre o mesmo item antes de uma atualização chegar ao outro lado. Às vezes não houve uma falha pontual. Houve atraso. A venda aconteceu antes de todos os canais saberem dela.
Quando o status de um pedido não se propaga
Cancelamento e reembolso deixam o problema ainda mais visível porque costumam atravessar vários sistemas em sequência. O marketplace processa o reembolso, a transportadora cuida da devolução física, o armazém confere o item e só então a atualização volta para ERP e loja. Se um elo atrasa ou falha, os status começam a divergir. E o caminho de volta da informação costuma ter mais pontos de falha do que o caminho de ida.
Esse limite aparece até em conectores oficiais de grandes plataformas. A documentação de suporte do Shopify Marketplace Connect explica que um pedido pode ser marcado como reembolsado no painel da loja sem que isso seja replicado de volta ao marketplace, porque o conector sincroniza o status do pedido uma única vez. Ver a documentação do Shopify sobre o impacto do cancelamento de pedidos no estoque. Nesse caso, a regra do conector é explícita. O problema operacional aparece quando a equipe não sabe que ela existe.
Quem é a referência quando os sistemas discordam?
Pedido duplicado, estoque divergente e status que não se propaga parecem problemas diferentes. Em todos eles, porém, chega uma hora em que mais de um sistema tem uma resposta para o mesmo fato e a operação precisa saber qual delas vale.
Em arquiteturas distribuídas, uma prática comum é definir uma fonte da verdade para cada entidade de dado. O Azure Architecture Center da Microsoft descreve esse desenho para microsserviços: um serviço fica responsável pelo dado e os demais podem manter cópias que serão atualizadas ao longo do tempo. Ver a documentação sobre fonte da verdade em arquiteturas de dados distribuídas.
Na operação isso pode significar fontes diferentes para fatos diferentes. O estoque físico pode ter como referência o WMS ou o ERP. O pagamento pode depender do gateway ou da adquirente. O status comercial de um pedido vindo de marketplace pode ter outra referência. Isso é normal. O risco aparece quando ninguém definiu, para cada tipo de dado, qual sistema manda e quais apenas mantêm cópias.
Por que o problema demora a aparecer
Em uma operação pequena, uma pessoa costuma absorver a inconsistência. Vê que o marketplace ainda mostra o pedido como pendente, liga para o cliente, corrige na mão e segue o dia. Como o caso foi resolvido, fica fácil concluir que o sistema também foi.
Com mais canais e mais pedidos, essa correção manual começa a pesar. O limite não é um número fixo. Depende de quantos sistemas participam da operação e de quantos casos exigem atenção. O padrão aparece quando pedidos começam a sumir, o estoque nunca fecha e o financeiro passa a gastar tempo recorrente só para localizar diferenças.
Reconciliação é o processo de comparar o que um sistema registrou com o que outro registrou e decidir o que fazer quando os dois não batem. A própria Stripe oferece relatórios para comparar os repasses recebidos com o que a operação esperava receber. Ver o relatório de conciliação de repasses da Stripe.
Divergências vão aparecer. A diferença está em encontrá-las por um processo previsto ou por acaso, no fechamento do mês.
Antes de conectar mais um sistema, decida isso
Para cada tipo de dado que atravessa mais de um sistema, como pedido, estoque, cancelamento, reembolso ou valores financeiros, a operação precisa conseguir responder antes que a divergência apareça:
- Qual sistema é a fonte da verdade para este dado específico, e quais sistemas só recebem cópias?
- Como uma cópia sabe que está desatualizada, e o que ela faz enquanto espera a atualização chegar?
- O sistema que recebe um aviso repetido consegue reconhecer que já processou aquela mesma mudança antes?
- Existe uma janela de tempo em que a divergência é esperada e tolerável? A operação sabe qual é essa janela?
- Quando a divergência ultrapassa essa janela, existe um processo de conferência definido, ou alguém só descobre quando um cliente reclama?
- Esse processo de conferência depende de uma pessoa notar o problema, ou existe alguma forma de ele aparecer sozinho?
Responder a essas perguntas raramente começa por trocar de sistema ou reconstruir tudo do zero. Começa por definir, para cada dado importante, qual sistema é a referência. Depois vem a parte que costuma dar trabalho: como os demais se atualizam, como a divergência aparece e o que acontece quando a resposta esperada não chega.
