Booking

While capacity bookings are primarily executed by the Promising module, understanding this transactional mechanism is critical for system integrator managing custom service categories.

The fundamental purpose of a capacity booking is to securely withhold capacity at a target node from the capacity availability pool. By withholding this capacity, the system dynamically influences subsequent reservation and estimated delivery date requests. Once a capacity slot depletes, the Promising engine automatically discovers the next available slot or pivots to an entirely different sourcing location in an effort to minimize delivery times and fulfillment delay penalties.

Supported booking types

The Capacity service supports two distinct booking mechanisms to handle varying operational complexities:
  • Single booking
    Allocates capacity for a single, specific time slot.
  • Atomic bulk booking
    Enables the concurrent reservation of multiple capacity slots across different lines. This API enforces strict all-or-nothing transactional behavior. If any single line fails the capacity check due to insufficient bandwidth, the entire transaction rolls back that ensures comprehensive order integrity.

Core booking attributes

Regardless of the selected booking type, the API operates by evaluating the following core parameters:
  • Node
  • Date and slot
    The targeted operational day and time window.
  • Resource Pool ID
  • Status
    The current transactional state, for example, Open, Confirmed, In Progress, or Completed.
  • Quantity
    The specific capacity units to withhold.
  • Reference
    The overarching business identifier, which typically resembles the cart or order ID.
  • Line reference
    An optional identifier corresponding to specific cart or order lines.
  • Minutes to expiry
    An optional parameter applicable only when the status is Open. It defaults to the tenant level setting but can be explicitly overridden at the API level.

Capacity status lifecycle and backlog management

Understanding the booking status lifecycle is essential for tracking fulfillment progression.
  • Open
    Resembles a cart reservation where the order has not yet been formalized in an order management system.
  • Confirmed
    Indicates that the order is successfully created and payment is authorized.
  • In progress
    Signifies that the order is undergoing scheduling and is actively assigned to a fulfillment node for processing.
  • Completed
    Marks the final stage when the order is successfully shipped.

Real-world operations are not always perfect and warehouses might experience unexpected labor shortages or misplaced packing slips. If a capacity booking remains in a Confirmed or In Progress status for a date that has already passed, the Capacity Service classifies these units as backlog capacity.

Status management and modification rules

To improve the management of capacity states, the system provides utility APIs that allow statuses to be updated:
  • By Booking ID
    Moves the status of a single, isolated booking.
  • By Reference
    Enables all bookings sharing the same cart or order reference to transition to a new status simultaneously.
It is important to note that capacity statuses do not always need to flow sequentially. In simplified use cases, a status may transition directly from Open to Completed. The statuses can also revert back to Open from any state. However, the Capacity service mandates that all Open bookings must possess a valid expiry time.
To protect the accuracy of operational estimates, the system does not permit the direct modification of booked capacity quantities. If a capacity unit requires an adjustment, the original booking must be explicitly canceled by deleting the booking record and subsequently re-booked for the same date.
Note: If the IBM OMS-SIP integration adapter is enabled, capacity statuses are maintained automatically, transitioning seamlessly as the order propagates throughout the standard fulfillment lifecycle.