Sincronização de preço e estoque: a rotina que ninguém enxerga
O mecanismo que mantém saldo e preço coerentes em todos os canais, o que sobe do ERP e o que jamais deve descer do canal para dentro do seu inventário.
A sincronização de preço e estoque é aquela rotina que ninguém elogia. Ela roda mais do que qualquer outra coisa no hub e só aparece quando falha. No meu caso, apareceu numa Black Friday, às onze da noite, com 23 pedidos de um item que tinha acabado às oito. O canal continuava mostrando saldo porque a última propagação ficou presa numa fila que eu nem sabia que existia.
O desenho do WAHub parte de uma regra dura: o ERP é dono do saldo e do preço base. O canal recebe atualização, mas não manda no inventário. Quase tudo que vem a seguir é consequência disso.
Se o conceito de fonte única ainda não está firme aí, comece por estoque centralizado para múltiplos marketplaces e volte aqui.
Sincronização de preço e estoque: o que vai em cada sentido
Do ERP para o canal seguem publicação e atualização quando suportadas, preço, estoque, pausa, ativação, afiliação e rastreio. Do canal para o ERP vêm anúncios, produtos e pedidos, conforme a capacidade do conector. Repare que saldo não aparece na segunda lista como sobrescrita. Mesmo quando o canal informa um número, ele não manda.
| Dado | Sentido | Regra aplicada |
|---|---|---|
| Preço | ERP para canal | Preço base com o markup definido na conta |
| Estoque | ERP para canal | Saldo central menos a reserva configurada |
| Estoque informado pelo canal | Canal para ERP | Não substitui o estoque central |
| Pausa e ativação | ERP para canal | Controle de exposição sem apagar o anúncio |
| Pedido | Canal para ERP | Gera baixa atômica e conta a receber |
Delta: só viaja o que mudou
Mandar o catálogo inteiro a cada ciclo seria caro, lento e provavelmente barrado pelo limite de requisições do canal. O hub detecta o delta, ou seja, identifica o que mudou desde o último envio, e enfileira apenas isso.
O comando de sincronização tem modos separados de estoque e de preços, e isso ajuda mais no diagnóstico do que na velocidade. Quando o preço propaga e o saldo não, você já cortou a investigação pela metade antes de abrir qualquer registro.
Rebalanceio depois da venda e do cancelamento
Chegou pedido por um canal, o hub faz a baixa atômica de produto e combinação e em seguida rebalanceia os demais canais com o saldo novo. Cancelou, o estoque é estornado e o rebalanceio acontece de novo, agora para cima.
Esse par é o que evita a venda dupla. O intervalo entre a venda e o rebalanceio é a janela de risco real, e ela encolhe com ciclos mais frequentes, assunto de agendamento das rotinas de sincronização.
Reserva protege, mas cobra pedágio
A reserva por conta existe para absorver a janela de sincronização e os compromissos assumidos em outros canais. Ajustada com critério, evita cancelamento. Ajustada por medo, esconde estoque e derruba sua posição na busca do canal. Vi uma loja reservar 30 por cento de tudo e reclamar que o marketplace não vendia.
- Reserva alta em item de giro lento só cria capital parado invisível
- Reserva em campeão de venda reduz risco de venda dupla em pico
- Reserva precisa ser revista sempre que a frequência de sincronização mudar
- Reserva não conserta contagem física errada
- Reserva não faz sentido em item de dropshipping sem saldo local
Markup por conta e a conta da comissão
Cada conta tem sua regra de markup, o que permite preços diferentes por canal a partir do mesmo preço base. A lógica é direta: canal com custo de intermediação maior precisa de preço final maior para entregar a mesma margem líquida.
Um exemplo apenas ilustrativo. Preço base de 100 reais, canal que fica com 15 por cento sobre a venda. Sem markup, o líquido cai para 85. Com markup calculado para preservar a margem, o preço publicado sobe o suficiente para o líquido voltar ao patamar que você quer. Os percentuais de verdade dependem sempre do contrato de cada canal.
Quando a propagação falha
Canal fora do ar, limite de requisição estourado, token vencido, categoria recusada. Acontece. O hub enfileira, aplica claim otimista, deduplica e tenta até cinco vezes, com intervalos de 1, 5, 15, 60 e 240 minutos. Falha passageira se resolve sozinha. Falha estrutural aparece como falha final no painel.
Entender isso me curou do vício de intervir cedo demais. Antes de recadastrar credencial ou republicar anúncio, veja se o item ainda está dentro da janela de tentativas descrita em fila de sincronização e política de tentativas.
Deixe frequência, reserva e markup escritos num lugar que o comercial consiga abrir sozinho. Depois, combine esses parâmetros com o planejamento de compras de produtos e estoque, para a reposição acompanhar a demanda de todos os canais.