A última unidade está no balcão enquanto outra pessoa tenta comprá-la no site. A arquitetura precisa decidir quem a reservou e o que informar ao outro canal. Ter um painel único não prova que essa disputa foi resolvida.
Uma experiência unificada exige um banco único?
Não necessariamente. Sistemas distribuídos podem coordenar a operação com responsáveis, contratos e estados explícitos. Um sistema central também depende de rede, dispositivos e parceiros. Chamar a solução de unified commerce não elimina essas dependências nem garante atualização instantânea.
A documentação da Microsoft sobre o padrão Saga mostra que operações distribuídas podem exigir ações compensatórias quando uma etapa falha. Na loja, cancelar uma reserva e conciliar um pagamento são decisões de negócio que precisam de tratamento específico.
Que cenários pedir na demonstração?
- Dois canais disputam a última unidade: identifique quando a reserva fica válida e como o canal sem saldo responde.
- Um pedido chega repetido: confirme que o identificador externo não produz outra reserva ou cobrança.
- O pagamento falha após a reserva: acompanhe liberação, prazo e atualização da oferta.
- A retirada não acontece no prazo: confira a política de contato, cancelamento e retorno da unidade.
- Uma troca inicia em outro canal: verifique elegibilidade, documento, valor e conciliação antes de prometer atendimento universal.
O guia de orquestração de pedidos define a sequência de referência: entrada, reserva, separação, conferência, NF e etiqueta, despacho e acompanhamento. O ERP ou motor fiscal responde pelo documento; o OMS coordena estados e componentes conforme o escopo.
Como medir consistência?
Guarde horários e identificadores da mudança na origem e no canal. Meça atraso de atualização, reservas expiradas, pedidos duplicados e divergências reconciliadas. O limite aceitável depende da promessa de venda e da capacidade de recuperação; não existe um prazo universal que prove maturidade.
Em um exemplo hipotético, uma reserva válida por quinze minutos vence sem pagamento. O teste deve demonstrar o destino do pedido e quando a unidade volta a poder ser vendida. Se a resposta do pagamento chegar depois, uma política explícita decide o tratamento; não basta reenviar o evento indefinidamente.
Como avaliar a arquitetura Onclick?
ERP Onclick e KPL são núcleos independentes, com bases próprias e sem comunicação entre si. APIECOMM e PDV Web complementam o núcleo escolhido conforme escopo, sem oferta avulsa. A escolha do núcleo precisa anteceder o desenho dos fluxos, sem presumir uma base compartilhada entre os dois.
O curso Automação com n8n e Make ajuda a organizar integrações e tratamento de exceções. A aprovação do projeto deve incluir evidência das disputas, repetições e falhas, além do custo por pedido concluído corretamente.