Por que minha loja online vende produtos que não tenho em estoque?

Isso é overselling: vender ou aceitar mais unidades do que as realmente disponíveis. Quase sempre é um problema de arquitetura, não de falta de cuidado. Uma causa comum em operações multicanal é o estoque existir como um número global que é sobrescrito, em vez de como um histórico de movimentações transacionais. Quando vários canais (loja, marketplace, ponto de venda) acessam o mesmo estoque simultaneamente, e ainda há atrasos ou desencontros de sincronização entre os sistemas, dois deles podem vender a mesma unidade ao mesmo tempo sem que nenhum perceba.

Sincronizar mais rápido entre sistemas resolve o overselling?

Não. Há duas limitações técnicas reais que tornam impossível uma sincronização verdadeiramente instantânea: os rate limits das APIs dos marketplaces e o fato de que, mesmo sem esses limites, sempre existe uma janela entre uma venda e o momento em que os outros sistemas tomam conhecimento dela. A solução é mudar como o estoque é modelado, e não sincronizar com mais frequência.

Qual é a diferença entre modelar o estoque como um número global e como um histórico de movimentações?

Estoque como número global significa armazenar um único valor mutável ('tenho 40 unidades') que é sobrescrito a cada venda, perdendo o contexto do que está alocado a pedidos pendentes, em trânsito ou em quarentena. O estoque transacional registra cada entrada, saída e reserva como um evento em um histórico e calcula a disponibilidade a partir dele. Assim, mesmo que vários canais vendam simultaneamente, fica um registro claro do que aconteceu e não é possível vender o mesmo item duas vezes.

A faturação eletrônica pode bloquear uma venda?

Sim, se a confirmação da venda e a emissão do comprovante fiscal estiverem acopladas na mesma transação: qualquer lentidão ou indisponibilidade do SIFEN bloqueia a venda inteira. A solução é separar as duas etapas — confirmar a venda primeiro e emitir o comprovante depois, como uma etapa desacoplada — para que uma indisponibilidade pontual do SIFEN não impeça o cliente de concluir a compra.

Como o Pymerce lida com a sincronização de estoque entre canais?

O Pymerce implementa duas decisões de arquitetura: estoque como histórico de movimentações transacionais por localização e produto, em vez de um número global mutável, e separação entre o registro da venda e a comunicação com o SIFEN, que ocorre depois como etapa desacoplada. Ele usa um banco de dados transacional como fonte de verdade, webhooks como gatilho principal e polling com reconciliação periódica como contingência. O mecanismo específico de reserva ou allocation para prevenir vendas concorrentes no mesmo instante não está documentado publicamente.

Um histórico de movimentações evita overselling por si só?

Não, por si só. Um ledger de movimentações fornece fonte de verdade e rastreabilidade — você sabe o que aconteceu e quando —, mas impedir que dois canais vendam a mesma unidade no mesmo instante também exige reservas ou alocação de estoque com uma política de expiração ou compensação, além do tratamento correto de concorrência e idempotência no sistema que processa as vendas.

O SIFEN precisa aprovar um comprovante antes de concluir uma compra online?

Não necessariamente. A venda e a transmissão do comprovante à DNIT são dois momentos distintos: o emissor pode gerar e assinar o Documento Eletrônico no momento da venda e enfileirar a transmissão ao SIFEN para concluí-la dentro do prazo fixado pela norma (até 72 horas a partir da assinatura eletrônica no modelo transacional diferido), sem bloquear a operação comercial — desde que o regime aplicável ao emissor permita isso.

Se eu uso webhooks, ainda preciso de polling ou reconciliação?

Sim. Webhooks falham ou não chegam por diversos motivos (timeouts, plataformas que não os suportam, erros pontuais), e em integrações entre sistemas externos não se deve presumir consistência instantânea. Por isso, o padrão recomendado combina webhooks como gatilho principal com polling e reconciliação periódica como contingência para detectar e corrigir eventos perdidos.

Voltar ao blog

Integrar ecommerce ao ERP no Paraguai: como evitar overselling e automatizar a faturação eletrônica

25 de setembro de 2026

integração ecommerce ERP Paraguai
sincronização de estoque multicanal
evitar overselling Paraguai
faturação eletrônica ecommerce Paraguai
arquitetura de estoque transacional
automação de pedidos Paraguai
SIFEN e ecommerce

ResumoO overselling quase nunca é falta de cuidado; é arquitetura: quando o estoque existe como um número global em vez de um histórico de movimentações por localização, dois canais podem vender a mesma unidade ao mesmo tempo. Sincronizar mais rápido não resolve isso. Um histórico de movimentações (ledger) fornece fonte de verdade e rastreabilidade, mas prevenir vendas concorrentes também exige reservas ou alocação de estoque e o tratamento correto de concorrência e idempotência — além de separar a confirmação da venda da transmissão do comprovante fiscal, como faz o Pymerce, a plataforma de gestão da Flexora.

Overselling é vender ou aceitar mais unidades de um produto do que as que estão realmente disponíveis. Em operações multicanal, atrasos ou desencontros na sincronização de estoque entre sistemas são uma causa frequente.

O sintoma: vender algo que você já não tem

Se o seu ecommerce já está em produção e você vende em mais de um canal (loja própria, marketplace ou ponto de venda físico), é provável que, em algum momento, um cliente tenha comprado um produto que na verdade não estava disponível. Isso é overselling. Em operações multicanal, o risco aumenta quando os diferentes sistemas não compartilham uma visão suficientemente atualizada e consistente do estoque.

Como descreve a Cin7, esses atrasos ou desencontros de sincronização aparecem especialmente quando a mesma operação vende em mais de um canal. Em integrações que sincronizam em lotes (batch), em vez de em tempo real, essa janela pode ficar em torno de 15 a 30 minutos, segundo a Bizowie — não é uma duração universal; depende de como cada integração está configurada. Um produto é vendido em um canal às 10:05, mas, se o outro sistema sincroniza a cada 25 minutos, só ficará sabendo às 10:30. Durante essa janela, o produto aparece disponível em todos os lugares, embora já não esteja.

Sincronizar com mais frequência reduz a janela de desatualização, mas não resolve sozinho o problema de concorrência e disponibilidade.

Por que isso acontece: estoque como número global vs. estoque como registro transacional

A maioria dos sistemas básicos trata o estoque como uma quantidade global: “tenho 40 unidades do produto X”. Mas, na operação real, essas 40 unidades nunca são um único número homogêneo. Segundo a análise da Bizowie, o estoque existe simultaneamente em múltiplos estados — alocado a pedidos pendentes, em trânsito, em quarentena e realmente disponível —, e um sistema que reduz tudo a um único contador perde essa distinção.

Há ainda uma questão estrutural: em integrações entre sistemas externos, não se deve presumir latência zero nem consistência instantânea. Rate limits de APIs, processamento assíncrono, entrega de eventos, falhas pontuais e tempo de propagação influenciam. Por mais otimizada que esteja a integração, sempre há uma janela, por menor que seja.

A combinação de um modelo de disponibilidade excessivamente simples com sincronização não instantânea aumenta o risco de overselling em operações multicanal, especialmente quando vários canais competem pelo mesmo estoque.

Um padrão mais robusto: estoque por localização e produto com movimentações históricas

Em vez de manter um contador global mutável, um padrão mais robusto é controlar o estoque como uma série de movimentações transacionais por localização e produto: cada entrada, saída e reserva fica registrada como um evento, e a disponibilidade é calculada a partir desse histórico, em vez de sobrescrever um número.

É exatamente isso que implementamos no Pymerce, a plataforma de gestão e vendas da Flexora: o estoque não é um campo atualizado in place; é um histórico de movimentações por localização e produto. Essa decisão de design oferece rastreabilidade completa e uma fonte central para calcular a disponibilidade de forma consistente: mesmo que múltiplos canais de venda acessem o mesmo estoque, cada movimentação fica registrada e é possível detectar e reconciliar inconsistências. Um ledger de movimentações resolve isso — rastreabilidade e fonte de verdade —, mas prevenir disputas entre vendas simultâneas (dois canais reservarem a mesma unidade no mesmo instante) também requer mecanismos de reserva ou alocação de estoque e controle de concorrência no sistema que processa as vendas.

Essa abordagem está alinhada ao que a ECOSIRE documenta sobre arquiteturas de sincronização em tempo real (uma fonte secundária sobre arquitetura de mercado, não normativa, mas consistente com padrões amplamente documentados na indústria): usar um banco de dados transacional como fonte de verdade, webhooks como gatilho principal das atualizações e polling com reconciliação periódica como contingência nos casos em que o webhook falha ou a plataforma não o suporta.

Quando pedido, pagamento e estoque são executados em serviços ou sistemas independentes, um padrão comum para coordená-los é o padrão Saga: cada etapa local é executada e confirmada separadamente e, se uma falhar (por exemplo, o pagamento), as etapas anteriores são revertidas por uma ação compensatória, em vez de depender de uma única transação distribuída (documentado pela Temporal). Aplicado ao estoque, isso significa reservar a unidade como parte da saga do pedido e liberá-la se o pagamento não for concluído, em vez de deixá-la bloqueada indefinidamente — uma reserva pendente de pagamento não é a mesma coisa que “consistência eventual” no sentido estrito do termo; é uma compensação explícita dentro de um fluxo de negócio.

O papel da faturação eletrônica no fluxo do pedido

Um segundo ponto de design é evitar acoplar desnecessariamente a confirmação da venda à comunicação fiscal dentro de uma única operação síncrona.

A documentação do Adobe Commerce indica que um pedido permanece editável e cancelável até que o pagamento seja recebido e o comprovante seja gerado — o momento exato em que a faturação é acionada depende de como o método de pagamento está configurado; não é um instante fixo universal.

No Paraguai, a faturação eletrônica sob o SIFEN separa três momentos distintos, segundo o Decreto N° 872/2023 e as perguntas frequentes do e-Kuatia da DNIT: primeiro, o emissor gera e assina digitalmente o Documento Eletrônico (DE) e o envia ao comprador; segundo, transmite esse XML assinado à DNIT para seu processo de aprovação; terceiro, a DNIT valida o documento e, se o aprovar, o converte em Documento Tributário Eletrônico (DTE), com validade jurídica, força probatória e incidência tributária. O modelo transacional do e-Kuatia (voltado a emissores médios e grandes) opera de forma diferida: a norma estabelece, de modo geral, que a transmissão deve ser concluída em até 72 horas após a data e a hora da assinatura eletrônica qualificada, embora a DNIT possa estabelecer prazos menores ou exigir aprovação prévia conforme o perfil do emissor.

Informações sobre o SIFEN revisadas em 25/09/2026.

Isso significa que, quando o regime aplicável ao emissor permite, a integração pode desacoplar a resposta do SIFEN do fluxo comercial: a venda é confirmada e o DE é gerado e assinado imediatamente, enquanto a transmissão à DNIT é enfileirada e repetida dentro do prazo correspondente caso o serviço fique lento ou apresente uma indisponibilidade pontual. No Pymerce, resolvemos isso separando o registro da venda da comunicação com a autoridade fiscal, para não confundir a emissão do comprovante (que ocorre no momento fiscal aplicável à operação) com sua transmissão e aprovação (que seguem o cronograma definido pela norma para cada perfil de emissor).

Este artigo não aborda custos nem prazos de implementação de faturação eletrônica no Paraguai — para isso, veja quanto custa integrar SIFEN com a DNIT.

Não existe um único evento técnico do ecommerce — fulfillment, captura de pagamento ou confirmação de envio — que determine universalmente quando a emissão do comprovante deve ser acionada: esse momento fiscal depende da operação e do perfil do emissor. O que tem regras explícitas é a transmissão do DE à DNIT depois de gerado, tendo o prazo de 72 horas como referência geral do modelo transacional.

Problema	Padrão útil	Limitação
Contador global de estoque	Ledger de movimentações	Não resolve a concorrência por si só
Vendas simultâneas	Reservas / alocação	Exige política de expiração ou compensação
Eventos de sincronização perdidos	Webhooks + polling	A consistência não é instantânea
Disponibilidade do SIFEN	Transmissão desacoplada	É preciso respeitar o momento de emissão e os prazos da DNIT

O que revisar na sua operação agora

Se você percebe overselling recorrente, revise isto antes de pensar em sincronizar mais rápido:

Seu estoque é modelado como um número global que é sobrescrito ou como um histórico de movimentações por localização e produto?
A confirmação da venda depende de que a comunicação com a autoridade fiscal termine com sucesso ou são duas etapas desacopladas?

Essas são duas decisões de arquitetura que vale a pena revisar primeiro quando surgem overselling ou vendas bloqueadas em integrações ecommerce-ERP.

Na Flexora, trabalhamos essas integrações por meio de serviços de e-commerce e automações e integrações. O módulo de ecommerce do Pymerce, que aplica esses mesmos padrões de estoque transacional e faturação desacoplada, está atualmente em desenvolvimento, em sua fase final.

Se você ainda está na fase de planejar seu ecommerce do zero, o checklist inicial está em o que um ecommerce precisa no Paraguai.

Fontes citadas

Perguntas frequentes

Por que minha loja online vende produtos que não tenho em estoque?: Isso é overselling: vender ou aceitar mais unidades do que as realmente disponíveis. Quase sempre é um problema de arquitetura, não de falta de cuidado. Uma causa comum em operações multicanal é o estoque existir como um número global que é sobrescrito, em vez de como um histórico de movimentações transacionais. Quando vários canais (loja, marketplace, ponto de venda) acessam o mesmo estoque simultaneamente, e ainda há atrasos ou desencontros de sincronização entre os sistemas, dois deles podem vender a mesma unidade ao mesmo tempo sem que nenhum perceba.
Sincronizar mais rápido entre sistemas resolve o overselling?: Não. Há duas limitações técnicas reais que tornam impossível uma sincronização verdadeiramente instantânea: os rate limits das APIs dos marketplaces e o fato de que, mesmo sem esses limites, sempre existe uma janela entre uma venda e o momento em que os outros sistemas tomam conhecimento dela. A solução é mudar como o estoque é modelado, e não sincronizar com mais frequência.
Qual é a diferença entre modelar o estoque como um número global e como um histórico de movimentações?: Estoque como número global significa armazenar um único valor mutável ('tenho 40 unidades') que é sobrescrito a cada venda, perdendo o contexto do que está alocado a pedidos pendentes, em trânsito ou em quarentena. O estoque transacional registra cada entrada, saída e reserva como um evento em um histórico e calcula a disponibilidade a partir dele. Assim, mesmo que vários canais vendam simultaneamente, fica um registro claro do que aconteceu e não é possível vender o mesmo item duas vezes.
O que é o padrão Saga e como ele ajuda com o estoque no ecommerce?: Quando pedido, pagamento e estoque executam em serviços independentes, o padrão Saga coordena essas etapas: cada uma é executada e confirmada separadamente e, se uma falhar (por exemplo, o pagamento), as etapas anteriores são revertidas por uma ação compensatória, em vez de depender de uma única transação distribuída. Aplicado ao estoque, a unidade é reservada como parte da saga do pedido e liberada se o pagamento não for concluído — é uma compensação explícita dentro do fluxo de negócio, não a mesma coisa que 'consistência eventual' em sentido estrito.
A faturação eletrônica pode bloquear uma venda?: Sim, se a confirmação da venda e a emissão do comprovante fiscal estiverem acopladas na mesma transação: qualquer lentidão ou indisponibilidade do SIFEN bloqueia a venda inteira. A solução é separar as duas etapas — confirmar a venda primeiro e emitir o comprovante depois, como uma etapa desacoplada — para que uma indisponibilidade pontual do SIFEN não impeça o cliente de concluir a compra.
Como o Pymerce lida com a sincronização de estoque entre canais?: O Pymerce implementa duas decisões de arquitetura: estoque como histórico de movimentações transacionais por localização e produto, em vez de um número global mutável, e separação entre o registro da venda e a comunicação com o SIFEN, que ocorre depois como etapa desacoplada. Ele usa um banco de dados transacional como fonte de verdade, webhooks como gatilho principal e polling com reconciliação periódica como contingência. O mecanismo específico de reserva ou allocation para prevenir vendas concorrentes no mesmo instante não está documentado publicamente.
Um histórico de movimentações evita overselling por si só?: Não, por si só. Um ledger de movimentações fornece fonte de verdade e rastreabilidade — você sabe o que aconteceu e quando —, mas impedir que dois canais vendam a mesma unidade no mesmo instante também exige reservas ou alocação de estoque com uma política de expiração ou compensação, além do tratamento correto de concorrência e idempotência no sistema que processa as vendas.
O SIFEN precisa aprovar um comprovante antes de concluir uma compra online?: Não necessariamente. A venda e a transmissão do comprovante à DNIT são dois momentos distintos: o emissor pode gerar e assinar o Documento Eletrônico no momento da venda e enfileirar a transmissão ao SIFEN para concluí-la dentro do prazo fixado pela norma (até 72 horas a partir da assinatura eletrônica no modelo transacional diferido), sem bloquear a operação comercial — desde que o regime aplicável ao emissor permita isso.
Se eu uso webhooks, ainda preciso de polling ou reconciliação?: Sim. Webhooks falham ou não chegam por diversos motivos (timeouts, plataformas que não os suportam, erros pontuais), e em integrações entre sistemas externos não se deve presumir consistência instantânea. Por isso, o padrão recomendado combina webhooks como gatilho principal com polling e reconciliação periódica como contingência para detectar e corrigir eventos perdidos.