Bestellungen und Sendungen in PrestaShop 9.2: wichtige Regressionsfälle

Eine Bestellung ist nicht abgeschlossen, sobald sie beim Bezahlvorgang angelegt wird. Mitarbeiter können Mengen ändern, die Abwicklung aufteilen, einen anderen Versanddienstleister wählen oder ein Dokument erneut erstellen. Jede Aktion muss einen stimmigen Zusammenhang zwischen der Bestellung, der zur Lieferung zugewiesenen Ware und den Informationen für die Kunden erhalten.

Die Arbeiten an Sendungen in 9.2 RC1 umfassen Korrekturen für Mengen in der Bearbeitungsansicht, die Variantenverarbeitung und fehlende Domänenvalidierungen. Eine separate Änderung betrifft die Frage, ob die Bestellbestätigungs-E-Mail die Einstellung des Bestellstatus zum Rechnungsanhang berücksichtigt. Korrektur der Sendungsdomäne, Korrektur des Rechnungsanhangs.

Dies sind Verbesserungen der Bestellverarbeitung und keine Behauptung, dass Sendungen erst in 9.2 eingeführt wurden. Die folgenden Szenarien in der Staging-Umgebung machen die Änderungen zu nützlichen betrieblichen Nachweisen für RC1 mit Stand vom 26. September 2026.

Wenn die Auftragsabwicklung über eine Integration verbunden ist, vergleichen Sie den Vorgang mit den Änderungen der Admin API in PrestaShop 9.2 und testen Sie die installierte Version des Ressourcenmoduls.

Bestimmen Sie vor der Bestellbearbeitung den getesteten Ablauf

Erfassen Sie den Core-Build, die bestellbezogenen Module und die aktiven Feature-Flags. Die Reproduktionsanleitung im Sendungs-PR verweist ausdrücklich auf das Flag improved_shipment . Ein Test eines anderen Ablaufs prüft möglicherweise nicht das korrigierte Domänenverhalten. Kontext zur Reproduktion der Sendungsprobleme im Ursprungsprojekt.

Verwenden Sie synthetische Bestellungen mit einfachen, bekannten Mengen. Berücksichtigen Sie ein Produkt mit Varianten und eines ohne Varianten. Fügen Sie mindestens einen Fall mit mehreren Einheiten einer einzelnen Bestellposition hinzu, damit eine fehlerhafte Null oder eine falsche Menge deutlich erkennbar ist.

Isolieren Sie Anfragen an Versanddienstleister und Kundenbenachrichtigungen. Ein Back-Office-Test kann extern sichtbare Auswirkungen haben, auch wenn kein Kunde die Shopoberfläche besucht. Nutzen Sie eine Versand-Testumgebung und einen E-Mail-Testempfänger oder dokumentieren Sie, welcher externe Schritt deaktiviert ist.

Erfassen Sie vor jeder Bearbeitung die Kennungen der Bestelldetails, die Mengen und die aktuelle Sendungszuordnung. Produktkennungen allein reichen möglicherweise nicht aus, um eine bestimmte Bestellposition zu beschreiben, insbesondere bei Varianten oder mehreren Einträgen.

Definieren Sie Mengeninvarianten in fachlichen Begriffen

Ein sinnvoller Test fragt nicht nur, ob sich ein modales Bearbeitungsfenster öffnet. Er fragt, ob die angezeigten Mengen den ausgewählten Bestellpositionen entsprechen und ob eine akzeptierte Bearbeitung die beabsichtigte Zuordnung erhält.

Prüfen Sie bei einem Testdatensatz mit drei Einheiten die ursprüngliche Sendungsbearbeitungsansicht. Kontrollieren Sie, dass die angezeigte Menge drei beträgt, wenn dies die erwartete Zuordnung ist, und nicht null oder ein Wert aus einer anderen Position. Ändern Sie eine zulässige Menge und öffnen Sie die Ansicht erneut.

Prüfen Sie anschließend den Bestell- und Sendungszustand gemeinsam. Ein erfolgreicher Vorgang in der Benutzeroberfläche darf nicht dazu führen, dass die Bestellung eine Menge und die Sendung eine andere ausweist, ohne dass ein ausdrücklicher, unterstützter Grund vorliegt.

Verwenden Sie eine Abgleichstabelle:

Die genau zulässigen Übergänge hängen vom aktiven Arbeitsablauf ab. Wenden Sie keine erfundene Rechenregel auf stornierte, zurückgegebene oder anderweitig angepasste Positionen an. Definieren Sie den erwarteten Zustand für den konkreten Vorgang, bevor Sie ihn ausführen.

Prüfen Sie Varianten und ungültige Beziehungen

Die Sendungskorrektur im Ursprungsprojekt umfasst eine Korrektur des Arguments zum Erstellen einer Variante und die Validierung, dass ein Produkt zur Bestellung gehört. Diese Details legen zwei wichtige Negativfälle nahe. Domänenkorrekturen in #42411.

Erstellen Sie zunächst zwei Varianten mit deutlich unterschiedlichen Referenzen oder Bezeichnungen. Bestellen Sie eine davon und prüfen Sie sie während der gesamten Sendungsbearbeitung. Der Vorgang muss sich weiterhin auf die bestellte Variante beziehen und nicht auf eine Standardvariante oder eine andere Variante.

Versuchen Sie anschließend, eine nicht unterstützte Beziehung ausschließlich über eine kontrollierte Testvorrichtung oder einen unterstützten Validierungsweg in der Staging-Umgebung herzustellen. Die Domäne sollte die Zuordnung eines nicht zur Bestellung gehörenden Produkts zur Sendung ablehnen. Testen Sie nicht durch manuelles Beschädigen von Datenbankeinträgen, um den daraus entstehenden Fehler anschließend als normales Anwendungsverhalten zu interpretieren.

Prüfen Sie bei einer individuellen Integration, welche Kennung ihr Befehl erwartet. Produkt-ID, Varianten-ID und Bestelldetail-ID sind nicht allein deshalb austauschbar, weil sie jeweils Ganzzahlen sind. Verwenden Sie eindeutige Variablennamen und Testdatensätze, die bei einer versehentlichen Vertauschung der Kennungen fehlschlagen würden.

Eine gute Fehlerantwort sollte den vorherigen gültigen Zustand unverändert lassen. Erfassen Sie sowohl das Validierungsergebnis als auch die nach der Ablehnung gespeicherte Sendung.

Änderungen des Versanddienstleisters müssen zum tatsächlichen Inhalt passen

Ein Versanddienstleister, der einen Artikel transportieren kann, ist möglicherweise für eine andere Menge, ein anderes Ziel oder eine Produktbeschränkung nicht geeignet. Prüfen Sie bei Änderungen des Sendungsinhalts die daraus resultierende Auswahl an Versanddienstleistern und den ausgewählten Anbieter.

Beginnen Sie mit einer gültigen Zuordnung und einem gültigen Versanddienstleister. Nehmen Sie eine unterstützte Änderung am Inhalt vor und prüfen Sie anschließend, ob der bisherige Versanddienstleister nach den konfigurierten Regeln weiterhin geeignet ist. Falls nicht, sollten Oberfläche und gespeicherter Zustand die erforderliche Korrektur deutlich machen.

Die Änderung der Sendungsdomäne umfasst bei relevanten Bearbeitungen und Wechseln eine Validierung der Existenz des Versanddienstleisters. Bestätigen Sie mit einem kontrollierten Testdatensatz, dass ein ungültiger Versanddienstleister nicht zu einer stillschweigend akzeptierten Beziehung wird. Kontext zur Validierung des Versanddienstleisters.

Unterscheiden Sie bei externen Versandmodulen die lokale Sendungsbearbeitung vom Vorgang beim Dienstleister. Eine korrekte lokale Änderung belegt nicht, dass ein zuvor erstelltes Etikett storniert, ersetzt oder aktualisiert wurde. Befolgen Sie den dokumentierten Arbeitsablauf des Moduls und prüfen Sie dessen Ergebnis in der Testumgebung.

Nehmen Sie nicht an, dass neue Sendungs-API-Vorgänge verfügbar sind, nur weil eine zugehörige Domänenkorrektur veröffentlicht wurde. Die Diskussion im Ursprungsprojekt trennt diese Domänenarbeiten ausdrücklich von den API-Arbeiten. Prüfen Sie den Bestand installierter Ressourcen, bevor Sie eine darauf aufbauende Integration entwerfen.

Dokumente und Benachrichtigungen benötigen eigene Tests

Die Korrektur des Rechnungsanhangs betrifft die Frage, ob eine Bestellbestätigung die entsprechende Bestellstatuseinstellung berücksichtigt. Dies ist enger gefasst als die Rechnungserstellung im Allgemeinen und sollte unabhängig getestet werden. Änderung des Anhangs der Bestellbestätigung.

Bereiten Sie zwei kontrollierte Bestellstatuskonfigurationen vor, die die unterstützten Anhangsoptionen abbilden. Erstellen Sie die entsprechenden Testbestellungen über den geeigneten Arbeitsablauf und prüfen Sie die Nachrichten im E-Mail-Testempfänger. Kontrollieren Sie das Vorhandensein des Anhangs, den Dateinamen und die Zuordnung zur richtigen Bestellung.

Leiten Sie das Anhangsverhalten nicht aus einer im Back Office sichtbaren Rechnung ab. Das Vorhandensein eines Dokuments und die Entscheidung, es einer Nachricht anzuhängen, sind unterschiedliche Bedingungen.

Wenn ein Modul den E-Mail-Versand ersetzt oder das Bestellstatusverhalten verändert, nehmen Sie es in den Testbestand auf. Wiederholen Sie bei der Diagnose einer Abweichung den relevanten Fall mit isolierter Erweiterung. Bewahren Sie die Nachrichtenheader und bereinigten Metadaten auf, statt Testrechnungen an echte Kunden zu senden.

Prüfen Sie außerdem, dass eine fehlgeschlagene oder wiederholte Verwaltungsaktion keine unbeabsichtigte zweite Benachrichtigung sendet. Dies ist eine shopspezifische Regressionsempfehlung und keine Behauptung, dass die angeführte Korrektur jeden Benachrichtigungsweg verändert.

Verfolgen Sie die Bestellung durch Abwicklung und Abgleich

Prüfen Sie nach dem erfolgreichen lokalen Bearbeitungstest die Daten, die das nächste System verwendet. Ein Lagerexport könnte Bestelldetails, Sendungsdatensätze oder eine eigene Zuordnungstabelle lesen. Ermitteln Sie, welche Quelle für die Integration maßgeblich ist.

Verwenden Sie während der gesamten Übergabe dieselben synthetischen Bestellkennungen. Bestätigen Sie, dass ausgewählte Variante, Menge und Versanddienstleisterinformationen übereinstimmen. Falls das externe System statt eines vollständigen Datenstands nur Änderungen erhält, prüfen Sie, dass eine wiederholte Übertragung die Änderung nicht zweimal anwendet.

Definieren Sie bei einer teilweise verarbeiteten Bestellung, welche Bearbeitungen noch zulässig sind. Sobald ein Dienstleister eine Sendung angenommen oder ein Lager mit der Kommissionierung begonnen hat, kann die Änderung des lokalen Datensatzes eine separate Ausgleichsaktion erfordern. Nehmen Sie nicht an, dass eine Bearbeitung im Back Office externe Arbeiten automatisch rückgängig macht.

Ein Abgleichsbericht sollte zwischen ausstehender, akzeptierter und fehlgeschlagener Übertragung unterscheiden. Ein einzelnes Kennzeichen „exportiert“ kann zu ungenau sein, um einen unterbrochenen Vorgang zu erklären. Bewahren Sie diese Nachweise im eigenen unterstützten Statusmechanismus der Integration auf.

Bewahren Sie die Nachweise aus der Zeit vor der Bearbeitung auf

Bei Sendungsregressionen ist die ursprüngliche Zuordnung oft ebenso wichtig wie der abschließende Screenshot. Speichern Sie vor Änderungen an Mengen oder Versanddienstleistern eine kompakte Beschreibung des Testdatensatzes. Fügen Sie die bestellte Variante, die zugewiesene Menge und die relevanten Zielortregeln hinzu.

Wenn die Bearbeitung fehlschlägt, öffnen Sie die Bestellung in einer neuen Anfrage erneut, bevor Sie eine weitere Korrektur versuchen. Stellen Sie fest, ob der Vorgang vollständig abgelehnt wurde oder ob sich ein Teil des Zustands geändert hat. Wiederholte Bearbeitungen können sonst den ersten Fehler verdecken und die abschließende Zuordnung schwer erklärbar machen.

Fügen Sie bei der Meldung eines Problems an den Integrationsbetreuer neben dem lokalen Ergebnis auch die erwarteten Übergabedaten hinzu. Ein Lager, das eine falsche Menge erhält, erfordert eine andere Untersuchung als ein modales Back-Office-Fenster, das eine falsche Menge anzeigt, während der Export korrekt bleibt.

Diese Dokumentation des Zustands davor und danach ermöglicht es Betriebsmitarbeitern und Entwicklern, über dasselbe Geschäftsereignis zu sprechen, ohne auf eine lange Bildschirmaufnahme oder eine Kopie der Produktionsdatenbank angewiesen zu sein.

Geben Sie Betriebsmitarbeitern einen nutzbaren Abnahmenachweis

Fassen Sie jeden Fall mit der ursprünglichen Bestellung, dem aktiven Arbeitsablauf, der Aktion, den erwarteten Mengenbeziehungen und den resultierenden Dokumenten oder externen Ereignissen zusammen. Fügen Sie die genauen Modulversionen und alle ungetesteten Dienstleisterschritte hinzu.

Priorisieren Sie Fehler nach ihren geschäftlichen Auswirkungen. Eine falsche Variante oder Menge ist ein Problem der korrekten Auftragsabwicklung. Ein unerwarteter Rechnungsanhang kann die Kundenkommunikation beeinträchtigen. Ein kosmetisches Problem eines modalen Fensters hat einen anderen Schweregrad, sofern es nicht die Daten verdeckt, die Mitarbeiter für eine richtige Entscheidung benötigen.

Führen Sie nach einer Korrektur die fehlgeschlagene Folge und die benachbarten Fälle mit derselben Domänengrenze erneut aus. Berücksichtigen Sie bei einer Variantenkorrektur Produkte mit und ohne Varianten. Berücksichtigen Sie bei einer Änderung der Versanddienstleistervalidierung gültige und ungültige Auswahlen.

Die Verbesserungen an Bestellungen und Sendungen in PrestaShop 9.2 sollten dort bewertet werden, wo sie wichtig sind: bei den Beziehungen zwischen Bestellpositionen, Zuordnungen, Versanddienstleistern und Dokumenten. Halten Sie diese Beziehungen in den Testnachweisen fest, und die betrieblichen Auswirkungen werden wesentlich klarer als bei einer pauschalen Freigabe mit „Bestellungen funktionieren“.

Zum Kontext der zugrunde liegenden Plattform lesen Sie unsere Beispiele zur API-Automatisierung in PrestaShop 9 und wenden Sie die obigen versionsspezifischen Prüfungen auf die bewertete Installation an.