PrestaShop 9.2 Orders and Shipments: Regression Cases That Matter

An order is not finished when checkout creates it. Staff may change quantities, split fulfillment, select a different carrier or regenerate a document. Each action must preserve a coherent relationship between what was ordered, what is assigned for delivery and what customers are told.

The 9.2 RC1 shipment work includes fixes for edit-view quantities, combination handling and missing domain validations. A separate change addresses whether the order-confirmation email respects the order state’s invoice-attachment setting. Shipment-domain fix, invoice-attachment fix.

These are refinements to order processing, not a claim that shipments first appeared in 9.2. The following staging scenarios turn the changes into useful operational evidence for RC1 as of September 26, 2026.

Where fulfillment is connected through an integration, compare the operation with the PrestaShop 9.2 Admin API changes and test the installed resource-module version.

Identify the path under test before editing an order

Record the core build, order-related modules and active feature flags. The shipment PR’s reproduction instructions specifically refer to the improved_shipment flag. A test on another path may not exercise the corrected domain behavior. Upstream shipment reproduction context.

Use synthetic orders with simple, known quantities. Include a product with combinations and a product without them. Add at least one case with several units of a single order line so an erroneous zero or wrong quantity is obvious.

Keep carrier requests and customer notifications isolated. A Back Office test can create externally visible effects even if no customer visits the storefront. Use sandbox shipping and a mail sink, or document which external step is disabled.

Before each edit, capture the order detail identifiers, quantities and current shipment allocation. Product identifiers alone may be insufficient to describe a particular order line, especially when combinations or multiple entries are involved.

Define quantity invariants in business terms

A useful test does not merely ask whether an edit modal opens. It asks whether the quantities shown correspond to the selected order lines and whether an accepted edit preserves the intended allocation.

For a fixture with three units, inspect the initial shipment edit view. Verify that the displayed quantity is three where that is the expected allocation, not zero or a value from another line. Change a supported quantity and reopen the view.

Then inspect the order and shipment state together. A successful UI operation should not leave the order claiming one quantity while the shipment describes another without an explicit, supported reason.

Use a reconciliation table:

The exact allowed transitions depend on the active workflow. Do not impose a made-up arithmetic rule on cancelled, returned or otherwise adjusted lines. Define the expected state for the specific operation before running it.

Check combinations and invalid relationships

The upstream shipment fix includes a correction involving the argument used to build a combination, and validation that a product belongs to the order. These details suggest two important negative cases. Domain corrections in #42411.

First, create two combinations with clearly different references or labels. Place an order for one and inspect it throughout the shipment edit. The operation must continue to refer to the ordered variant rather than a default or another combination.

Second, attempt an unsupported relationship only through a controlled test harness or supported validation path in staging. The domain should reject assigning an unrelated product to the shipment. Do not test by corrupting database records manually and then interpreting the resulting failure as normal application behavior.

For a custom integration, verify which identifier its command expects. A product ID, combination ID and order-detail ID are not interchangeable simply because each is an integer. Use explicit variable names and fixtures that would fail if the identifiers were accidentally swapped.

A good failure response should leave the previous valid state intact. Record both the validation result and the persisted shipment after rejection.

Carrier changes must follow the actual contents

A carrier that can transport one item may not be valid for another quantity, destination or product restriction. When shipment contents change, inspect the resulting carrier choices and selected carrier.

Start with a valid allocation and carrier. Make a supported change to the contents, then verify whether the previous carrier remains eligible under the configured rules. If it does not, the interface and persisted state should make the required correction clear.

The shipment-domain change includes carrier-existence validation on relevant edits and switches. Use a controlled fixture to confirm that an invalid carrier does not become a silently accepted relationship. Carrier validation context.

For external shipping modules, distinguish the local shipment edit from the provider operation. A correct local change does not establish that a previously created label was cancelled, replaced or updated. Follow the module’s documented workflow and inspect its sandbox result.

Do not assume new shipment API operations are available because a related domain fix shipped. The upstream discussion explicitly separates this domain work from API work. Verify the installed resource inventory before designing an integration around it.

Documents and notifications need their own tests

The invoice-attachment fix concerns whether an order-confirmation message respects the relevant order-state setting. This is narrower than invoice generation generally and should be tested independently. Order-confirmation attachment change.

Prepare two controlled order-state configurations representing the supported attachment choices. Generate the corresponding test orders through the appropriate workflow and inspect messages in the mail sink. Check attachment presence, filename and association with the correct order.

Do not infer attachment behavior from an invoice visible in the Back Office. The existence of a document and the decision to attach it to a message are different conditions.

If a module replaces email sending or modifies order-state behavior, include it in the test inventory. Repeat the relevant case with the extension isolated when diagnosing a discrepancy. Preserve the message headers and sanitized metadata rather than sending test invoices to real customers.

Also verify that a failed or repeated administrative action does not send an unintended second notification. That is a store-specific regression recommendation, not a claim that the cited fix changes every notification path.

Follow the order into fulfillment and reconciliation

After the local edit passes, inspect the data consumed by the next system. A warehouse export might read order details, shipment records or its own mapping table. Identify which source is authoritative for the integration.

Use the same synthetic order identifiers throughout the handoff. Confirm that the selected combination, quantity and carrier information agree. If the external system receives a delta rather than a full snapshot, verify that repeating the transfer does not apply the change twice.

For a partially processed order, define which edits are still permitted. Once a provider has accepted a shipment or a warehouse has begun picking, changing the local record may require a separate compensating action. Do not assume editing the Back Office automatically reverses external work.

A reconciliation report should distinguish pending transfer, accepted transfer and failed transfer. A single “exported” flag may be too vague to explain an interrupted operation. Keep this evidence in the integration’s own supported status mechanism.

Preserve the evidence from before the edit

For shipment regressions, the starting allocation is often as important as the final screenshot. Save a compact fixture description before changing quantities or carriers. Include the ordered variant, assigned quantity and relevant destination rules.

If the edit fails, reopen the order in a fresh request before attempting another correction. Determine whether the operation was rejected entirely or whether part of the state changed. Repeated edits can otherwise obscure the first failure and make the final allocation difficult to explain.

When reporting a problem to an integration maintainer, include the expected handoff data as well as the local result. A warehouse receiving the wrong quantity needs a different investigation from a Back Office modal displaying the wrong quantity while the export remains correct.

This before-and-after record allows operations staff and developers to discuss the same business event without relying on a long screen recording or a production database copy.

Give operations staff an acceptance record they can use

Summarize each case with the starting order, active workflow, action, expected quantity relationships and resulting documents or external events. Include the exact module versions and any untested provider step.

Prioritize failures by business effect. A wrong combination or quantity is a fulfillment correctness issue. An unexpected invoice attachment can affect customer communication. A cosmetic modal problem has a different severity unless it obscures the data staff need to make a correct decision.

After a fix, rerun the failing sequence and the adjacent cases sharing its domain boundary. For a combination correction, include both combination and non-combination products. For a carrier validation change, include valid and invalid selections.

PrestaShop 9.2’s order and shipment refinements should be evaluated where they matter: the relationships between order lines, allocations, carriers and documents. Preserve those relationships in the test evidence and the operational impact becomes much clearer than a generic “orders work” sign-off.

For the underlying platform context, see our PrestaShop 9 API automation examples and apply the version-specific checks above to the installation you are evaluating.