Conteúdo patrocinado.
Uma venda no e-commerce pode deixar de baixar no estoque porque loja, pagamento e ERP trabalham com estados e atualizações diferentes. A correção exige definir a fonte do saldo e tratar eventos repetidos, cancelamentos e devoluções.
O sistema informa que um pedido está pago, mas a operação encontra um estorno parcial. Em outro caso, a confirmação chega duas vezes e gera duas liberações. Há ainda pedidos que parecem pendentes porque uma notificação não foi processada. Para automatizar a conciliação de pedidos e pagamentos, é preciso tratar essas situações como parte do processo.
A pergunta operacional é: os registros disponíveis sustentam a ação que a empresa pretende executar agora? Liberar um serviço, iniciar uma separação ou encaminhar uma divergência exige critérios diferentes. O fluxo deve relacionar pedido, transação e evento, preservando a explicação de cada mudança.
A venda acontece em um sistema, a disponibilidade mora em outro
Disponível para vender não é igual ao físico no depósito
Separações pendentes, produtos avariados, devoluções sem conferência e pedidos reservados devem ter tratamento próprio. Um único saldo genérico esconde decisões distintas.
Uma loja virtual pode vender um produto que o ERP já reservou para uma venda presencial. O erro costuma surgir quando os dois sistemas tratam estoque como cópias independentes, quando a sincronização ocorre em intervalo longo ou quando um pedido confirmado não gera o evento correto. O resultado aparece na separação: produto indisponível, expedição interrompida, contato de desculpas e eventual cancelamento.
Antes de integrar, a empresa precisa decidir qual sistema será a fonte de verdade para estoque disponível, estoque físico, reservas e devoluções. São números diferentes. Uma unidade separada para um pedido ainda não despachado não deveria continuar disponível para outra venda, embora permaneça fisicamente no depósito.
- Pagamento aprovado não é necessariamente pedido já faturado.
- Cancelamento de pedido não implica devolução instantânea ao saldo vendável.
- Troca com item avariado pode exigir entrada em estoque não comercializável.
- Vendas presenciais e em marketplaces disputam o mesmo saldo.
Relacione identificadores antes de comparar valores
O pedido deve atravessar sistemas com uma referência estável
Número de carrinho, transação financeira e nota fiscal podem ser distintos. O integrador precisa relacioná-los explicitamente para evitar baixa atribuída a pedido errado.
Sem chave de correlação, o relatório de vendas pode estar certo e o estoque continuar errado.
- Referencie o pedido original.
- Grave mudanças de status com data.
- Relacione devoluções aos itens.
- Reprocesse apenas as etapas incompletas.
Um pedido pode ter mais de uma tentativa de pagamento. Uma transação pode receber confirmações, atualizações e ajustes posteriores. Portanto, usar apenas número do pedido e valor total como chave pode misturar acontecimentos distintos.
Defina um identificador interno para o pedido e registre as referências correspondentes nos provedores envolvidos. Quando houver parcelamento, pagamentos parciais ou tentativas substituídas, represente essas relações explicitamente. O desenho deve permitir responder qual transação sustenta cada parcela do estado atual.
Valores também precisam de contexto: moeda, precisão, valor originalmente solicitado e ajustes registrados. Não compare um valor bruto com outro líquido sem saber o que cada campo representa. Se houver taxas ou retenções, documente quais diferenças o modelo admite e quais exigem análise.
Use estados que expliquem a ação possível
Não faça uma baixa definitiva apenas porque recebeu uma notificação. Primeiro confirme a regra do negócio e o estado atual do pedido.
Um campo genérico “pago: sim ou não” pode ser insuficiente para a operação. O modelo abaixo é uma proposta didática; os nomes e transições devem ser adaptados à documentação dos provedores e às regras do negócio.
| Estado operacional | O que significa no modelo | Próxima ação |
|---|---|---|
| Aguardando informação | Ainda não há evidência suficiente | Consultar ou aguardar a fonte definida |
| Compatível com a liberação | Os critérios definidos para aquela ação foram atendidos | Executar uma única vez e registrar |
| Divergente | Há conflito entre referências, estados ou valores | Encaminhar à fila de exceções |
| Alterado após a liberação | Um evento posterior exige reavaliação | Aplicar o procedimento de ajuste |
| Em revisão | Uma pessoa assumiu a análise | Guardar evidência e decisão |
O registro de um pagamento não deve apagar a trajetória anterior. A operação precisa saber qual informação autorizou a ação naquele momento e o que mudou depois. Isso ajuda a corrigir o processo sem reconstruir a história a partir de mensagens soltas.
Um pedido precisa de identificador e estados bem definidos
A separação precisa de uma fila de exceções
O expeditor deve identificar rapidamente pedido sem estoque, endereço incompleto e pagamento em revisão. Essa triagem reduz a tentação de corrigir divergências diretamente no banco de dados.
Em um exemplo hipotético, o cliente compra duas peças no site. O pedido recebe um identificador único, a disponibilidade é reservada e o ERP confirma o recebimento. O gateway comunica o pagamento. A expedição separa os itens e a baixa definitiva segue o momento combinado na regra da empresa. Se a mesma confirmação chegar novamente, ela precisa atualizar o registro existente, não criar outra saída.
| Evento | Tratamento esperado | Conferência |
|---|---|---|
| Pedido criado | Registrar ou reservar conforme política | ID de pedido e itens |
| Pagamento aprovado | Autorizar próxima etapa | Referência financeira |
| Pedido cancelado | Reverter reserva aplicável | Motivo e status de separação |
| Devolução recebida | Conferir condição antes de disponibilizar | Itens recebidos e divergências |
A LOFRANO Tecnologia descreve serviços de automação de pedidos e estoque que partem do processo, das regras e das exceções da operação. No e-commerce, é recomendável começar por um fluxo prioritário e ampliar apenas após conferir os dados dos pedidos reais.
Valide a origem e trate repetição e ordem
A documentação de eventos da Adyen orienta verificar autenticidade e integridade por HMAC antes de processar os dados, além de tratar duplicidade e ordenação. Uma notificação inválida não deve autorizar liberação. No projeto, adote o mecanismo documentado pelo provedor e teste sua validação.
O sistema deve registrar a chegada, reconhecer o evento e avaliar se ele já foi tratado. Reconhecer uma repetição não significa descartar qualquer mensagem parecida: a identificação deve seguir o contrato do provedor, pois eventos posteriores podem carregar mudanças legítimas.
Um estado antigo não deve sobrescrever automaticamente uma situação mais recente. Quando os dados recebidos forem insuficientes para decidir, consulte a fonte definida como referência ou encaminhe a análise. A regra de precedência precisa existir no modelo, especialmente quando integrações diferentes atualizam o mesmo pedido.
Simule um estorno parcial depois da entrega
A devolução parcial não desfaz todo o pedido
Uma troca de apenas um item exige conferir unidades e estados específicos. Reverter o pedido inteiro pode adicionar saldos que não voltaram ao depósito.
- Quantidade efetivamente devolvida.
- Condição do item na chegada.
- Restituição financeira separada.
- Disponibilidade após inspeção.
Imagine uma operação fictícia com um pedido de R$ 1.000. O sistema recebe a evidência prevista para liberação e registra a entrega. Posteriormente, chega uma atualização referente a um estorno de R$ 200. Esse cenário é apenas um exercício de desenho, sem representar um caso de cliente.
Marcar todo o pedido como “não pago” perderia informação. Ignorar o novo evento também seria inadequado. O modelo deve registrar o ajuste, manter o histórico da entrega e encaminhar a situação ao procedimento correspondente. A ação seguinte depende do negócio e não deve ser inventada pela integração.
Agora repita o evento de estorno. O total ajustado não pode passar para R$ 400 por causa de uma retransmissão. Envie também uma confirmação antiga depois do ajuste: ela não deve restaurar a visão anterior sem reavaliação. Esses testes exercitam a lógica que sustenta o saldo operacional do pedido.
Faça da fila de exceções uma ferramenta de trabalho
A divergência só deixa de ser risco operacional quando alguém pode localizá-la, assumir a correção e verificar seu encerramento.
A fila precisa informar o pedido, as referências externas, a diferença encontrada, a última tentativa e o responsável. Uma mensagem como “erro na integração” é insuficiente para orientar a decisão. Categorias como referência ausente, valor incompatível e estado não reconhecido tornam o encaminhamento mais claro.
Defina quais ações podem ser repetidas, quais dependem de confirmação humana e quais exigem intervenção técnica. Toda correção deve registrar autor, momento e justificativa. Se a pessoa ajustar um vínculo entre registros, preserve a informação anterior para permitir revisão.
Também evite que o recebimento de uma notificação seja confundido com conclusão. O evento pode estar armazenado e ainda aguardar processamento. Essa distinção ajuda a identificar se o atraso ocorre na comunicação, na aplicação da regra ou na resolução de uma exceção.
Verifique a cobertura da conciliação
Conte os pedidos que deveriam ter sido sincronizados
Monitorar apenas as mensagens recebidas oculta pedidos que nunca entraram no fluxo. A conferência deve comparar os totais por período, status e origem.
- Confronte amostras de pedidos com o ERP e o estoque físico.
- Registre divergências que exigem intervenção da operação.
- Teste repetição de evento, estorno, devolução e cancelamento.
- Confirme em quais horários ocorre a atualização do saldo.
Uma rotina periódica pode comparar o conjunto de registros esperados com o que foi processado, conforme as interfaces disponíveis. Isso ajuda a encontrar lacunas que um fluxo baseado apenas em notificações não evidenciou. O intervalo deve refletir a necessidade operacional e as limitações das fontes.
Para aceitar a implantação, teste duplicidade, atraso, indisponibilidade temporária, referência desconhecida, pagamento parcial e ajuste posterior. Inclua uma notificação com assinatura inválida: ela não pode alterar o pedido nem autorizar entrega.
Envie também duas confirmações simultâneas para o mesmo pedido. Depois, simule uma interrupção após a liberação, mas antes do registro de conclusão. Ao retomar, o fluxo deve confirmar o efeito já produzido e evitar uma segunda entrega. Isso exige controle de concorrência e uma referência durável para reconhecer a ação. O sucesso deve ser observado no efeito de negócio, além da resposta técnica do conector.
Mapear regras, exceções e registros de execução faz parte do serviço de automação da empresa de desenvolvimento. Em um projeto de conciliação, esses elementos devem ser detalhados para os provedores e sistemas utilizados, permitindo que a operação compreenda tanto as correspondências quanto as divergências.
