Skip to content

OrderFlow Operational Functions

OrderFlow Ltd.

Document Version: 4.2.4

Document Built: 2024-02-16

This document and its content is copyright of OrderFlow Ltd. All rights reserved.
You may not, except with our express written permission, distribute, publish or commercially exploit the content.
Any reproduction of part or all of the contents in any form is prohibited.

Courier Management

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.

Courier Properties

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.

Courier Management Workflow

TODO - describe the workflow for different types of integrations

API: before shipment becomes pickable, but after stock assignment, label is fetched.

Describe shipment states:

  • courier not selected
  • courier not validated
  • courier invalid

Cancellation

Manifesting

TODO - add this, perhaps in a courier chapter.