Order Management
Last updated
Last updated
In the fulfillmenttools platform, an order is a request from an end customer via an external store system that must be fulfilled in one of the facilities. It is the key component of the connection between shop systems and the fulfillment platform and the starting point and basis for all subsequent order routing processes of the distributed order management (DOMS).
An order contains information on the customer, the delivery preferences, the items which are ordered and optionally, additional information such as services. The order entity can also be used to provide further information that may be relevant in the subsequent routing or fulfillment process.
Please go to the for more information on managing orders via API. The API documentation can be found here.
This graphic shows an example of the order flows through different modules of the platform.
The fulfillmenttools systems differentiate between ship-from-store orders and click-and-collect orders. Ship-from-store (SfS) orders are shipped from a facility by a shipping provider to the customer's address. Whether this facility is actually a store or a warehouse does not matter. Click-and-collect (C&C) orders are picked up by the customer in the store.
A Click & Collect order is not routed by the DOMS logic since the customer has already chosen a facility from where she wants to pick up the order within the ordering procedure in the web shop. This means a C&C order must contain facility information and the order is routed directly to the specified facility. Optionally, the same is possible for Ship-from-Store orders (see below).
For click & collect orders, the following attributes can be defined:
Primary facility: This is the facility which was chosen by the customer as a pickup location for her order. This attribute will be evaluated by the service type fence.
Supplying facilities:
These facilities are a fallback for the primary facility in case the primary facility cannot fulfill all ordered items. In this case, a re-route can be triggered into one of the supplying facilities (which have to be of service type ship-from-tore). 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 amount of facilities that have to be considered by the DOMS. This attribute will be evaluated by the service type fence.
In case supplying facilities are specified for a click & collect order, they will compete against the primary click & collect facility already when routing the order initially. In case a supplying facility performs better than the primary click & collect facility, this order will be routed to the supplying facility directly. The supplying facility in turn fulfills the order and sends it back to the primary facility.
If the order is a Ship-from-store order it is routed by the DOMS system. In order to perform routing decisions, orders as well as facilities need to be configured. Further input parameters like listings and stock information can improve the routing decision but are not mandatory.
For Ship-from-store orders, the following attributes can be defined:
Service level: Defines whether the customer requires same day or standard delivery. This attribute is evaluated by the service type fence.
Preferred carrier: Can be used in case the customer wants to have her order delivered by a specific carrier. This attribute is evaluated by the carrier availability fence.
Preselected Facilities: Specifies a number of facilities that should be taken into consideration when performing a routing decision instead of all facilities within the network. This attribute is evaluated by the preselected facility fence.
Additionally, custom services can be added to order lines or independent of order lines to an order. Custom services add services to orders or order lines which are executed after picking. This could be shortening of pants, an engraving of a watch or an appointment for an eye test at an optician.
Since a locked order does not create a pick job such an order is not effected by a time triggered reroute.
The expiry feature allows automatic canceling of orders if they are not fulfilled within a specified timeframe. When an order is placed, a specified fulfillment time is set. If the order is not fulfilled within this timeframe, the expiry feature automatically cancels the order and releases the reserved items.
Configure the expiry feature by defining a fulfillment buffer time which is added to the provisioning time to determine the expiry time. Additionally, the "provisioningTime" value must be defined in the order. Alternatively, an expiry entity can be created via the API.
There can only be one expiry entity for each process
If updated, the expiry time is recalculated based on the new information.
Please see here for the API documentation.
Paid: A flag that indicates whether the order has yet to be billed when picked up by the customer (click & reserve) or already has been paid online (click & collect). The flag is not evaluated by any fence or rating but merely shown within the .
There are use-cases where not every order should be fulfilled as soon as possible. In some cases it might me necessary to do some manual checks on an order, e.g., customer verification or fraud detection. This is where a "locked" order can be used. Locked orders are routed to a facility but do not result in a pick job until they are unlocked. The unlocking can be done manually via the or via API.
Please go to the for more information on how to create locked orders.
