{"id":129,"date":"2026-09-23T09:00:00","date_gmt":"2026-09-23T09:00:00","guid":{"rendered":"https:\/\/leiritech.pt\/blog\/nao-duplicar-encomenda-erp-idempotencia"},"modified":"2026-09-23T09:00:00","modified_gmt":"2026-09-23T09:00:00","slug":"nao-duplicar-encomenda-erp-idempotencia","status":"publish","type":"post","link":"https:\/\/leiritech.pt\/blog\/nao-duplicar-encomenda-erp-idempotencia","title":{"rendered":"N\u00e3o cria a encomenda duas vezes: escrever no ERP a s\u00e9rio"},"content":{"rendered":"

N\u00e3o cria a encomenda duas vezes: o que separa a demo da produ\u00e7\u00e3o<\/h1>\n

O cliente escreve no WhatsApp: "sim, confirma essas 40 caixas". Passam tr\u00eas segundos, a rede treme, ele n\u00e3o v\u00ea o visto azul e escreve outra vez: "confirmado?". Do outro lado, o teu assistente autom\u00e1tico processou as duas mensagens. E agora tens duas ordens de 40 caixas no armaz\u00e9m, dois picking slips a sair da impressora, e algu\u00e9m da equipa a passar a manh\u00e3 a perceber se o cliente quer 40 ou 80.<\/p>\n

Esta \u00e9 a parte que nenhuma demo bonita te mostra. Responder a uma pergunta \u00e9 f\u00e1cil. Escrever no teu ERP sem estragar nada \u00e9 que \u00e9 o trabalho<\/strong> \u2014 e \u00e9 exatamente a\u00ed que o bot de \u20ac25 e o agente ligado ao teu sistema deixam de ser a mesma coisa.<\/p>\n

\"Operador<\/p>\n

Um "ok" repetido n\u00e3o \u00e9 uma ordem nova<\/h2>\n

O problema tem nome de engenharia: idempot\u00eancia<\/strong>. Traduzindo para linguagem de opera\u00e7\u00f5es \u2014 uma a\u00e7\u00e3o idempotente pode ser executada duas, tr\u00eas, dez vezes e o resultado \u00e9 sempre o mesmo que se fosse executada uma vez s\u00f3. Carregar duas vezes no bot\u00e3o do elevador n\u00e3o chama dois elevadores. Um "ok, confirma" repetido n\u00e3o deve criar duas encomendas.<\/p>\n

Parece \u00f3bvio dito assim. Mas o software n\u00e3o sabe, por defeito, que a segunda mensagem \u00e9 a mesma inten\u00e7\u00e3o da primeira. Para ele s\u00e3o dois pedidos distintos, cada um a bater \u00e0 porta do ERP a dizer "cria a ordem". Se ningu\u00e9m desenhou a prote\u00e7\u00e3o, o ERP obedece \u00e0s duas. E os motivos para a mensagem chegar em duplicado s\u00e3o triviais e di\u00e1rios: o cliente impaciente que reenvia, a app que faz retry<\/em> autom\u00e1tico quando o Wi\u2011Fi falha, o webhook da Meta que entrega o mesmo evento duas vezes porque n\u00e3o recebeu confirma\u00e7\u00e3o a tempo. N\u00e3o \u00e9 um caso raro de laborat\u00f3rio \u2014 \u00e9 ter\u00e7a-feira de manh\u00e3.<\/p>\n

O que o bot de \u20ac25 faz (e o que n\u00e3o faz)<\/h2>\n

O bot comoditizado, no melhor cen\u00e1rio, n\u00e3o escreve no teu ERP<\/strong> \u2014 ele "anota" a inten\u00e7\u00e3o num gui\u00e3o e algu\u00e9m da tua equipa transcreve \u00e0 m\u00e3o para o sistema. A\u00ed a duplica\u00e7\u00e3o \u00e9 um problema humano: a pessoa v\u00ea duas mensagens iguais, hesita, pergunta ao cliente, perde tempo. Custo escondido, mas ainda recuper\u00e1vel.<\/p>\n

No pior cen\u00e1rio, ligaram o bot ao ERP por um webhook<\/em> qualquer sem pensar no dia mau. A\u00ed a duplica\u00e7\u00e3o vira uma ordem a mais que j\u00e1 entrou no picking, j\u00e1 reservou stock que n\u00e3o existe, e talvez j\u00e1 gerou uma fatura. Agora n\u00e3o \u00e9 hesita\u00e7\u00e3o \u2014 \u00e9 uma nota de cr\u00e9dito, um cliente irritado e stock bloqueado.<\/p>\n

A diferen\u00e7a n\u00e3o est\u00e1 em qual dos dois "conversa melhor". Est\u00e1 em quem foi desenhado para o momento em que as coisas correm mal<\/strong>.<\/p>\n

Como se escreve no ERP a s\u00e9rio: a chave de idempot\u00eancia<\/h2>\n

Um agente feito para produ\u00e7\u00e3o resolve isto com tr\u00eas pe\u00e7as, e nenhuma delas \u00e9 magia:<\/p>\n

    \n
  1. \n

    Chave de idempot\u00eancia.<\/strong> No instante em que a conversa gera a inten\u00e7\u00e3o "criar encomenda", o agente calcula uma chave est\u00e1vel a partir do que a define \u2014 cliente, artigos, quantidades, janela de tempo. Essa chave viaja com o pedido de escrita. O ERP (ou a camada de integra\u00e7\u00e3o \u00e0 frente dele) guarda-a. Chega um segundo pedido com a mesma chave? O sistema responde "j\u00e1 processei este" e devolve a mesma<\/strong> ordem que criou \u00e0 primeira, em vez de criar outra. O cliente pode carregar em "confirma" as vezes que quiser: a ordem n\u00famero 2026\/1487 continua a ser uma s\u00f3.<\/p>\n<\/li>\n

  2. \n

    Estado de confirma\u00e7\u00e3o expl\u00edcito.<\/strong> O agente n\u00e3o salta da conversa para a escrita. Ele constr\u00f3i um rascunho, mostra-o \u2014 "40 caixas, artigo X, para entrega quinta, confirmas?" \u2014 e s\u00f3 o "sim" transita o estado de rascunho<\/em> para confirmado<\/em>. Entre os dois h\u00e1 uma fronteira clara, n\u00e3o uma infer\u00eancia a partir do tom da frase.<\/p>\n<\/li>\n

  3. \n

    Log de auditoria por origem.<\/strong> Cada tentativa de escrita fica registada: quem pediu, quando, com que chave, qual foi a resposta do ERP, e se foi uma cria\u00e7\u00e3o nova ou um pedido repetido ignorado. Quando o cliente ligar a dizer "recebi duas confirma\u00e7\u00f5es", tens a resposta em dez segundos, com o trilho, em vez de um encolher de ombros.<\/p>\n<\/li>\n<\/ol>\n

    \"Contabilista<\/p>\n

    O mesmo problema muda de fato conforme o setor<\/h2>\n

    Armaz\u00e9m e log\u00edstica.<\/strong> A duplica\u00e7\u00e3o come stock. Reservas o dobro, o picking bloqueia mercadoria que ia para outro cliente, e o invent\u00e1rio deixa de bater com a prateleira. A escrita idempotente mant\u00e9m uma ordem = uma reserva.<\/p>\n

    Fatura\u00e7\u00e3o eletr\u00f3nica.<\/strong> Aqui n\u00e3o h\u00e1 "desfazer" f\u00e1cil. Uma fatura emitida em duplicado numa plataforma como o SII no Chile ou o e-invoicing da AT em Portugal \u00e9 um documento fiscal com folio consumido e comunica\u00e7\u00e3o feita ao Estado. Corrigir significa nota de cr\u00e9dito, novo documento, e uma conversa com a contabilidade. A chave de idempot\u00eancia \u00e9 o que impede que o segundo "emite" gere um segundo DTE assinado.<\/p>\n

    Sa\u00fade e cuidados.<\/strong> Numa casa de repouso, uma ordem de medica\u00e7\u00e3o registada duas vezes n\u00e3o \u00e9 um custo \u2014 \u00e9 um risco cl\u00ednico. Um sistema de circuito fechado com leitura de c\u00f3digo de barras confirma a administra\u00e7\u00e3o uma<\/strong> vez, e recusa a segunda leitura da mesma dose com uma mensagem clara, deixando o registo auditado que a norma exige.<\/p>\n

    Calibra\u00e7\u00e3o e QMS.<\/strong> Um certificado de calibra\u00e7\u00e3o emitido em duplicado quebra a rastreabilidade que a ISO te obriga a manter. O n\u00famero do certificado tem de ser \u00fanico por origem, e o sistema tem de garantir isso \u2014 n\u00e3o confiar em que o t\u00e9cnico n\u00e3o carregou duas vezes.<\/p>\n

    \"Enfermeira<\/p>\n

    Porque \u00e9 que um agente grounded ganha ao bot que adivinha<\/h2>\n

    Um chatbot baseado em gui\u00e3o ou s\u00f3 num modelo de linguagem adivinha<\/strong> a resposta a partir de padr\u00f5es de texto. N\u00e3o tem no\u00e7\u00e3o de estado: para ele, cada mensagem \u00e9 nova, sem mem\u00f3ria do que j\u00e1 escreveu no mundo real. \u00c9 por isso que a duplica\u00e7\u00e3o lhe escapa \u2014 ele n\u00e3o sabe que j\u00e1 criou a ordem porque n\u00e3o \u00e9 ele que a cria, \u00e9 o teu sistema, e ele nunca olhou l\u00e1.<\/p>\n

    Um agente grounded<\/em> trabalha ao contr\u00e1rio: antes de agir, consulta o teu ERP<\/strong> (read-only, auditado) para saber o que j\u00e1 existe. "Este cliente j\u00e1 tem uma ordem aberta com estes artigos criada h\u00e1 30 segundos? Ent\u00e3o n\u00e3o crio outra \u2014 mostro a que existe." A resposta n\u00e3o sai da eloqu\u00eancia do modelo; sai dos teus dados. \u00c9 essa a linha inteira desta discuss\u00e3o: n\u00e3o \u00e9 quem responde mais bonito, \u00e9 quem verifica antes de escrever.<\/p>\n

    A obje\u00e7\u00e3o honesta: "n\u00e3o posso s\u00f3 p\u00f4r o bot a n\u00e3o repetir?"<\/h2>\n

    Podes tentar. E vais descobrir que "n\u00e3o repetir" \u00e9 f\u00e1cil no caminho feliz e dif\u00edcil em todos os outros: mensagens que chegam fora de ordem, o mesmo cliente com duas encomendas leg\u00edtimas parecidas no mesmo dia, o retry<\/em> que chega 40 segundos depois quando o rascunho j\u00e1 expirou. Cada um destes exige uma decis\u00e3o de desenho \u2014 quanto tempo a chave \u00e9 v\u00e1lida, o que conta como "a mesma" ordem, o que fazer quando h\u00e1 d\u00favida. \u00c9 trabalho de engenharia de integra\u00e7\u00e3o, n\u00e3o uma caixa que se liga num painel no-code numa tarde. \u00c9 precisamente por isso que a escrita fi\u00e1vel custa \u20ac250 a \u20ac1.200 por m\u00eas e o bot custa \u20ac25: um deles tomou estas decis\u00f5es por ti, o outro empurra-as para a tua equipa.<\/p>\n

    O pr\u00f3ximo passo, concreto<\/h2>\n

    Pega no teu assistente atual \u2014 ou no que te andam a vender \u2014 e faz-lhe uma pergunta s\u00f3: o que acontece se o cliente confirmar a mesma encomenda duas vezes em cinco segundos?<\/strong> Se a resposta for "criava duas" ou "n\u00e3o sei", j\u00e1 sabes qual dos dois est\u00e1s a comprar.<\/p>\n

    Se quiseres ver como fica uma escrita idempotente e auditada sobre o teu ERP \u2014 PHC, Primavera ou o que tens \u2014 mostramos-te o trabalho, com o log \u00e0 frente. Fala connosco em leiritech.pt<\/strong> ou hello@leiritech.com<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Um ‘ok, confirma’ n\u00e3o pode gerar a mesma ordem duas vezes. Porque a escrita idempotente e auditada no ERP \u00e9 o fosso que nenhum bot de \u20ac25 tem.<\/p>\n","protected":false},"author":1,"featured_media":126,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[44,186,185,184,183,74,187],"class_list":["post-129","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-integracao","tag-agente-ia-erp","tag-chatbot-vs-agente","tag-encomenda-duplicada","tag-escrita-no-erp","tag-idempotencia-erp","tag-integracao-erp-whatsapp","tag-phc-primavera-integracao"],"_links":{"self":[{"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/posts\/129","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=129"}],"version-history":[{"count":0,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/posts\/129\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/media\/126"}],"wp:attachment":[{"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/media?parent=129"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/categories?post=129"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leiritech.pt\/blog\/wp-json\/wp\/v2\/tags?post=129"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}