Order management

In fulfillmenttools, an order represents the customer's intent as captured in the shop system. It describes what the customer wants, independent of how it will fulfill it later. The order is the starting point for all subsequent routing and fulfillment activities.

The order entity has its own lifecycle and can appear in several states that describe the condition of the customer request itself.

Order statuses

The order status reflects the state of the customer's request. This is the status shown in the orders API.

Status	Description
OPEN	The order has been created and is ready for further processing.
PROMISED	This state represents a preliminary order created for availability and feasibility checks. In this state, the platform can evaluate stock availability, earliest possible delivery dates, carrier options, and other fulfillment constraints before the order becomes binding. A promised order either expires and transitions to an OBSOLETE status, or it's confirmed and becomes a real customer order in the OPEN status. For more details on availability checks and promising logic, see the Availability and Promising documentation.
LOCKED	In some cases, it might be necessary to perform manual checks on an order, for example, customer verification or fraud detection. Locked orders are routed to a facility but don't result in a pick job until they are unlocked. Unlocking can be done manually in Backoffice or using the orders action REST API. . Since a locked order doesn't create a pick job, it's not affected by a time-triggered reroute.
CANCELLED	The order was canceled manually or automatically, depending on the configuration.
OBSOLETE	A promised order expires and transitions to this state.

These statuses belong to the order entity itself and don't represent operational progress. They determine whether and when the customer request can move into operational handling.

Order definition

Consumer information

The consumer section describes the party on whose behalf the order is placed. It may represent an end customer (a typical eCommerce order) or a facility (a supply order or an order placed on behalf of a customer in-store).

The consumer information includes:

• One or more addresses (postal, invoice, parcel locker)

• Facility references (for supply orders) (optional)

• Custom attributes for tenant-specific extensions

Items and product information

The orderLineItems section contains the articles being purchased, including:

• Quantities

• Measurement units

• Scannable codes

• Custom attributes

• Measurement units and their tolerance validations

• Allowed substitutes

• Pricing information

• Tags

If all relevant attributes are maintained in the listing, an item can be provided in its minimal form: tenantArticleId and quantity. All additional article information is then resolved from the listing.

Custom services

Custom services extend the order with additional tasks that must be performed after picking. This enables complex service workflows such as engraving, tailoring, or appointment-based services. They can be attached to the entire order or to specific order line items.

Each service includes:

• Service definition

• Nested service items (optional)

• Article references

• Additional information fields

Delivery preferences and order types

Delivery preferences describe how an order should be fulfilled. They also implicitly define the order type. The platform doesn't require an explicit order type field. Instead, the type is derived from the provided delivery preferences.

• If delivery preferences specify a collect, the order becomes a Click & Collect order.

• If delivery preferences specify a shipping, the order becomes a Ship‑from‑Store order.

• If no delivery preference is provided, the system defaults to Ship‑from‑Store.

• If the consumer is a facility, the order becomes a supply order.

Delivery preferences may include:

• Collect preferences

• Shipping preferences

• Reservation preferences

• Sourcing options reference

• Supplying facilities

• Target times

Click & Collect order

A Click & Collect order is created implicitly when the delivery preferences specify a collection at a facility.

• Facility reference: The customer's chosen facility location for picking up their order. The service type fence will evaluate this attribute.

• Provisioning time: Indicates when the order is expected to be ready for customer pickup at the selected facility.

• Supplying facility configuration:

  • These facilities serve as backups for the primary facility in case the primary facility cannot fulfill all ordered items. In this case, a reroute can be triggered into one of the supplying facilities (which have to be of service type ship-from-store). The supplying facility then fulfills the order and sends it back to the primary facility, where the customer can pick it up. This limits the number of facilities the Distributed Order Management System (DOMS) must consider. The service type fence will evaluate this attribute.

  • If supplying facilities are specified for a Click & Collect order, they will compete against the primary Click & Collect facility during initial routing. If a supplying facility performs better than the primary Click & Collect facility, this order will be routed directly to the supplying facility. The supplying facility, in turn, fulfills the order and sends it back to the primary facility.

Ship‑from‑Store order

A Ship‑from‑Store order is created implicitly when the delivery preferences specify shipment to a customer address. If no delivery preference is provided, this is the default.

DOMS performs routing based on:

• Facility configuration

• Listings

• Stock

• Routing parameters (optional)

Relevant delivery preference attributes:

• Service level: Defines whether the customer requires same day or standard delivery. The service type fence will evaluate this attribute.

• Preferred carrier: Can be used if the customer wants their order delivered by a specific carrier. The carrier availability fence will evaluate this attribute.

• Preselected facilities: Specifies several facilities that should be taken into consideration when performing a routing decision instead of all facilities within the network. The preselected facility fence will evaluate this attribute.

• Desired delivery time/target time: Used for prioritization and promise calculations.

Supply order

A supply order is created implicitly when the consumer information indicates that a facility is placing the order on its own behalf.

Characteristics:

• The requesting facility appears as the consumer.

• DOMS identifies the best supplying facility.

• The order is fulfilled as an internal interfacility transfer.

Payment information

The paymentInfo section captures the payment method and currency. It does not influence routing but is relevant for operational visibility and customer communication.

Custom attributes, stickers, and tags

Custom attributes or tags allow tenants to add additional, tenant‑specific information to an order. They can be used to influence routing logic through the DOMS Toolkit or to attach stickers to operational entities for better visibility during fulfillment.

See the Developer Docs for more information on managing orders via the orders REST API.

Order flow

This graphic illustrates how order flows through the platform's modules.

Processes

While the order describes the customer request, the process represents the operational lifecycle required to fulfill it. A process begins once the platform starts processing the order and continues through fulfillment, cancellation, and returns.

A process may include:

• Routing decisions

• Reservations

• Picking and packing

• Hand over to carriers and customers

• Rerouting

• Expiry handling

• Returns or operational cancellations

Process status

The process status provides a high‑level summary of the order's operational progress. It reflects the overall phase of fulfillment, while the detailed execution is defined by the underlying routing and operational entities such as pick jobs, pack jobs, and handover tasks. Each of these entities has its own lifecycle and status model, and their combined states determine the aggregated process status. The following sections describe the individual operational entities and their specific statuses. This is the status found in the process API.

Status	Description
CREATED	The process has been created and is ready for further processing.
IN_PROGRESS	The process is actively being executed. This includes running routing operations, ongoing fulfillment tasks, or an initiated return.
FINISHED	All underlying operational entities have completed their lifecycles, and the process is fully resolved.
CANCELED	The process has been terminated because the associated order was canceled.
ERROR	The process cannot progress because one or more underlying entities are stuck or failed, for example, due to unroutable items or an unsuccessful shipping‑label creation.

Order events

You can find the relevant order management events in the available events article.

Backoffice order view

For operational users, Backoffice provides a consolidated view of the order and all related process entities. It allows inspecting routing decisions, monitoring fulfillment progress, reviewing operational tasks such as pick and pack jobs, and executing permitted actions. For more details on how orders and processes are represented operationally, see the Backoffice order view article.