The fulfilment pipeline
Packing, out for delivery and delivered — the two doors that advance an order and the guards on both.
Once an order is paid, it moves through packing and delivery. Three stages, two doors, and one guard worth understanding.
The stages
PAID → PACKING → OUT_FOR_DELIVERY → DELIVERED
Each stage stamps its own timestamp when it is reached.
Two doors, one engine
From WhatsApp
The verbs are the ones you would actually say, not the internal names — nobody
types OUT_FOR_DELIVERY while loading a van.
| Command | Moves the order to |
|---|---|
PACK FB-1204 | Packing |
SHIP FB-1204 | Out for delivery |
DELIVERED FB-1204 | Delivered |
From the dashboard
The order screen has a Fulfilment card with the same three actions. Buttons for stages the order cannot reach are disabled, and they read the same list of legal transitions the command does — so a disabled button and a refused command can never disagree.
Both doors call the same code, which is what guarantees neither can forget to tell the customer.
Forward only
An order cannot go backwards. Trying to move a delivered order back to packing is refused, and the refusal names the status it is actually in — so you can see you were looking at the wrong order rather than just being told "no".
Skipping is allowed
Going straight from paid to delivered is legal and common: a customer collects from the shop, or a driver drops it on the way past.
A skip sets only the stage it reached. If an order jumps from packing to delivered, the out-for-delivery timestamp stays empty — because empty is the record that the stage was skipped. Back-filling it would invent a moment that never happened, and the order timeline reads those gaps deliberately.
The customer gets one message about where the order actually got to. Not three, narrating a journey it did not take.
What advancing does not do
Advancing a status never touches stock. Stock moved when the order was confirmed; it is already sold. If your counts look wrong, packing and delivery are not where to look — see your catalogue and aliases.
If the customer message fails
The status change and the customer notification are deliberately separate. The status change commits first; the message is sent afterwards.
A message that cannot be delivered therefore never rolls back a status you correctly set. You are alerted that it failed, and the conversation view marks that message as not delivered rather than showing it as if it had arrived.