# 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: estoque, preço, pedido, fiscal e idempotência. Veja como um hub blinda.

Biblioteca · tecnologia · 30 de maio de 2026 · 9 min de leitura · Equipe Agrega
Fonte: https://agrega-site.pages.dev/biblioteca/integracao-erp-ecommerce-industria

## Em resumo

- 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.

> **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](/biblioteca/bling-tiny-mercado-livre-sincronizacao).

> **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](/biblioteca/quanto-custa-operacao-d2c). 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.](/blog/d2c-nao-e-canal-e-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.

## Leia também

- [Quanto custa montar uma operação D2C completa pra indústria R$50M+](https://agrega-site.pages.dev/biblioteca/quanto-custa-operacao-d2c)
- [Bling/Tiny + Mercado Livre: por que sua reputação despenca por falha de sincronização](https://agrega-site.pages.dev/biblioteca/bling-tiny-mercado-livre-sincronizacao)
- [D2C não é canal. É infraestrutura de dado.](https://agrega-site.pages.dev/blog/d2c-nao-e-canal-e-infraestrutura-de-dado)