Order management

Introduction

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 Developer Docs for more information on managing orders via the orders REST API.

Order flow

This graphic shows an example of the order flows through different modules of the platform.

Order service types

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.

Click & collect orders

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:

• 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 Operations App.
• 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.

Ship-from-store orders

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.

Custom services in order

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.

Locked orders

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 Backoffice or via orders action REST API.

Since a locked order does not create a pick job such an order is not effected by a time triggered reroute.

Please go to the Developer Docs for more information on how to create locked orders.

Order expiry

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 expiries REST API.

• There can only be one expiry entity for each process

• If updated, the expiry time is recalculated based on the new information.

Order modification and cancelation

The following operations are supported:

• Change carrier: Allows changing the carrier of the corresponding picking task. If a label has already been requested, it becomes obsolete when the carrier was changed. A new label must be requested in that case.

• Change consumer addresses: It is possible to change addresses in case of a typo or an incorrect entry.

• Cancel order: Cancels all corresponding entities of an order. The following conditions must apply to perform this action :

  • all pick jobs are in status OPEN

  • no items have been picked

  • no labels were requested

• Force canceling an order: Cancels all corresponding entities of an order. This function differs from the previous one. Force cancelation is possible at any time and no operational status are checked. This means that processes might be revised operationally without system support. An example might be that picked items must be stowed back and stock must be adjusted manually. If items were not picked but reserved, the system releases the reservations. This feature must be activated via REST API.