Sincronizar stock e encomendas entre loja e ERP

Para sincronizar stock e encomendas entre a loja online e o ERP, é preciso definir qual dos sistemas manda em cada dado e como as alterações passam para o outro. O stock disponível pode seguir do ERP para a loja, enquanto as encomendas seguem da loja para o ERP, com regras próprias para reservas e cancelamentos. A ligação deve identificar os artigos sem ambiguidades, impedir registos duplicados e guardar os pedidos pendentes quando um dos sistemas falha.

Que dados devem passar da loja para o ERP e no sentido contrário?

A expressão «sincronização nos dois sentidos» pode esconder um problema: permitir que ambos os sistemas alterem o mesmo campo sem uma regra de prioridade. Convém atribuir uma origem principal a cada informação e documentar as exceções.

Uma distribuição a avaliar é esta:

Esta tabela é uma proposta de organização, não uma descrição das capacidades de todas as versões de PHC, Primavera ou Moloni. Antes de escolher a ligação, é necessário confirmar o produto e a versão instalados, os acessos disponíveis e as operações que a integração consegue executar.

Também deve ficar escrito quando uma encomenda passa para o ERP: ao ser criada, depois do pagamento ou após validação manual. O momento escolhido afeta a reserva de stock e o tratamento dos pagamentos que ficam pendentes.

Para enquadrar o restante percurso, o artigo sobre como automatizar pagamentos, faturação, envios e mensagens de uma loja online trata das etapas que ficam fora desta sincronização.

Como evitar erros nos códigos de artigo e conflitos de stock?

Cada artigo vendável precisa de uma correspondência inequívoca entre os sistemas. O nome comercial não deve ser usado como identificador: pode mudar, repetir-se ou aparecer escrito de maneira diferente.

O código de artigo, muitas vezes designado SKU, deve identificar a mesma unidade de venda na loja e no ERP. Cada variante que tenha stock próprio precisa da sua correspondência. Se os códigos existentes forem diferentes, deve existir uma tabela que relacione o identificador da loja com o do ERP, sem obrigar a alterar todo o catálogo.

Antes de ligar a sincronização, há que procurar códigos repetidos, referências em falta e diferenças nas unidades. Uma embalagem e uma unidade individual não podem ser tratadas como equivalentes sem uma regra de conversão explícita.

O stock exige outra decisão: stock físico e stock disponível para venda não devem ser confundidos. A disponibilidade publicada deve refletir as reservas e os armazéns autorizados para vendas online. Se for usada uma margem de segurança, esta deve entrar numa regra documentada.

No Moloni, a API de artigos permite definir stock por armazém e, com gestão de armazéns, o stock global pode resultar da soma dos stocks enviados para esses armazéns. Por isso, antes de publicar uma quantidade global na loja, convém confirmar se todo esse stock pode realmente satisfazer encomendas online.

Quando existem vendas simultâneas em canais diferentes, a integração deve prever reservas e uma validação da disponibilidade no momento definido para aceitar a encomenda. Ainda assim, não se deve prometer ausência de conflitos: é necessário decidir o que acontece quando chega uma encomenda para um artigo que entretanto deixou de estar disponível.

Com que frequência deve ser feita a sincronização?

A frequência deve acompanhar o risco de vender stock desatualizado. Artigos com muita rotação ou poucas unidades disponíveis justificam atualizações mais próximas da alteração. Um catálogo com pouca movimentação pode admitir sincronização periódica, desde que a empresa aceite o intervalo de desatualização.

Há duas formas principais de organizar a passagem dos dados:

• Por evento: uma alteração desencadeia o envio para o outro sistema. Serve quando os sistemas permitem comunicar essas alterações e a disponibilidade precisa de ser atualizada rapidamente.
• Por consulta periódica: a integração procura novidades em intervalos definidos. Serve quando não existe um mecanismo de aviso adequado ou quando o processo tolera algum atraso.

Pode combinar-se o envio por evento com uma verificação periódica de diferenças. O primeiro tenta transmitir a alteração logo que acontece; a segunda procura alterações que tenham ficado por tratar.

A frequência de consulta deve respeitar as condições técnicas dos sistemas. Também é preciso distinguir «enviado» de «confirmado»: um pedido só deve ficar concluído depois de existir confirmação do destino.

A interface de programação, ou API, é o meio pelo qual os programas trocam dados. Na integração com o Moloni, por exemplo, a documentação determina que os pedidos à API sejam enviados por POST. São requisitos a validar na implementação, mesmo que a gestão diária não exija conhecer esses detalhes.

O que acontece quando a loja, o ERP ou a ligação falham?

A falha deve deixar um registo visível, não uma encomenda esquecida. O plano de recuperação precisa de distinguir uma indisponibilidade temporária de um erro nos dados: repetir um pedido não resolve um código de artigo inexistente.

O tratamento deve seguir uma sequência:

1. Guardar a operação pendente, com a sua origem e um identificador único.
2. Registar o resultado de cada tentativa, distinguindo falta de resposta de rejeição explícita.
3. Repetir os pedidos que possam ser recuperados, sem criar outra encomenda para a mesma compra.
4. Encaminhar os erros de dados para uma pessoa responsável, com informação suficiente para os corrigir.
5. Depois da recuperação, comparar os registos dos sistemas e investigar as diferenças.

O identificador único merece atenção especial. Se o ERP tiver aceite uma encomenda, mas a resposta não tiver chegado à loja, repetir a criação sem verificar o resultado pode duplicá-la. A integração deve conseguir reconhecer que aquela compra já foi tratada.

Durante uma interrupção, também é necessário decidir se a loja continua a vender com a última disponibilidade conhecida, restringe determinados artigos ou suspende a venda dos produtos afetados. A escolha depende do risco comercial e deve ficar definida antes da falha.

Para investigar diferenças no Moloni, a consulta de movimentos de stock permite filtrar por armazém, dia e artigo. Esta consulta pode apoiar a verificação, mas a equipa continua a precisar de um registo das operações da integração para perceber onde ocorreu a divergência.

Como escolher e validar a ligação antes de a colocar em produção?

Um conector existente pode ser suficiente quando cobre os sentidos dos dados, os estados das encomendas e as regras de stock pretendidas. Convém avaliar o comportamento perante erros e a possibilidade de recuperar operações, em vez de decidir apenas pela presença dos nomes da loja e do ERP na descrição.

Uma integração à medida faz sentido quando ficam regras essenciais por cumprir, como reservas específicas ou correspondências complexas de artigos. A página sobre software à medida e a comparação com soluções por licença ajuda a enquadrar essa escolha, sem assumir que desenvolver de raiz é sempre preferível.

Antes da entrada em produção, os testes devem incluir uma compra normal, repetição do mesmo pedido, pagamento pendente e cancelamento. Devem também simular-se falhas de comunicação e alterações de stock durante a recuperação. O resultado esperado de cada teste deve estar escrito e ser validado por quem gere as encomendas.

No caso RR Customs, a AI Solutions automatizou o atendimento multicanal e a recuperação de carrinhos, com uma base de dados de produtos sincronizada com a loja WooCommerce. O ponto comum com este tema é a necessidade de manter informação de produtos coerente entre sistemas, embora o caso não documente uma sincronização de stock e encomendas com um ERP.

O próximo passo prático é preparar uma folha com os campos a sincronizar, o sistema responsável por cada campo e o comportamento esperado em caso de erro. Juntar referências reais do catálogo e encomendas em estados diferentes permite avaliar uma solução com critérios concretos, antes de autorizar alterações nos sistemas em produção.

Perguntas frequentes

É necessário sincronizar todo o catálogo logo no início?

Não. Pode começar-se por um conjunto controlado de artigos, desde que fique claro quais estão abrangidos e como são tratados os restantes. A expansão deve acontecer depois de validar encomendas, reservas e recuperação de erros.

Um cancelamento deve repor stock automaticamente?

Depende do estado da encomenda. Cancelar antes da expedição pode implicar libertar uma reserva; uma devolução exige confirmar o regresso e a condição do produto antes de o disponibilizar novamente.

A sincronização deve criar também a fatura?

Só se esse passo estiver previsto no processo e tiver validações próprias. Criar a encomenda, confirmar o pagamento e emitir a fatura devem ser tratados como operações distintas, com estados e tratamento de erros definidos.