Estoque furado entre marketplaces: por que isso acontece

Por que o estoque furado entre marketplaces acontece

Na maioria das operações o estoque não fura por descuido. Fura porque o número que vai para o canal é o errado: sincroniza-se o saldo total, quando o que o canal precisa saber é o saldo disponível — o que sobra depois de descontar o que já está reservado em pedido não faturado.

O segundo motivo é a janela. Entre uma sincronização e a seguinte existe um intervalo de minutos. Se o mesmo último item é comprado no Mercado Livre e na loja própria dentro desse intervalo, os dois pedidos entram válidos. Nenhum sistema errou; o modelo é que permitiu.

Os três números que não são o mesmo número

Operação que trata os três como um só vende o que já vendeu. É a causa isolada mais comum de cancelamento por falta em marketplace — e cancelamento por falta é o que derruba reputação de vendedor, que custa muito mais caro que o pedido perdido.

Como parar de furar

1. Separe disponível de reservado no seu sistema. Se ele só tem uma coluna de saldo, nenhuma integração vai consertar isso de fora.
2. Mande o disponível para os canais, nunca o físico. Parece óbvio e quase ninguém faz.
3. Reserve no momento do pedido, não no faturamento. Entre pedido e nota podem passar horas; nelas, o item precisa já estar fora da vitrine.
4. Trate o estoque como um registro de movimentos, não um número que se sobrescreve. Com o histórico de entradas e saídas, dá para responder por que o saldo é o que é. Com um número solto, só dá para constatar que está errado.
5. Garanta idempotência na fila de integração. Reprocessar o mesmo pedido não pode criar um segundo pedido — e reprocessar vai acontecer, porque a API do marketplace vai cair.
6. Exija retry com log por etapa. Falha silenciosa é pior que falha ruidosa: o saldo diverge e ninguém descobre até o cliente reclamar.
7. Guarde uma margem de segurança nos itens de giro alto. Não é solução, é rede de proteção enquanto o resto entra no lugar.

Saldo por local, com disponível separado de reservado — é o disponível que vai para os canais.

O que costuma dar errado

Aumentar a frequência da sincronização e achar que resolveu. Reduz a janela, não a fecha. O erro fica mais raro e mais difícil de investigar, o que é pior.

Integração sem idempotência. Uma queda de rede no meio do envio, um reenvio automático, e o pedido entra duas vezes. O estoque se move duas vezes. Ninguém percebe até o inventário.

Não guardar o que a plataforma respondeu. Quando o saldo diverge, a pergunta é "o que mandamos e o que eles aceitaram?". Sem log por etapa — e por tentativa — não há como responder, e a conversa com o suporte do marketplace não sai do lugar.

Cadastro desalinhado entre canais. O mesmo produto com SKU diferente em cada lugar faz a sincronização acertar o item errado. Vincular por GTIN resolve boa parte, e é trabalho de uma vez só.

Tratar devolução como venda negativa. Devolução volta para o físico, mas nem sempre para o disponível — item avariado não pode voltar à vitrine. Quem soma de volta sem conferir cria um furo na direção contrária.

Referência rápida

Se o furo aparece na entrada e não na saída, o problema é outro: a nota do fornecedor que alguém digitou. Se ele aparece só em um dos seus endereços, é saldo por local. E se some pedido em vez de sobrar saldo, a causa costuma ser falta de idempotência na integração.

Quando a conta que não fecha for a de manter quatro sistemas conversando na mão, ela está em o custo escondido da integração manual — e a decisão de manter ou trocar, em integrar ou substituir o Bling, Omie e Bluesoft.