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 PICKABLE and ACCESSIBLE traits. Both inventory traits are enabled by default.

  • availableUntil is 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:

Ranking:

  • Stock candidates: ranked by picking sequence location score if configured (highest first), then availableUntil (earliest expiring first), then receiptDate (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

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 availableFrom

  • Largest reservation quantity

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:

Path
Trigger
Scope

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

Timeline
Event
Action

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

Timeline
Event
Action

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.

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

Timeline
Event
Action

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:

Reservations actions

The reservation actions endpoint uses the following fields to define its scope:

  • The reservationSelector field selects reservations at a high level, for example, by order.

  • The reservationPredicate field refines the selection made by the reservationSelector. 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:

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:

Last updated