Commandes et expéditions de PrestaShop 9.2 : les cas de régression importants

Une commande n’est pas terminée lorsque le passage en caisse la crée. Le personnel peut modifier les quantités, répartir le traitement, choisir un autre transporteur ou régénérer un document. Chaque action doit préserver une relation cohérente entre ce qui a été commandé, ce qui est affecté à la livraison et ce qui est annoncé aux clients.

Les travaux sur les expéditions de la version 9.2 RC1 comprennent des corrections des quantités dans la vue de modification, de la gestion des déclinaisons et des validations manquantes dans le domaine métier. Une modification distincte concerne le respect, par l’e-mail de confirmation de commande, du réglage de pièce jointe de facture de l’état de commande. Correction du domaine des expéditions, correction de la pièce jointe de facture.

Il s’agit d’améliorations du traitement des commandes, et non d’une affirmation selon laquelle les expéditions seraient apparues dans la version 9.2. Les scénarios de préproduction suivants transforment ces changements en éléments opérationnels utiles pour RC1, au 26 septembre 2026.

Lorsque le traitement des commandes passe par une intégration, comparez l’opération avec les changements de l’Admin API de PrestaShop 9.2 et testez la version installée du module de ressources.

Identifiez le parcours testé avant de modifier une commande

Consignez la version exacte du cœur, les modules liés aux commandes et les indicateurs de fonctionnalité actifs. Les instructions de reproduction de la PR sur les expéditions font précisément référence à l’indicateur improved_shipment . Un test sur un autre parcours risque de ne pas solliciter le comportement métier corrigé. Contexte de reproduction des expéditions dans le projet amont.

Utilisez des commandes fictives avec des quantités simples et connues. Incluez un produit avec déclinaisons et un produit sans déclinaison. Ajoutez au moins un cas comportant plusieurs unités d’une même ligne de commande afin qu’un zéro erroné ou une mauvaise quantité soit évident.

Isolez les requêtes aux transporteurs et les notifications aux clients. Un test dans le Back Office peut produire des effets visibles à l’extérieur même si aucun client ne visite la boutique. Utilisez un environnement de test pour les expéditions et un collecteur d’e-mails, ou indiquez quelle étape externe est désactivée.

Avant chaque modification, relevez les identifiants des détails de commande, les quantités et l’affectation actuelle aux expéditions. Les seuls identifiants de produit peuvent ne pas suffire à décrire une ligne de commande précise, notamment en présence de déclinaisons ou de plusieurs entrées.

Définissez les invariants de quantité en termes métier

Un test utile ne vérifie pas seulement qu’une fenêtre modale de modification s’ouvre. Il vérifie que les quantités affichées correspondent aux lignes de commande sélectionnées et qu’une modification acceptée préserve l’affectation prévue.

Pour un jeu de données de test comportant trois unités, examinez la vue initiale de modification de l’expédition. Vérifiez que la quantité affichée est bien trois lorsque cette affectation est attendue, et non zéro ou une valeur provenant d’une autre ligne. Modifiez une quantité autorisée, puis rouvrez la vue.

Examinez ensuite ensemble l’état de la commande et celui de l’expédition. Une opération réussie dans l’interface ne doit pas laisser la commande indiquer une quantité et l’expédition en décrire une autre sans raison explicite et prise en charge.

Utilisez un tableau de rapprochement :

Les transitions précisément autorisées dépendent du processus actif. N’imposez pas une règle arithmétique inventée aux lignes annulées, retournées ou autrement ajustées. Définissez l’état attendu pour l’opération concernée avant de l’exécuter.

Vérifiez les déclinaisons et les relations non valides

La correction des expéditions dans le projet amont comprend une correction de l’argument servant à construire une déclinaison et une validation de l’appartenance d’un produit à la commande. Ces détails suggèrent deux cas négatifs importants. Corrections du domaine métier dans #42411.

Créez d’abord deux déclinaisons avec des références ou libellés clairement différents. Passez une commande pour l’une d’elles et examinez-la pendant toute la modification de l’expédition. L’opération doit continuer à désigner la variante commandée plutôt qu’une déclinaison par défaut ou une autre déclinaison.

Ensuite, tentez une relation non prise en charge uniquement au moyen d’un dispositif de test contrôlé ou d’un parcours de validation pris en charge en préproduction. Le domaine métier doit refuser l’affectation à l’expédition d’un produit sans lien avec la commande. Ne testez pas en corrompant manuellement les enregistrements de la base de données pour ensuite interpréter l’échec obtenu comme un comportement normal de l’application.

Pour une intégration personnalisée, vérifiez quel identifiant sa commande attend. Un identifiant de produit, de déclinaison et de détail de commande ne sont pas interchangeables simplement parce qu’ils sont tous des entiers. Utilisez des noms de variables explicites et des jeux de données de test qui échoueraient en cas d’inversion accidentelle des identifiants.

Une bonne réponse d’échec doit laisser intact l’état valide précédent. Consignez à la fois le résultat de validation et l’expédition enregistrée après le rejet.

Les changements de transporteur doivent suivre le contenu réel

Un transporteur capable de transporter un article peut ne pas convenir à une autre quantité, destination ou restriction liée au produit. Lorsque le contenu de l’expédition change, examinez les choix de transporteur proposés et le transporteur sélectionné.

Partez d’une affectation et d’un transporteur valides. Apportez une modification prise en charge au contenu, puis vérifiez si le transporteur précédent reste admissible selon les règles configurées. Si ce n’est pas le cas, l’interface et l’état enregistré doivent indiquer clairement la correction nécessaire.

Le changement du domaine des expéditions comprend une validation de l’existence du transporteur lors des modifications et changements concernés. Utilisez un jeu de données de test contrôlé pour confirmer qu’un transporteur non valide ne devient pas une relation acceptée sans avertissement. Contexte de validation du transporteur.

Pour les modules d’expédition externes, distinguez la modification locale de l’expédition de l’opération du prestataire. Une modification locale correcte ne prouve pas qu’une étiquette créée auparavant a été annulée, remplacée ou mise à jour. Suivez le processus documenté du module et examinez son résultat dans l’environnement de test.

Ne supposez pas que de nouvelles opérations d’API pour les expéditions sont disponibles parce qu’une correction métier associée a été publiée. La discussion du projet amont distingue explicitement ces travaux métier des travaux sur l’API. Vérifiez l’inventaire des ressources installées avant de concevoir une intégration qui en dépend.

Les documents et les notifications nécessitent leurs propres tests

La correction de la pièce jointe de facture porte sur le respect, par un message de confirmation de commande, du réglage de l’état de commande concerné. Son périmètre est plus restreint que la génération des factures en général et elle doit être testée séparément. Modification de la pièce jointe de confirmation de commande.

Préparez deux configurations contrôlées d’état de commande représentant les choix de pièce jointe pris en charge. Générez les commandes de test correspondantes par le processus approprié et examinez les messages dans le collecteur d’e-mails. Vérifiez la présence de la pièce jointe, son nom de fichier et son association à la bonne commande.

Ne déduisez pas le comportement des pièces jointes d’une facture visible dans le Back Office. L’existence d’un document et la décision de le joindre à un message sont deux conditions différentes.

Si un module remplace l’envoi des e-mails ou modifie le comportement des états de commande, incluez-le dans l’inventaire des tests. Répétez le cas concerné en isolant l’extension lors du diagnostic d’un écart. Conservez les en-têtes des messages et les métadonnées expurgées plutôt que d’envoyer des factures de test à de vrais clients.

Vérifiez également qu’une action administrative échouée ou répétée n’envoie pas involontairement une deuxième notification. Il s’agit d’une recommandation de régression propre à la boutique, et non d’une affirmation selon laquelle la correction citée modifierait tous les parcours de notification.

Suivez la commande jusqu’au traitement logistique et au rapprochement

Une fois la modification locale validée, examinez les données consommées par le système suivant. Un export vers l’entrepôt peut lire les détails de commande, les enregistrements d’expédition ou sa propre table de correspondance. Identifiez la source qui fait autorité pour l’intégration.

Utilisez les mêmes identifiants de commande fictive tout au long du transfert. Confirmez la concordance de la déclinaison sélectionnée, de la quantité et des informations de transporteur. Si le système externe reçoit un différentiel plutôt qu’un instantané complet, vérifiez qu’un transfert répété n’applique pas le changement deux fois.

Pour une commande partiellement traitée, définissez les modifications encore autorisées. Une fois qu’un prestataire a accepté une expédition ou qu’un entrepôt a commencé la préparation, modifier l’enregistrement local peut nécessiter une action compensatoire distincte. Ne supposez pas qu’une modification dans le Back Office annule automatiquement le travail externe.

Un rapport de rapprochement doit distinguer le transfert en attente, le transfert accepté et le transfert échoué. Un seul indicateur « exporté » peut être trop vague pour expliquer une opération interrompue. Conservez ces éléments dans le mécanisme de statut pris en charge par l’intégration elle-même.

Conservez les éléments de preuve antérieurs à la modification

Pour les régressions d’expédition, l’affectation initiale est souvent aussi importante que la capture d’écran finale. Enregistrez une description concise du jeu de données de test avant de modifier les quantités ou les transporteurs. Incluez la variante commandée, la quantité affectée et les règles de destination pertinentes.

Si la modification échoue, rouvrez la commande dans une nouvelle requête avant de tenter une autre correction. Déterminez si l’opération a été entièrement rejetée ou si une partie de l’état a changé. Sinon, les modifications répétées peuvent masquer le premier échec et rendre l’affectation finale difficile à expliquer.

Lorsque vous signalez un problème au responsable d’une intégration, incluez les données de transfert attendues ainsi que le résultat local. Un entrepôt recevant une mauvaise quantité exige une investigation différente de celle d’une fenêtre modale du Back Office affichant une mauvaise quantité alors que l’export reste correct.

Cet enregistrement avant et après permet au personnel opérationnel et aux développeurs de discuter du même événement métier sans s’appuyer sur un long enregistrement d’écran ou une copie de la base de données de production.

Fournissez au personnel opérationnel un relevé d’acceptation exploitable

Résumez chaque cas avec la commande initiale, le processus actif, l’action, les relations de quantité attendues et les documents ou événements externes obtenus. Incluez les versions exactes des modules et toute étape du prestataire non testée.

Classez les échecs selon leurs effets métier. Une déclinaison ou une quantité incorrecte relève de l’exactitude du traitement logistique. Une pièce jointe de facture inattendue peut affecter la communication avec le client. Un défaut visuel de fenêtre modale présente une gravité différente, sauf s’il masque les données dont le personnel a besoin pour prendre une bonne décision.

Après une correction, réexécutez la séquence en échec et les cas voisins partageant sa frontière métier. Pour une correction de déclinaison, incluez des produits avec et sans déclinaisons. Pour un changement de validation du transporteur, incluez des sélections valides et non valides.

Les améliorations des commandes et des expéditions de PrestaShop 9.2 doivent être évaluées là où elles comptent : dans les relations entre lignes de commande, affectations, transporteurs et documents. Préservez ces relations dans les éléments de test ; l’impact opérationnel devient alors bien plus clair qu’une validation générique « les commandes fonctionnent ».

Pour le contexte de la plateforme sous-jacente, consultez nos exemples d’automatisation avec l’API de PrestaShop 9 et appliquez les vérifications propres à la version décrites ci-dessus à l’installation que vous évaluez.