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.
Insight. Integração não é um arquivo que vai de um sistema para o outro. É uma camada de software com responsabilidade própria — fila, retry, log e regra de negócio. Quem trata isso como CSV agendado vai descobrir o custo no Reclame Aqui.
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.
[!DADO] A regra do buffer Reserve uma % do estoque físico como colchão para latência de sincronização (ex: não exponha as últimas unidades de SKUs de alto giro). Isso troca um pouco de venda por zero cancelamento — e reputação no marketplace vale mais que a última peça.
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.
Atencao. O modelo "estoque compartilhado entre canais" sem reserva por canal é uma bomba-relógio. Dois pedidos simultâneos no site e no marketplace para a última unidade = um cliente vai ser cancelado. Idempotência e reserva atômica resolvem; planilha nã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.
Regra. Um SKU tem N preços, não um. Preço de distribuidor, preço D2C no site, preço em cada marketplace (cada um com sua comissão), preço de campanha. Essa matriz vive na camada de integração, nunca na loja e nunca hardcoded no ERP.
É 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.
Caso. Sexta-feira, 18h, ERP entra em janela de manutenção. A loja continua vendendo. Sem fila, cada pedido pago nessas duas horas tenta chamar o ERP, falha e some. Segunda de manhã, dezenas de clientes pagaram e ninguém vai separar nada — porque o registro nunca chegou. Com fila + retry, os pedidos esperam na fila e entram sozinhos quando o ERP volta.
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.
[!DADO] O check fiscal não é opcional Na indústria, regime tributário, Substituição Tributária e a complexidade de CFOP por operação fazem da emissão fiscal um projeto à parte. Subestimar isso é a causa nº 1 de operação que "está pronta" mas não consegue despachar o primeiro pedido.
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".
Insight. A pergunta certa não é "qual ferramenta de integração comprar". É "quem opera essa camada todo dia". A ferramenta é commodity; a operação é o ativo. Por isso a integração bem feita pertence a quem já tem DNA logístico — quem nasceu de armazém entende que pedido perdido é caixa perdida, não um ticket de suporte.
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..