Comércio eletrônico e integração de ERP: o estoque não pode estar correto em dois lugares ao mesmo tempo

O fato de o mesmo produto apresentar 12 unidades em sua loja, 8 em um marketplace e 5 no depósito não se trata de uma falha na integração. Geralmente, trata-se de uma integração projetada sem que tenha sido definido qual sistema tem autoridade para determinar o valor correto.

A fonte única de verdade

Antes de criar qualquer integração, designe um responsável para cada tipo de dado. O responsável é o único sistema autorizado a alterar esses dados; todos os demais apenas os consultam.

• Estoque → ERP. As mercadorias estão no depósito e o registro do depósito fica no ERP. As lojas e os marketplaces consultam o estoque no ERP e nunca o modificam.
  
• Preço → ERP. Preços específicos por canal são aceitáveis, mas as regras de precificação devem estar em um único local.
  
• Dados do produto → ERP ou um sistema de informações de produtos. Campos técnicos, como código, unidade e peso, ficam no ERP; imagens e textos de marketing podem ficar no site da loja.
  
• Pedidos → Canal. Os pedidos são originados no canal e fluem para o ERP. O ERP os atende; não os altera.
  
• Clientes → ERP. A exclusividade da conta é mantida no ERP.
  

Detalhes importantes na sincronização de estoque

Estoque reservado. Encomendado, mas ainda não despachado. Esse estoque deve ser deduzido do estoque disponível para venda; caso contrário, o mesmo item será vendido duas vezes — o que é crítico nas últimas unidades.

Reserva de segurança. Expor o estoque total a todos os canais leva à venda excessiva durante atrasos na sincronização. Manter uma pequena reserva para itens de alta rotatividade é uma prática comum.

Vários armazéns. Caso a remessa seja feita a partir de mais de um local, é necessário definir qual canal se abastece em qual armazém. Apresentar o estoque total como um único conjunto prejudica o planejamento de expedição.

Frequência de sincronização. Atualizações acionadas por eventos são ideais, mas podem atingir as cotas da API do marketplace. Um compromisso prático: atualização imediata para itens críticos e periódica para os demais.

Fluxo de pedidos

• Correspondência de clientes: Quando a mesma pessoa faz pedidos por meio de canais diferentes, é criada uma única conta? É necessário definir uma regra de correspondência com base no e-mail ou no número de telefone.
  
• Taxas de envio e serviços: Estas devem chegar ao ERP como itens de linha; caso contrário, o total do pedido não corresponderá à fatura.
  
• Comissões e deduções: A comissão do marketplace deve ser registrada como custo; caso contrário, a rentabilidade do canal não poderá ser calculada.
  
• Devoluções e cancelamentos: O fluxo mais frequentemente ignorado. Uma devolução deve repor o estoque e gerar um crédito na conta.
  
• Remessas parciais: O status no canal deve ser atualizado quando apenas parte de um pedido for enviada.
  

Tratamento de erros

Falhas nas integrações: tempo limite da API, cotas esgotadas, formatos inesperados. O que importa não é que as falhas nunca ocorram, mas que elas nunca ocorram silenciosamente:

• As operações com falha são enfileiradas e repetidas automaticamente.
  
• Após um número definido de tentativas, é emitido um alerta.
  
• As mensagens de erro são compreensíveis — “código do produto não encontrado no marketplace”, e não “Erro 500 do servidor interno”.
  
[*]Há uma tela de intervenção manual para que a equipe de operações possa corrigir os problemas sem esperar pela equipe de engenharia.

Rentabilidade por canal

O verdadeiro retorno da integração não é a conveniência operacional, mas a capacidade de visualizar a margem por canal. Isso requer uma marcação de canal em cada pedido e a coleta, no lado dos custos, de comissões, frete, taxa de devolução e custo de embalagem por canal.

Uma vez que esse cálculo esteja disponível, a maioria das empresas descobre que seu canal de maior receita não é necessariamente o mais lucrativo. As decisões mudam com base nesses dados.

Em resumo

Na venda multicanal, o problema não é o número de canais, mas a propriedade indefinida dos dados. Designe um responsável por tipo de dado, atualize o estoque em uma única direção e planeje os fluxos de devoluções e comissões desde o início.

Podemos projetar uma integração adequada aos seus canais com o E-ComMekjoy.