Integração com marketplaces: pedidos, estoque e preço

O produto vendeu no Mercado Livre às 22h, na Shopee às 22h05 e na Amazon às 22h12. Havia duas unidades. Na manhã seguinte, a expedição descobre o problema, alguém cancela um pedido e a conta ganha um cancelamento por falta de estoque na reputação.

Quem vende em mais de um marketplace conhece a cena, e conhece o remédio caseiro: planilha de estoque atualizada à mão, uma pessoa por canal, preço reajustado anúncio por anúncio. Funciona enquanto o volume é pequeno. Depois de alguns canais e algumas centenas de SKUs, o trabalho manual vira o gargalo, e o erro vira rotina.

A seguir: o que muda de um marketplace para outro, como centralizar catálogo, estoque, preço e pedidos sem que cada canal novo vire um projeto do zero, e quando um hub pronto resolve melhor do que desenvolvimento próprio.

Cada marketplace é uma integração diferente

Visto de fora, todo marketplace faz a mesma coisa: exibe o produto, recebe o pedido, cobra o cliente e repassa o dinheiro. Visto pela API, cada um é um mundo:

• Catálogo. Cada canal tem a sua árvore de categorias e a sua ficha técnica. O atributo opcional em um é obrigatório em outro, com outro nome e outra lista de valores aceitos.
• Modelo de anúncio. Em alguns canais o vendedor cria o próprio anúncio. Em outros, como na Amazon e nos anúncios de catálogo do Mercado Livre, ele associa uma oferta a um produto que já existe e disputa a mesma página com outros vendedores.
• Logística. Envio pela logística do marketplace com etiqueta gerada por ele, coleta, postagem em agência, entrega própria ou estoque guardado no armazém do canal (fulfillment). Cada modalidade tem regras próprias.
• Prazos. Cada canal define quanto tempo o vendedor tem para despachar, e o atraso pesa na reputação da conta e na exposição dos anúncios.
• Tarifas. Comissão que varia por categoria e por tipo de anúncio, tarifas por item em alguns casos, participação do vendedor no frete em programas de frete grátis.
• API. Autenticação, limites de requisição, formato das notificações e ciclo de vida do pedido são diferentes em cada um, e mudam com o tempo.

O erro mais comum é integrar o primeiro canal direto no ERP ou na loja virtual, com as regras dele espalhadas pelo código. Funciona. Quando chega o segundo canal, o código vira uma sequência de "se for Mercado Livre, faça isso; se for Shopee, aquilo". No terceiro, ninguém sabe mais o que uma mudança vai quebrar.

A saída é de arquitetura: um núcleo multicanal com um modelo interno único (produto, anúncio, estoque, preço, pedido) e um adaptador por canal, que traduz esse modelo para o dialeto de cada marketplace. As diferenças ficam isoladas nas bordas. Canal novo é adaptador novo, não reforma no sistema inteiro.

Catálogo único, anúncios por canal

O cadastro mestre do produto existe uma vez só: SKU, código de barras (GTIN), peso e dimensões, fotos, descrição base, variações, NCM e dados fiscais. Normalmente ele nasce no ERP, que manda no cadastro fiscal, como detalhamos em integração entre ERP e e-commerce.

O anúncio é outra coisa. Ele deriva do cadastro, mas tem vida própria em cada canal:

• título ajustado ao limite de caracteres e ao jeito de buscar daquele público;
• categoria e atributos mapeados para a árvore do canal;
• variações (cor, tamanho, voltagem) agrupadas conforme a regra de cada um;
• tipo de anúncio, modalidade de envio e preço daquele canal;
• o identificador que o marketplace devolveu, para o sistema saber qual anúncio corresponde a qual SKU.

Separar produto de anúncio evita dois problemas clássicos. O primeiro é a sincronização sobrescrever um título que o time de marketplace otimizou à mão. O segundo é o anúncio órfão: um SKU que saiu de linha e continua ativo em algum canal, vendendo o que não existe mais.

O mapeamento de categorias e atributos merece tratamento de primeira classe: tabelas de-para com tela própria, mantidas por quem entende do negócio, e não constantes escondidas no código. Quando um canal muda a ficha técnica exigida, e isso acontece, o anúncio rejeitado precisa aparecer numa fila de pendências com o motivo, não num log que ninguém lê.

Estoque compartilhado e reserva por canal

Estoque é onde a venda multicanal dói primeiro. O princípio é o de qualquer operação: o canal só enxerga o saldo disponível, que é o físico menos o reservado e o bloqueado. Como calcular e auditar esse saldo está em sistema de gestão de estoque sob medida. Aqui interessa o que muda com vários canais vendendo ao mesmo tempo.

Política de distribuição. Há três formas comuns de repartir o saldo:

Na prática, a política é definida por produto ou por família, não para a empresa inteira. O último par de um tênis não precisa estar em cinco canais; o item com centenas de unidades pode estar em todos.

Reserva no momento da venda. O pedido chega do canal e o saldo é reservado na hora, antes de faturar ou separar. A reserva tem dono, o pedido, e acompanha o estado dele: cancelamento libera, despacho vira baixa. Como cada canal informa o pagamento num momento diferente, a regra precisa dizer o que acontece com o pedido ainda não confirmado.

Publicar o novo saldo nos outros canais. Cada reserva muda o disponível, e o valor novo tem de chegar aos demais canais o quanto antes. A margem de segurança existe para absorver os segundos, às vezes minutos, em que um canal ainda mostra o saldo antigo.

Fulfillment é outro depósito. Estoque guardado no armazém do marketplace pertence àquele canal. Não pode ser oferecido nos outros, e a remessa até lá precisa ser registrada como transferência entre locais, com o trânsito visível e a documentação fiscal correspondente.

Preço por canal e regras de comissão e frete

Mesmo produto, preço diferente por canal, e por motivo concreto: o que sobra para a empresa depende de comissão, tarifas, frete subsidiado e tributos, e cada canal cobra de um jeito. Com vários canais e milhares de anúncios, reajustar preço à mão é garantia de vender com prejuízo em algum lugar.

O núcleo multicanal trata preço como regra, não como número digitado. Os ingredientes:

• Custo de referência do produto, vindo do ERP.
• Custos do canal: comissão por categoria e tipo de anúncio, tarifa por item quando houver, parcela do frete que fica com o vendedor.
• Tributos sobre a venda, conforme o enquadramento da empresa.
• Margem-alvo e margem mínima por família de produto.

Com isso, o sistema calcula o preço de cada canal e, mais importante, bloqueia a publicação abaixo do piso. Promoções criadas no painel do marketplace, campanhas em que a conta entrou e descontos automáticos precisam voltar para o núcleo; sem isso, a margem calculada é ficção. E uma pergunta precisa de resposta clara antes de qualquer código: quem manda no preço de cada anúncio, o núcleo ou o time que opera o painel? Os dois ao mesmo tempo significa sobrescrita mútua.

Em anúncios de catálogo, em que vários vendedores disputam a mesma página, preço e prazo de entrega pesam em quem aparece como oferta principal. Reprecificação automática é possível, mas sempre com piso definido pela margem, nunca só "ficar um centavo abaixo do concorrente".

Pedidos, etiquetas e prazos de envio

O pedido é o fluxo que mais mexe com a operação e o que menos tolera atraso.

Importação e normalização. Cada canal tem os seus estados de pedido, e o núcleo traduz todos para um ciclo interno único: recebido, pago, em separação, faturado, despachado, entregue, cancelado, devolvido. A tabela de tradução mora no adaptador de cada canal.

Faturamento. Quando a empresa vende como lojista no marketplace, a nota fiscal é emitida por ela, pelo ERP ou pelo emissor que já usa. Em várias modalidades de envio, o canal exige os dados da NF-e (chave de acesso ou XML) antes de liberar a etiqueta. A sequência fica assim: pedido pago, reserva, nota autorizada, dados fiscais enviados ao canal, etiqueta. Qualquer elo parado segura a expedição.

Etiquetas e separação. Com a logística do marketplace, a etiqueta vem pronta, em PDF ou no formato das impressoras térmicas. O ganho está em consolidar: uma lista de separação única para todos os canais, ordenada pelo prazo de despacho, e a etiqueta certa impressa na hora de embalar, sem ninguém abrir cinco painéis.

Prazo como prioridade. O prazo de despacho de cada canal vira um campo do pedido, e a tela da expedição mostra primeiro o que vence primeiro. Pedido travado por nota rejeitada ou etiqueta que não saiu gera alerta antes do prazo, não depois.

Cancelamentos e devoluções. O cancelamento feito pelo comprador precisa chegar à expedição antes de o pacote sair. A devolução é um fluxo reverso completo: recebimento, conferência, decisão entre voltar ao estoque vendável ou bloquear, e o tratamento fiscal da devolução.

Hub de mercado ou núcleo multicanal próprio

Não existe resposta única, e desenvolver tudo do zero raramente é a primeira recomendação.

Hub ou conector pronto faz sentido quando:

• a operação é padrão: catálogo simples, um depósito, logística do próprio marketplace;
• são poucos canais, e os que interessam estão cobertos;
• as regras de preço e de distribuição de estoque cabem nas configurações da ferramenta;
• a empresa ainda está descobrindo quais canais valem a pena.

Hubs multicanal e ERPs voltados ao varejo online trazem conectores mantidos pelo fornecedor, que acompanha as mudanças de API de cada marketplace. Isso tem valor real e não deve ser subestimado.

Núcleo próprio começa a fazer sentido quando:

• a regra de preço depende de variáveis que a ferramenta não modela;
• há vários depósitos, fulfillment em mais de um canal ou mais de um CNPJ vendendo;
• no volume da operação, o atraso de sincronização do hub vira cancelamento;
• a empresa precisa de canais que o hub não cobre, como loja própria, venda B2B ou representantes;
• a cobrança do hub, que costuma crescer com pedidos ou anúncios, passa a pesar mais que manter a própria camada de integração.

Híbrido é o caminho mais frequente em empresas médias: o núcleo próprio concentra as regras (catálogo, estoque, preço, prioridade de expedição) e usa conectores prontos como transporte até alguns canais. Trocar de hub, então, não mexe nas regras do negócio.

Se a ideia não é vender em marketplaces de terceiros, e sim operar o seu, o problema é outro: veja como desenvolver um marketplace B2B.

Limites de API, filas e sincronização segura

Nenhuma dessas regras sobrevive a uma comunicação frágil com os canais. É aqui que integrações caseiras falham em produção, geralmente no pior dia: o da campanha.

Tudo passa por fila. Nenhuma venda depende de a API do canal responder naquele segundo. Pedidos entram por uma fila, atualizações de estoque e preço saem por outra, e cada canal tem as suas. Se um marketplace fica instável, os outros continuam sincronizando.

Respeite os limites de requisição. Todo canal limita quantas chamadas uma aplicação ou conta pode fazer num intervalo. Estourou, a resposta é esperar e tentar de novo com intervalo crescente, não insistir. Em campanha, com milhares de alterações de preço e estoque, a vazão precisa ser planejada.

Prioridade e consolidação. Zerar o estoque de um item esgotado vale mais que atualizar a descrição de outro. E se o saldo de um SKU mudou dez vezes em um minuto, só o último valor importa: o sistema consolida e envia uma atualização.

Saldo absoluto, não diferença. "O disponível agora é 7", com horário, é seguro de repetir e de receber fora de ordem. "Diminua 1" não é: reenviado, baixa duas vezes.

Notificação avisa, varredura confirma. Os canais notificam pedidos novos e mudanças, mas notificação atrasa e se perde. Uma rotina periódica busca os pedidos recentes de cada canal e compara com o que já foi importado. O identificador do pedido no canal é a chave de idempotência: importar o mesmo pedido duas vezes não pode gerar duas reservas.

Credenciais que expiram. A autorização com os marketplaces costuma usar tokens de validade curta e renovação periódica. Renovação que falha em silêncio é a causa clássica de canal parado sem ninguém perceber. O monitoramento mostra, por canal, a última sincronização bem-sucedida.

Conciliação diária. Saldo publicado em cada canal contra saldo calculado pelo núcleo; pedidos do canal contra pedidos importados. Divergência vira lista de ação, não surpresa.

Esses padrões valem para qualquer integração, e o guia geral está em como integrar seu sistema com o ERP. Desenhar essa camada é trabalho de arquitetura de software, porque as decisões tomadas aqui definem quanto vai custar, lá na frente, cada canal novo.

Erros que se repetem

• Integrar o primeiro canal direto. O atalho vira dívida no segundo.
• Duas mãos no mesmo dado. Preço alterado no painel e no núcleo; estoque ajustado no canal e no ERP.
• Estoque compartilhado sem folga em item de alto giro.
• Esquecer que fulfillment é outro local. O saldo do armazém do canal aparece como disponível para todos.
• Integração sem monitoramento. O canal parou de sincronizar na sexta e ninguém viu até segunda.
• Devolução tratada como exceção manual. O produto volta, mas o estoque não.

Como medir se funcionou

Meça antes de começar, para ter com o que comparar:

• cancelamentos por falta de estoque, por canal;
• pedidos despachados fora do prazo de cada canal;
• tempo entre a venda e a reserva, e entre a reserva e a atualização nos demais canais;
• anúncios rejeitados ou pausados por erro de cadastro;
• margem real por canal, conciliando a comissão e o frete efetivamente descontados no repasse com o que o preço previa;
• esforço para colocar um canal novo no ar.

Por onde começar

1. Diagnóstico. Canais atuais e desejados, volume de pedidos e de SKUs, depósitos, modalidades de envio e onde o trabalho manual acontece hoje.
2. Fonte da verdade. Quem manda em cada dado: cadastro, preço, estoque, pedido, nota.
3. Modelo interno e primeiro adaptador. Começar pelo canal de maior volume, com estoque e pedidos antes de preço automático.
4. Operação assistida. Rodar em paralelo, conciliando todo dia, até a divergência sumir.
5. Evolução. Novos canais como novos adaptadores, regras de preço, prioridade de expedição e devoluções.

O cronograma de cada fase é definido depois do diagnóstico, quando o tamanho real do problema está na mesa.

Onde a Pervian Tech entra

A Pervian Tech desenha e constrói núcleos multicanal sob medida: modelo único de catálogo, estoque e pedidos, um adaptador por marketplace e integração com o ERP que a empresa já usa, com filas, conciliação e monitoramento desde o primeiro canal. Quando um hub pronto resolve, dizemos isso também, e o projeto pode combinar os dois.

Cada operação tem canais, depósitos e regras de preço próprios, então o investimento é definido sob consulta, depois do diagnóstico. Se a planilha ainda é o que segura os seus canais, conte como a sua operação vende hoje e começamos por entender onde ela trava.