{"id":845,"date":"2026-10-23T09:00:00","date_gmt":"2026-10-23T09:00:00","guid":{"rendered":"https:\/\/leiritech.pt\/blog\/mensagem-repetida-nao-duplica-encomenda"},"modified":"2026-10-23T09:00:00","modified_gmt":"2026-10-23T09:00:00","slug":"mensagem-repetida-nao-duplica-encomenda","status":"publish","type":"post","link":"https:\/\/leiritech.pt\/blog\/mensagem-repetida-nao-duplica-encomenda","title":{"rendered":"Mensagem repetida no WhatsApp, uma s\u00f3 encomenda"},"content":{"rendered":"

Mensagem repetida no WhatsApp, uma s\u00f3 encomenda<\/h1>\n

\u00abEu s\u00f3 pedi uma vez. Porque \u00e9 que tenho duas encomendas?\u00bb<\/p>\n

\u00c9 a conversa que queres evitar com o teu cliente. Ele confirma um pedido pelo WhatsApp. A integra\u00e7\u00e3o recebe a notifica\u00e7\u00e3o, cria a encomenda no ERP e, por uma falha na comunica\u00e7\u00e3o, volta a receber o mesmo evento. Se tratar cada entrega como uma nova inten\u00e7\u00e3o de compra, tens duas encomendas para um \u00fanico pedido.<\/p>\n

A resposta do assistente at\u00e9 pode estar impec\u00e1vel. O problema est\u00e1 no que aconteceu depois: duas tarefas de prepara\u00e7\u00e3o, duas reservas de stock ou trabalho administrativo para desfazer o erro.<\/p>\n

A diferen\u00e7a entre responder bonito e integrar o teu ERP aparece aqui. N\u00e3o na capacidade de escrever \u00abpedido recebido\u00bb, mas na capacidade de provar que uma confirma\u00e7\u00e3o s\u00f3 produz uma encomenda, mesmo quando a infraestrutura repete a entrega.<\/p>\n

\"Respons\u00e1vel<\/p>\n

A mesma notifica\u00e7\u00e3o pode chegar mais de uma vez<\/h2>\n

Um webhook \u00e9 uma notifica\u00e7\u00e3o enviada de um sistema para outro. Quando chega uma mensagem, a plataforma avisa a tua integra\u00e7\u00e3o por HTTP. A integra\u00e7\u00e3o acusa a rece\u00e7\u00e3o e trata o evento.<\/p>\n

Segundo a documenta\u00e7\u00e3o de webhooks do WhatsApp da Meta consultada para este artigo, as entregas que falham ou n\u00e3o recebem a resposta HTTP 200 podem ser novamente tentadas durante at\u00e9 sete dias. A pr\u00f3pria documenta\u00e7\u00e3o admite notifica\u00e7\u00f5es repetidas. Isto n\u00e3o significa que todas as mensagens sejam repetidas nem que a plataforma duplique encomendas. Significa que quem constr\u00f3i a integra\u00e7\u00e3o n\u00e3o pode assumir uma entrega \u00fanica.<\/p>\n

Pensa numa chamada telef\u00f3nica que cai depois de dizeres \u00abest\u00e1 confirmado\u00bb. A outra pessoa n\u00e3o sabe se ouviste. Repetir a frase \u00e9 uma forma razo\u00e1vel de recuperar a comunica\u00e7\u00e3o. Repetir a compra n\u00e3o \u00e9.<\/p>\n

H\u00e1 tamb\u00e9m relatos p\u00fablicos da dor na conversa. Na issue 221827 do Odoo, aberta em agosto de 2025 sobre a vers\u00e3o 18.0, um utilizador descreve que o cliente recebe a mensagem duas vezes quando mensagens de entrada e sa\u00edda se cruzam. O relato \u00e9 sobre mensagens, n\u00e3o sobre encomendas duplicadas. N\u00e3o prova uma falha de cria\u00e7\u00e3o de encomendas. Mostra por que motivo conv\u00e9m separar o que aparece no chat do que ficou efetivamente registado no ERP.<\/p>\n

O exemplo: dez caixas, uma confirma\u00e7\u00e3o, duas entregas<\/h2>\n

Imagina um distribuidor. Este \u00e9 um exemplo de teste, n\u00e3o um resultado de uma instala\u00e7\u00e3o Leiritech.<\/p>\n

O cliente pede dez caixas de um artigo. O sistema identifica o cliente e a refer\u00eancia no ERP, apresenta o resumo e recebe a confirma\u00e7\u00e3o. Essa confirma\u00e7\u00e3o fica associada a uma opera\u00e7\u00e3o concreta, por exemplo pedido-482<\/code>. O nome \u00e9 ilustrativo; interessa existir uma identidade est\u00e1vel para aquela decis\u00e3o de compra.<\/p>\n

A primeira entrega do evento leva \u00e0 cria\u00e7\u00e3o da encomenda. O ERP grava-a, mas a resposta perde-se antes de a integra\u00e7\u00e3o conseguir registar o sucesso. Entretanto, chega outra entrega da mesma confirma\u00e7\u00e3o.<\/p>\n

Uma implementa\u00e7\u00e3o ing\u00e9nua volta a executar \u00abcriar encomenda\u00bb. Uma implementa\u00e7\u00e3o preparada reconhece a opera\u00e7\u00e3o e apura o resultado anterior antes de avan\u00e7ar. Se confirmar que a encomenda j\u00e1 existe, associa-lhe a opera\u00e7\u00e3o e devolve a refer\u00eancia existente. N\u00e3o cria uma segunda.<\/p>\n

\u00c9 isto que se procura com idempot\u00eancia<\/strong>: repetir a mesma opera\u00e7\u00e3o n\u00e3o acrescenta outro efeito de neg\u00f3cio. N\u00e3o significa impedir que um cliente fa\u00e7a duas compras iguais. Significa impedir que a infraestrutura transforme uma compra em duas.<\/p>\n

Essa distin\u00e7\u00e3o muda o desenho da integra\u00e7\u00e3o. H\u00e1 duas identidades a preservar: a do evento recebido, para reconhecer a repeti\u00e7\u00e3o da notifica\u00e7\u00e3o, e a da opera\u00e7\u00e3o confirmada, para reconhecer a mesma encomenda ao longo das tentativas de execu\u00e7\u00e3o.<\/p>\n

O texto da mensagem n\u00e3o chega para nenhuma das duas. \u00abQuero dez caixas\u00bb pode ser uma compra leg\u00edtima hoje e outra amanh\u00e3. Eliminar mensagens iguais durante alguns minutos pode esconder a falha t\u00e9cnica \u00e0 custa de apagar pedidos v\u00e1lidos.<\/p>\n

A prote\u00e7\u00e3o tem de existir antes da escrita<\/h2>\n

Uma mem\u00f3ria da conversa n\u00e3o \u00e9 um mecanismo de exclus\u00e3o. Dizer ao modelo \u00abn\u00e3o dupliques encomendas\u00bb tamb\u00e9m n\u00e3o \u00e9. Dois processos podem receber o mesmo evento ao mesmo tempo, consultar o hist\u00f3rico, n\u00e3o encontrar nada e avan\u00e7ar ambos.<\/p>\n

O primeiro controlo \u00e9 uma rece\u00e7\u00e3o dur\u00e1vel. A integra\u00e7\u00e3o valida a origem da notifica\u00e7\u00e3o e guarda o evento antes de acusar a rece\u00e7\u00e3o. A identifica\u00e7\u00e3o deve incluir o contexto necess\u00e1rio, como a empresa ou conta e o identificador da mensagem ou do evento relevante. N\u00e3o basta marcar um pacote inteiro como tratado se esse pacote contiver v\u00e1rios eventos distintos.<\/p>\n

O registo tem de impedir duplicados de forma at\u00f3mica: numa base de dados, uma restri\u00e7\u00e3o de unicidade pode garantir que apenas um processo consegue registar aquela identidade. Consultar primeiro e inserir depois, sem essa prote\u00e7\u00e3o, deixa aberta a corrida entre processos.<\/p>\n

S\u00f3 depois de guardar duravelmente o evento faz sentido devolver o HTTP 200 e continuar o trabalho atrav\u00e9s de uma fila. Assim, a rece\u00e7\u00e3o n\u00e3o fica dependente de esperar pela cria\u00e7\u00e3o da encomenda. Mas isto resolve apenas a entrada. Se o processo cair depois de guardar o evento, tem de existir uma forma de retomar o trabalho; \u00abj\u00e1 recebido\u00bb n\u00e3o pode passar a significar \u00abesquecido\u00bb.<\/p>\n

A opera\u00e7\u00e3o precisa, portanto, de um estado persistente: recebida, em processamento, confirmada ou com resultado por apurar. Uma segunda entrega consulta esse estado. N\u00e3o volta a entregar ao modelo uma autoriza\u00e7\u00e3o em branco para comprar.<\/p>\n

O ponto dif\u00edcil: o ERP gravou, mas ningu\u00e9m recebeu a resposta<\/h2>\n

\"Respons\u00e1vel<\/p>\n

Um timeout diz que n\u00e3o recebeste a resposta a tempo. N\u00e3o diz que o ERP recusou a opera\u00e7\u00e3o.<\/p>\n

Esta \u00e9 a falha que uma demonstra\u00e7\u00e3o sem interrup\u00e7\u00f5es n\u00e3o revela. A integra\u00e7\u00e3o pode guardar todos os eventos corretamente e, ainda assim, duplicar uma encomenda se repetir uma escrita cujo resultado desconhece.<\/p>\n

A melhor prote\u00e7\u00e3o depende da API concreta. Se aceitar uma chave de idempot\u00eancia, todas as tentativas daquela opera\u00e7\u00e3o devem usar a mesma chave. Se permitir uma refer\u00eancia externa com unicidade efetivamente imposta na cria\u00e7\u00e3o, essa refer\u00eancia pode cumprir uma fun\u00e7\u00e3o semelhante. \u00c9 preciso verificar a garantia, a dura\u00e7\u00e3o e o \u00e2mbito dessa prote\u00e7\u00e3o na vers\u00e3o utilizada; um campo chamado \u00abrefer\u00eancia\u00bb n\u00e3o implica unicidade.<\/p>\n

Pesquisar a refer\u00eancia antes de criar ajuda a reconciliar, mas, isoladamente, n\u00e3o fecha o problema. Duas tentativas podem pesquisar ao mesmo tempo e ambas concluir que ainda n\u00e3o existe encomenda. A prote\u00e7\u00e3o da escrita tem de ser garantida no destino ou por um mecanismo que controle efetivamente as tentativas e as falhas relevantes.<\/p>\n

Se a API n\u00e3o oferecer uma forma fi\u00e1vel de distinguir \u00abn\u00e3o foi criado\u00bb de \u00abfoi criado, mas a resposta perdeu-se\u00bb, a op\u00e7\u00e3o segura \u00e9 suspender a repeti\u00e7\u00e3o autom\u00e1tica e encaminhar a opera\u00e7\u00e3o para reconcilia\u00e7\u00e3o. Nesse momento, a mensagem correta \u00e9 \u00abestamos a verificar o registo\u00bb, n\u00e3o \u00aba encomenda falhou\u00bb nem \u00abj\u00e1 est\u00e1 confirmada\u00bb.<\/p>\n

H\u00e1 aqui uma escolha operacional: perante incerteza, preferes atrasar uma confirma\u00e7\u00e3o ou arriscar uma segunda encomenda? A integra\u00e7\u00e3o deve tornar essa decis\u00e3o expl\u00edcita. Prometer \u00abexatamente uma vez\u00bb sem explicar esta fronteira entre sistemas n\u00e3o resolve nada.<\/p>\n

Consultar o ERP n\u00e3o \u00e9 ter autoriza\u00e7\u00e3o para escrever nele<\/h2>\n

Na Leiritech, o acesso conversacional ao ERP \u00e9 apresentado como s\u00f3 de leitura, auditado e fundamentado nos dados do cliente. Essa fronteira importa: consultar uma encomenda e criar uma encomenda s\u00e3o permiss\u00f5es diferentes.<\/p>\n

Um assistente s\u00f3 de leitura pode verificar a exist\u00eancia do pedido, consultar o estado e apresentar a refer\u00eancia que encontrou. N\u00e3o cria documentos, n\u00e3o reserva stock e n\u00e3o deve alegar que executou uma a\u00e7\u00e3o que as suas permiss\u00f5es n\u00e3o permitem.<\/p>\n

Para acrescentar cria\u00e7\u00e3o de encomendas, \u00e9 necess\u00e1rio um fluxo de escrita separado, autorizado e implementado para o teu sistema. O modelo pode ajudar a interpretar o pedido e a apresentar o resumo. A execu\u00e7\u00e3o deve passar por regras determin\u00edsticas: identidade do cliente, empresa certa, artigos v\u00e1lidos, confirma\u00e7\u00e3o, permiss\u00f5es e controlo de repeti\u00e7\u00e3o.<\/p>\n

Ter a resposta fundamentada nos dados reais reduz o espa\u00e7o para inventar refer\u00eancias ou estados. N\u00e3o substitui a prote\u00e7\u00e3o transacional. A linguagem natural trata da conversa; o conector e o ERP t\u00eam de garantir o efeito da opera\u00e7\u00e3o.<\/p>\n

O desenho aqui descrito \u00e9 uma proposta de implementa\u00e7\u00e3o e teste. N\u00e3o \u00e9 uma afirma\u00e7\u00e3o de que qualquer ERP, vers\u00e3o ou conector dispon\u00edvel j\u00e1 oferece estas garantias.<\/p>\n

O custo da duplica\u00e7\u00e3o muda conforme o teu trabalho<\/h2>\n

Num armaz\u00e9m<\/strong>, uma encomenda repetida pode originar uma segunda tarefa de prepara\u00e7\u00e3o. Mesmo que algu\u00e9m detete o erro antes da expedi\u00e7\u00e3o, j\u00e1 houve tempo gasto a separar material ou a desfazer reservas. O teste deve acompanhar a encomenda at\u00e9 \u00e0 tarefa que ela desencadeia, n\u00e3o terminar quando o chat responde.<\/p>\n

Num laborat\u00f3rio de calibra\u00e7\u00e3o<\/strong>, a confirma\u00e7\u00e3o de um servi\u00e7o pode abrir um processo de trabalho associado a equipamentos concretos. Receber outra vez a mesma confirma\u00e7\u00e3o n\u00e3o deve criar um segundo processo para a mesma opera\u00e7\u00e3o. Dois servi\u00e7os efetivamente encomendados continuam, naturalmente, a precisar de identidades diferentes.<\/p>\n

Na sa\u00fade ou num lar<\/strong>, considera um pedido autorizado de consum\u00edveis \u00e0 farm\u00e1cia ou ao fornecedor. Uma confirma\u00e7\u00e3o repetida n\u00e3o deve duplicar a requisi\u00e7\u00e3o. Isto n\u00e3o autoriza um assistente a alterar medica\u00e7\u00e3o ou a executar decis\u00f5es cl\u00ednicas; o exemplo limita-se ao circuito de aprovisionamento e \u00e0s suas permiss\u00f5es.<\/p>\n

Na fatura\u00e7\u00e3o eletr\u00f3nica<\/strong>, quando o processo inclui emiss\u00e3o, uma resposta perdida n\u00e3o permite concluir que o documento n\u00e3o existe. Antes de repetir a opera\u00e7\u00e3o, tens de consultar e reconciliar o resultado pelos mecanismos do sistema aplic\u00e1vel. Um identificador de conversa n\u00e3o substitui a identidade documental nem as regras fiscais.<\/p>\n

Nos quatro casos, o objetivo \u00e9 o mesmo: a repeti\u00e7\u00e3o t\u00e9cnica n\u00e3o pode passar silenciosamente a ser uma nova decis\u00e3o de neg\u00f3cio.<\/p>\n

\"Operadora<\/p>\n

\u00abMas um bot de 25 euros tamb\u00e9m recebe pedidos\u00bb<\/h2>\n

Pode receber, organizar a conversa e encaminhar para a equipa. Isso pode ser exatamente o que precisas. O problema come\u00e7a quando \u00abreceber um pedido\u00bb \u00e9 vendido ou entendido como \u00abexecutar uma encomenda segura no ERP\u00bb.<\/p>\n

Na oferta publicada pela 3HASH em junho de 2026, o conjunto site e WhatsApp soma 25 euros por m\u00eas, com IVA inclu\u00eddo, e tem 100 euros de configura\u00e7\u00e3o. A p\u00e1gina descreve respostas, recolha de contactos e encaminhamento. N\u00e3o especifica uma integra\u00e7\u00e3o ERP nesse pacote. A mesma empresa anuncia integra\u00e7\u00f5es empresariais noutra oferta, sob consulta. N\u00e3o seria correto concluir que n\u00e3o as sabe construir.<\/p>\n

Tamb\u00e9m n\u00e3o seria correto dizer que s\u00f3 a Leiritech conhece este problema. A Agathas, num artigo de outubro de 2026 sobre integra\u00e7\u00e3o ERP\u2013WhatsApp, j\u00e1 descreve fila e deduplica\u00e7\u00e3o. A oportunidade n\u00e3o est\u00e1 em usar uma palavra t\u00e9cnica que ningu\u00e9m conhece. Est\u00e1 em demonstrar que a prote\u00e7\u00e3o funciona no teu ERP, na tua opera\u00e7\u00e3o e quando a comunica\u00e7\u00e3o falha.<\/p>\n

O pre\u00e7o mensal, por si s\u00f3, n\u00e3o prova essa capacidade. Pede o \u00e2mbito e o teste. Um assistente de atendimento e uma integra\u00e7\u00e3o com responsabilidade sobre escritas podem partilhar a janela de chat sem serem o mesmo produto.<\/p>\n

O teste que vale mais do que uma resposta bonita<\/h2>\n

A Black Friday de 2026 \u00e9 a 27 de novembro, data indicada no Calendarr: a 23 de outubro, faltam 35 dias. N\u00e3o \u00e9 uma previs\u00e3o de tr\u00e1fego nem uma raz\u00e3o para ligar escritas \u00e0 pressa. \u00c9 uma janela para testar antes de dependeres do fluxo.<\/p>\n

Num ambiente controlado, sem expedi\u00e7\u00f5es ou emiss\u00e3o fiscal reais, confirma uma encomenda de teste e entrega duas vezes o mesmo evento. Repete tamb\u00e9m com as duas entregas em simult\u00e2neo. Depois simula a interrup\u00e7\u00e3o no ponto mais inc\u00f3modo: o ERP j\u00e1 gravou, mas a integra\u00e7\u00e3o ainda n\u00e3o sabe.<\/p>\n

O resultado aceit\u00e1vel n\u00e3o \u00e9 apenas \u00abo bot respondeu uma vez\u00bb. Deves conseguir seguir a cadeia: evento recebido, opera\u00e7\u00e3o identificada, tentativa de execu\u00e7\u00e3o, refer\u00eancia efetiva no ERP e tratamento da repeti\u00e7\u00e3o. Se o resultado estiver incerto, deve ficar visivelmente pendente, sem nova cria\u00e7\u00e3o autom\u00e1tica.<\/p>\n

Consulta tamb\u00e9m os efeitos seguintes. Uma encomenda \u00fanica com duas tarefas de prepara\u00e7\u00e3o continua a ser uma falha. E faz o teste inverso: duas compras leg\u00edtimas com conte\u00fado igual t\u00eam de continuar a produzir duas opera\u00e7\u00f5es distintas.<\/p>\n

A auditoria deve permitir reconstruir o que aconteceu, com identificadores, estados, instantes e autoriza\u00e7\u00f5es relevantes. N\u00e3o exige guardar indefinidamente conversas completas nem expor dados pessoais a quem n\u00e3o precisa deles. Exige prova suficiente para distinguir uma repeti\u00e7\u00e3o evitada de um pedido perdido.<\/p>\n

Envia para hello@leiritech.com o nome e a vers\u00e3o do teu ERP e a opera\u00e7\u00e3o que queres ligar ao WhatsApp.<\/strong> O pr\u00f3ximo passo \u00e9 definir um teste de repeti\u00e7\u00e3o controlado: duas entregas da mesma confirma\u00e7\u00e3o, uma s\u00f3 encomenda e um registo que explique porqu\u00ea.<\/p>\n","protected":false},"excerpt":{"rendered":"

Se o WhatsApp entregar o mesmo pedido duas vezes, o teu ERP cria duas encomendas? V\u00ea o teste que distingue conversa de integra\u00e7\u00e3o segura.<\/p>\n","protected":false},"author":1,"featured_media":838,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[1049,1046,1047,77,1048,953],"class_list":["post-845","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-integracao","tag-automacao-de-encomendas","tag-encomendas-duplicadas","tag-idempotencia","tag-integracao-whatsapp-erp","tag-webhooks-whatsapp","tag-whatsapp-erp"],"_links":{"self":[{"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/posts\/845","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/comments?post=845"}],"version-history":[{"count":0,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/posts\/845\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/media\/838"}],"wp:attachment":[{"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/media?parent=845"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/categories?post=845"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/tags?post=845"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}