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:

• Clicking ‘Add’ will insert a new record.
• Clicking ‘Save’ will save any changes made and deletes the carrier configuration record.
• Clicking ‘Delete’ will delete the carrier configuration record.
• Clicking ‘Close’ will return the user to the menus.

The fields will be:

1. ‘Label Format’ (Controls which label format will be used)
2. ‘Manifest Format’ (Controls which physical manifest format will be used)
3. ‘Print Manifest’ (Controls whether the physical manifest will be printed automatically)
4. ‘Vol Factor’ (Stores the volumetric factor for the carrier to convert a weight into a dimensional weight in Kg/m3)
5. ‘Location’ (i.e. the despatching depot of the trip)
6. ‘Customer’ (i.e. the customer of the order)
7. ‘Schedule Number’
8. ‘Account Number’
9. ‘Contract Number’
10. ‘Shipment Tracking Ref’ (Controls which tracking number range will be used at the shipment level and defines destination of lookup on existing data)
11. ‘Unit Tracking Ref’ (Controls which tracking number range will be used at the delivery unit level and defines destination of lookup on existing data)

The ‘RES_CARRIER’ database table will be changed to include the following columns displayed in the second section of the screenshot above:

A new database table called ‘RES_CARRIER_CONFIG’ will be created to store the following columns displayed in the third section of the screenshot above:

The following indexes will be added to the new database table:

Normal Ascending Index 1:

1. CARRIER_ID
2. LOCATION_ID
3. CUSTOMER_ID

Normal Ascending Index 2:

1. CARRIER_ID
2. CUSTOMER_ID
3. LOCATION_ID

The numbers and tracking references may be maintained at the carrier level, at the carrier/location level, at the carrier/customer level or the carrier/location/customer level as required.

In the example above the ‘Unit Tracking Ref’ has been set at the carrier level because a location and a customer have not been set.

The ‘Label Format’ and ‘Manifest Format’ fields will have a list of values based on the new ‘RES_CARRIER_FORMATS’ database table described in section 3.1.2: the ‘Label Format’ must have a type of ‘Label’ and the ‘Manifest Format’ must have a type of ‘Manifest’.

‘Print Manifest’ will be a dropdown list with values of ‘N’ and ‘Y’ available: ‘Y’ will indicate that the physical manifest will be printed to the default printer when the trip is updated to ‘EN-ROUTE’. A ‘NULL’ value will be considered to be ‘N’.

The ‘Schedule Number’, ‘Account Number’ and ‘Contract Number’ will be free text.

The ‘Shipment Tracking Ref’ and ‘Unit Tracking Ref’ fields will have a list of values based on the new ‘RES_CARRIER_TRACKING’ database table described in section 3.5.

The formats are expected to be setup as follows:

N.B. The level at which the tracking numbers will be generated will control whether a despatch unit and/or a shipment label will be produced:

• If only a ‘Unit Tracking Ref’ exists then a label will be printed for each despatch unit quantity.

• If only a ‘Shipment Tracking Ref’ exists then a label will be printed for each despatch unit quantity in the shipment and a label will be printed for the shipment itself.

• If both a ‘Unit Tracking Ref’ and a ‘Shipment Tracking Ref’ exist then a label will be printed for each despatch unit quantity in the shipment and a label will be printed for the shipment itself.

Carrier Printing Formats

A new tab page called ‘Carrier Formats’ will be created in the ‘Resource Maintenance’ screen to maintain the valid label and manifest formats.

A new database table called ‘RES_CARRIER_FORMATS’ will be created to store the following columns:

The new tab page will display fields called ‘Type’ and ‘Format’ as shown in the example below:

• Clicking ‘Add’ will insert a new record.
• Clicking ‘Save’ will save any changes made and also deletes the route codes for the version number if set in the ‘Delete Version’ column.
• Clicking ‘Delete’ will delete the record and associated routing codes.
• Clicking ‘Close’ will return the user to the menus.

The ‘Type’ and ‘Format’ fields will be free text to enable any other formats to be used in the future.

The ‘Print Total on Label’ field will control the printing of the total number of labels per shipment/transport order, i.e. ‘of X’ or ‘/X’. There will be a dropdown list with values of ‘N’ and ‘Y’ available: if the total number of labels needs to be printed on the label (if possible for the label format) then ‘Y’ should be entered.

A list of values will be present for the ‘Current Version’ and ‘Delete Version ‘fields based on the corresponding ‘RES_CARRIER_ROUTING’ or ‘CAR_GAZ_VERSION’ database tables.

The user will be able to update the current version of the format (should one exist on the corresponding ‘RES_CARRIER_ROUTING’ or ‘CAR_GAZ_VERSION’ database table) and the activation date will store the system date and time when the record is updated.

It is expected that the label format will correspond to the gazetteer/routing codes and that the appropriate carrier(s) will be assigned the label format.

The user will be able to delete any old gazetteer/routing codes from the corresponding ‘RES_CARRIER_ROUTING’ or ‘Yodel’ database tables. A check will be present to ensure that the deleted version is not the current version number.

It is expected that the deleted versions will be versions that are no longer required.

N.B. The ‘Current Version’ field will contain validation for ‘Yodel’ to ensure that the gazetteer ID entered exists on the new ‘GAZ_YODEL_VERSION’ database table and that the same gazetteer ID exists on the related database tables ‘GAZ_YODEL_ACTIVATE’, ‘GAZ_YODEL_DEST_STAT’, ‘GAZ_YODEL_PRDSERV’, ‘GAZ_YODEL_DEST_EXC’, ‘GAZ_YODEL_REAMUSID’, ‘GAZ_YODEL_SERVICES’, ’GAZ_YODEL_FEATURE’, ‘GAZ_YODEL_HANDLING’, ‘GAZ_YODEL_COUNTRY’ and ‘GAZ_YODEL_FREIGHT’. It will also be a requirement that the activation date present in the ‘GAZ_YODEL_ACTIVATE’ database table is not in the future.

These database tables will include a gazetteer ID obtained from the filename (e.g. ‘SERVICES.102’) so that they may be maintained with the other database tables described above.

See section 3.6 for further information about the import process.

The current version will be used when the gazetteer/routing code information is accessed.

Carrier Service Types

A new tab page called ‘Carrier Services’ will be created in the ‘Resource Maintenance’ screen to maintain the relationship between the service type of the trip stops and the service code of the carriers for printing on the labels.