Reservations
A reservation is made after an order has been assigned to a facility. The reservation reserves an existing or future stock for a customer. If no stock is available, the reservation is saved and assigned to the first available stock.
Creating reservations
A reservation is created when an order is placed or a delivery promise is made to a consumer. fulfillmenttools continuously evaluates existing reservations redistributes them when necessary. During reservation creation, the system identifies the most suitable stock — a process called candidate selection.
Stock candidate selection
When realizing or reassigning a reservation, fulfillmenttools finds the best stock to place it on based on various criteria.
A stock qualifies as a candidate if:
Available quantity is greater than 0 (quantity minus existing reservations).
Has
PICKABLEandACCESSIBLEtraits. Both inventory traits are enabled by default.availableUntilis later than the current time (if the order has no desired delivery day) or the order's delivery date.
An expected stock qualifies as a candidate if the order has a desired delivery date and:
Available quantity is greater than 0.
Arrival date of the stock (
purchaseOrder.requestedDate) is before the latest possible pick start.Not delayed (
purchaseOrder.requestedDateis in the future).
Ranking:
Stock candidates: ranked by picking sequence location score if configured (highest first), then
availableUntil(earliest expiring first), thenreceiptDate(oldest first).Expected stock candidates: ranked by expected date (latest first), then
availableUntil(earliest expiring first).Expected stock is ranked higher than regular stock to avoid blocking inventory that could serve other demand.
Redistributing reservations
After a reservation has been assigned to an (expected) stock, fulfillmenttools continuously ensures that the reservations can still be fulfilled. If reservations can't be fulfilled anymore, fulfillmenttools will try to redistribute them to possible (expected) stock candidates.
The system reevaluates reservations whenever stock or expected stock changes, for example, when:
Stock is updated
Stock is deleted
Stock becomes non-pickable or non-accessible: This could mean the stock was relocated within the facility to a location without the pickable or accessible trait.
Expected stock arrival date changes: If users are notified of changes to a delivery's arrival date, we recommend adjusting the requested date in the purchase order. This will trigger a check to ensure that all reservations can still be fulfilled.
Expected stock quantity changes: If users are notified of changes to the requested items in a delivery, we recommend updating the purchase order to reflect those changes. This will trigger a check to ensure that all reservations can still be fulfilled.
A purchase order is canceled
When a reservation is removed from expected stock (for example, because an order was canceled), the system doesn't use this newly released expected stock to resolve any existing over‑reservations automatically.
Reservations in a facility can be manually rechecked and optimized, for example, to determine whether reservations can be reassigned to a later-arriving expected stock.
This functionality is intended for troubleshooting and is available only upon request. If you encounter reservation issues, contact our Support team to trigger this process.
Exceptions to automatic reassignment
Reservations aren't automatically moved if:
Expected stock becomes delayed: In this case, users are expected to update the requested date of the purchase order via the API or cancel the purchase order (via API or Backoffice).
Stock expires or reaches its available until date: In this case, users are expected to mark expired stock as non-pickable, non-accessible, or delete it completely. This can be done via the stock API or Backoffice.
Over-reservations
If no stock is available when a reservation is created, an over-reservation is automatically created. It's automatically assigned once stock meeting the reservation criteria becomes available.
In Backoffice, over-reservations appear alongside all other reservations in the Stock overview view. Facilities with over-reservations show an info icon and tooltip.
An over-reservation is calculated when the sum of reserved and safety stock exceeds the available pickable and accessible stock. An over-reservation is only reported when other reservations exist. If safety stock alone exceeds the available stock but there are no reservations, an over-reservation isn't shown.
The order remains available for picking during the defined timeframe. If a short‑pick is reported, the system can re‑route the order or allow a manual reassignment.
Reservation prioritization
When stock becomes available at a facility, reservations are handled in a clear, defined order.
1. Over-reservations (reservations without stock)
These are handled first.
Sorting:
Reservations of orders that must be picked earliest
Largest reservation quantity (For example, a reservation for 5 items is prioritized over one for 2 items.). This is done to avoid orders being shipped in multiple shipments.
2. Reservations on expected stock
Only applies if expectedStock.generateFromRoutingPlan = true.
Sorting:
Earliest
availableFromLargest reservation quantity
For details, refer to the Global Inventory Hub configurations article.
3. Tie-breaker
If several reservations qualify at the same time, the reservation with the earliest pick start is improved first.
Removing reservations
Reservations are removed when fulfillment progresses or is canceled. By default, reservations are automatically removed after the related pick job is closed, aborted, rerouted, or canceled.
There are three independent release paths:
Facility unassignment
Routing plan unassigned (due to reroute or cancellation).
All reservations for the routing plan.
Operational release
Pick job closed/aborted/rerouted, or handover job completed/aborted.
Use the reserved stock configuration to define a different removal event.
All reservations for the routing plan.
Action API
If a facility doesn't use operational entities (such as pick or handover jobs), reservations can be removed via the REST API.
Individual reservations by ID, order reference, routing plan reference, or predicate. See reservation actions for more information.
Stock can be marked as outbound first and removed later using the outbound stock configuration.
Use case examples
Reservation completed without issues (happy path)
A customer places an order online. Physical stock is available, and all conditions are met.
Starting situation
Order
Online order via webshop
Order delivery date
15 February 2026
Stock
50 units, pickable and accessible
Expected stock
0
Stock expiry date
31 March 2026 (after delivery date)
Configuration
Default configuration
Timeline
1
The consumer places an order, and it's assigned to a facility. Valid stock is checked.
Stock is pickable, accessible, and valid until 31 March 2026. All conditions met. A reservation is created on the physical stock.
2
Pick job is started
Users begin picking the reserved items.
3
Pick job is closed
Reservations and stock are automatically removed.
Result
The reservation is completed without manual intervention.
Delayed delivery (expected stock)
Starting situation
Order
Online order via webshop
Order delivery date
20 February 2026
Stock
0
Expected stock
Purchase order: 100 units, planned arrival 12 February 2026
Stock expiry date
-
Configuration
Default configuration
Timeline
1
Order is received
System finds no physical stock. Expected stock arriving on 12 February qualifies (arrival before pick start). A reservation is placed on the expected stock.
2
Supplier reports delay: new arrival 25 February 2026
The new date is in the future, but now falls after the order's delivery date (20 February). Expected stock is now treated as delayed.
3
Reservation can no longer be fulfilled in time
The reservation on the expected stock is not automatically redistributed. It remains in place but can no longer be fulfilled as-is.
4
User resolves the situation manually
The info icon and tooltip in Backoffice indicate the facility has over-reservations. The user must update the purchase order or adjust the stock manually in Backoffice.
5
Pick job is started and closed
Users begin picking the reserved items. Reservations and stock are automatically removed after the pick job is finished.
Important: The system doesn't automatically reassign reservations on delayed expected stock. A manual action is required. For example, correct the purchase order date, update the stock in the facility, or reroute the order.
Result
The reservation is held until the delayed delivery arrives. If it arrives too late, the order's promised delivery date will be missed. To ensure on-time fulfillment, manual intervention is needed.
What should I do as a user?
Update the purchase order in the system to reflect the new arrival date.
Check whether an alternative source or another facility can fulfill the order.
Notify the customer of the delay and update the delivery date if needed.
Over-reservation
Starting situation
Order
Two orders of 10 units each (Order A and Order B)
Order delivery date A
18 February 2026 (earlier)
Order delivery date B
22 February 2026 (later)
Stock
0
Expected stock
0
Stock expiry date
-
Configuration
Default configuration
Timeline
1
Both orders are received
No stock available. System creates over-reservations for both orders. These appear in Backoffice with an info icon.
2
New goods receipt: 10 units arrive
System detects available stock. Prioritization begins.
3
System prioritizes over-reservations
Order A has the earlier delivery date and is served first. Order A receives a reservation for the 10 units.
4
Order B remains an over-reservation
No further stock available. Order B remains over-reserved until additional stock arrives.
5
Another new goods receipt: 10 units
Order B is now also assigned stock. Over-reservation is resolved.
6
Pick jobs are started and closed
Users begin picking the reserved items. Reservations and stock are automatically removed after the pick jobs are finished.
Result
Over-reservations are resolved automatically as soon as matching stock becomes available. Priority is based on the earliest delivery date. So, no manual action needed.
What do I see in Backoffice?
Facilities with over-reservations show an info icon with a tooltip.
Over-reservations appear in the reservations list alongside all other reservations.
Once the stock arrives, the over-reservation is automatically resolved.
Using the reservations endpoints
Search reservations
To search for reservations, execute the following POST request with a JSON body:
The example above searches for reservations matching a specific tenantArticleId, facilityRef, and routingPlanRef.
Reservations actions
The reservation actions endpoint uses the following fields to define its scope:
The
reservationSelectorfield selects reservations at a high level, for example, by order.The
reservationPredicatefield refines the selection made by thereservationSelector. This allows for more granular control, such as removing reservations for only specific line items within an order.The response provides insights into the success of the operations to remove reservations and reduce stock.
Remove reservations and reduce stock
To remove reservations and the corresponding reserved stock, use the REMOVE_RESERVATIONS_REDUCE_STOCKS action.
Execute the following POST request with the specified JSON body:
A successful request returns a 200 OK response with the following body.
Remove reservations and keep stock
To remove only the reservations without reducing stock, use the REMOVE_RESERVATIONS_KEEP_STOCKS action. In this transaction, no stock is reduced.
Execute the following POST request with the specified JSON body:
A successful request returns a 200 OK response with the following body.
Last updated

