Module de protection des commandes - empêche les commandes en double et les factures ou paiements en double.

30/09/2026
v1.2.0

Ce défaut présente une variante que la version 1.1.0 n'a pas détectée : lorsque le module de paiement crée la commande APRÈS le paiement, ce n'est pas la facture qui est dupliquée, mais la commande elle-même . Chaque élément reste cohérent en interne (la facture avec ses lignes de commande et son paiement rapproché), c'est pourquoi aucun des trois critères précédents ne l'a signalé. Sur une boutique réelle avec 143 649 commandes : 29 paniers contenant deux commandes, et parmi les 54 commandes les plus récentes, la version 1.1.0 n'en aurait signalé aucune .

• Nouveau critère duplicate_order : Une autre commande est active dans le même panier, avec une référence différente. Cette référence permet de la distinguer d'une commande fractionnée par colis, opération effectuée intentionnellement par PrestaShop, où toutes les commandes partagent la même référence. Par conséquent, un index unique sur orders.id_cart ne constitue pas le tableau approprié. Ce critère est vérifié lors de l' actionValidateOrder , déclenchée par la détection d'une nouvelle commande, et lors de chaque vérification ultérieure.
• Nouvel écran : Commandes → Commandes en double. Vérifiez et corrigez celles déjà présentes dans la boutique, une opération qui nécessitait jusqu'à présent une intervention manuelle. La colonne RKROG_SINCE n'est pas prise en compte : cette date sert au suivi en temps réel, et c'est ici que vous trouverez la précédente.
• La classification est l'élément essentiel de cet écran et provient de order_payment.transaction_id , qui est une donnée centrale indépendante de la passerelle de paiement : A correspond à un paiement et deux commandes (le trop-perçu est annulé, aucun remboursement n'est effectué), B à deux paiements distincts (un remboursement est nécessaire et la décision revient à un opérateur), et C à une situation indéterminée (elle est simplement listée). Seul le cas A est modifié.
• Et ce qu'il ne fait pas, et qui est tout aussi important : si le surplus a une facture numérotée, la facture n'est pas touchée (cela nécessite une correction), si un colis a été expédié, rien n'est touché, la passerelle n'est jamais appelée ni un retour émis, et rien n'est exécuté par lots sans marquage et confirmation.
• La simulation donne exactement les mêmes résultats que l'exécution. La décision finale est prise dans la analizar() `, qui ne produit aucune donnée ; aplicar() exécute uniquement les décisions déjà prises. Le rapport est équilibré par construction ( grupos = reparados + saltados + sin nada ) et un avertissement s'affiche en cas de déséquilibre.
• Le stock est mesuré, et non présumé. Le système central restitue le stock en cas d'annulation, mais uniquement si l'état précédent était pertinent et si le produit n'est pas géré par une administration avancée. Le stock est mesuré avant et après la restitution, et seul le stock non restitué est remis en stock : ajouter du stock par précaution entraînerait un double retour, ce qui est plus préjudiciable que de ne pas le restituer du tout.
• La référence de la passerelle devient la première clé de verrouillage. Sur un serveur n'autorisant qu'une seule requête GET_LOCK par session, seule la première clé est utilisée. Avec le panier d'achat en première ligne, les deux appels à la passerelle verrouillaient des noms différents : aucune exclusion mutuelle n'était possible, et le module était installé, actif, mais inactif. La référence de la passerelle est la seule à parvenir par les deux chemins ; la notification serveur à serveur arrive généralement sans aucun de nos paramètres.
• Journalisation optionnelle des verrous acquis ( RKROG_TRACE , désactivée par défaut). Sans elle, identifier la clé ayant bloqué une requête prendrait une après-midi entière : il était impossible de déterminer quelle clé avait bloqué cette requête.