Process an order
This is the loop your Innendienst runs dozens of times a day. Every step below is an action on the order detail page, and every one of them writes a row to the order's history that your integrations and your auditors can read.
Find the order
Go to Order Management › Orders. The list shows the three statuses as columns, with a filter for each of them and one for On hold, and it opens with four ready-made queues:
| Queue | What it contains |
|---|---|
| Open | status in pending, placed, in_fulfillment |
| Awaiting payment | payment_status in open, pending |
| Ready to ship | placed or in_fulfillment, payment authorized or paid, not fully shipped, not on hold |
| On hold | on_hold = true |
Two queues you build yourself with the filters, because the built-in ones do not cover them:
| Queue | Filter |
|---|---|
| Awaiting approval | status = pending |
| Part-shipped | fulfillment_status = partial |
authorized or paid. If you
sell on invoice and record the payment when the money arrives, weeks after
delivery, your invoice orders never appear in that queue. Pick from
status = placed, not on hold, instead, and treat Ready to ship as the
prepayment queue.The Cockpit dashboard shows counters for Awaiting approval, Orders on hold and Open returns, each linking to its list.
Read the order before you touch it
Open the order. Four things tell you where it stands:
- The Lifecycle section at the top of the Overview tab: lifecycle, payment and fulfillment status side by side. See The three order statuses.
- Customer order number (PO) in the Order section. This is the buyer's own PO number and it goes on every document you send them.
- The positions grid further down, with the ordered quantity per line and the shipped, returned and cancelled quantities beside it.
- A banner if the order is on hold, with the reason and a Release hold action.
The rail on the left carries the customer, the addresses and the totals. The organization and contact links are live records; the Buyer block beside them is the snapshot taken when the order was placed. If the two disagree, the buyer has been edited since. The order is still right about what was ordered.
Acknowledge it
Acknowledge records that the fulfilling system has taken the order. It
stamps acknowledged_at and stores the ERP's own order number in
External reference. Where an integration exists, the ERP does this itself;
where it does not, someone does it by hand after keying the order in.
Ship it
On the Fulfilment tab, Create shipment takes the positions and
quantities that are leaving, plus a carrier and a tracking code, and produces a
shipment with its own number from the delivery range. The dialog shows the
open quantity per position and offers only that. Leave every line selected and
everything still open ships.
Shipping moves two things: the lifecycle to in_fulfillment, and each
position's quantity_shipped. When the last open quantity ships, the order
completes, subject to the setting Complete an order on:
| Setting | The order completes |
|---|---|
| Full shipment (default) | As soon as every position has shipped |
| Full shipment and payment | When everything has shipped and payment_status is paid |
| Manually | Never on its own; someone selects Complete |
For less than everything, see Partial deliveries and backorders.
Record the payment
Where a payment provider is involved, payment_status arrives on its own. For
an invoice paid by bank transfer, someone records it: Update payment, then
the new status and, if you have one, the payment reference.
Do this from the payment side of your process, not the order side. An order marked paid because it looked finished is an order your dunning process never chases.
Talk to the customer, and to your colleagues
The Comments tab holds notes, and each carries a visibility:
| Visibility | Who sees it |
|---|---|
internal | Only your team |
customer | The buyer, wherever your storefront shows order comments |
A comment written in the Cockpit takes your tenant's default visibility, which
is internal unless someone changed Default comment visibility. A comment
arriving through the API or a storefront carries its own. Check the default
before you write anything you would not want the customer to read, because the
difference between the two is one field.
Put it on hold
Put on hold with a reason stops the order proceeding: a credit check, an unresolved dispute, an export-control question. The order keeps its place in the lifecycle; it cannot move. Release hold lifts it and puts the order back in the fulfillment queue.
What a hold blocks is the tenant setting A hold blocks: shipping only, shipping and cancellation, or nothing (the flag becomes advisory). If you use holds for credit checks, blocking cancellation as well is the right choice.
Close it
Most orders close themselves when the last position ships. Two cases need Complete by hand:
- Your tenant completes manually rather than on shipment.
- The order never ships at all: a service, an installation, a licence. This is the honest end of such an order, and it beats leaving it open forever or cancelling something that was delivered.
What to check
After each shipment, confirm on the Overview tab that:
quantity_shippedon each line matches what left the building.fulfillment_statusmoved topartialorfulfilled.- The shipment appears on the Fulfilment tab with its number, carrier and tracking code.
- The History tab shows the action, with who did it.
The History tab answers almost every "who changed this" question. Every action writes a row there with the actor and the payload.
Next
- Partial deliveries and backorders: shipping less than everything.
- Cancel or change an order: when it should not go out at all.