A three-line order ships from two warehouses on different days. What does the customer see, and what does that do to your order model?

Order, shipment and parcel are three entities and the split proves it

A single-shipment order lets you get away with an impoverished model, because order, shipment and parcel are in one-to-one correspondence and one status field can plausibly describe all three. The moment a second warehouse is involved, that collapses, and everything that was implicit has to be made explicit.

The order is a commercial agreement: these items, at these prices, to this address, on these terms. A shipment is an operational unit: a set of order lines, or parts of lines, allocated to one fulfilment location, picked together, despatched together, on one carrier consignment. A parcel is a physical box with its own barcode, and one shipment may be several parcels because of weight or dimensional limits, while a carrier consignment may group parcels in ways that do not match either. The cardinality runs order to shipments to parcels, and none of the arrows is one-to-one.

Once those are separate entities with their own identifiers and their own state machines, the awkward questions become answerable. Which of the three does "despatched" describe? What does a tracking number belong to? Which entity does a return reference? Systems that never made the separation answer these with a mixture of nullable columns and convention, and the convention is where the customer-facing bugs live.

The header status is the thing to be sceptical about. Once the order has two shipments in different states, there is no single word that is true. What the header can honestly hold is a derived summary, computed from the lines, with a rule you can state: nothing despatched, partly despatched, all despatched, all delivered, plus the terminal cases. Storing that as an authoritative field which some other process updates independently is how an order ends up displaying as complete while a line is still sitting unallocated.

The promise lives on the line and the customer hears one date

Availability and lead time are properties of an item at a location, so the delivery promise is naturally per line. The customer, on the other hand, asked one question and wants one answer, and giving them three dates at checkout for a three-item basket is a conversion problem as well as a comprehension one.

The resolution is that the promise is computed per line and presented as a shape rather than as a number. Either you tell the customer the order will arrive in two deliveries, with a date for each, or you tell them the later date and deliberately hold the first shipment so that everything arrives together. Both are legitimate and the choice is commercial: consolidating costs one delivery instead of two and delays the part the customer may want most, while splitting delights the customer who wanted one item urgently and doubles the delivery cost and the carbon.

What is not legitimate is quoting the earliest line's date for the whole order, which is the default behaviour of a system that computes availability per line and displays a single value. It converts a fulfilment decision into a broken promise, and the resulting contact volume is a real cost.

The consolidation decision also has to be revisitable. Stock that was available at promise time may not be at allocation time, a warehouse may miss a cut-off, and the plan that made sense yesterday may need to become two shipments today. That means the split is an allocation-time output rather than an order-capture attribute, and anything that depends on it, including the customer communication, has to tolerate it changing.

Money follows despatch, not the order

The financial consequences of splitting are where candidates who have only built catalogue and cart systems come unstuck.

At checkout you typically hold an authorisation against the customer's card for the order total. Funds are captured when goods are despatched, because charging for goods you have not shipped is both a commercial and in many markets a regulatory problem. With two despatches on different days, that means two captures against one authorisation, and authorisations do not live forever: they expire after a window that varies by scheme and acquirer, and their expiry is a real operational event when the second shipment is a fortnight behind the first. So the design needs partial capture, a plan for re-authorising when the original has aged out, and a recognition that re-authorisation can fail on a card that has since been cancelled.

Invoicing follows the same pattern. Each despatch produces its own invoice for what it contained, which means the tax point is per shipment, delivery charges have to be allocated rather than duplicated, and any promotion applied at order level needs apportioning across shipments in a way that survives one of them being cancelled. A basket-level discount that is entirely consumed by the first invoice leaves the second one overcharged relative to what the customer agreed.

Refunds then have to be able to reverse a part of a part. A single line, from a single shipment, with its apportioned share of the discount and possibly of the delivery charge. Systems that model refunds against the order rather than against the invoice line cannot compute that, and end up refunding round numbers agreed by an agent, which is both a leakage and an audit problem.

Cancellation and amendment have a moving boundary

A customer who wants to change an order is asking about something that is partly still changeable and partly already in a lorry, and the boundary moves during the day.

So amendability is a property of the line, or more precisely of the allocated portion of the line, and it is derived from where that portion has reached in fulfilment. Before allocation almost anything is possible. After allocation but before picking, a cancellation is a de-allocation that returns stock to availability. Once a wave is released and a picker is walking towards the location, cancellation becomes a request the warehouse may decline, and the honest interface tells the customer that the request has been submitted rather than that it has succeeded. After despatch it is no longer a cancellation at all, it is a refused delivery or a return, with different money and different logistics.

The consequence for the interface is that the order page must be able to say different things about different lines at the same time, and must not offer an action it cannot perform. A cancel button on an order header, on a split order, is a promise about three lines with three different answers.

There is a legal dimension worth flagging rather than asserting. Consumer protection rules in a number of markets tie the cancellation and return window to when the goods are received rather than to when the order was placed, which for a split order raises the question of whether one clock or two apply, and whether the last delivery governs. It varies by jurisdiction and it is a question for whoever owns compliance in each market, not one to answer from architectural instinct. Naming it as a question you would go and confirm is a stronger answer than inventing a rule.

One page, several journeys

The customer-facing surface is where the model either pays for itself or fails visibly. Two shipments means two carrier consignments, potentially with two carriers, two sets of tracking events, two estimated dates and two delivery outcomes, and the page has to present that as one order rather than as two unrelated things that happen to share a number.

What works is a grouped view: the order at the top with what it contains, then each delivery as a block listing its items, its current position and its own date. What does not work is a single timeline merging events from both consignments, because it produces sequences that read as contradictions, with a delivered event followed by an in-transit event. Notifications need the same discipline, since a customer who receives "your order has been delivered" while one item is still in a warehouse will contact you, and the fix is that the notification names the delivery and the items it contained.

Returns close the loop and expose whether the model held. A return authorisation references order lines, and the physical return references a parcel that arrived from a specific shipment, and the two need reconciling because customers routinely put items from two deliveries into one box and post it back. That reconciliation is only expressible if a shipment line is an entity with an identity, which is the same conclusion the whole question keeps arriving at.

The split is not an edge case to handle, it is the normal case that reveals whether order, shipment and parcel were ever separate things in your model. Every promise, every payment and every return attaches to one of the three, and getting that attachment wrong is what the customer eventually sees.