Back-Orders

Back-orders are the app's answer to "the customer ordered more than we currently have in stock". The default is to take the order anyway, route the unfulfilable portion to the country's primary warehouse, and trust that warehouse to handle the back-order — by ordering from a supplier, by waiting for an incoming shipment, or by escalating.

This page describes the behaviour from an operator perspective. For the algorithm internals, see Auto-Assignment.

The back-order home rule

When the app cannot fully cover an order line, the uncovered residual stays on the country's #1 (primary) warehouse. The primary warehouse is always the first entry in the channel-country priority list configured in Configuration.

Why pin to the primary

Anchoring back-orders to a single warehouse per country is a deliberate choice:

• Clear accountability. When stock arrives or is replenished, only one warehouse needs to act. Spreading back-orders across all warehouses creates ambiguity about whose problem it is.
• Predictable for operators. When a customer asks "where is my order?", you know the answer is always "the country's primary warehouse".
• Matches how supply chains actually work. Replenishment typically goes to one central warehouse, not all of them simultaneously.

Back-order scenarios

Stock situation	What the app does	What an operator sees
Stock fully available	Routes normally.	Standard delivery view; reservations fully match demand.
Partial coverage from multiple warehouses, with leftover	Splits the available portion across warehouses (creating extra deliveries), keeps the leftover on the original delivery against the primary warehouse.	Multiple deliveries — fulfilable ones can ship today; the original delivery has the back-ordered units and waits for the primary's stock.
Partial coverage from primary only	Keeps everything on the original delivery against the primary. Reservations cover what's in stock; the remainder is recorded as a back-order entry on the same reservation request.	One delivery with the primary inventoryKey. The reservation request shows a back-order entry alongside the reservations.
No stock anywhere	Pins the whole line to the country's primary warehouse. The full demand becomes a back-order entry on the reservation request.	One delivery with the primary inventoryKey. The reservation request consists entirely of a back-order entry — entirely waiting on warehouse procurement.
Missing channel config (no priority list set)	Skips routing entirely.	Delivery stays at inventoryKey: "auto_assign" — a clear sign that configuration is missing. Add the country's priority list, save, and the delivery will route on next change.
Empty delivery address country code	Skips routing entirely.	Same as above — delivery stays as auto_assign. Fix the address.

Clearing a back-order

Most back-orders clear themselves. The SKU actor runs its reservation calculator after every relevant change to the warehouse's stock or reservations, and any back-order entries waiting on that SKU are promoted to reservations as soon as enough stock is available.

The operator only has to intervene when they want to redirect the delivery to a different warehouse — for example, if stock arrived at a warehouse that wasn't the one the back-order is pinned to. In that case:

1. The order changes (any field) and the routing rule re-runs, or
2. An operator manually re-triggers routing via right-click → Auto assign inventory, or
3. The delivery's inventoryKey is set back to "auto_assign" and saved.

A delivery's history is preserved

Re-running auto-assignment on a delivery does not erase its history. The order activity log records every routing decision, so an auditor can trace how a delivery moved from back-order to fulfilable to picked.

When a back-order cannot be served by re-routing

Some back-orders won't clear by waiting — the product is being discontinued, the supplier has dropped them, etc. In that case the operator should:

1. Cancel the back-ordered delivery (it has the residual quantity), or
2. Issue a refund / partial fulfilment via the standard order flow.

The routing app itself doesn't model "abandoned back-order" — that's a business decision handled through ordinary order management.

Reservations and back-orders

Back-orders are first-class data in Hantera, not an implicit consequence of numbers going negative.

When the routing app reserves stock against a warehouse, it sends a single reservation request for the full demand. The SKU actor processes that request as follows:

1. It places reservations against actual stock — physical units on hand plus expected incoming shipments. Reservations never exceed available stock, so availableStock floors at zero.
2. Anything still uncovered is recorded as a back-order entry linked to the same reservation request.

So a reservation request for 10 units against a warehouse with 7 in stock produces:

• Reservations totalling 7 (linked to the request).
• One back-order of 3 (also linked to the request).
• availableStock = 0.

Because back-orders are explicit records, they're useful for:

• Generating procurement orders. A job can query all open back-orders on a SKU and decide whether to raise a purchase order with the supplier.
• Replenishment dashboards. Operators see at a glance which warehouses have outstanding back-orders.
• Inter-warehouse transfers. When one warehouse has surplus and another has back-orders, a rule can move stock between them.

Back-orders auto-clear when stock becomes available. Whenever the SKU actor processes a relevant change — stock arrives (physical or incoming), another order is cancelled and releases stock, a competing reservation shrinks — it runs its reservation calculator and promotes back-order entries to reservations against the freshly available stock. No human action is required, and no re-routing is needed unless you want to redirect the delivery to a different warehouse.

The back-order signal is also preserved across re-routing initiated by the app: if a delivery's inventoryKey is set back to auto_assign and the rule picks a different warehouse, the old reservations and back-order entries on the old warehouse are released, and new ones are created at the new warehouse.

See also

• Stock Reservations — how reservations flow through the order lifecycle, and how they interact with completing or cancelling a delivery.
• Auto-Assignment — the routing decision that produces back-orders.