A hotel kitchen in Alexandria orders from its food-service distributor once a week: frozen seafood, frozen vegetables, cooking oil, canned tomatoes and rice, all on one purchase order. The frozen lines leave on a refrigerated truck in the morning. The ambient lines leave on a second vehicle in the afternoon, and two of them cannot be completed on that run, so they follow in a second drop the next day. The purchasing officer has one order in mind. The distributor now has three delivery notes, and when the first truck is signed for, the order is marked delivered. When the outstanding ambient lines are keyed in again so the second drop can go out, they get an order number of their own. Nothing here is broken. One order simply became more than one record somewhere between the warehouse and the invoice.
The split is physical. The order should not be.
Splitting the delivery was the right call. Frozen and ambient lines may travel as separate shipments, as they do here, on different vehicles with different handling; a multi-temperature vehicle can also carry every zone as one shipment. The temperature zone article covers that handling in detail. A line that cannot go on the first run going on a second one is ordinary fulfilment. The warehouse did nothing wrong in Alexandria. The failure is in the records.
When the system holding the order knows only one status and one delivery, every extra shipment has to be forced into it, and there are two common ways to do that. The first marks the order delivered at the first signature and lets the rest travel informally, so the order says the goods arrived while the rice is still in the warehouse. The second opens a new order for the remainder, so the buyer now has a reference they never created, matched against a purchase order that never mentioned it. Both end the same way: a purchasing officer phoning a sales coordinator to ask where the rest of the order is, and nobody able to answer from one record.
One order, several shipments, never two orders.
The model that holds up is one to many. The buyer's order is one entity with one lifecycle, and it may produce several shipments: the frozen run, the ambient run and the second ambient drop. Each shipment has its own timeline, its own tracking reference and, once delivered, its own proof of delivery. The shipments belong to the order. They are not copies of it, so the reference the buyer quotes, the purchase order they reconcile and the documents that follow all point back to the same record.
This is why the remainder never needs a new order. A partial delivery generates a second drop under the same order, not a second order. The buyer's lines stay on the order they placed, and the shipments record how those lines travelled. Reorder works the same way: it is an action taken on a past order, not a separate kind of record, because there is only ever one order to act on.
The warehouse decides how an order travels. It should never decide how many orders the buyer placed.
The order's status is its least advanced open shipment.
The buyer still needs one answer at the level of the order: where is it? The order lifecycle has nine statuses: Received, Validated, Processing, Preparing Shipment, Shipped, Out for Delivery, Delivered, Invoiced and Closed. When an order has several shipments, its status is the least advanced status among its open shipments. In Alexandria, once the frozen run and the first ambient run are both delivered and the second drop is on the road, the order reads Out for Delivery. It reaches Delivered only when every shipment has.
The alternatives show why this rule is the right one. A status that follows the most advanced shipment tells the buyer the order arrived while part of it is still on a truck, and that is exactly the phone call the split produced in the first place. A status that tries to describe the mix needs a value the nine statuses do not have, and every invented value is one more state the buyer has to learn and the ERP has no record of. The least-advanced rule says only what is true of the whole order. No additional lifecycle states are introduced, so the nine statuses mean the same thing on an order with one shipment as on an order with three.
Frozen run delivered, first ambient run delivered, second drop out for delivery: the order reads Out for Delivery. It moves to Delivered when the last open shipment is delivered.
The detail lives on the shipment, not in a new status.
The least-advanced rule deliberately says less than the buyer may want to know, which is why the per-shipment timeline carries the detail. The purchasing officer opening the order sees one status for the order and, under it, each shipment with its own position, its tracking reference and its proof of delivery once signed for. The order answers whether all of it is here. The shipment answers which part is.
When something goes wrong on one shipment, it stays on that shipment. An exception never becomes a lifecycle status. The buyer sees the specific cause attached to the shipment or line it affects, such as an adjusted line with its reason code, and never an internal severity label. On the supplier's side, the same event is carried on order health, a separate axis that only the operations team sees, covered in Order Health Signals.
Why the rollup belongs in the ordering infrastructure.
Back in Alexandria, the same week looks different. The hotel's order is one record from submission to close. The frozen run, the first ambient run and the second drop each carry their own timeline and their own proof of delivery. The order reads Out for Delivery until the last drop is signed for, then Delivered. Nobody keys the remainder as a new order, and the purchasing officer has no reason to phone and ask where the rice is, because the shipment list already says.
The documents follow the same structure. Every delivery note and invoice refers back to the order the buyer placed, not to a remainder record nobody ordered. Where a delivered quantity differs from the ordered one, the buyer sees the adjustment with its reason code before the invoice is raised, and the rate quoted at ordering is the rate on the invoice. That is the design Emdaad is built on: shipments split the way the warehouse and the cold chain require, and the order the buyer placed stays the order they track.