Integração entre ERP e e-commerce sem planilha no meio

A cena é conhecida por quem vende online e tem loja física. A promoção começa à noite, os pedidos entram, e na manhã seguinte o comercial descobre que vendeu mais do que havia na prateleira. Parte da equipe passa o dia pedindo desculpas aos clientes; a outra redigita pedidos no ERP e cola código de rastreio numa planilha.

Quase nunca falta ferramenta: existe um ERP competente, uma plataforma de loja madura e algum conector entre os dois. O que falta é desenho: quem manda em cada dado, em que direção ele anda, com que frequência e o que acontece quando um dos lados falha.

Este texto é o desenho que usamos para integrar ERP, loja virtual e loja física num mesmo saldo.

O sintoma: vender o que não tem e faturar à mão

Integração ruim entre ERP e e-commerce não para de uma vez. Ela vaza aos poucos, e cada vazamento vira rotina manual:

• Venda sem estoque. O saldo da loja está atrasado em relação ao do ERP, e a diferença aparece justamente no pico.
• Pedido redigitado. O pedido chega por e-mail ou por uma exportação, e alguém lança no ERP para conseguir faturar.
• Nota e rastreio que não voltam. O ERP emite a NF-e e o despacho gera o rastreio, mas alguém precisa copiar os dois para a plataforma, pedido por pedido.
• Planilha de conferência. Alguém cruza o saldo do ERP com o da loja e ajusta o que divergiu, sem saber por quê.

A planilha no meio existe porque ninguém confia no dado que chegou sozinho. O objetivo é torná-la desnecessária, não automatizá-la.

Quem é a fonte da verdade de cada dado

Antes de escolher conector, decida por escrito quem é dono de cada entidade e em que direção ela flui. Sem isso, os dois sistemas editam o mesmo dado e a integração vira cabo de guerra. Um mapa típico, como ponto de partida:

Duas observações sobre essa tabela.

Cadastro técnico e conteúdo comercial são coisas diferentes. O ERP manda no NCM, no peso e no código; a equipe de e-commerce manda na foto e no texto. Misturar os dois produz uma integração que sobrescreve a descrição caprichada com o nome abreviado do ERP.

Promoção é o ponto que mais gera discussão. Se o desconto nasce na plataforma, o pedido precisa chegar ao ERP com preço cheio, desconto e preço final separados, para que nota, comissão e margem fechem. Se nasce no ERP, a loja só exibe. O que não funciona é os dois criarem promoções de forma independente.

E um alerta: se o controle de estoque ainda é frágil dentro de casa, a integração só vai espalhar o problema mais rápido. Nesse caso, vale ler antes quando um sistema de gestão de estoque sob medida faz sentido.

Catálogo, preço e estoque em tempo quase real

O número que a loja exibe como disponível não deveria ser o estoque físico. Deveria ser um cálculo:

disponível para venda = saldo físico − reservas em aberto − estoque de segurança do canal

O estoque de segurança protege contra o atraso entre a venda e a atualização. Em giro lento, pode ser zero; em promoção agressiva, segura algumas unidades para não vender online o que acabou de sair pelo balcão.

Evento em vez de carga completa

A forma mais comum de integrar estoque também é a mais frágil: a cada tantos minutos, o conector reenvia o saldo de todos os produtos. Com catálogo grande, a carga demora, esbarra nos limites de requisição da API da plataforma e, no pico da promoção, o saldo chega velho.

O desenho mais robusto trabalha com eventos: cada movimentação no ERP (venda, entrada, ajuste, transferência entre locais) gera uma mensagem com o SKU afetado, e só esse SKU é atualizado na loja. A carga completa continua existindo, mas como conciliação periódica, não como mecanismo principal. Quando o ERP não emite eventos, dá para chegar perto consultando só o que mudou desde a última leitura.

Preço e cadastro mudam menos, mas erram de forma mais cara. Registre quem alterou o preço e qual era o anterior, e configure uma trava que segura variações fora do padrão até alguém confirmar.

Loja física, PDV e retirada na loja no mesmo saldo

Quando existe loja física, o saldo deixa de ser um número e passa a ser um número por local: centro de distribuição, loja do centro, loja do shopping. Ignorar isso faz a loja virtual oferecer um item que só existe numa unidade longe do cliente.

Três fluxos pedem atenção:

• Venda no balcão. O PDV baixa o estoque da loja, com o documento fiscal do varejo (em geral, a NFC-e), e essa baixa precisa chegar ao saldo que o site enxerga. Se o PDV trabalha em contingência sem conexão, as vendas offline só sobem depois, e o saldo online fica otimista nesse intervalo.
• Retirada na loja. O cliente compra online e escolhe buscar na unidade. O pedido precisa reservar o saldo daquela loja específica, não o total da rede, e a equipe da loja precisa receber a lista do que separar. Se o cliente não aparece no prazo combinado, o cancelamento devolve a reserva ao saldo.
• Envio a partir da loja. Quando as lojas despacham pedidos online, a mesma unidade pode ser disputada pelo balcão e pelo site ao mesmo tempo.

A regra geral é simples de enunciar: toda reserva precisa ter começo, dono e fim. Ela nasce de um pedido, pertence a um local e termina em baixa (faturou), devolução (cancelou) ou expiração (o prazo venceu). Reserva sem expiração é o que produz o estoque "preso": o sistema diz que não há disponível, a prateleira diz que há.

Pedido, faturamento e rastreio: ida e volta com o ERP

O pedido faz ida e volta, e cada trecho precisa de um gatilho claro.

1. O pedido nasce na plataforma e fica lá até o pagamento ser confirmado. Cobrança Pix não paga expira, boleto espera compensação, cartão passa por antifraude. Enviar ao ERP antes disso cria pedidos que depois são cancelados à mão.
2. Com o pagamento aprovado, o pedido vai para o ERP, com cliente (CPF ou CNPJ), itens, preço cheio, descontos, frete e pagamento, no formato que o ERP espera para faturar sem intervenção.
3. O ERP separa e fatura. Na venda online de mercadorias, o documento costuma ser a NF-e, com as regras de ICMS aplicáveis, inclusive nas vendas para consumidor de outro estado. Esse trecho deve ficar no ERP, que acompanha a legislação.
4. A nota volta para a loja. Chave de acesso, XML e DANFE são devolvidos à plataforma, que os disponibiliza ao cliente. Contingência, rejeição e demais detalhes de emissão estão no texto sobre emissão automática de NF-e e NFS-e integrada ao sistema.
5. Despacho e rastreio. O código e cada mudança de status voltam para a loja, que notifica o cliente.

O caminho inverso também precisa estar desenhado: cancelamento antes do faturamento devolve a reserva; cancelamento depois do faturamento envolve cancelamento da nota ou devolução fiscal, conforme o prazo e a situação da mercadoria; troca e devolução dão entrada no item com o documento correspondente. É comum a integração cobrir só o caminho feliz e deixar o resto para o atendimento.

Falhas, reprocessamento e pedido duplicado

É aqui que a integração se prova: notificação entregue duas vezes, eventos fora de ordem, ERP em manutenção, API lenta no pico.

Pedido duplicado quase sempre vem de retentativa sem proteção: a plataforma reenvia a notificação porque não recebeu confirmação a tempo, e a integração cria o pedido de novo. A defesa é a idempotência: o número do pedido na plataforma é chave única, e receber a mesma mensagem várias vezes tem o mesmo efeito que recebê-la uma vez.

Eventos fora de ordem exigem que cada atualização carregue sua data ou versão de origem. Se um saldo mais antigo chegar depois de um mais novo, ele é descartado em vez de sobrescrever.

ERP fora do ar não pode parar a loja. Com uma fila entre os dois, a loja continua vendendo com o último saldo conhecido (mais conservador se a parada se prolongar), e os pedidos esperam o ERP voltar para entrar em ordem e sem duplicar.

Mensagem que falhou de verdade, como produto sem cadastro fiscal ou cliente com documento inválido, vai para uma fila de exceções com dono, motivo legível e opção de reprocessar depois da correção. Se reprocessar exige chamar o desenvolvedor, a operação volta para a planilha. Os princípios gerais desse tipo de projeto estão em como integrar seu sistema com o ERP sem dor de cabeça.

Por fim, conciliação diária: comparar saldo por SKU e local, pedidos da plataforma contra pedidos no ERP e notas emitidas contra pedidos faturados. Divergência vira alerta, não descoberta no fechamento do mês.

Um cuidado transversal: pedido carrega dados pessoais, e a LGPD (Lei 13.709/2018) vale para a integração como para qualquer sistema. Logs e filas de exceção não devem expor mais dado pessoal do que o necessário, e o acesso a eles precisa ser restrito.

Conector pronto, hub de integração ou desenvolvimento próprio

São três caminhos, e nenhum serve para todos.

ERPs como TOTVS, SAP, Omie e Bling e plataformas como VTEX, Shopify, Nuvemshop e Tray costumam ter integrações nativas ou de parceiros. Vale testá-las com os seus casos difíceis, não com a demonstração. Se a empresa também vende em marketplaces, o hub entra na conversa; as particularidades estão no texto sobre integração com marketplaces: pedidos, estoque e preço.

A integração própria se justifica quando o conector deixa de fora exatamente o que dói: saldo por loja, retirada, reservas com expiração, reprocessamento seguro. Também é comum o desenho misto, com conector para cadastro e camada própria para estoque e pedidos. Essa escolha é uma decisão de arquitetura de software, não de ferramenta.

Os erros que mais aparecem

• Duas fontes da verdade para preço ou cadastro.
• Carga completa como mecanismo principal de estoque, que funciona até o dia da promoção.
• Erro sem dono, guardado num log que ninguém abre.
• Testar só pedido simples. Kit, brinde, cupom, pagamento em dois cartões e retirada na loja precisam estar no roteiro.

Como medir depois de colocar no ar

Meça a situação atual antes de ligar a integração, para ter com o que comparar:

• Pedidos cancelados por falta de estoque, o sinal mais direto de saldo defasado.
• Tempo entre a aprovação do pagamento e o faturamento.
• Pedidos com intervenção manual para chegar ao ERP ou ser faturados.
• Divergências na conciliação diária, por SKU e local.
• Tamanho e idade da fila de exceções, que deveria encolher com o tempo.
• Contatos no atendimento perguntando por nota ou rastreio.

Um roteiro para tirar a planilha do meio

1. Liste as entidades e preencha a tabela de fonte da verdade, direção e frequência.
2. Mapeie os locais de estoque e decida quais alimentam cada canal.
3. Defina a regra de reserva: quando nasce, a que local pertence, quando expira.
4. Escolha o gatilho do pedido: qual status de pagamento libera o envio ao ERP.
5. Transforme os casos difíceis da operação em roteiro de teste e avalie conector, hub ou integração própria contra eles.
6. Desenhe as falhas antes do código: idempotência, fila, exceções, reprocessamento e conciliação.
7. Rode em paralelo com o processo atual, conferindo pedidos e saldos.
8. Desligue a planilha só quando a conciliação bater de forma consistente.

Do mapa de dados ao primeiro pedido integrado

Na Pervian Tech, esse trabalho começa pelo diagnóstico: quais sistemas existem, o que cada um expõe, onde o saldo diverge hoje e quais casos a operação ainda resolve na mão. A partir daí desenhamos a integração sob medida, aproveitando conectores quando eles atendem e construindo só a camada que falta, com fila, idempotência e conciliação desde o início.

O cronograma segue fases (diagnóstico, protótipo, primeiro canal integrado em produção, evolução) e é definido depois do diagnóstico. O investimento é sob consulta, porque depende do número de canais, de locais de estoque e das regras da sua operação. Se a sua loja ainda precisa de planilha para fechar o dia, conte como ela funciona hoje.