Integração Sankhya ecommerce B2B: pedido, NF e estoque sem falhas

Quando o assunto é Sankhya ecommerce, a conversa com o time de TI raramente trava na parte comercial. Ela trava na arquitetura: o que acontece quando um pedido entra no portal às 23h47, o ERP está em janela de manutenção e o cliente espera a confirmação? Quem garante que o pedido não será duplicado no reenvio? Em que momento o estoque reservado vira estoque baixado?

Essas perguntas definem se a integração entre o Sankhya e o canal digital vai funcionar em produção ou virar uma fila de chamados. Este artigo percorre o ciclo completo, do pedido à nota fiscal e ao retorno de estoque, com foco no que o time de TI precisa deixar claro antes de escrever a primeira linha de mapeamento.

O objetivo não é substituir a documentação do Sankhya, e sim organizar as decisões de arquitetura que costumam ser descobertas tarde demais, quando o canal já está no ar.

O que você vai aprender neste artigo

• O ciclo completo pedido, faturamento e estoque entre portal B2B e Sankhya

• Quais eventos devem disparar sincronização e quais podem esperar a janela

• Como desenhar retry sem gerar pedidos duplicados no ERP

• Por que idempotência é o requisito central da integração

• Como definir a janela de sync para preço, estoque e status

• Onde uma plataforma B2B pronta reduz o esforço de arquitetura

O problema real: dois sistemas com donos diferentes da verdade

Em qualquer projeto de Sankhya ecommerce, a primeira decisão de arquitetura é definir quem é a fonte de verdade de cada dado. O ERP é dono do cadastro fiscal, das tabelas de preço, do estoque contábil e do faturamento. O portal é dono da sessão de compra, do carrinho e da experiência do cliente. O erro clássico é deixar essa fronteira implícita.

Quando a fronteira não está clara, aparecem os sintomas conhecidos: pedido aprovado no portal com estoque que já não existia no Sankhya, preço divergente entre catálogo e nota, status de faturamento que o cliente só descobre ligando para o televendas. Nenhum desses problemas é do ERP nem do portal isoladamente. Todos são problemas de contrato de integração.

Distribuidoras de autopeças, alimentos e material de construção sentem isso de formas diferentes. Em autopeças, o giro alto de SKUs torna a defasagem de estoque o risco número um. Em alimentos, lote e validade entram no ciclo. Na construção, pedidos grandes com faturamento parcial exigem que o status volte ao portal por item, não por pedido. A arquitetura precisa nascer sabendo qual desses cenários é o seu.

O ciclo completo: do pedido no portal à baixa de estoque no Sankhya

O fluxo saudável de uma integração Sankhya ecommerce pode ser descrito em seis etapas, cada uma com um dono e um evento claro:

Repare no padrão: o portal escreve no ERP uma única vez, na criação do pedido. Todo o resto é o Sankhya devolvendo estado. Integrações que permitem escrita bidirecional no mesmo dado, como estoque editável nos dois lados, são as que mais geram inconsistência.

Pedido: síncrono ou assíncrono?

A criação do pedido de venda no Sankhya deve ser assíncrona do ponto de vista do cliente. O portal confirma o recebimento do pedido imediatamente, grava em fila e a integração entrega ao ERP em seguida. Se a entrega ao Sankhya for síncrona com o clique do cliente, qualquer indisponibilidade do ERP vira erro na tela de checkout, e o comprador B2B não tenta de novo: ele manda WhatsApp para o vendedor, e o canal digital perde a confiança que estava construindo.

Nota fiscal: o evento que o cliente mais espera

O retorno do faturamento precisa carregar, no mínimo, número da NF, chave de acesso, XML ou link do DANFE e a relação de itens faturados. Em operações com faturamento parcial, o portal deve tratar o pedido como uma coleção de entregas, não como um estado único. Esse detalhe muda o modelo de dados do portal e é caro de corrigir depois.

Eventos versus janela de sync: o que é tempo real e o que não é

Nem tudo precisa ser evento em tempo real, e tratar tudo como tempo real encarece a integração sem ganho perceptível. Uma divisão que funciona bem na prática:

• Tempo real (evento): criação de pedido, mudança de status de faturamento, bloqueio de crédito. São fatos que o cliente percebe em minutos.

• Janela curta (5 a 15 minutos): saldo de estoque por SKU. A defasagem tolerável depende do giro: quanto maior o giro, menor a janela.

• Janela longa (1 a 24 horas): cadastro de produtos, tabelas de preço por cliente, condições comerciais. Mudam com baixa frequência e podem rodar em lote fora do horário de pico do ERP.

O insight de comportamento que sustenta essa divisão: o comprador B2B tolera uma pequena defasagem de estoque se o portal for honesto sobre ela, mas não tolera comprar um item confirmado e receber um cancelamento no dia seguinte. Por isso muitas operações trabalham com margem de segurança no saldo exposto, reservando um percentual do estoque físico antes de publicar o disponível no canal digital.

Definir a janela também é proteger o Sankhya. Consultas de saldo em alta frequência, feitas SKU a SKU, degradam o banco do ERP. O correto é sincronizar por delta: apenas os SKUs que tiveram movimentação desde a última janela.

Retry e idempotência: o coração da integração Sankhya ecommerce

Toda integração falha em algum momento. Timeout de rede, janela de manutenção do ERP, lock de tabela durante o fechamento. A pergunta de arquitetura não é como evitar a falha, e sim o que acontece depois dela.

Como desenhar o retry

Reenvio imediato e infinito é a receita para amplificar um problema. O padrão recomendado é backoff exponencial com limite: primeira tentativa em segundos, depois minutos, com teto de tentativas antes de mover a mensagem para uma fila de erro com alerta para o time. O pedido nunca se perde; ele espera em um estado visível e auditável.

Por que idempotência não é opcional

O cenário crítico: a integração envia o pedido ao Sankhya, o ERP grava o registro, mas a resposta se perde no timeout. Para a integração, a operação falhou; para o ERP, ela aconteceu. Sem idempotência, o retry cria um segundo pedido de venda, que vira segunda reserva de estoque e, no pior caso, segunda nota fiscal.

A solução é enviar uma chave de idempotência por pedido, um identificador único gerado pelo portal, e garantir que o ERP ou a camada de integração rejeite qualquer tentativa de criação com chave já processada. Antes de reenviar, a integração consulta se o pedido com aquela chave já existe. Reenviar passa a ser seguro por construção, não por sorte.

O mesmo princípio vale na direção contrária: eventos de status vindos do Sankhya podem chegar duplicados ou fora de ordem. O portal deve aplicar atualizações de forma idempotente e descartar eventos mais antigos que o estado atual, usando timestamp ou número de sequência.

Construir a integração ou usar uma plataforma com conector pronto?

Tudo descrito até aqui, fila, retry, idempotência, deltas de sincronização, tratamento de faturamento parcial, é trabalho de engenharia recorrente, não um projeto com fim. Times de TI que constroem essa camada internamente assumem a manutenção dela a cada atualização do ERP e a cada nova regra comercial.

A alternativa é adotar uma plataforma de e-commerce B2B com integração ERP nativa, em que esses padrões já vêm resolvidos. A Zydon mantém conector com o Sankhya que cobre o ciclo completo, pedido, retorno de faturamento, NF e sincronização de estoque e preço por cliente, com a mecânica de retry e deduplicação embutida na plataforma. O time de TI define o mapeamento e as janelas; a plataforma sustenta a operação.

Isso muda o papel da TI no projeto: em vez de escrever e manter middleware, ela governa o contrato de dados e monitora exceções. Para a operação comercial, o resultado é um portal de pedidos B2B que reflete o ERP com fidelidade, sem redigitação e sem os erros que ela carrega.

Perguntas frequentes sobre Sankhya e e-commerce B2B

O Sankhya se integra com e-commerce B2B?

Sim. O Sankhya expõe APIs e mecanismos de integração que permitem conectar um portal B2B ao ciclo de pedido, faturamento e estoque. A qualidade do resultado depende da camada de integração: filas, retry com backoff e idempotência precisam estar presentes para a operação ser confiável.

O que deve ser sincronizado entre o Sankhya e o portal B2B?

Do ERP para o portal: produtos, preços por cliente, condições comerciais, saldo de estoque, status de pedido e dados da nota fiscal. Do portal para o ERP: apenas a criação do pedido de venda. Manter a escrita em uma única direção por dado evita conflitos de fonte de verdade.

Como evitar pedidos duplicados na integração com o ERP?

Com chave de idempotência: cada pedido recebe um identificador único e o ERP rejeita novas criações com a mesma chave. Combinado com consulta prévia antes do reenvio, o retry se torna seguro mesmo após timeouts em que a resposta se perdeu.

Qual a frequência ideal de sincronização de estoque?

Depende do giro. Operações de alto giro trabalham com janelas de 5 a 15 minutos e sincronização por delta, apenas dos SKUs movimentados. Cadastro e tabelas de preço podem rodar em janelas maiores, fora do horário de pico do ERP.

Vale a pena desenvolver a integração internamente?

Só quando há requisitos muito específicos e time dedicado para manter a camada de integração no longo prazo. Para a maioria das distribuidoras e indústrias, um conector pronto e mantido pela plataforma B2B entrega o ciclo completo com menos risco e menos custo de manutenção.

Conclusão: a arquitetura decide o futuro do canal

Um projeto de Sankhya ecommerce bem-sucedido não se mede pela tela do portal, e sim pelo que o cliente não vê: pedidos que chegam ao ERP uma única vez, notas que retornam com a chave correta e estoque que reflete a realidade dentro de uma janela conhecida. Em 2026, com o comprador B2B cada vez mais habituado à autonomia digital, essa confiabilidade é o que separa canais que crescem de canais que voltam para o WhatsApp.

A frase que resume a decisão de arquitetura: integração B2B confiável não é a que nunca falha, é a que falha sem duplicar, sem perder e sem esconder o erro.

Conheça a integração da Zydon com o Sankhya e coloque seu canal B2B em produção com o ciclo completo de pedido, NF e estoque já resolvido.