Skip to content

Customer Implementation Technical Guide

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 Integration

Courier Integration

OrderFlow Courier Setup

The modules for the integrations that need to be active at launch need to be present on the system.

This requires:

  • the necessary modules need to be enabled for the customer in RemoteMan.
  • the modules need to be installed in OrderFlow (and declare on their module profile list).
  • the associated Courier entries need to be be visible.

See the Deploy new module in customer environment HowTo for details on this.

Once this is all in place, the setup for each courier should be applied, as per the instructions defined for that courier. Initially, the setup will use just test credentials.

Set Property Granularity

With any courier integration, a number of properties may need to be set to be site or organisation scoped.

For example, if different account numbers with different credentials are used for different channels or organisations, the scoping of the relevant application properties will need to be modified to reflect this.

End to End Testing on Test Account

Using orders for a test organisation and channel, the next step is to verify the courier integration process end to end.

This will involve:

  • importing a set of test orders onto the system.
  • pushing these orders through the courier validation process.
  • 'picking' the orders, then printing the labels at the packing desk.
  • verifying that the labels scan without difficulty.
  • sending the physical labels for verification with the courier.
  • performing any end of day notification or manifest submission.

At this point you will be connecting using the courier integration test credentials and URL.

Verification should involve end to end testing which should ensure that:

  • the interaction with the external courier system works as expected.
  • the label prints as expected.
  • the printed label can be easily scanned.
  • that all of the address and contact information is present on the label.

This verification should be applied for an appropriate mix of orders:

  • orders with different combinations of address:
  • company name present and absent.
  • long addresses with all relevant fields present.
  • short addresses with allowable fields not present.
  • addresses to different destination categories (e.g. domestic vs international orders).
  • all relevant services.

In particular, it should be verified that relevant address and contact information received from the source system is passed to the courier, and is present in the courier label. The API messages and the labels should be inspected to verify this.

The labels as well as information supplied to the courier should be checked for:

  • all main address fields present as expected, including town and region, and no missing address lines
  • contact information present as expected
  • business name present as expected
  • weights, dimension, prices and any other required information present as expected
  • if appropriate, product details such as pricing and customs information present as expected

The testing should be carried out by the OrderFlow Implementation Engineer, as well as the customer.

Note that testing should be conducted from orders received from the third party system, in order to ensure that no information is 'lost' along the way.

A Note on Courier Testing

Attention to detail is very important in this stage in the process, as failure to spot missing information can result in parcels returning undelivered, which will be expensive and bad for customer service.

Courier Selection

The rules for performing courier selection need to be defined and implemented.

This requires:

  • communication from the customer of the rules that need to be applied. This may be in the form of a spreadsheet.
  • a unit tested courier selection script that covers the test scenarios identified.
  • verification using a handful of orders that the rules are being applied correctly.

Note that unit testing is beneficial in reducing the requirement to end to end test exhaustively through all scenarios, which is much less efficient.

For more details on courier selection, see the Courier Selection chapter in the OrderFlow Scripting Guide.

Live Setup and Verification

This involves the setup of live credentials for the courier integration service.

Once this is done, the courier protocol should be followed in terms of testing and verifying labels.

This typically will involve the following, but details may vary:

  • importing a set of test orders with characteristics that represent the mix of orders likely to be received from real customers. This should include a mix by destination, business vs personal addresses, etc.
  • pushing these orders through the courier validation process.
  • 'picking' the orders, then printing the labels at the packing desk.
  • verifying that the labels scan without difficulty.
  • sending the physical labels for verification with the courier.
  • performing and verifying any end of day notification or manifest submission.

Note that the same tests Verification steps that are applied for the test account should be repeated with the live account setup.

Introducing New Accounts

Only really applies for 3PL. May need to use separate account when introducing new clients, from billing point of view.

Need to verify whether this is the case, and hand over mechanism for doing this.