Módulo order guard - evita pedidos duplicados y estados de pago o factura duplicados

v1.2.02026/09/30

El fallo tiene una variante que la 1.1.0 no veía: cuando el módulo de pago crea el pedido DESPUÉS de pagar, lo que se duplica no es la factura, es el pedido. Cada uno de los dos queda internamente coherente —su factura con sus líneas y su cobro cuadrado— así que ninguno de los tres criterios anteriores lo señalaba. Sobre una tienda real con 143.649 pedidos: 29 carritos con dos pedidos, y de los 54 más recientes la detección de la 1.1.0 habría marcado cero.

• Criterio nuevo duplicate_order: existe otro pedido VIVO del mismo carrito con referencia distinta. La referencia es lo que lo separa de una división por paquete, que PrestaShop hace a propósito y en la que todos los pedidos comparten referencia — por lo mismo, un índice único sobre orders.id_cart no es el arreglo. Se comprueba en actionValidateOrder, que es cuando se sabe que acaba de nacer un pedido, y en cada revisión posterior.
• Pantalla nueva: Pedidos → Pedidos duplicados. Revisa y arregla los que ya están en la tienda, que es lo que hasta ahora había que hacer a mano uno a uno. No mira RKROG_SINCE: esa fecha es para la vigilancia en vivo, y aquí se viene justamente a ver lo anterior.
• La clasificación es lo importante de esa pantalla, y sale de order_payment.transaction_id, que es del núcleo y no depende de la pasarela: A un cobro y dos pedidos —se cancela el sobrante, no hay dinero de más—, B dos cobros distintos —hay que devolver dinero y eso lo decide una persona— y C indeterminado, que sólo se lista. Sólo el caso A se toca.
• Y lo que no hace, que importa igual: si el sobrante tiene factura numerada no se toca la factura (eso pide una rectificativa), si ha salido un paquete no se toca nada, nunca se llama a la pasarela ni se emite una devolución, y nada se ejecuta en lote sin marcarlo y confirmarlo.
• Simular cuenta exactamente lo mismo que ejecutar. La decisión entera vive en analizar(), que no escribe; aplicar() sólo ejecuta lo ya decidido. El informe cuadra por construcción (grupos = reparados + saltados + sin nada) y la pantalla avisa si alguna vez no cuadrara.
• El stock se mide, no se supone. El núcleo lo devuelve al cancelar, pero sólo si el estado anterior contaba y el producto no va por gestión avanzada. Se mide antes y después y sólo se repone lo que no haya vuelto: inyectar por si acaso lo devolvería dos veces, que es peor que no devolverlo.
• La referencia de la pasarela pasa a ser la PRIMERA clave de bloqueo. En un servidor que sólo admite un GET_LOCK por sesión se toma únicamente la primera, y con el carrito delante las dos llamadas de la pasarela bloqueaban nombres distintos: cero exclusión mutua, y el módulo instalado, activo y sin hacer nada. La referencia de la pasarela es la única que llegan por los dos caminos — la notificación servidor-a-servidor suele venir sin un solo parámetro nuestro.
• Registro opcional de los bloqueos tomados (RKROG_TRACE, apagado de fábrica). Sin él, descubrir lo anterior cuesta una tarde: no había forma de ver qué clave había bloqueado una petición.