Auto-Assignment

Auto-assignment is the routing decision the app makes for each delivery marked with inventoryKey: "auto_assign". It runs automatically on every order change.

Inputs

For each auto_assign delivery, the app looks at:

1. The channel of the order, and the country code on the delivery address. These pick a priority list from configuration.
2. The inventory date on the delivery. This becomes the asOf parameter for stock availability.
3. The order lines' SKUs and quantities — converted to stock requirements via each line's SKU composition.
4. The available stock at each candidate warehouse, as of the inventory date. This includes incoming shipments expected to arrive by that date.

Per-line decision

The app makes a decision per order line, and then aggregates those decisions into delivery-level actions.

Step 1: Single-fulfiller preference

For each line, the app first asks: "is there a single warehouse — searched in priority order — that can cover the entire line by itself?" If yes, that warehouse wins. This includes a lower-priority warehouse beating a higher-priority one that can only partially cover the line.

Why single-fulfiller is preferred

A pick from one warehouse means one parcel, one shipping label, one box, one process. A two-warehouse split means twice the picking labour, two parcels, and an unhappier customer ("why did my t-shirt arrive in two boxes?"). Picking from one location even at a slightly higher cost-per-unit usually wins on operational cost.

Step 2: Greedy fill

If no single warehouse covers the line, the app greedily fills the line in priority order — top warehouse takes as much as it can, next warehouse takes more, until either the line is satisfied or all warehouses are exhausted.

Step 3: Back-order residual

If after the greedy fill there are still uncovered units, the order line stays whole on the original delivery against the country's #1 warehouse. The full demand goes into a single reservation request — the SKU actor places reservations against any physical or incoming stock and records the uncovered units as an explicit back-order entry linked to that request. Back-orders are first-class data — operators, procurement systems, and replenishment jobs can query them directly.

Case table — what the operator sees

This is the per-line outcome translated into what shows up on the order view, plus stock reservations.

Scenario	Routing action	What the operator sees on the order	Stock reservations
A single warehouse can cover the full line	Whole line routed to that warehouse	One delivery with the resolved inventoryKey. No extra deliveries created.	Reserved against the chosen warehouse.
Two warehouses needed; primary has some + secondary has some; together they cover	Line is split across two deliveries	Original delivery shrinks to the primary's share; a new delivery is created with the same shipping address, carrying the secondary's share.	Each portion reserved against its own warehouse.
Stock partially missing — primary covers some, no other warehouse covers the rest	Allocated portion stays on the original delivery; missing portion remains on the same delivery as back-order	One delivery with the country's primary inventoryKey. The full original quantity is on it, even though some units can't be picked today.	Reservations against the primary up to its available stock; the uncovered quantity is recorded as a back-order entry on the same reservation request.
Stock completely missing — no warehouse has any units	Whole line stays on the country's primary warehouse as back-order	One delivery with the country's primary inventoryKey. Warehouse will need to back-order from supplier.	No reservations against actual stock; the full demand becomes a back-order entry linked to the reservation request.
Mixed warehouses + back-order residual	Splits per warehouse + leftover on the original delivery	Multiple deliveries, one per warehouse with stock. The original delivery carries the back-ordered units against the country's primary warehouse.	Each fulfilable portion reserved against its warehouse.

Operator workflow

The above happens automatically when an order is created or modified. As an operator, you mostly observe the result:

1. Open the order in the portal.
2. Look at the deliveries panel — each delivery shows its resolved warehouse, the order lines, and its inventory date.
3. If a delivery has back-ordered units (visible as more demand than reserved), check the warehouse's incoming shipment schedule.

If you need to re-route a delivery (e.g. because stock arrived at a different warehouse), you can:

• Right-click the delivery → Auto assign inventory in the order view. This sets inventoryKey back to auto_assign and re-runs the rule.
• Or open the delivery and manually pick an inventory from the dropdown.

Inventory date behaviour

The inventory date set on a delivery is preserved when the app creates additional deliveries from splits. So a customer's pre-order with inventoryDate = today + 14 days results in deliveries that all share that 14-day horizon — including the deliveries created by the routing app itself.

This means stock that arrives within the 14-day window counts for all of them, even though the deliveries were technically created at slightly different moments by different mutations.

See also

• Configuration — set the priority lists the algorithm reads.
• Back-Orders — what happens when stock is insufficient, and how to handle it.
• Stock Reservations — how reservations move through the order lifecycle.