Una reducció doble pot provocar una falsa ruptura d’estoc: la botiga mostra un producte esgotat tot i que del magatzem només n’ha sortit una unitat. El segon canvi pot provenir d’esdeveniments de pagament duplicats, hooks propis, ajustos manuals o una sincronització externa.
Reconcilia primer la quantitat. Una altra comanda, devolució o moviment de magatzem podria explicar una part de la diferència.
Construeix la línia temporal
Llegeix les notes privades de la comanda i l’historial d’inventari disponible. Registra transicions, notes d’estoc, esdeveniments de la passarel·la i sincronitzacions.
- ID de comanda i quantitat de la línia
- producte o variació
- estoc anterior i posterior
- actor o integració
- ID d'esdeveniment del proveïdor
- data, hora i zona horàriaExclou dades personals i credencials. La seqüència ha de demostrar si hi va haver dues operacions o una lectura endarrerida.
Identifica el propietari de l’inventari
Determina si mana WooCommerce, un ERP, el magatzem o un marketplace. Dos sistemes poden reaccionar a la mateixa venda i retornar tots dos una reducció.
Documenta la direcció: WooCommerce envia la venda i rep una quantitat absoluta, o l’extern rep una diferència. Barrejar models exigeix idempotència. Si les comandes noves amplien l’error, pausa només la ruta defectuosa i conserva els logs i la continuïtat de preparació.
Inspecciona el marcador intern
WooCommerce registra si ja ha descomptat l’estoc perquè les crides normals no repeteixin l’operació. El codi que evita les API o esborra aquest marcador anul·la la protecció.
$order = wc_get_order( $order_id );
$reduced = $order ? $order->get_meta( '_order_stock_reduced' ) : null;Llegeix-lo com a evidència. Modificar-lo pot causar una altra reducció o impedir una reposició legítima.
Localitza hooks duplicats
Busca al codi propi wc_reduce_stock_levels(), setters de producte i callbacks connectats a Processing, Completed o pagament completat. Un connector pot actuar en dues transicions del mateix esdeveniment comercial.
Els hooks es poden executar més d’una vegada. El callback ha de saber si ja ha processat aquell esdeveniment. No editis el nucli ni desactivis globalment totes les funcions d’estoc.
Revisa webhooks i reintents
Una passarel·la repeteix notificacions després d’un timeout. La mateixa confirmació pot arribar diverses vegades i canviar l’estat si el receptor no és idempotent.
Compara els ID i l’historial d’entrega amb les notes. Un doble clic també pot crear dues comandes: demostra que realment és una comanda amb dos descomptes.
Corregeix respostes lentes i aconsegueix que un esdeveniment repetit finalitzi sense repetir efectes. Conserva l’ID processat durant tot el termini de reintents.
Prova també dos lliuraments simultanis del mateix ID. La protecció ha de ser atòmica: comprovar i marcar en passos separats permet que dos processos passin la comprovació alhora. Registra el resultat sense desar el payload complet del pagament.
Diferencia els moviments legítims
Una restauració seguida d’una reducció nova pot semblar duplicació si només es mira el valor final. Llegeix la seqüència completa de cancel·lacions i reemborsaments.
Un reemborsament no sempre reposa estoc automàticament; el personal pot seleccionar-ho o fer un ajust. Els estats personalitzats també poden restaurar i reduir en un ordre inesperat. Cada moviment necessita una referència.
Corregeix sense reescriure la història
Compta l’estoc físic i revisa vendes, devolucions i ajustos del període. Restaura només l’excés demostrat mitjançant l’eina compatible del sistema propietari.
Afegeix una nota administrativa. No passis una comanda pagada a Pending i de nou al seu estat per manipular quantitats: podria reenviar correus i reactivar integracions.
Prova en sandbox el pagament, el reintent, el canvi d’estat, la cancel·lació i la devolució. Una venda lògica ha de reduir una vegada. El seguiment recurrent ha de detectar diverses notes de reducció o canvis sense operació associada.