Courier Management

Carriers and Services

OrderFlow integrates with a host of systems to support courier integration. On the system, a courier integration is represented using the courier entity.

In some cases, the integration is directly with the carrier itself. In other cases, the integration is with a third party integration service, such as MetaPack or NetDespatch. When integrating with a third party integration service, this can be done either with a particular carrier and service in mind. However, some integration services, notably MetaPack, will select a carrier and service automatically.

OrderFlow supports a range of couriers to enable shipment of items directly to end user addresses. These courier integrations are both directly through integration with the individual carriers systems, and indirectly through specialist integration services such as MetaPack.

See the Advanced section for more details on Integration.

OrderFlow supports three types of integration with third party couriers. Which of these three types of integrations a particular courier uses does have significant implications for order management workflow as well as on the ground support requirements.

Web Services API integration. OrderFlow integrates with the courier via a web services API. OrderFlow uses the courier's API to submit details of shipments to be sent out. Usually, the courier returns one or more labels to be printed, either as a PDF document, some image format (such as PNG), or in raw printable text using a printing language such as ZPL. It also normally provides a tracking reference for the customer's use.

The API also often exposes other operations, for cancelling shipments, generating end of day manifests, etc.

Where possible, we favour using a web services API to integrate with couriers in preference to the other methods, described next.

EDI-based integration. A second type of courier integration involves the use of EDI (Electronic Data Interchange). With this type of integration, OrderFlow manages the assignment of tracking references to shipments internally, typically allocating tracking references from a range provided by the courier. OrderFlow also generates the label internally.

Shipment details are uploaded in bulk to the courier via an end of day manifest, typically either via FTP or HTTP.

This approach has the advantage of allowing the courier integration to easily fit within the order processing workflow. The main weakness is that there is no mechanism for validating the selection of services directly with the courier prior to shipping parcels.

Desktop software integration. Many courier, particularly those that do not provide a web services API, provide a desktop software application for capturing shipment details and generating labels. These software packages are typically installed on desktop PCs on the packing desk in the warehouse. With the help of the Print Server, OrderFlow normally submits shipment data by writing to a file in a folder monitored by the courier desktop application. It then reads files in that folder to obtain tracking references.

The main advantage of the desktop software integration approach is that less work is required initially for the typical integration. However, these integrations typically require much more support effort to set up and maintain, and are consequently our least favoured type of courier integration.

Third Party Delivery Management

For many of the courier integrations in OrderFlow, the integration is done directly with the carrier's software.

There is an alternative that is becoming increasingly common, where the integration is done not with the carrier directly, but with a third party, known as a Delivery Management System.

The role of the Delivery Management Software falls within a range. The most sophisticated suppliers will:

provide a unified interface that allows for a common interface, regardless of the choice of carrier.
performs a service selection, typically based on a cost ranking of available services for the shipment destination, subject to service level requirements.
prepare labels for the selected service.
provide additional value-add services, such as delivery tracking, management reporting, etc.

The number of Delivery Management Software providers has grown in recent years, and includes, among others:

OrderFlow Courier Definitions

As a point of terminonlogy, in OrderFlow, a Courier represents an courier integration, not a carrier. The integration may either be direct with one of the carrier's systems, or indirect via a Delivery Management service.

For some carriers, there a several different integration options available. For example, with RoyalMail, integration can be done via:

NetDespatch, via the courier entries royalmail_domestic_netdespatch and royalmail_international_netdespatch
Despatch Manager Online (DMO), via the courier entry royalmail_dmo
Internally managed in OrderFlow, as in the courier entry royalmail_tracked

For direct with carrier integrations, there is a direct association between the courier and the carrier, so in this case the carrier and courier terms may be used interchangeably.

For indirect integrations via Delivery Management Software providers, the OrderFlow Courier will typically refer to the Delivery Management system. Depending on circumstances, the carrier may be determined either within OrderFlow, or by the Delivery Management Software.

Courier Management Workflow

In the section below we describe the most common workflow for courier selection and management used in OrderFlow.

Courier Integration

Courier selection (described below) is often performed at the time an order and its associated shipment are imported. If a courier selection is required (almost always the case), and no selection is performed on import, then the shipment will typically move into the state courier_not_selected.
The shipment is assigned stock and picking locations. Before the shipment moves into the pickable, the system will determine whether courier validation is required for the shipment. If no validation is required, then the shipment will move directly to the pickable state at this point. If validation is required, the shipment will move into the state courier_not_validated.
If validation is required, the courier validation operation will then be performed, normally automatically via a scheduled job. Courier validation normally involves an operation on the system to determine whether the courier selection is valid for that shipment, and to prepare the label for that shipment. If the validation operation succeeds, the shipment will be moved into the state pickable, and will be ready for the next stage in the picking workflow.
If courier validation fails, the shipment will move into the state courier_invalid. The shipment will need to be modified, or an alternative selection will need to be made manually, in order to allow the shipment to progress.
Once the shipment has been picked, it will arrive at the packing desk, at which point the label will be printed. Note that if the packer determines that multiple packages are required, then the existing courier submission will be cancelled, and the shipment will be resubmitted for validation with the courier as a multi-package shipment.

Courier Selection

Courier selection typically involves the following:

selecting the courier (identified by the reference to the OrderFlow courier entry)
optionally, selecting a service
optionally, specifiying additional options for the courier or service selection

Courier selection is typically performed using the Courier Selection Script, which is covered in the OrderFlow Scripting Guide document. The courier selection script allows for advanced rules on courier selection to be applied. It is represented by a scoped OrderFlow application property, meaning that different courier selection logic can be applied on a per site, organisation or channel basis, or based on combinations of these.

Note that when using a third party Delivery Management System for integration, the job of the courier selection step may simply be to associate the shipment with that system's OrderFlow courier entry. The actual selection of a carrier may take place only as an outcome of submitting the shipment to the delivery management system. The OrderFlow Scripting Guide also discusses a Delivery Management System specific mechanisms for influencing the carrier and service selection on those systems.

Courier selection is covered in detail in the OrderFlow Scripting Guide document.

Courier Stages

For each courier, an association is made between the Shipment Courier State and the relevant courier stage.

The key courier stages are:

import: indicates the courier state which the shipment should reach at the point where import is completed. If the import courier state is on or after partially selected, this may indicate that the courier selection script should be run directly following import.
pick: indicates the courier state which should be reached prior to picking. Mostly commonly used to indicate that courier selection or validation needs to take place before the shipment can be marked as pickable.
pack: indicates the courier state the shipment needs to before the shipment can be moved to packing. Typically used to force a courier selection or validation prior to displaying the packing screen.
label print: typically used to indicate that the shipment needs to be validated or accepted before any attempt can be used to print the shipment label.
despatch: currently not used. However, may in the future be used to indicate that a shipment needs to appear on a manifest before it can be marked as despatched.

Shipment Courier States

In addition to shipment states, a Shipment has shipment courier states, which relate specifically to the courier selection and label printing processes for that Shipment.

A Shipment can progress (sequentially) through the following shipment courier states:-

Shipment Courier States

Name	Description
not_selected	Used to indicate that no courier selection has been made for the shipment. Typically used to trigger the running of the courier selection script at a point in the shipment processing workflow that is later than import, but still prior to picking.
partially_selected	Value for courier against shipment. However, the courier selection is not complete; typically, this means that a courier service or options need to be set.
selection_requires_input	Indicates that the courier selection is complete. However, there may be further information required in order for the shipment to progress further through the courier validation and acceptance process.
selection_complete	All courier and shipment information is present. However, the shipment may still require external validation, for example, via a Web Services API call.
not_validated	Used to indicate that no courier selection has been made for the shipment. Typically used to trigger the running of the courier selection script at a point in the shipment processing workflow that is later than import, but still prior to picking.
validated	Applies when a shipment is using a courier for which some additional processing is required prior to picking. This may involve an API call to a third party system.
invalid	Indicates that a shipment has failed validation, typically via a call to the courier's web service interface. This may occur if the address data for the shipment is faulty, or if the service selection for the shipment is not valid for the shipping destination.
accepted	Indicates that the shipment has been validated and accepted by the courier, for example, through its Web Services API.
label_created	Indicates that a courier label has been produced for the shipment. Does not make any statement on whether the label has been printed or not, as this typically takes place at the point at which the shipment is packed.
manifested	Indicates that the courier has been accepted into a third party manifest.