The defining characteristic of e-commerce fulfillment is the act of shipping orders directly to customers. For a large online retailer, this involves sending hundreds or even thousands of shipments to customers everyday. For many retailers, these customers will be located not just in the UK, but internationally, with delivery carried out by a plethora of courier companies.
In this kind of environment, a seamless integration between the warehouse management system (WMS) and the carrier is essential, both for the productivity of the operation but also for heading off potential problems with delivery once products leave the warehouse.
Types of courier integration
Broadly speaking, there are three types of courier integrations:
- With API integration, OrderFlow communicates directly with the courier’s system over the internet using their Web Services API.
- OrderFlow can also be configured to communicate with carrier-specific Windows desktop-based software that’s running within the warehouse itself.
- Furthermore, OrderFlow can be configured to send end of day reports (or manifests) on dispatched shipments, using an electronic file transfer.
Where available, API integration is the option of choice. This is because it supports the closest, most fine-grained interaction between the WMS and the courier, helping to ensure that a valid service choice is made for each shipment and that the correct order information is included on the courier label and any customs documentation.
As the API integration is now offered by most carriers, this is the format we’ll focus on for the remainder of this article.
What’s involved in a typical WMS courier integration?
There are two fundamental things that happen with every courier integration involving OrderFlow.
Firstly, OrderFlow will send shipment details to the courier for consignments that are due to be sent. This information exchange fulfils a number of purposes. Basic information such as the address and contact information can be validated, and the courier is able to verify that the selected service is valid for the shipment’s destination, weight and dimensions.
Secondly, at least one courier label will need to be produced for each shipment. When an API Integration is used, the label is normally produced by the carrier software, then sent back to OrderFlow as an electronic document. The most common format is PDF, but other formats are used, such as image files (typically PNG) or as text in a printer control language such as ZPL.
Labels are produced by the carrier as they're best placed to ensure that the presentation and layout of the label is correct. When necessary however, we have taken on the task of producing the courier label within the OrderFlow platform itself.
For some courier integrations, the sending of shipment details and the creation of the courier label are the only interactions that are required. Other integrations involve additional messages which are designed to handle certain scenarios.
A cancellation, also known as voiding, is when you notify the carrier that you will no longer be sending a specific shipment.
The need for a cancellation operation is partly driven by the question of how the courier deals with shipments for which a label has been created, but never subsequently sent.
With some couriers, the retailer will only be billed for carriage from the point the shipment is scanned into the depot. If this never happens, the shipment label can be left to expire after a period.
Less commonly, the retailer may be billed from the point of label creation. Here, the creation of the label is analogous to the purchase of a stamp. If the label is not needed, then a cancellation step is important so that a refund or credit can be issued.
Having an explicit cancellation step can be beneficial for the courier in avoiding the unnecessary accumulation of consignments that will never be sent. Without this, there is no way to distinguish on the courier system between shipments that were never sent, and those that were lost in transit.
A manifest is, in general, a notification that shipments have been despatched. The format and content of the manifest will vary greatly from courier to courier, but the basic idea is for the manifest to contain a list of shipments actually dispatched. If done intelligently, a manifesting process can be very useful, in that it provides a mechanism for reconciliation.
It allows the retailer to be specific about which shipments have been sent out during a defined pickup. On receipt at the courier depot, these shipments can be scanned in and compared with the originating manifest to ensure that nothing has been lost in transit. In practice, only a fraction of carriers support a manifesting process of this kind.
Support for all courier integration options
Depending on the courier integration, OrderFlow has support for all of the above options.
Most of the interactions with the courier take place within a standard workflow that’s used for most orders;
- After warehouse picking locations have been assigned for all of the ordered items, details of the shipment will be sent to the courier;
- The label, normally generated on the courier system, will be sent to OrderFlow and stored in the OrderFlow database, ready for printing;
- The items for the shipment will be picked and passed to the packer;
- At this point the stored label will be printed;
- If manifesting is used, the shipment will be added to a manifest after packing;
- Packed shipments included in the same manifest will be dispatched, with manifest documentation and courier API interactions taking place as necessary.
Variations where necessary
There are some variations to this basic workflow. If a shipment turns out to require multiple packages, then a new set of labels will need to be created. As the package contents are only determined at the packing desk, there may be a late stage cancellation and label recreation interaction to make this happen.
Similarly, if there is an extended lag between label creation and picking, the label itself may expire before it becomes usable. OrderFlow can be set up to handle this scenario, and automatically retrieve a new label after a configured expire time has elapsed.
The multi-package and label expiry scenarios are just two of the many things to think about when building an integration between a WMS such as OrderFlow and courier software.
In a later article, we’ll turn to more of these considerations, and talk about some of the gotchas and pitfalls that need to be navigated when creating a seamless integration with courier systems suitable for a high volume e-commerce environment.
Benefit from seamless integration with your couriers by choosing Realtime Despatch. Select from over 40 courier integrations, either directly with individual carriers or indirectly through 3rd party platforms through our OrderFlow WMS platform, helping you minimise processing and shipping costs while keeping your customers happy.
Contact us to find out more.