Integração ERP × e-commerce na indústria: onde sempre quebra e como blindar
Integração ERP e-commerce na indústria quebra em 5 pontos previsíveis. Veja onde estoque, preço e nota fiscal travam — e como um hub blinda a operação.
TL;DR
- A integração ERP × loja não quebra por bug exótico — quebra em 5 pontos previsíveis: estoque, tabela de preço, fila de pedido, emissão fiscal e idempotência.
- O erro estrutural é tratar a integração como um script de export/import. O certo é uma camada própria (hub/middleware) com fila, retry e log de auditoria.
- Estoque tem que ser near-real-time com buffer de segurança, não batch noturno. Vender o que não tem destrói reputação no marketplace.
- Preço é por canal e por tabela, nunca o preço-base do ERP cru. MAP Policy e margem de canal vivem na camada de integração, não na loja.
- Idempotência é o que separa operação madura de amadora: o mesmo evento pode chegar duas vezes, e o sistema não pode duplicar pedido nem baixar estoque em dobro.
Por que a integração entre ERP e e-commerce quebra tanto na indústria?
A integração entre o ERP (SAP, TOTVS, Oracle) e a loja própria ou marketplace é o ponto onde a maioria das operações digitais da indústria realmente quebra — não no design da vitrine, não no checkout, mas na costura invisível entre o sistema que controla o estoque físico e o sistema que vende. Quando essa costura falha, o sintoma é sempre o mesmo: vendeu o que não tinha, cobrou o preço errado, o pedido não baixou, a nota travou.
O problema raramente é um bug exótico. É estrutural. A indústria nasceu com um ERP desenhado para Sell-in — vender em caixa fechada para distribuidor, faturar em lote, conferir no fim do mês. O e-commerce exige o oposto: estoque vivo, preço por canal, pedido unitário, nota na hora. Forçar um sistema Sell-in a operar como Sell-out via um "script de export noturno" é a origem de 80% das dores.
Este post abre cada um dos pontos de falha e mostra como uma camada de integração bem feita — o que o mercado chama de Middleware ou hub — blinda a operação. É o tipo de plumbing que ninguém vê quando funciona e todo mundo vê quando falha.
Quais são os 5 pontos onde a integração sempre quebra?
São cinco pontos previsíveis, e eles aparecem quase sempre nesta ordem de gravidade: sincronização de estoque, tabela de preço por canal, fila de pedidos, emissão fiscal e idempotência. Resolver os cinco é a diferença entre uma operação que escala e uma que vira plantão de bombeiro.
| Ponto de falha | Sintoma visível | Causa raiz comum |
|---|---|---|
| Sincronização de estoque | Vendeu produto esgotado; oversell | Sync em batch noturno, sem buffer |
| Tabela de preço por canal | Preço do site ≠ preço do marketplace | ERP manda preço-base cru, sem regra de canal |
| Fila de pedidos | Pedido pago não baixa no ERP | Chamada síncrona que falha e não tem retry |
| Emissão fiscal | NF-e travada, pedido não despacha | Cadastro fiscal incompleto, sem fila de reprocesso |
| Idempotência | Pedido duplicado, estoque baixado 2x | Evento reentregue sem chave de deduplicação |
Cada linha dessa tabela já causou demissão de gerente de e-commerce em algum lugar. Vamos abrir uma por uma.
Como integrar estoque sem vender o que não tenho?
Estoque precisa sincronizar em near-real-time com um buffer de segurança, nunca em batch noturno. O oversell — vender o que já acabou — é o pecado capital do marketplace, porque o algoritmo do canal pune cancelamento por falta com queda de reputação e perda de Buy Box. Quem sincroniza estoque uma vez por dia está apostando que ninguém vai comprar as últimas unidades nas 23 horas entre um sync e o outro. Em Black Friday, essa aposta sempre perde.
A arquitetura correta usa eventos: quando o estoque muda no ERP (entrada, venda, transferência), um evento dispara para a camada de integração, que atualiza todos os canais. Sem polling burro de "consulta tudo a cada hora". O Fulfillment físico e a vitrine digital têm que falar a mesma língua em segundos, não em turnos. Esse é exatamente o tipo de falha que detona reputação em marketplace — o mecanismo está detalhado em Bling/Tiny + Mercado Livre: por que sua reputação despenca por falha de sincronização.
Como funciona a tabela de preço por canal?
Preço nunca deve sair cru do ERP para a loja. A camada de integração precisa aplicar regra de preço por canal e por tabela antes de publicar. O preço-base do ERP foi pensado para o distribuidor — é preço de Sell-in. O preço da vitrine é Sell-out, e ele carrega margem de canal, comissão de marketplace, frete embutido, promoção e — crítico para a indústria — a MAP Policy, o preço mínimo anunciado que protege o canal indireto de uma guerra de preço suicida.
É aqui que a indústria que vende via canal indireto mais tropeça. Publicar o preço de Sell-in na loja D2C significa competir com o próprio distribuidor por baixo — conflito de canal explícito. A camada de integração é o lugar onde você protege a MAP Policy programaticamente: o sistema simplesmente recusa publicar abaixo do piso. Esse é o coração do que chamamos de Distribuidor Digital — você opera o digital sem detonar a cadeia que já vende seu produto.
O pedido foi pago mas não aparece no ERP. Por quê?
Quase sempre é fila de pedido mal feita: uma chamada síncrona que falhou e não tinha retry. Quando o cliente paga, o pedido precisa viajar da loja até o ERP para virar ordem de separação, faturamento e despacho. Se essa viagem é uma chamada direta (a loja chama a API do ERP e espera resposta na hora), qualquer instabilidade — ERP em manutenção, timeout, pico de carga — faz o pedido sumir no limbo. Pago no cartão, invisível na operação.
A solução é assíncrona: o pedido entra numa fila durável, e um worker tenta entregar ao ERP com retry exponencial até confirmar. Se o ERP está fora, a fila segura; quando volta, drena sozinha. Nada se perde, nada duplica. Essa fila é o que transforma "a integração caiu e perdemos pedido" em "a integração ficou atrasada 40 minutos e ninguém percebeu".
Como evitar pedido duplicado e nota fiscal travada?
Pedido duplicado se evita com idempotência — uma chave única por evento que faz o sistema ignorar a segunda entrega do mesmo pedido. Em sistemas distribuídos, mensagens são reentregues: o mesmo webhook de "pedido pago" pode chegar duas, três vezes por causa de retry de rede. Sem idempotência, cada reentrega vira um pedido novo, baixa estoque de novo e emite NF-e de novo. Com idempotência, o sistema vê a chave repetida e descarta a duplicata silenciosamente.
A emissão fiscal é o gargalo final e o mais perverso, porque trava o despacho. Uma NF-e rejeitada pela SEFAZ — CFOP errado, NCM incompleto, ICMS-ST mal calculado, cliente com cadastro fiscal furado — segura o pedido inteiro. A camada de integração precisa de uma fila fiscal própria com reprocessamento: NF-e que falha não pode bloquear a fila inteira de pedidos saudáveis; ela vai para uma esteira de exceção, é corrigida e reprocessada.
Idempotência, fila durável e esteira fiscal de exceção são os três marcadores de uma integração madura. Se a sua não tem os três, ela não quebrou ainda — ela só não foi testada o suficiente.
Comprar um hub pronto ou construir a integração internamente?
Depende do quão padrão é a sua operação. Para volume e fluxo padrão, um hub de mercado resolve; para regra fiscal e logística complexa da indústria, geralmente é preciso uma camada dedicada. Esta é a decisão de arquitetura que define o custo de toda a operação digital.
| Opção | Faz sentido quando | Cuidado |
|---|---|---|
| Hub/middleware de mercado (SaaS) | Operação padrão, SKUs simples, fiscal comum | Pode não cobrir Substituição Tributária e MAP Policy da indústria |
| Integração custom (in-house) | Regra fiscal/logística específica, alto volume | Custo de manutenção vira passivo permanente |
| Camada operada por parceiro | Indústria que quer digital sem virar empresa de software | Exige parceiro com DNA logístico, não só de software |
A armadilha mais cara é tratar integração como projeto de TI pontual — "vamos integrar e acabou". Integração é operação contínua: SEFAZ muda layout, marketplace muda API, ERP atualiza versão. Alguém precisa cuidar disso todo dia, com monitoramento e plantão. Não funciona pra quem quer "ligar e esquecer".
O Agrega trata a integração ERP × canal como o que ela é: infraestrutura crítica de uma operação que nasceu de armazém. Não vendemos um conector e desejamos boa sorte. Operamos a camada — fila, idempotência, fiscal, estoque near-real-time — como Distribuidor Digital da marca, sem substituir o distribuidor físico que já vende seu produto. Antes de decidir o caminho, vale dimensionar o todo: o custo real dessa infraestrutura está aberto em quanto custa montar uma operação D2C completa. E para entender por que esse plumbing é estratégico e não acessório, vale a leitura de D2C não é canal. É infraestrutura de dado..
Perguntas frequentes
como integrar meu erp com o e-commerce sem quebrar o estoque?
Sincronize estoque em near-real-time por eventos, não em batch noturno, e exponha um buffer de segurança em vez do estoque cru. Quando o estoque muda no ERP, um evento atualiza todos os canais em segundos; reservar uma % das últimas unidades de SKUs de alto giro elimina o oversell. Batch diário é a causa nº 1 de vender o que não se tem.
qual a diferença entre middleware e hub de integração?
Na prática são o mesmo conceito: uma camada de software entre o ERP e os canais de venda que aplica regra de negócio (preço por canal, fila de pedido, idempotência, fiscal). 'Hub' costuma designar produtos SaaS prontos com conectores; 'middleware' é o termo genérico de arquitetura. O que importa não é o nome, mas se a camada tem fila durável, retry e log de auditoria.
por que meu pedido foi pago mas não aparece no ERP?
Quase sempre porque a integração usa chamada síncrona sem fila nem retry: se o ERP estava instável ou em manutenção quando o cliente pagou, o pedido falhou ao ser entregue e se perdeu. A correção é colocar os pedidos numa fila durável com retry, que segura quando o ERP cai e drena sozinha quando ele volta — nenhum pedido se perde.
o que é idempotência na integração de e-commerce?
Idempotência é garantir que processar o mesmo evento duas vezes tenha o mesmo efeito que processá-lo uma vez. Como webhooks de pagamento são reentregues por retry de rede, sem uma chave única de deduplicação o sistema cria pedido duplicado, baixa estoque em dobro e emite NF-e repetida. É o marcador que separa integração madura de amadora.
preciso de uma tabela de preço diferente para cada marketplace?
Sim. Cada canal tem comissão, frete e regra de margem próprios, e a indústria ainda precisa respeitar a MAP Policy (preço mínimo anunciado) para não conflitar com o canal indireto. O preço nunca deve sair cru do ERP — a camada de integração aplica a regra de preço por canal antes de publicar, recusando qualquer valor abaixo do piso.