The order lifecycle

In B2B, placing an order starts a process rather than ending one. It runs for days or weeks, involves your warehouse, your ERP, a carrier and your customer's accounts-payable department, and it has to stay explainable to all of them afterwards. This article is about what an order is before it is a screen you click.

An order is a snapshot, not a live view

The single most important property of an order here: it is frozen at the moment it is placed.

Each position carries a copy of the product as it looked at place-time (name, price, unit, tax rate) in its own product snapshot. The buyer, the billing address, the shipping address, the chosen payment arrangement and the chosen shipping arrangement are all copied onto the order. The totals (subtotal, tax_total, shipping_total, grand_total) are computed once from the positions and never recalculated.

That is deliberate, and it is what separates an order from a cart:

Where orders come from

Orders arrive from outside the Cockpit:

• from a checkout in your storefront,
• from a buyer's saved order list converted in one click,
• from a quick order or cart upload,
• from a punchout session inside your customer's procurement system (Punchout explained),
• from EDI or your ERP through the API, which is the same door the storefront uses.

The Cockpit is where you work an order; it enters through one of these doors. If your Innendienst still takes orders by phone, that order needs to come in through one of them too, or half your order volume stays invisible to every report you build later.

The five states

status is the lifecycle dimension. It has five values and one straight path:

pending ──► placed ──► in_fulfillment ──► completed
   │            │              │
   └────────────┴──────────────┴──► cancelled

completed and cancelled are the two final states. Everything else is an open order. Filter a worklist on that question, "is the order still open?", rather than on a list of status names you have to keep up to date.

Where completed falls is a setting. It can be reached on full shipment, on full shipment and payment, or never automatically. See The three order statuses.

Positions keep their own books

An order-level status cannot describe "six of ten delivered". So every position carries four quantities:

The open quantity of a position is quantity − quantity_shipped − quantity_cancelled. Every partial delivery, partial cancellation and partial return in the platform is arithmetic on those four numbers. The platform keeps no separate "backorder" record that could drift out of sync.

Positions also carry position (10, 20, 30; the numbering step is configurable, see Number ranges), a unit, a cost_center and a free position_text. A position can be a catalogue product, a configuration (a configured article with its options in the configuration field) or a custom line for something that is not in the catalogue at all.

The two references B2B runs on

Two text fields decide whether your order can be matched at the other end.

customer_order_number is the buyer's own purchase-order number, their Bestellnummer rather than yours. In German B2B this field is what gets your invoice paid. The buyer's ERP raised a PO before they ever opened your shop; their AP department matches your invoice against it, and an invoice that carries no PO number is frequently returned unpaid. Capture it at checkout, print it on every document, and never hide it in a comment field.

external_ref points the other way: it is the order's identity in your fulfilling system. It is written back when the ERP acknowledges the order.

acknowledged_at is the timestamp of that acknowledgement, and it is a boundary. Until it is set, an order can still be narrowly modified: addresses, buyer details, references. After it, the fulfilling system owns the order and changes go through that system instead. A tenant that needs late address corrections can allow modification after acknowledgement, but the default is a frozen order, because two systems editing one order in parallel is how a delivery goes to the old address.

On hold is a separate flag

on_hold is a flag with its own hold_reason, and it is orthogonal to everything above. During a credit check, an unresolved dispute or a customs question, the order stays exactly where it is in the lifecycle and cannot proceed. What a hold blocks is configurable: shipping, shipping and cancellation, or nothing at all (advisory). A held order shows a banner on its detail page with a Release hold action.

How this works in the Revenue Cloud

The Orders app is the order management core. In the Cockpit you find it under Order Management › Orders, with Returns and Shipments beside it and Number ranges under Configuration.

An order's detail page is built from the model above:

The History tab is the audit trail, and it is the same feed your integrations subscribe to: every action writes an event, and those events are what an ERP workflow or a notification reacts to. See Events and webhooks.

Next

• The three order statuses — the concept everything else in this area depends on.
• Process an order — the daily loop.