Skip to main content

Order types

Not everything Click and Collect picks is a customer order. Every order carries an order type that says what kind of work it is, and it changes how you should interpret the order's business units.

Order typeWhat it is
CUSTOMER_ORDERthe default — a customer bought something and a store picks it
STORE_TRANSFERanother store asked this store to supply goods; the same pickers pick it the same way

The field is orderType on the order, and it is always present — an order created without one is a CUSTOMER_ORDER.

Why store transfers appear here at all​

A store transfer is picking work. Somebody walks the aisles, finds the goods, marks them picked, and the goods leave the store. That is exactly what Click and Collect already does, so a store transfer is presented to the picker as an order rather than as a separate workflow with its own screens.

For the picker there is no difference. The same picking flow, the same statuses, the same substitutions and pauses. The type exists so that everything around the picking can tell the two apart.

🛑 Where it matters: the business units mean different things​

This is the trap, and it is silent.

For a customer order, the business unit on the order is the store picking for a customer. There is one store involved.

For a store transfer, two stores are involved and they are not interchangeable:

  • the supplying store — picks the goods, and is the business unit that owns the order in Click and Collect;
  • the requesting store — asked for the goods, and does not appear as the picking store.

An integration that assumes "the business unit on the order is the store that wanted the goods" gets store transfers backwards, and will look correct for every customer order it sees first.

Telling them apart without reading the payload​

Every order-status-changed message carries an Order-Type message attribute as well as the field in the payload. That means a subscriber can filter server-side and never receive the type it does not care about:

attributes.Order-Type = "CUSTOMER_ORDER"

⚠ The attribute is always one of the two values. An absent or unrecognised value is normalised to CUSTOMER_ORDER before publishing rather than passed through, so a filter cannot silently miss messages carrying something unexpected.

What this means for you​

If you consume Click and Collect events for customer analytics, sales, or fulfilment reporting — filter to CUSTOMER_ORDER. A store transfer is stock moving between your own stores, not a sale, and counting it as one inflates every figure it touches.

If you reconcile stock movements — you want both, but treat them differently. A customer order removes stock from the estate; a store transfer moves it from one business unit to another and the corresponding receipt happens elsewhere.

If you are only interested in store transfers — the transfer itself is owned by Store Transfer, not by Click and Collect. Click and Collect tells you about the picking; the transfer's own lifecycle, including what happens when the goods arrive at the requesting store, belongs to that service.

  • Order statuses — the same statuses apply to both types
  • Events — where orderType and the Order-Type attribute appear