Integração de ERP com plataforma e-commerce B2B: guia técnico completo por sistema
A integração entre ERP e plataforma de e-commerce B2B é, consistentemente, o componente mais subestimado de qualquer projeto de digitalização B2B. Empresas planejam 3 semanas para integração e entregam em 12. Estimam R$ 40.000 e gastam R$ 180.000. Vão ao ar com integração "funcionando" e descobrem em produção que estoque atualiza a cada 4 horas — não em tempo real.
Este guia não é uma visão geral do tema. É um mapa técnico para quem vai executar a integração ou avaliar se o fornecedor escolhido tem capacidade para fazê-la corretamente.
Arquiteturas de integração: qual modelo escolher
Antes de falar em ERP específico, é preciso entender que existem três arquiteturas possíveis — e a escolha errada vai custar caro.
API REST: o padrão moderno e o único recomendável para B2B de médio e grande porte
A integração via API REST permite comunicação bidirecional em tempo real entre a plataforma B2B e o ERP. Quando um cliente faz um pedido no portal, o pedido entra no ERP em segundos. Quando o estoque muda no ERP, o portal reflete a mudança em minutos.
Como funciona na prática:
- A plataforma B2B expõe endpoints para receber pedidos e retornar status
- O ERP expõe endpoints para consulta de estoque, preço, crédito e cadastro de clientes
- Um middleware (que pode ser proprietário do fornecedor da plataforma ou desenvolvido pelo cliente) orquestra as chamadas entre os dois sistemas
Quando usar: sempre que o ERP tiver API disponível e o volume de transações justificar o investimento em integração robusta (acima de 30 pedidos/dia, praticamente qualquer operação de médio porte).
Cuidado: "ter API" não é o mesmo que "ter API bem documentada e estável". Antes de comprometer com esse modelo, peça ao fornecedor do ERP o changelog das últimas 3 versões da API. APIs que mudam sem versionamento correto quebram integrações sem aviso.
EDI (Electronic Data Interchange): para grandes redes varejistas e operações de alto volume padronizado
O EDI é a troca de arquivos estruturados em formatos padronizados (EDIFACT, X12, ANSI) entre sistemas. Não é integração em tempo real — as trocas acontecem em lotes programados (a cada 2 horas, diariamente, etc.).
Quando faz sentido: operações B2B que precisam integrar com grandes redes de varejo (Carrefour, Assaí, Atacadão) que operam nativamente com EDI. Também para fornecedores industriais com fluxo de pedidos altamente padronizado e previsível.
Limitação crítica: latência. Se o seu modelo de negócio exige que o comprador veja estoque atualizado em tempo real, EDI não serve. Em distribuição de alimentos com estoque volátil, um lote de atualização a cada 2 horas pode gerar pedidos de produtos indisponíveis.
Integração por arquivo (CSV/XML): solução temporária, não definitiva
O ERP exporta um arquivo em formato tabular ou XML em horário programado; a plataforma importa. Simples de implementar, difícil de manter e inaceitável como solução permanente para qualquer operação com volume relevante.
Quando tolerar: fase de piloto com ERP legado sem API disponível, enquanto se planeja a integração robusta. Ou para sincronização de dados menos sensíveis ao tempo, como catálogo de produtos que não muda com frequência.
Nunca usar para: estoque em tempo real, status de pedido, crédito disponível.
Dados críticos: o que precisa integrar e como
Independente do ERP e da arquitetura escolhida, estes são os fluxos de dados que toda integração de e-commerce B2B precisa cobrir:
1. Estoque disponível por produto (e por depósito)
Direção: ERP → Plataforma B2B
Frequência ideal: tempo real ou máximo 5 minutos de latência
Complexidade: alta em operações com múltiplos centros de distribuição
O portal precisa mostrar o estoque real disponível para venda — não o estoque total, mas o estoque disponível após reservas, pedidos em processamento e estoques de segurança. Em ERPs bem configurados, esse dado existe como "saldo disponível" ou "quantidade disponível para comprometer" (ATP — Available to Promise).
Armadilha comum: integrar o estoque físico bruto em vez do estoque disponível para venda. O cliente faz pedido de 50 caixas, o estoque diz 80 disponíveis, mas 60 já estão comprometidas com outros pedidos. A venda acontece, o ERP bloqueia. Conflito.
Para operações com múltiplos CDs: a plataforma precisa decidir de qual CD o pedido vai ser atendido — e mostrar a disponibilidade do CD correto para aquele cliente/região. Isso exige lógica de roteamento que precisa estar clara antes da integração.
2. Tabela de preços por cliente
Direção: ERP → Plataforma B2B
Frequência ideal: tempo real para mudanças urgentes, diariamente para manutenção rotineira
Complexidade: muito alta — é o ponto que mais falha em integrações B2B
No ERP, a precificação B2B é armazenada de formas diferentes dependendo do sistema:
- TOTVS Protheus: tabelas de preço (TES) com hierarquia de cliente × produto × quantidade
- SAP: listas de preços (condition records) com condições de acesso
- Sankhya: tabelas de preço associadas a grupos de clientes
O portal precisa receber, para cada cliente autenticado, o preço exato que aparecerá no carrinho. Isso significa que a integração precisa suportar:
- Preço base por produto
- Desconto por cliente específico
- Desconto por volume (tabela progressiva)
- Preço especial por campanha ou período
- Preço diferente por canal (distribuidor vs. revendedor)
Por que isso falha: a lógica de precificação no ERP é frequentemente complexa, com regras sobrepostas e exceções históricas. "Extrair o preço correto para o cliente X do produto Y" parece simples — até você descobrir que tem 7 condições de preço que se aplicam em hierarquia diferente dependendo do volume.
3. Envio de pedidos (Plataforma → ERP)
Direção: Plataforma B2B → ERP
Frequência: tempo real (cada pedido aprovado deve entrar no ERP imediatamente)
Complexidade: alta
O pedido que chega do portal precisa ser "traduzido" para a linguagem do ERP. Isso inclui:
- Dados do cliente: código do cliente no ERP (não só o CNPJ), endereço de entrega, condição de pagamento
- Dados dos produtos: código interno do ERP (que pode ser diferente do código exibido no portal), unidade de medida, quantidade
- Dados fiscais: tipo de operação, CFOP, regime tributário do comprador, destino (dentro ou fora do estado)
- Dados comerciais: representante responsável, tabela de preço usada, desconto aplicado
A integração precisa mapear cada campo do pedido no portal para o campo correspondente no ERP — e tratar os casos onde esse mapeamento não é direto.
4. Status do pedido e da entrega (ERP → Plataforma)
Direção: ERP → Plataforma B2B
Frequência: a cada mudança de status (event-driven) ou polling a cada 15 minutos
Complexidade: média
O cliente precisa saber, em tempo real, o status do pedido: recebido, em análise de crédito, aprovado, em separação, faturado, em trânsito, entregue.
Cada um desses status vive em tabelas diferentes do ERP — e o mapeamento entre "status do ERP" e "status legível pelo cliente no portal" precisa ser definido explicitamente.
Integração com transportadoras: o status de "em trânsito" e "entregue" frequentemente vive no sistema da transportadora, não no ERP. A integração completa exige também conexão com a API da transportadora (ou com um sistema de TMS que agrega múltiplas transportadoras).
5. Crédito disponível por cliente
Direção: ERP → Plataforma B2B
Frequência: tempo real ou a cada transação
Complexidade: alta em operações com gestão de crédito sofisticada
O portal precisa saber, antes de confirmar um pedido, se o cliente tem crédito disponível. Três situações possíveis:
- Crédito suficiente: pedido confirmado normalmente
- Crédito insuficiente: pedido bloqueado, cliente notificado, fluxo de aprovação especial acionado
- Cliente sem política de crédito: pedido condicional a pagamento antecipado
A integração precisa consumir o saldo de crédito disponível do ERP — e atualizar esse saldo após cada pedido aprovado.
Integração por ERP: especificidades de cada sistema
TOTVS Protheus
O Protheus é o ERP mais comum em indústrias e distribuidoras de médio porte no Brasil. A integração com plataformas e-commerce B2B tem características específicas que quem não conhece o sistema não antecipa.
API disponível: o Protheus tem o framework REST/HTTP que expõe endpoints configuráveis via ADVPL. As versões mais recentes (12.1.27 em diante) têm API mais estável, mas versões anteriores exigem desenvolvimento de endpoints customizados.
Pontos de atenção:
- O Protheus trabalha com o conceito de "empresa" e "filial" — pedidos, estoques e tabelas de preço podem estar segregados por filial. A integração precisa saber de qual filial está operando.
- Customizações são extremamente comuns em instalações de Protheus. Um campo padrão pode ter sido reutilizado para armazenar dados customizados — e a integração pode estar lendo dados errados sem saber.
- O controle de transações (commit/rollback) no Protheus tem particularidades que afetam integrações assíncronas. Pedidos em processamento podem aparecer como "enviados" no portal antes de terem sido efetivamente processados no ERP.
Estratégia recomendada: para integrações com Protheus, exija que o fornecedor da plataforma apresente pelo menos 3 cases de integração com a mesma versão e módulos que você usa. A variação entre versões e customizações é enorme.
SAP Business One (B1)
O SAP B1 é comum em empresas de médio porte com operação mais estruturada. A integração é tecnicamente mais previsível que o Protheus porque o B1 tem estrutura de dados mais padronizada e API bem documentada.
API disponível: o SAP B1 Service Layer (desde a versão 9.2) é uma API RESTful robusta e bem documentada, com suporte a OData. É a forma recomendada de integração para plataformas e-commerce B2B modernas.
Pontos de atenção:
- O Service Layer tem rate limiting — em volumes altos de pedidos simultâneos, a integração pode ser throttled. Planejar circuit breakers e filas de envio.
- Preços no B1 são gerenciados via Price Lists, que têm uma hierarquia de aplicação. É preciso entender a lógica de prioridade de listas de preço para extrair o preço correto por cliente.
- O B1 usa o conceito de Business Partner para clientes — e a integração precisa mapear o código de BP do portal para o código correto no B1.
Vantagem: o SAP B1 tem um ecossistema grande de parceiros de integração no Brasil, e a documentação da API é suficientemente completa para que integradores experientes não precisem de suporte do SAP para implementar.
SAP S/4HANA
Para empresas enterprise que usam S/4HANA, a integração é tecnicamente mais sofisticada e exige um projeto dedicado. A maioria das plataformas B2B de médio porte não tem conector nativo para S/4HANA — e as que dizem ter geralmente têm integrações limitadas que não cobrem todos os fluxos críticos.
API disponível: S/4HANA expõe APIs via SAP API Business Hub (OData e REST). A documentação é extensa, mas o modelo de dados é complexo.
Estratégia recomendada: para S/4HANA, o caminho mais robusto é usar SAP Integration Suite (anteriormente SAP Cloud Platform Integration) como middleware, em vez de integração direta. Isso adiciona custo mas garante manutenção de longo prazo e suporte do próprio SAP.
Sankhya
O Sankhya é muito usado em distribuidoras, atacadistas e empresas de serviços no Brasil. A integração tem características específicas do modelo de dados do sistema.
API disponível: o Sankhya tem API REST própria (SankhyaW API) que cobre os principais fluxos. A documentação é menos abrangente que SAP, mas cobre os casos de uso de e-commerce B2B.
Pontos de atenção:
- O modelo de pedidos no Sankhya usa o conceito de "cabeçalho + itens" com campo NUNOTA como chave de controle. A integração precisa tratar corretamente a geração desse identificador.
- Tabelas de preço no Sankhya são gerenciadas por grupos de clientes — a integração precisa consultar o grupo do cliente para buscar a tabela correta.
- Integrações com Sankhya frequentemente precisam de endpoints customizados (chamados "Sankhy Scripts") para operações que a API padrão não cobre.
Senior Sistemas
Usado principalmente no setor de varejo e distribuição no sul e sudeste do Brasil.
API disponível: Senior tem API REST (Senior X Platform) que cobre os principais fluxos de integração. Integrações de e-commerce B2B com Senior são menos comuns, então o pool de integradores com experiência específica é menor.
Tratamento de erros: o que fazer quando a integração falha
A integração vai falhar. Não "pode falhar" — vai falhar. A questão é ter um plano para cada tipo de falha antes que elas aconteçam em produção.
Tipos de falha e estratégia de resposta
Timeout na comunicação com o ERP O portal enviou o pedido, mas o ERP não respondeu em tempo hábil. O pedido foi processado no ERP? Não foi? Está em fila?
Estratégia: implementar idempotency keys — cada pedido tem um identificador único que permite ao ERP identificar e ignorar reenvios duplicados. Nunca reenviar sem verificar primeiro se o pedido já existe.
ERP fora do ar (manutenção ou falha) O ERP ficou indisponível por 2 horas durante o horário de pico.
Estratégia: definir comportamento do portal durante a indisponibilidade. Opções:
- Aceitar pedidos e colocar em fila para processamento posterior (recomendado para operações com clientes que precisam de continuidade)
- Bloquear novos pedidos e exibir mensagem de indisponibilidade (mais seguro, menos UX)
- Aceitar pedidos com estoque "congelado" (risco de oversell)
Erro de mapeamento de dados O pedido chegou ao ERP mas falhou na criação por dado inválido — código de produto inexistente, CFOP incorreto, condição de pagamento não mapeada.
Estratégia: logs detalhados de erro com payload completo, alertas automáticos para a equipe técnica, fila de pedidos com erro para reprocessamento manual ou automático após correção.
Divergência de dados entre portal e ERP O cliente fez pedido de 100 unidades que o portal mostrava como disponíveis. O ERP rejeitou porque, no momento do processamento, o estoque havia zerado.
Estratégia: reserva de estoque no momento em que o cliente adiciona ao carrinho (não só no checkout), com tempo de expiração. Mais complexo de implementar, mas elimina a maioria das divergências.
Monitoramento de integração em produção
Uma integração que não é monitorada é uma integração que vai quebrar silenciosamente. As falhas de integração silenciosas — onde o portal continua funcionando mas os dados estão incorretos — são as mais perigosas porque ninguém percebe até o cliente reclamar.
Métricas que precisam estar em dashboard
Taxa de sucesso de pedidos integrados: percentual de pedidos enviados do portal que foram processados com sucesso no ERP. Meta: acima de 99,5%. Qualquer queda abaixo de 98% requer investigação imediata.
Latência de sincronização de estoque: tempo médio entre uma mudança de estoque no ERP e a atualização no portal. Meta: abaixo de 5 minutos para operações em tempo real.
Taxa de divergência de preço: percentual de pedidos onde o preço calculado no portal foi diferente do preço no ERP. Meta: zero. Qualquer divergência indica problema no conector de preços.
Volume de pedidos em fila de erro: pedidos que chegaram ao portal mas não foram integrados com sucesso. Meta: zero em produção estável. Qualquer pedido em fila de erro por mais de 1 hora exige alerta.
Latência de status de pedido: tempo entre uma mudança de status no ERP e a atualização no portal para o cliente. Meta: abaixo de 15 minutos.
Alertas automáticos essenciais
- Taxa de sucesso de integração cai abaixo de 98% nos últimos 30 minutos
- ERP não respondeu nos últimos 5 minutos
- Mais de 5 pedidos em fila de erro simultâneos
- Divergência de preço detectada em qualquer pedido
- Sincronização de estoque não ocorreu nas últimas 30 minutos
Como avaliar se o fornecedor de plataforma sabe integrar com seu ERP
Estas são as perguntas que separam fornecedores com experiência real de fornecedores que dizem que "suportam integração com TOTVS":
- Quantas implementações em produção vocês têm com o TOTVS Protheus 12.1.X? (substitua pela sua versão específica)
- Qual a versão mais antiga do meu ERP que vocês integraram com sucesso nos últimos 12 meses?
- Quem foi o responsável técnico pela última integração com esse ERP? Posso falar com ele?
- Como vocês tratam customizações no ERP que afetam os campos de preço e estoque?
- Qual o SLA para correção de falhas de integração em produção? E quem paga pelo retrabalho se o ERP lançar uma atualização que quebre o conector?
- Vocês têm ambiente de homologação que espelha o ambiente de produção do meu ERP?
- Como é feito o monitoramento da integração em produção? Vocês têm acesso aos logs ou eu preciso abrir chamado para investigar falhas?
Se o fornecedor hesitar em qualquer uma dessas perguntas, trate como sinal de alerta — não como detalhe menor.
Checklist de pré-implementação de integração
Antes de iniciar qualquer desenvolvimento de integração:
Do lado do ERP:
Do lado da plataforma B2B:
Dados para limpar antes da integração:
A FastChannel mantém conectores certificados para TOTVS Protheus, SAP Business One, Sankhya e outros ERPs brasileiros, com equipe técnica especializada em cada sistema e histórico de implementações em diferentes versões e configurações. Para entender a especificidade da integração com o seu ERP, visite fastchannel.com.