Comandes duplicades a l'ERP: què fer quan una comanda s'envia dues vegades

Pocs problemes generen tanta desconfiança en una integració com les comandes duplicades a l'ERP. El client compra una vegada i a l'ERP apareixen dues comandes, dos albarans o, pitjor encara, dues factures. El magatzem prepara mercaderia de més, comptabilitat ha d'anul·lar documents i ningú no sap exactament quan va començar. Rarament es tracta d'un error puntual. El normal és que la integració es dissenyés donant per fet que cada missatge arriba una sola vegada.

Per què apareixen comandes duplicades a l'ERP

Les connexions entre sistemes fallen, i no sempre de la manera que esperes. Aquests són els escenaris més habituals:

• Webhooks repetits. Moltes plataformes reenvien la notificació si no reben una resposta correcta a temps, de manera que, si el teu endpoint triga massa, pot rebre una altra vegada una comanda que ja havia processat.
• Timeouts ambigus: la integració envia la comanda, l'ERP la crea i la resposta es perd pel camí. Des de la botiga sembla un error i es torna a intentar.
• Processos reiniciats. Una tasca programada s'atura a mig lot i, quan es torna a llançar, processa de nou comandes que ja havia enviat.
• Reprocessaments manuals, quan algú prem «reenviar» en un panell sense saber que la comanda ja era a l'ERP.

Posem una botiga que sincronitza comandes cada cinc minuts. Un dia l'ERP va lent, la petició supera el temps d'espera i la integració marca la comanda com a fallida. A l'execució següent la torna a enviar, i l'ERP, que sí que l'havia creada, en crea una altra. Cap sistema no ha caigut; simplement ningú no va decidir què calia fer quan la resposta no arriba.

Un identificador estable per reconèixer repeticions

La base per evitar duplicats és la idempotència: repetir una operació ha de produir el mateix efecte que fer-la una vegada. Per aconseguir-ho necessites una referència estable de la comanda a l'origen que viatgi amb cada missatge i que el destí sàpiga reconèixer.

Com triar aquesta referència

• Fes servir l'identificador intern de la comanda a la botiga. El número visible només serveix si no canvia mai ni es reinicia.
• Si hi ha diverses botigues o canals, combina el canal i l'identificador perquè sigui únic a tot el sistema.
• Desa'l en un camp de l'ERP que es pugui consultar, ja sigui una referència externa, un camp personalitzat o una taula de correspondències, segons el que permeti el teu ERP.
• Descarta combinacions com el nom del client, la data i l'import, perquè dues comandes legítimes poden coincidir.

Amb aquesta referència, la lògica és senzilla. Abans de crear, consulta si la comanda ja existeix; si existeix, actualitza-la o retorna «ja processada», i si no, crea-la. Si l'ERP permet imposar unicitat sobre aquest camp, encara millor, perquè el mateix sistema rebutjarà el duplicat encara que falli la consulta prèvia.

És un dels punts que més revisem en qualsevol projecte d'integració ERP i ecommerce. Dissenyar-lo al principi costa poc i corregir-lo després costa molt.

Estats de l'operació, de rebuda a confirmada

Entre «sincronitzada» i «no sincronitzada» hi ha diversos estats, i cadascun demana una acció diferent:

• Rebuda: la integració té la comanda, però encara no l'ha validada.
• Validada: els productes existeixen, el client està identificat i els imports quadren.
• Enviada: la petició a l'ERP ha sortit, però encara no hi ha confirmació.
• Confirmada: l'ERP ha retornat la seva referència i s'ha desat.
• Rebutjada: l'ERP o la validació han detectat un problema que no s'arregla reintentant.

L'estat delicat és «enviada». Si hi ha un error després d'enviar, el reintent ha de preguntar primer a l'ERP si la comanda existeix i crear-la només si no hi és. Així es tanca el forat dels timeouts ambigus.

Cancel·lacions i modificacions

Els duplicats també apareixen després de crear la comanda. Si se'n modifica o se'n cancel·la una que ja estava importada, la integració l'ha de localitzar per la mateixa referència i actualitzar el document existent en lloc de generar-ne un de nou. Decideix des del principi quins canvis es propaguen a l'ERP i quins necessiten intervenció manual.

Reintents amb límits i alertes

Cal reintentar, però amb control. Si l'ERP ha caigut i la integració reintenta sense pausa, satura un sistema que ja tenia problemes. Un esquema raonable inclou:

• Intervals creixents entre intents (per exemple, al cap d'un minut, de cinc i de trenta).
• Un nombre màxim de reintents, després del qual la comanda passa a una cua d'incidències.
• Separar els errors transitoris (timeout, servei no disponible) dels definitius (producte inexistent, dades no vàlides), que no es reintenten.
• Alertes que diguin quina comanda és, quin pas ha fallat, el missatge d'error i què pot fer l'equip sense risc.

Una alerta que només diu «error en la sincronització» obliga a investigar des de zero. Amb «comanda 1234 enviada a l'ERP sense resposta; comprovar si existeix abans de reenviar», l'equip ho resol en minuts. Si vols anar més lluny, l'automatització de comandes amb excepcions visibles converteix aquesta cua en un panell que l'equip revisa cada dia.

Proves que destapen duplicats abans de producció

Una demostració amb una comanda perfecta no et diu res sobre duplicats. Abans de donar per bona una integració, provoca els errors expressament:

• Simula una resposta lenta de l'ERP que superi el timeout i comprova que la comanda no es crea dues vegades.
• Envia el mateix webhook dues vegades seguides.
• Talla la connexió just després que l'ERP creï la comanda.
• Envia una comanda amb un article que no existeix a l'ERP.
• Provoca un error d'autenticació i verifica que no es perd cap comanda.
• Fes arribar esdeveniments desordenats, amb una cancel·lació abans de la creació.
• Cancel·la una comanda després d'haver-la importada.

Cada cas ha d'acabar en un estat explícit i traçable, sense documents duplicats ni comandes perdudes. Si la teva botiga és a Shopify, aquestes proves formen part de qualsevol projecte d'integracions Shopify ben plantejat, perquè els webhooks de la plataforma es poden repetir.

Què cal exigir al proveïdor de la integració

Tant si la desenvolupes internament com si l'encarregues, demana com a mínim:

• Poder consultar, comanda per comanda, què s'ha enviat, quan i què ha respost l'ERP.
• Una política de reintents documentada: quants, cada quant i quins errors en queden fora.
• Un procediment per reprocessar una comanda sense duplicar-la.
• La referència creuada, amb l'identificador d'origen desat a l'ERP i viceversa.
• Proves que s'han assajat els escenaris d'error anteriors.

Si ja tens duplicats en producció, esbrina on es trenca la idempotència abans de posar pedaços. Una auditoria tècnica ecommerce de la integració sol localitzar-ho revisant logs, estats i el punt exacte en què es perd la referència.

Checklist ràpida

• Cada comanda té una referència estable que viatja en tots els missatges.
• L'ERP desa aquesta referència i es pot consultar abans de crear.
• Els estats intermedis estan separats i el reintent comprova abans de crear.
• Els reintents tenen límit, interval i distinció d'errors.
• Les alertes indiquen la comanda, el pas i l'acció recomanada.
• S'han provat timeouts, repeticions, cancel·lacions i esdeveniments desordenats.