290934

DHL C-TMS

Parcel Carrier Management

FUNCTIONAL SPECIFICATION - 10.7

28/11/11 - 3.1
Reference: FS 290934 NW-8KEMRU

FUNCTIONAL OVERVIEW

Client Requirement

It is assumed that this RIO will be managed in conjunction with the Project Rigel System Requirements Document v1.0 or higher.

Parcel carrier integration including the creation of a standard EDI output to DHL Link of an electronic Carrier Manifest, a hard copy (.pdf or .csv) manifest and labels based on carrier specifications. This also includes the ability to manage carrier tracking numbers and import gazetteer.

Solution

The ‘TripOrder’ XML format will be used for the production of the electronic parcel carrier manifests.

A hard copy will be available in PDF format in the specific format for the carrier.

A new trip error message will be generated, and displayed in a new tab page in the ‘Interface Errors’ screen, should the electronic parcel carrier manifest fail to be transferred to DHL Link so that the users are aware that the manifest has not been sent to the carrier. Therefore, there will also be the ability to re-send the file for the manifest via a button in a new tab page called ‘Carrier Manifest’ of the ‘Interface Errors’ screen.

The existing ‘Default Printer Maintenance’ screen will be used to store the default printer required for each user.

The default printer for the user will then be used automatically when the user requests the automatic printing of the labels via the ‘Pack Confirmation’ EDI message. If the ‘Pack Confirmation’ message contains a printer then its value will be used in preference to the default value stored against the user.

For manually requested re-printed labels, and during manual ‘Pack Confirmation’, the user will be able to specify a printer but will be given the option to accept the user’s default printer setup for the process.

Once planning and packing has been completed and the DU’s labelled (e.g. PARCELS or PALLETS), an end of day manifest will need to be sent to each Parcel Carrier. This will send an electronic copy of the manifest. The trigger point to generate the electronic copy of the carrier manifest should be the changing of the status of the Trip to EN-ROUTE. This should also generate the Despatch Confirmation message from C-TMS to Unison or another WMS.

There is a requirement to be able to delay the transmission of this Despatch Confirmation message to Unison or another WMS for certain transport orders: a new screen will be developed to enable the user to hold the transmission for any transport order on the trip stop.

A new screen called ‘Trip Message Holds’ will be developed for the trip screens to view all orders scheduled on it. There will be a check box against each order that can be manually checked by a user: this will hold the ‘Despatch Confirmation’ message once it is generated. Another button will be available to release the holds.

N.B. There are a number of different label formats required for each carrier of the trip:

• Parcelforce (Logos & Barcodes):
  • Standard Domestic Label
• Domestic Label – Saturday Delivery
• Yodel (Logos & Barcodes)
• DHL Express TD (Logos & Barcodes)
• DHL Own Fleet (Logos & Barcodes)
• Polarspeed (Logos & Barcodes)
• Movianto (Barcodes)

Each label will be produced from a text file, which includes the appropriate printer commands, which will be printed directly to a remote printer as requested by the packer upon processing of the packing confirmation message. All labels will be printed to ZPL2 standard.

A new import message will be created for the upload of the parcel carrier gazetteer information into C-TMS. (See RIO NW-8KENDW for further details.)

A new maintenance screen for the parcel carrier gazetteer/route codes information will be developed.

The following new functionality will be required in C-TMS to allow integration with these Parcel Carriers:

• Routing Tables
• Routing Codes
• Tracking References***

The Range is provided by the Parcel Carrier and held in C-TMS. A system alert or warning message is required to highlight when a new range is required i.e. only 200 numbers left.

Parcel Carrier tracking ranges can be defined in three ways:

• A tracking range covering a shipment
• A tracking range covering shipment and a separate tracking range covering DU
• A tracking range covering DU only

In the instance where the tracking range is applied at DU level the associated interface should include a shipment reference as well. See system requirement documents Appendix 13.2.

The following information is specific to Yodel and is also required to be held and managed within C-TMS:

• Meter Number – Covers all clients in DHL Healthcare – one number
• Account Number – Site Specific (Assigned to specific Despatching Location/Depot and/or C-TMS Customers and multiple combinations thereof)
• Contract Number – Site Specific (Despatching Location/Depot)
• Schedule Number – Client code within account (C-TMS Customer/Warehouse Owner Code)

This information is to be held against the carrier.

This information is used by YODEL to identify particular clients and contracts within DHL and is required to be passed to them with the daily manifest files.

A new tab page will be developed for the carrier to maintain these numbers for combination of location (i.e. despatching depot) and customer.

A Service Table will be required in C-TMS which will drive the labels and manifests; this is one table of seven that is part of the “gazetteer” or Routing Table. Routing Tables are generally updated every three to six months and this should be handled either via a CSV import into C-TMS.

Each carrier will handle this differently as shown:

• Yodel – Multiple Files
• DHL Express TD – Single File
• Polarspeed – Single File
• Movianto – Single File
• Parcelforce – Single File

Service Types are used by Parcel Carriers to manage their delivery capability and SLAs.

If the Service Type is blank an assumption should be made in DHL Link and the field populated with S24. This should then be mapped to the Parcel Carrier Service Type once scheduled.

Scope

This change will be applied to system version 10.7.0.

SET-UP

Pre-Requisites

Table changes have been applied.

Data

The new reports will be added to the standing data to allow it to be selected from the standard reports form.

Implementation Advice

Database table changes must be applied before the new programs are compiled and installed.

Access to the new tab pages will be controlled for specific user groups.

FUNCTIONAL DESCRIPTION

Trip Message Holds

A new form called ‘Trip Message Holds’ (‘TRIP_MSG_HOLDS.fmb’) will be created and made available via a right-click option in the ‘Trip Manipulation’, ‘Trip Execution’, Trip Overview’, ‘Trip Debrief’ and ‘Trip Planning’ screens, to enable the user to prevent the transmission of the despatch confirmation message to DHL Link for a transport order.

The right-click option called ‘Desp Conf Message Hold’ will be available in the following data blocks:

The parameters passed will be:

1. Trip ID (SCH_TRIP.TRIP_ID)
2. Stop Number (SCH_TRIP_STOP.STOP_NO)
3. ‘DESP_CONF’ (message type)

An error message will be issued if the user attempts to call the new screen at a stop that is not loading at the owning depot of the trip.

The ‘Trip Execution’ screen will pass the stop number of the ‘Load Location’.

The ‘Trip Overview’ screen will pass the stop number for the loading activity at the owning depot of the trip when the data is displayed at the trip level and the order level in each tab page.

The ‘Trip Debrief’ screen will pass the stop number of the ‘Load’ location.

If the user accesses the screen via the menu then the trip and stop number may be entered to select the orders on the trip stop; if the screen is called from another trip screen then the trip and stop number will be passed by the calling screen and used automatically to select the orders.

The message type may be selected from a dropdown list which will be ‘Despatch Confirmation’ at present (but the screen could be developed in the future for other messages).

The screen will display the transport orders present on the trip stop at the despatching depot of the trip with a box for each order, when the box is ticked it will prevent transmission of the despatch confirmation message.

For example:

• Clicking ‘Release All’ will un-tick all of the ‘Hold’ boxes.
• Clicking ‘Hold All’ will tick all of the ‘Hold’ boxes.
• Clicking ‘Save’ will save any changes made.
• Clicking ‘Close’ will close the screen and return the user to the calling trip screen or menu.

If the ‘Hold’ box is ticked then the transmission of the message will be prevented. (See section 3.13 for further details about the transmission.)

The ‘SCH_ORD’ database table will be changed to include the following column:

The menu structure will be changed so that the new form is available in the ‘Trip Management’ menu.

Access to the new form will be restricted to specific user groups in the ‘User Access Control’ screen by a new function called ‘TRIP_MESSAGE_HOLD’ (i.e. ‘Allow access to the ‘Trip Message Hold’ screen’). The same access controls will be used to activate the right-click option in the other trip screens.

Access to the new form will also be restricted by user group in the ‘Menus’ tab.

Orion Menu

The menus will be changed so that the new form is available in the ‘Trip Management’ menu:

‘Trip Message Holds’ will be added to the menu options.

Default Printer Maintenance

The default printers may be setup for the user in the ‘User Access Control’ screen:

The default printer type will be a dropdown list of values from the existing ‘REP_PRINTER_TYPE’ database table and the expected values will be:

• Label
• Laser
• Matrix

The default printer type and name for the user will be stored on the existing ‘ADM_DFLT_PRINTER’ database table.

The manifest reports setup should not contain a default queue as the user’s default printer will be used.

The function ‘REP.PARAMS’ will be called for the printing of the manifests specifying local printing but not the user as the system username will be used.

The user’s default printer will be obtained for the printer type of the report: therefore, the manifest reports should be setup for printer type ‘Laser’ and the carrier labels should be setup for printer type ‘Label’.

Meter Number

The meter number will be maintained for the cost centre code of the client, a new field called ‘Meter Number’ will be added to the ‘Cost Centres’ tab page of the ‘Customers’ screen:

The ‘REV_COST_CENTRE’ database table will be changed to include the following column:

Location Maintenance

A new field called ‘Collecting Depot’ will be added to the ‘Locations’ maintenance screen to store the code of origin of the depot location.

The new field will be displayed for ‘CROSSDOCK’ and ‘RDC’ location types.

The ‘GEO_LOCATION’ database table will be changed to include the following column:

For example, the collecting depot could be ‘OXF’ although the location exists for a different sortation hub of ‘LUT’.

Despatch Unit Types Maintenance

A new column called ‘DU Category’ will be added to the ‘Despatch Unit Types’ tab page of the ‘Resource Maintenance’ screen and to the ‘Edit’ screen.

The ‘DU Category’ will define the type of despatch unit for the carrier manifests from a dropdown list of values (e.g. ‘Parcel’ or ‘Pallet’).

The ‘RES_DESPATCH_UNIT_TYPE’ database table will be changed to include the following column:

Carrier Maintenance

Carriers

A new tab page called ‘Config’ (i.e. ‘Carrier Configuration’) will be added to the ‘Resource Maintenance’ screen to include extra fields related to the production of labels and manifests.

The schedule number, account number and contract number are stored against the carrier rather than the customer: they are carrier specific but can be applied at the customer level.

Access to the new tab page will be restricted to specific user groups in the ‘User Access Control’ screen.

For example: