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.

The ‘PARCELFORCE’ carrier will be setup with service types ‘S09’, ‘S10’, ‘S12’, ‘SND’ and ‘SUP’.

The ‘CARRIER CODE’ column above is the Unison carrier code and it will be mapped by DHL Link to the carrier ID in C-TMS during the order upload.

The new ‘Carrier Services’ tab page will enable the carrier service type of the trip stop to be mapped to the carrier service code for printing on the labels (e.g. ‘S24’ maps to ‘24’):

For example:

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

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

Unique Ascending Index 1:

1. CARRIER_ID
2. SERVICE_TYPE

Carrier Routing Codes

Maintenance

The new ‘Carrier Routing’ tab page will display records from the new ‘RES_CARRIER_ROUTING’ database table in the ‘Resource Maintenance’ screen:

For example:

A horizontal scrollbar will be present to display the other columns:

• Earliest Del Time
• Sun
• Mon
• Tue
• Wed
• Thu
• Fri
• Sat

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

The days of the week will be a tick box which if ticked will have a value of ‘Y’.

The earliest delivery time will be stored as 4 digits, e.g. ‘0730’.

The ‘RES_CARRIER_ROUTING’ database table will be created for the new carrier route code files:

Each of the carrier routing files uploaded (except ‘Yodel’) will write data to the new database table as follows:

Each upload of a route code file for the carrier will be provided with a version number so that the current version may be set.

The version number will be a sequential number for the carrier file.

N.B. It is expected that unused versions will be deleted to limit the number of records stored on the database tables. This will be a process managed by the user and the records will not be deleted automatically.

N.B. It is expected that only the ‘ESD’ format will be uploaded for ‘DHL Express’ and not the ‘TDB’ format.

Activation

The current ‘Yodel’ gazetteer and other carrier routing codes will be maintained in the new ‘Carrier Printing Formats’ tab page of the ‘Resources’ screen: the user will be able to set the current version and delete any old versions.

A check will be in place for when the gazetteer is activated to check that all records are present with the same version number, if they are not then the gazetteer cannot be activated.

Carrier Tracking Numbers

Maintenance

A new maintenance tab page called ‘Carrier Tracking’ will be created in the ‘Resources’ screen to maintain the tracking ranges required for each combination of carrier, client (customer) and level (shipment and/or DU level).

An example of the current tracking number ranges is shown below:

The carrier ID will have a shipment reference and/or a DU reference assigned to it to obtain the next tracking number at the appropriate level.

A new database table called ‘RES_CARRIER_TRACKING’ will be created to store the tracking numbers at the different levels:

‘RES_CARRIER_TRACKING’:

A unique primary key constraint will be created for the following columns:

• REF_TYPE

The remaining numbers will be calculated by the deduction of the next number from the end number for each record.

The new ‘Carrier Tracking’ tab page will display records from the new ‘RES_CARRIER_TRACKING’ database table in the ‘Resource Maintenance’ screen:

For example:

A horizontal scrollbar will be be present to display the other columns:

• SMS Number 2
• SMS Number 3
• SMS Number 4

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

The alert may be sent to an e-mail address plus up to 4 mobile phone numbers as a text message, therefore, at least one address must exist for the alert to be sent.

The check digit will be maintained with the update of the next number because the next number is used to form the check digit.

For example, next number ‘717923521’ will have a check digit of ‘0’ based on the function for the carrier.

There will be check digits formats for ‘Parcelforce’, ‘DHL Express’, ‘Courier’ and ‘Own Fleet’ carrier/customer combinations only:

‘Recycle’ will be a tick box that will indicate that the next number may return automatically to the start of the range when the end of the range has been reached; an alert will still be sent even if the number range may be recycled. A ticked box will have a value of ‘Y’. The default will be ‘N’ for no recycling.

The maintenance tab pages may be used to insert, change and delete records.

Parcelforce Check Digit Algorithm

To calculate a check digit for a ‘Guaranteed’ service consignment number where:

XX is a two character alphabetic prefix

nnnnnn is a 6 digit number

C is the check digit

The procedure is as follows:

1. Multiply the first digit in the 6 digit number by 4.

Multiply the second digit in the 6 digit number by 2. Multiply the third digit in the 6 digit number by 3. Multiply the fourth digit in the 6 digit number by 5. Multiply the fifth digit in the 6 digit number by 9. Multiply the sixth digit in the 6 digit number by 7.

1. Add the results together.
2. Divide the resulting total by 11, note the remainder.
3. Subtract the remainder from 11.
4. If the result of (4) is 10, then the check digit is zero.

If the result of (4) is 11, then the check digit is 5. Else the check digit is the result of (4).

Thus, given a 6 digit number of 162738 the check digit calculation is as follows:

1. 1 x 4 = 4.

6 x 2 = 12. 2 x 3 = 6. 7 x 5 = 35. 3 x 9 = 27. 8 x 7 = 56.

1. 4 + 12 + 6 + 35 + 27 + 56 = 140.
2. 140 * 11 = 12 remainder 8.
3. 11 – 8 = 3.
4. Check digit = 3.

Alerts

An alert message will be generated in an e-mail when the tracking number range is nearing its limit for the calendar year (i.e. when the number of remaining tracking numbers reaches the alert level set).

The recipient e-mail address will be setup for the tracking reference type.

The alert message will have the following format:

‘Tracking reference type X is approaching its limit – please investigate.’

The e-mail will be sent to the e-mail address of the required recipient when the next tracking number used leaves the remaining numbers below the threshold set.

N.B. The method of transfer of messages to be used is described in section 3.6 of the functional specification ‘FS-290930 NW-8KENDB SMS Pre-advice v1.0.doc’.

Processing

When the label is printed the tracking number will be stored at the appropriate level on a new database table called ‘SCH_ORD_TRACKING’:

REF_TYPE’ will indicate the type of tracking reference recorded: ‘S’ for shipment level and ‘D’ for despatch unit level depending on the next number used from the ‘RES_CARRIER_TRACKING’ database table.

• ‘SHIPMENT_ID’ will indicate the shipment ID generated for the transport order/shipment.
• ‘CARRIER_ID’ will indicate the carrier for whom the tracking reference was generated.
• ‘LINE_NO’ will indicate the line of the transport order to link the despatch unit tracking reference with the despatch unit.
• ‘DU_TYPE’ will indicate the despatch unit type of the despatch unit tracking reference.
• ‘TRACKING_NO’ will be the actual number used (‘next’ at the time).
• ‘TRACKING_REF’ will be the full tracking referenced used on the packing label.
• ‘CARTON_NUMBER’ will be the carton number obtained from the ‘CIPD’ message from Unison WMS, for which the despatch unit tracking numbers will be generated.

If a tracking number is used at the shipment or the despatch unit levels then a record will be written to the new table to store which tracking numbers have been used for which shipments/despatch units. The full tracking reference (a.k.a. air bill number) will also be recorded.

The storage of the carton number on the ‘SCH_ORD_TRACKING’ database table means that a record will need to be written when the ‘CIPD’ message is processed and then the record will be updated when the tracking number is generated for the printing of the label. The tracking number may then be linked to the carton number for the ‘CITD’ message that is sent to Unison WMS to store the tracking number against the carton number.

N.B. If a transport order has been entered manually then a carton number and sales order number will not be known and thus the ‘CARTON_NUMBER’ and ‘SO_REF’ columns on the ‘SCH_ORD_TRACKING’ database table will be blank. Therefore, the columns may be described as ‘nullable’.

Parcel Carrier Gazetteer

Imports - Yodel

A new import type of ‘GAZ_YODEL’ will be introduced for the ‘Import Maintenance’ screen so that the following record type may be setup:

• VERSION (Version)

The import of the gazetteer will be run for a single record type for the version and all of the other files will be processed automatically with the version provided that all files are for the same gazetteer ID.

The other record types are listed below although they do not need to be setup in the ‘Import Maintenance’ screen:

• ACTIVATE (Activation)
• DESTINATION_STATION (Destination Station)
• DESTINATION_PRDSERV (Destination Services)
• DESTINATION_EXCEPT (Destination Exception)
• REAMUSID (Reamusid)
• SERVICES (Service Codes)
• FEATURE (Feature Codes)
• HANDLING (Handling Codes)
• COUNTRY (Country Codes)
• CONFRDES (Freight Codes)

The format name will be setup as ‘Yodel Carrier Gazetteer’, for example, with an import type of ‘GAZ_YODEL’ and a default filename of ‘VERSION.txt’.

The fields in the files to be uploaded will be delimited by pipes (‘|’) (configurable).

If only the version file were not used then the other pipe-delimited files would be setup as separate record types; and separate import and record types would be introduced, as listed below, for the files that do not contain the gazetteer ID as an item:

• SERVICES (Service Codes)
• FEATURE (Feature Codes)
• HANDLING (Handling Codes)
• COUNTRY (Country Codes)
• CONFRDES (Freight Codes)

The fields in the above files to be uploaded would be of fixed length.

‘String’ data types will be considered as ‘VARCHAR2’ data types and ‘Float’ data types will be considered as ‘NUMBER’ data types.

All import files processed will add new records on the new database tables created for each aspect of the gazetteer.

The following filenames will be expected and they will be required to be placed by the user into the required directory to be found in the browser:

The files expected will be:

1. VERSION.txt
2. ACTIVATE.999
3. DESTINATION_PRDSERVICE.999
4. DESTINATION_STATION.999
5. DESTINATION_EXCEPTION.999
6. REAMUSID.999
7. SERVICES.999
8. FEATURE.999
9. HANDLING.999
10. COUNTRY.999
11. CONFRDES.999

The ‘Import Maintenance’ and ‘Import’ screens will not be changed.

IMP Package

For the gazetteer information, only the file ‘VERSION.txt’ need be imported to set the gazetteer ID; the other files will then be uploaded using the gazetteer ID as the suffix (e.g. ‘ACTIVATE.102’); this will be done by appending the gazetteer ID obtained in the ‘VERSION.txt’ file.

The whole set of files must be uploaded together so that the gazetteer is maintained correctly, the gazetteer ID in the ‘VERSION.txt’ file must match the gazetteer ID contained in the other files as the suffix.

A check will be performed to ensure that the 11 gazetteer files are present in the same directory with the same version number before the upload can proceed: if the whole gazetteer is not present and validated then the upload will be rejected.

The gazetteer ID must be greater than the previous gazetteer IDs stored to ensure that old data is not re-used.

The files with a suffix of ‘999’ will be renamed with a suffix of ‘txt’ prior to upload, for example, ‘ACTIVATE_102.txt’.

The ‘Import’ button in the ‘Import’ screen will call the ‘IMP.IMPORT_SERVER_FILE’ function and pass the directory path and file found.

Function ‘IMP.IMPORT_SERVER_FILE’ will then read and validate the file received.

Changes will be made for the new ‘GAZ_YODEL’ import type.

‘IMPORT_SERVER_FILE’

This function will be changed to check for the new import types and call the new functions.

‘PROCESS_YODEL_GAZ’

A check will be performed at the start of the function to ensure that all of the gazetteer information is present in the same directory with the same gazetteer ID. (N.B. The 6 different filenames will be stored as the record types for the ‘GAZ_YODEL’ import type: VERSION, ACTIVATE, DESTINATION_STATION, DESTINATION_PRDSERV, DESTINATION_EXCEPT, REAMUSID; the other 5 files will be available as separate record types due to their fixed formats.)

If a valid set of gazetteer files is present then each file will be processed after the ‘VERSION.txt’ file within the same import process. Thus there will not be a requirement to import all of the files separately.

Each file will need to be processed consecutively so the file will need to be accessed and read afresh; it will be necessary to rename the files with a ‘txt’ suffix; UNIX commands may be used for this purpose.

The import will only store the data on the new gazetteer tables (external) and will not update automatically the active data for the carrier lanes used to assign carriers and to schedule transport orders/shipments onto trips for the carriers.

A new screen called ‘Carrier Printing Formats’ will be available to perform the update of the new version of the gazetteer as the live data once the activation date has passed. See section 3.5.2 for further information.

‘PROCESS_YODEL_SERVICES’

The file will be processed and it will be necessary to rename the file with a ‘txt’ suffix; UNIX commands may be used for this purpose.

‘PROCESS_YODEL_FEATURE’

The file will be processed and it will be necessary to rename the file with a ‘txt’ suffix; UNIX commands may be used for this purpose.

‘PROCESS_YODEL_HANDLING’

The file will be processed and it will be necessary to rename the file with a ‘txt’ suffix; UNIX commands may be used for this purpose.

‘PROCESS_YODEL_COUNTRY’

The file will be processed and it will be necessary to rename the file with a ‘txt’ suffix; UNIX commands may be used for this purpose.

‘PROCESS_YODEL_CONFRDES’

The file will be processed and it will be necessary to rename the file with a ‘txt’ suffix; UNIX commands may be used for this purpose.

The breakdown of each file is shown in the following sections.

Version

The only row of the file contains the Gazetteer ID (version number):

This record type will have the following field type available for selection:

1. GAZETTEER_ID

For example:

102

A new database table called ‘GAZ_YODEL’ will be created to store the information uploaded for the ‘VERSION’ record type:

Activate

The only row of the file contains the Gazetteer ID (version number) and the activation date:

This record type will have the following field types available for selection:

1. GAZETTEER_ID
2. ACTIVATION_DATE

For example:

10230/04/2009

A new database table called ‘GAZ_YODEL_ACTIVATE’ will be created to store the information uploaded for the ‘ACTIVATE’ record type:

DESTINATION_STATION

The first row of the file contains the Gazetteer ID (version number), with a pipe delimiter end:

This record type will have the following field types available for selection:

1. GAZETTEER_ID
2. COUNTRY_CODE
3. TOWN
4. COUNTY
5. FROM_POSTCODE
6. TO_POSTCODE
7. PRODUCT_CODE
8. FROM_WEIGHT
9. TO_WEIGHT
10. SERVICE_CENTRE_REAMUSID
11. SORTATION_HUB_REAMUSID

For example:

102|||||||||| GB|||AB10 0AA|AB16 9ZZ|01|0|3150|077240|077760| GB|||ZE1 1AA|ZE3 9ZZ|17|0|99999|98|98|

The first line is the ‘Gazetteer ID’ and will be processed separately by the import process.

The following item will be validated that it exists in C-TMS:

• COUNTRY_CODE

A new database table called ‘GAZ_YODEL_DEST_STAT’ will be created to store the information uploaded for the ‘DESTINATION_STATION’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTEER_ID
• COUNTRY_CODE
• FROM_POSTCODE
• TO_POSTCODE
• PRODUCT_CODE
• FROM_WEIGHT
• TO_WEIGHT

DESTINATION_PRDSERV

The first row of the file contains the Gazetteer ID (version number), with a pipe delimiter end:

This record type will have the following field types available for selection:

1. GAZETTEER_ID
2. SERVICE_CENTRE_REAMUSID
3. PRODUCT_CODE
4. FEATURE_CODE
5. ALLOWED

For example:

102||||

0|17|C0|Y|

078016|01|17|Y|

The first line is the ‘Gazetteer ID’ and will be processed separately by the import process.

A new database table called ‘GAZ_YODEL_DEST_PRDSERV’ will be created to store the information uploaded for the ‘DESTINATION_PRDSERV’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTEER_ID
• SERVICE_CENTRE_REAMUSID
• PRODUCT_CODE
• FEATURE_CODE

DESTINATION_EXCEPT

The first row of the file contains the Gazetteer ID (version number), with a pipe delimiter end:

This record type will have the following field types available for selection:

1. GAZETTEER_ID
2. COUNTRY_CODE
3. TOWN
4. COUNTY
5. FROM_POSTCODE
6. TO_POSTCODE
7. PRODUCT_CODE
8. FEATURE_CODE

For example:

102|||||||

GB|||AB10 0AA|AB10 9ZZ|01|04|

GB|||ZE3 0AA|ZE3 9ZZ|01|17|

The first line is the ‘Gazetteer ID’ and will be processed separately by the import process.

The following item will be validated that it exists in C-TMS:

• COUNTRY_CODE

A new database table called ‘GAZ_YODEL_DEST_EXC’ will be created to store the information uploaded for the ‘DESTINATION_EXCEPT’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTEER_ID
• COUNTRY_CODE
• FROM_POSTCODE
• TO_POSTCODE
• PRODUCT_CODE
• FEATURE_CODE

N.B. It is possible that because of the number of records per gazetteer that the file may be split and uploaded in sections: this will not be a problem as long as the gazetteer ID is provided in the first line of each file.

REAMU SID

The first row of the file contains the Gazetteer ID (version number), with a pipe delimiter end:

This record type will have the following field types available for selection:

1. GAZETTEER_ID
2. REAMUSID
3. LOCATION_NAME
4. OPUNIT
5. COUNTRY_CODE
6. LOCATION_ID

For example:

102||||

11|NEWCASTLE|11|GB|

078016|BELFAST HUB|078016|GB|

102||||

The first and last lines are the ‘Gazetteer ID’ and will be processed separately by the import process.

The following item will be validated that it exists in C-TMS:

• COUNTRY_CODE

A new database table called ‘GAZ_YODEL_REAMUSID will be created to store the information uploaded for the ‘REAMUSID’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTEER_ID
• COUNTRY_CODE
• REAMUSID

Services

A new import type of ‘GAZ_YODEL_SERVICES’ will be introduced for the ‘Import Maintenance’ screen.

The fields in the files to be uploaded will be of fixed length.

The file contains the following fixed-length items:

This record type will have the following field types available for selection:

1. SERVICE_ID
2. SERVICE_DESC
3. PRODUCT_LINE_1
4. PRODUCT_LINE_2
5. PRODUCT_CODE
6. DATE_CODE
7. DAY_TEXT
8. TIME_CODE
9. TIME_TEXT
10. HANDLING_FEATURE_TEXT
11. FEATURE_ID
12. FEATURE_CODE
13. FILE_TYPE
14. CON_FLAG
15. DS_FLAG
16. FILLER

For example:

A new database table called ‘GAZ_YODEL_SERVICES’ will be created to store the information uploaded for the ‘GAZ_YODEL_SERVICES’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTEER_ID
• SERVICE_ID

Feature

A new import type of ‘GAZ_YODEL_FEATURE’ will be introduced for the ‘Import Maintenance’ screen.

The fields in the files to be uploaded will be of fixed length.

The file contains the following fixed-length items:

This record type will have the following field types available for selection:

1. FEATURE_ID
2. NO_FEATURE
3. CUSTOMS_CLEAR
4. CASH_ON_DEL
5. EX_WORKS
6. FUTURE_USE_1
7. FUTURE_USE_2
8. FUTURE_USE_3
9. FUTURE_USE_4
10. FUTURE_USE_5
11. FUTURE_USE_6
12. FUTURE_USE_7
13. NO_FIXED_DAY
14. FIXED_DAY_01
15. FIXED_DAY_02
16. FIXED_DAY_03
17. FIXED_DAY_04
18. FIXED_DAY_05
19. FIXED_DAY_06
20. FIXED_DAY_07
21. FIXED_DAY_08
22. FIXED_DAY_09
23. FIXED_DAY_10
24. FIXED_DAY_11
25. FIXED_DAY_12
26. FIXED_DAY_13
27. FIXED_DAY_14
28. FIXED_DAY_15
29. FIXED_DAY_16
30. FIXED_DAY_17
31. FIXED_DAY_18
32. FIXED_DAY_19
33. FIXED_DAY_20
34. FIXED_DAY_21
35. FIXED_DAY_22
36. FIXED_DAY_23
37. FIXED_DAY_24
38. FIXED_DAY_25
39. FIXED_DAY_26
40. FIXED_DAY_27
41. FIXED_DAY_28
42. FIXED_DAY_29
43. FIXED_DAY_30
44. FIXED_DAY_31
45. FILLER

A new database table called ‘GAZ_YODEL_FEATURE’ will be created to store the information uploaded for the ‘GAZ_YODEL_FEATURE’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTER_ID
• FEATURE_ID

Handling

A new import type of ‘GAZ_YODEL_HANDLING’ will be introduced for the ‘Import Maintenance’ screen.

The fields in the files to be uploaded will be of fixed length.

The file contains the following fixed-length items:

This record type will have the following field types available for selection:

1. FEATURE_ID
2. FEATURE_DESC
3. HANDLING_TEXT
4. CF_CODE
5. CB_REQ

For example:

A new database table called ‘GAZ_YODEL_HANDLING’ will be created to store the information uploaded for the ‘GAZ_YODEL_HANDLING’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTEER_ID
• FEATURE_ID

Country

A new import type of ‘GAZ_YODEL_COUNTRY’ will be introduced for the ‘Import Maintenance’ screen.

The fields in the files to be uploaded will be of fixed length.

The file contains the following fixed-length items:

This record type will have the following field types available for selection:

1. COUNTRY_ID
2. COUNTRY_CODE
3. INVALID_FEATURES
4. NO_TIME_CODE
5. NO_TIME_CODE_TEXT
6. 0900_TIME_CODE
7. 0900_TIME_CODE_TEXT
8. 1000_TIME_CODE
9. 1000_TIME_CODE_TEXT
10. 1200_TIME_CODE
11. 1200_TIME_CODE_TEXT
12. 1700_TIME_CODE
13. 1700_TIME_CODE_TEXT
14. 2100_TIME_CODE
15. 2100_TIME_CODE_TEXT
16. TIME_CODE_6
17. TIME_CODE_6_TEXT
18. TIME_CODE_7
19. TIME_CODE_7_TEXT
20. TIME_CODE_8
21. TIME_CODE_8_TEXT
22. TIME_CODE_9
23. TIME_CODE_9_TEXT
24. PRODUCT_01
25. PRODUCT_02
26. PRODUCT_03
27. PRODUCT_04
28. PRODUCT_05
29. ...
30. PRODUCT_99
31. FILLER

A new database table called ‘GAZ_YODEL_COUNTRY’ will be created to store the information uploaded for the ‘GAZ_YODEL_COUNTRY’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTEER_ID
• COUNTRY_ID

CONFRDES

A new import type of ‘GAZ_YODEL_CONFRDES’ will be introduced for the ‘Import Maintenance’ screen.

The fields in the files to be uploaded will be of fixed length.

The file contains the following fixed-length items:

This record type will have the following field types available for selection:

1. FREIGHT_CODE
2. FREIGHT_DESC

For example:

PAPALLETS

PCPARCELS

CACARTONS

ROROLLS

BOBOXES

DRDRUMS

CRCRATES

SBSACKS/BAGS

MBMAIL/DOCUMENT BAG

RECABLE REELS

CSCASES

JBJIFFY BAGS

ENENVELOPES

STSTILLAGE

BABALES

OTOTHER FREIGHT

A new database table called ‘GAZ_YODEL_FREIGHT’ will be created to store the information uploaded for the ‘GAZ_YODEL_CONFRDES’ record type:

A unique primary key constraint will be created for the following columns:

• GAZETTEER_ID
• FREIGHT_CODE

Imports - DHL ESD

A new import type of ‘GAZ_DHL_ESD’ will be introduced for the ‘Import Maintenance’ screen.

The fields in the files to be uploaded will be delimited using a pipe (i.e. ‘|’).

The file contains the following delimited items:

This record type will have the following field types available for selection:

1. COUNTRY_CODE
2. COUNTRY_NAME
3. TOWN
4. BLANK1
5. BLANK2
6. SORTATION_HUB
7. FROM_POSTCODE
8. TO_POSTCODE

For example:

GB|UNITED KINGDOM|||BARKING|LCY|IG11|IG11|

GB|UNITED KINGDOM|||BARKING GT LON|LCY|IG11|IG11|

GB|UNITED KINGDOM|||BARKINGSIDE|LGW|IG6|IG6|

GB|UNITED KINGDOM|||BUCKHURST HILL|LGW|IG9|IG9|

GB|UNITED KINGDOM|||CHIGWELL|LGW|IG7|IG7|

GB|UNITED KINGDOM|||CHIGWELL ROW|LGW|IG7|IG7|

GB|UNITED KINGDOM|||CLAYHALL|LGW|IG5|IG5|

GB|UNITED KINGDOM|||CREEKMOUTH|LCY|IG11|IG11|

GB|UNITED KINGDOM|||DEBDEN ESSEX|LGW|IG10|IG10|

GB|UNITED KINGDOM|||GRANGE HILL|LGW|IG7|IG7

GB|UNITED KINGDOM|||HAINAULT|LGW|IG6|IG6|

GB|UNITED KINGDOM|||HIGH BEACH|LGW|IG10|IG10|

GB|UNITED KINGDOM|||ILFORD|LCY|IG1|IG1|

GB|UNITED KINGDOM|||ILFORD|LCY|IG2|IG2|

GB|UNITED KINGDOM|||ILFORD|LCY|IG3|IG3|

GB|UNITED KINGDOM|||ILFORD|LGW|IG4|IG4|

GB|UNITED KINGDOM|||ILFORD|LGW|IG6|IG6|

GB|UNITED KINGDOM|||ILFORD GT LON|LCY|IG1|IG1|

GB|UNITED KINGDOM|||LOUGHTON|LGW|IG10|IG10|

GB|UNITED KINGDOM|||LOUGHTON ESSEX|LGW|IG10|IG10|

GB|UNITED KINGDOM|||SEVEN KINGS|LCY|IG3|IG3|

GB|UNITED KINGDOM|||WOODFORD BRIDGE|LGW|IG8|IG8|

GB|UNITED KINGDOM|||WOODFORD GREEN|LGW|IG8|IG8|

GB|UNITED KINGDOM|||WOODFORD GT LON|LGW|IG8|IG8|

GB|UNITED KINGDOM|||WOODFORD WELLS|LGW|IG8|IG8|

Imports - Movianto

A new import type of ‘GAZ_MOVIANTO’ will be introduced for the ‘Import Maintenance’ screen.

The fields in the files to be uploaded will be delimited using a pipe (i.e. ‘|’).

The file contains the following fixed-length items:

This record type will have the following field types available for selection:

• POSTCODE
• AREA
• DEPOT
• DEPOT_LABEL
• AMBIENT_SERVICE_LEVEL
• CHILL_SERVICE_LEVEL

For example:

HU|HULL|YORK|YO|2409|2409CC

HX|HALIFAX|YORK|YO|2409|2409CC

HX5|HALIFAX|YORK|YO|241030|241030CC

HX6|HALIFAX|YORK|YO|241030|241030CC

HX7|HALIFAX|YORK|YO|241030|241030CC

IG|ILFORD|CAMBRIDGE|CB|2409|2409CC

Imports - Polarspeed

A new import type of ‘GAZ_POLARSPEED’ will be introduced for the ‘Import Maintenance’ screen.

The fields in the files to be uploaded will be delimited using a pipe (i.e. ‘|’).

The file contains the following fixed-length items:

This record type will have the following field types available for selection:

• POSTCODE
• DEPOT
• ROUTE_NO
• DROP_SEQ
• DIRECTION
• EARLIEST_DEL_TIME
• SUNDAY
• MONDAY
• TUESDAY
• WEDNESDAY
• THURSDAY
• FRIDAY
• SATURDAY

For example:

IG1|LON|780|23|S|0900|N|Y|Y|Y|Y|Y|N

IG2|LON|780|24|S|0900|N|Y|Y|Y|Y|Y|N

IG3|LBZ|700|16|S|0900|N|Y|Y|Y|Y|Y|N

IG5 0EB|LON|780|1|S|0700|N|Y|Y|Y|Y|Y|N

IM|DHL|2|1|S|0830|N|N|N|N|N|N|N

Triggers

Database triggers will exist for each parcel carrier gazetteer table to populate the created date and user when inserting a record and the updated date and user when changing a record.

Maintenance

The information uploaded for the ‘Yodel’ carrier gazetteer will not be visible in C-TMS because there is not a single record to maintain due to the upload of several files to form the gazetteer.

There will be a new tab page called ‘Carrier Routing’ in the ‘Resource Maintenance’ screen: this new tab page will contain a single table for all of the carriers (except Yodel).

The different versions of the gazetteer/routing codes can be activated separately.

Electronic Parcel Carrier Manifests

Format

The ‘TripOrder’ XML format will be used and it will include all available items required for the different formats.

The electronic parcel carrier manifests will be generated when the trip is updated to status ‘EN-ROUTE’ and all manifests will be produced in the same ‘{CARRIER_ID}_{TRIP_ID}_EN_ROUTE_{SEQ}.XML’ filename format.

N.B. The XML file will only be generated if it contains a delivery and is not solely for trunking between depots.

A database sequence number will be created for the electronic carrier manifests and will be a count of the files produced.

The sequence number will be 5 digits and will restart when the range is full.

The actual parcel carrier manifest will be produced by DHL Link from the XML file sent from C-TMS.

Trigger

The electronic and physical parcel carrier manifests will be produced by a database trigger when the status of the trip is updated to ‘EN-ROUTE’.

The same trigger will be used to print the physical manifests to the user’s default printer and produce the despatch confirmation message.

The order of processing will be:

1. Physical Manifest
2. Electronic Manifest
3. Despatch Confirmation Message

The ‘TIU_TRIP_STATUS’ database trigger will be changed to perform the new functionality.

Production

The XML file will be produced via a database job using a new procedure ‘INT_XML_OUT2.PROCESS_XML_MANIFEST’.

The physical manifests will be produced using a new procedure ‘DP_REPORTS.P_RUN_MANIFEST_REPORT’.

Transmission

The electronic parcel carrier manifests will be sent to DHL Link via FTP.

The directory structure and login details for DHL Link will be maintained in the new system parameters specifically for the electronic manifest.

For example:

• CTMS_MANF_FTP_DESTINATION_DIRECTORY
• CTMS_MANF_FTP_DESTINATION_IP_ADDRESS
• CTMS_MANF_FTP_DESTINATION_PASSWORD
• CTMS_MANF_FTP_DESTINATION_USERNAME
• CTMS_MANF_FTP_DESTINATION_PORT

Parcel Carrier Manifests

Each of the parcel carriers will have their own format of the manifest and a new report will be developed in each format.

N.B. The physical parcel carrier manifests will be produced when the status of the trip is updated to ‘EN-ROUTE’ with the reports sent to the user’s default printer setup in C-TMS for the process.

The ‘Reports’ screen can also be used to produce the manifests to the appropriate output device as selected by the user:

The manifests are expected to be produced for the parcel carriers in the following formats:

• DHL Express
• Yodel
• Movianto
• Standard1
• Standard2

The same parameters will be used for each of the manifests:

• Start Date
• End Date
• Trip ID (optional)
• Carrier ID (optional)

The ‘Start Date’ and the ‘End Date’ will be validated to ensure that they exist and that the ‘Start Date’ is not later than the ‘End Date’ of the range.

The manifests will require the following names to be created:

Each report will be created as an Oracle ‘PDF’ report.

Carrier Manifest (DHL Express)

An example of the physical manifest format is below:

A new page will be started for each different account number with associated header and detail information.

The footing information should be displayed on the final page only for the account number (which may be per combination of trip carrier/order customer/trip despatching depot).

Only the shipment number will be displayed on the manifest if both DU and Shipment tracking ranges are used for the packages.

The physical manifest will contain the following information, for example:

Items 11-44 are repeated for each of the shipments on the trip.

• ‘Shipper Name’ is the name of the carrier of the trip.
• ‘Ship Date’ is the despatching date of the trip from the depot.
• ‘Airbill Number’ is the tracking number of the shipment (or unconsolidated transport order).
• ‘Shipper Reference’ is the unique shipment ID generated for the shipment (or unconsolidated transport order).
• ‘Dest IATA’ is the sortation hub for the delivery location.
• ‘Prod Type’ is the service level code mapped for the carrier.
• ‘AWB Pieces’, ‘Airbill Weight’ and ‘Airbill Dim Wgt’ are for the shipment (or unconsolidated transport order).
• ‘Airbill Dim Wgt’ is calculated from the volumetric factor information stored in the ‘Carrier Maintenance’ screen.
• ‘Airbill Contents’ is the description of the product type.
• ‘Warehouse Reference’ is the customer reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Customer Reference’ is the delivery point reference of the unconsolidated transport order or a transport order in the shipment.

Carrier Manifest (Yodel)

An example of the physical manifest format is below:

A new page header will be started for each combination of account number, contract number and schedule number and the totals to be listed at the end of each section will be by contract.

There will be a breakdown by carrier service code per contract.

The footing information should be displayed on the final page only for the trip.

The physical manifest will contain the following information, for example:

Items 25-35 are repeated for each shipment on the trip.

The count stored for ‘Shpts’ is the number of shipments used for the range of despatch unit tracking references listed.

Items 36-38 and 44-50 are repeated for each of the service/product & feature combinations on the trip.

• ‘Collection Date’ is the planned arrival time at the despatching depot of the trip.
• ‘Sender’ is the address of the despatching depot of the trip.
• ‘Service / Product & Feature’ is obtained from the gazetteer.
• ‘Lowest LP’ and ‘Highest LP’ are the tracking references for the despatch units.

N.B. A shipment may consist of a single transport order.

N.B. The service level may be different depending on the delivery point of the shipments; therefore, different service levels may exist on the same trip.

Carrier Manifest (Movianto)

An example of the physical manifest format is below:

The physical manifest will contain the following information, for example:

Items 21-43 are repeated for each of the shipments on the trip.

Items 35-43 are repeated for each of the despatch units in the shipment on the trip.

• ‘Start Time’ is the planned arrival time of the first stop of the trip.
• ‘End Time’ is the planned departure time of the last stop of the trip.
• ‘Start Location’ is the address of the despatching depot of the trip.
• ‘Consignee’ is the destination location of the shipment.
• ‘WMS Ref’ is the customer reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Cust Ref’ is the delivery point reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Con No’ is the tracking reference of the shipment (or unconsolidated transport order).

N.B. ‘Totals by TU Category’ will be renamed ‘Totals by DU Category’ and it will be the new DU category.

N.B. The DU type subtotals will be displayed in black and not red as in the example.

Carrier Manifest (Standard1)

Examples of the physical manifest format are below:

The physical manifest will contain the following information, for example:

Items 21-41 are repeated for each of the shipments on the trip.

Items 35-41 are repeated for each of the despatch units in the shipment on the trip.

• ‘Start Time’ is the planned arrival time of the first stop of the trip.
• ‘End Time’ is the planned departure time of the last stop of the trip.
• ‘Start Location’ is the address of the despatching depot of the trip.
• ‘Consignee’ is the destination location of the shipment.
• ‘WMS Ref’ is the customer reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Cust Ref’ is the delivery point reference of the unconsolidated transport order or a transport order in the shipment.

N.B. A shipment may consist of a single transport order.

N.B. the ‘Own Fleet’ and ‘Vaccines’ formats can include ‘WMS Ref’ as specified for the ‘Standard2’ (‘Polarspeed’) format.

Carrier Manifest (Standard2)

An example of the physical manifest format is below:

The physical manifest will contain the following information, for example:

Items 19-42 are repeated for each of the shipments on the trip.

Items 32-40 are repeated for each of the despatch units in the shipment on the trip.

• ‘Start Time’ is the planned arrival time of the first stop of the trip.
• ‘End Time’ is the planned departure time of the last stop of the trip.
• ‘Start Location’ is the address of the despatching depot of the trip.
• ‘Consignee’ is the destination location of the shipment.
• ‘WMS Ref’ is the customer reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Cust Ref’ is the delivery point reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Con No’ is the tracking reference of the shipment (or unconsolidated transport order).

N.B. A shipment may consist of a single transport order.

N.B. ‘Totals by TU Category’ will be renamed ‘Totals by DU Category’ and it will be the new DU category.

Interface Errors

A new tab page called ‘Carrier Manifests’ will be added to the ‘Interface Errors’ screen.

The new tab page will be setup as follows:

Access to the new tab page will be controlled by user groups:

The new tab page will display an audit trail of the electronic parcel carrier manifests sent successfully or unsuccessfully to DHL Link for transfer to the carrier assigned to the trip for the shipments.

The proposed layout of the new tab page is shown below:

• Clicking ‘Reprocess’ will re-send the ‘FAILED’ record.
• ‘Trans Date’ will be the date when the record was transferred to DHL Link.
• ‘Carrier’ will be the carrier assigned to the trips.
• ‘Trip’ will be the trip ID for which the carrier manifest was produced.
• ‘Status’ will be either PROCESSING’, ‘SUCCESS’ or ‘FAILURE’.

Parcel Label Formats

Some of the following sample labels have been produced for the following ‘From’ location:

N.B. If a route is not found for the postcode of the delivery then only the following text will be printed on the label:

‘Shipment X – Unable to Route’

A database sequence number will be created for the labels and will be a count of the labels produced per despatch unit. This will be the ‘LPN’ (‘Label Print Number’).

The sequence number will have a maximum value of ‘9999999999999999999999999’.

N.B. A label will be produced per despatch unit of the shipment, or unconsolidated transport order, and the shipment label will be produced after the last despatch unit label for the order in the shipment has been printed.

Shipment Label

The shipment label will be produced should the combination of carrier/customer/location generate a shipment tracking number as described in section 3.7.1.

N.B. The labels will be printed for each despatch unit in the shipment, or unconsolidated transport order, and then for the shipment itself.

The shipment label will have the same format as the despatch-unit label described in the subsequent sections, except that the label count will always be 1 (e.g. ‘1/1’ or ‘1 of 1’) and any information pertaining to the transport orders contained in the shipment will be obtained from a transport order contained in the shipment (e.g. the special instructions and customer/WMS reference).

The quantities displayed will be for the despatch units of the shipment and not for the individual transport orders that constitute the shipment. The despatch units and their quantities will be advised in the ‘CIPD’ message by the packer of the shipment.

N.B. Prior to the commencement of Project Prospero a shipment will not be generated because the transport orders will not be consolidated into shipments for delivery.

It will be possible for the ‘Shipment Tracking Ref’ to be setup although a shipment label will only be printed should the criteria described above be satisfied.

Yodel

The example label above is based on the Arial font. The following values specify minimum font sizes. However, the maximum height per block has to be considered. Furthermore, the font size for the consignee address must be bigger than the font size for the sender address. For each address, the postcode and town font size must not be smaller than the size of the biggest font used in the respective address.

N.B. ‘Font height in mm’ and ‘Size in dots at 200 dpi’ are rounded values and for information purpose only. They have been added to make programming easier

The illustrations below are the domestic services as they should appear on the label. The text for these services has been taken from the domestic service table. The wording of each service must match exactly as with the values in the service table.

Shipment Information:

A Shipment is an administrative concept that is used to designate one or more items, defined by the carrier, that are to be transported at the same time, with the same service from the same location to the same delivery address.

The shipment is identified by a unique “shipment number”, assigned by the carrier.

This part of the label contains the following information:

• Shipment Number. For the select services this will be the select consignment number. No dummy replacements with incorrect information are allowed. For other movements if this information cannot be specified correctly for consolidated shipments, it must be left out.

• Consignee Reference. This is likely to be a key to the receiver’s database, and can be used by the receiver to reference and track items on the web. The Consignee reference is optional and for the receivers internal purposes only.

• Senders’ Reference. This is likely to be a key to the sender’s database, and can be used by the sender to reference and track items on the web. The sender’s reference is optional and for the sender’s internal purposes only.

• Shipment Date. The despatch date of the shipment / item, represented in ISO format (CCYY‐MM‐DD). This field is not mandatory.

• Relative Item Number of the item within a shipment and the total number of items in the shipment. If this information cannot be specified correctly for consolidated shipments, it must be left out. No dummy replacements with incorrect information are allowed.

Licence Plate Numbering:

Must begin with a combination of characters, the issuing agency code (IAC), which is assigned by the Registration Authority to the issuing agency. The EAN organisation issues a Licence plate (called the Serial Shipping Container Code, SSCC), with numeric Issuing Agency code. Other issuing agency codes usually contain letters, “JD00” for Licence Plates issued through the DP EE partnership

• Must be constructed according to the specification of the issuing agency
• Must be unique so that no user can re‐use a number within a sufficiently long time period so that the first number has a unique meaning for every user of this standard. We have decided to set this period to 12 months; recommended for a longer time e.g. 3 years
• May only contain numbers or upper case letters (no lower case letters or other characters). This means only the characters “0” ‐ “9” and “A” ‐ “Z” are allowed; drawn from ISO/IEC 646
• Customers own Licence Plates may not contain more than 35 characters. Because no extra information other than the unique number is expected in the barcode, in practice the barcode will not likely contain more than 20 characters.

The CAS Link system must assign a unique Licence plate to every item:

Customers building CAS Link systems are issued a series of Licence Plate numbers that are part of the range controlled by the DP EE partnership. The numbers allocated, when used according to this specification, comply with the rules of the issuing agency. The Licence Plates are constructed and coded according to the “ISO Licence plate ANSI Code list” though organisations creating valid Licence Plates using the EAN Code list will not be expected to convert to this standard.

ANSI Code List Elements:

The ANSI code list starts with a data identifier to show that it concerns a Licence plate code, followed by the IAC code and the sequence number. The sequence number contains a reference number (supplied by the issuing agency) followed by a sequence number, generated by the client. In this way uniqueness can be guaranteed, whilst allowing the CAS to generate numbers within a number range.

N.B. The ANSI data identifier is NOT part of the Licence Plate! It does not have to be considered when determining the length of the Licence Plate.

Plausibility Checks:

The following plausibility checks will be applied to the item identification barcode (this means, we will not accept Licence Plates that do not meet the following requirements):

• On any item, there is to be only one Licence plate
• The Licence plate may not be identical to a Licence plate that has already been processed within one year.
• The Licence plate must be the last barcode present on the label. On landscape type labels the positioning must be bottom right of the label.

ANSI Code List:

Any linear barcode using barcode symbology CODE 128 or Code 39 and starting with the ANSI Data Identifier J, 1J, 2J, 3J, 4J, 5J or 6J will be considered the (ANSI) Licence Plate of the item. The identifier is printed in parenthesis in the eye‐readable representation of the Licence plate. We will apply the following plausibility checks:

• The Licence plate must not contain more than 35 characters
• The Licence plate may only contain numeric and upper case alphabetic characters drawn from ISO/IEC 646 ‐ they must not include any lower case character or punctuation mark.
• The Licence plate must start with a string of characters representing an issuing agency assigned by ISO. See the table below for the current issuing agency codes (IAC).

EAN Code List for Licence Plates:

Any linear barcode using barcode type EAN128 and starting with the special character FNC1 and EAN Application Identifier “JD” will be considered the (EAN) Licence Plate of the item. In this case we will apply the following plausibility checks:

• The Licence plate must contain 16 characters (not counting the “JD” application identifier).
• The Licence plate shall only contain numeric characters excluding 2 digit IAC identifier

Licence Plate Barcode:

In order to ensure that Item Number and Licence Plate identifiers are unique we will issue ranges of numbers to be used in generating these identifiers. The CAS Link system must not create numbers outside these ranges nor may it create duplicate numbers inside a reasonable time scale. When a range expires the numbers are re‐cycled but there must be NO repetition of Licence Plate identifier within one calendar year.

Customers upgrading existing systems must create a method to create and record Licence Plate numbers and make sure the same Licence Plate number is not repeated within 12 months.

Shipment reference numbers or Consignment numbers should also be kept unique ensuring the shipment or consignment can be effectively tracked using this number. Guidance is given here and a range of numbers will be allocated for the Select consignment numbers.

For CAS Link installations the Licence Plates will always be an 18‐character code with a layout as shown below:

(J) F IAC KKK A B C d e 1 2 3 4 5 6

The leading “(J)” is ignored for identification purposes but must be included in the LP barcode and the parentheses only appear in the eye‐readable representation. The first significant set of characters (F IAC KKK) (as described above) will be for example “JD00 022” (or “JD00 026” for Eire). Next an identifier of 5 digits followed by a range of 6 digits. The size of the identifier and the number of digits in the range will depend on the size of range that has to be allocated to cope with the projected parcel volumes.

When the upper limit of this range has been reached the system will have to start back at the lowest number in the range.

DHL will supply an 11 digit pool number range so the CAS system can create the 18 digit (19 digits with leading identifier) Licence Plate Barcode identifier and the 18 digit eye‐readable number (19 digits with leading identifier).

The Licence Plate Barcode identifier is made up from a static prefix of eight alphanumeric characters, for example: JJD00022 for UK followed by the pool number.

Example Licence Plate Barcode for pool number 98765000001:

JJD0002298765000001

The eye‐readable number including spacing would be:

(J)JD00 022 987 6500 0001

Licence Plates identifiers are allocated in a straight numeric sequence start at the lower limit and increment by 1 every time you generate a shipping label.

N.B. The eye‐readable Licence Plate number is prefixed with ‘(J)’ ‐ shown without the brackets in the barcode, the spacing required for the eye readable Licence Plate numbers is:

(J)JD00 022 123 1234 1234

The qualifier J in brackets followed by the first 4 characters JD00, then a space, then the country code 022 (or 026 if shipped from Ireland), then a space, followed by the next three characters, then a space, followed by the remaining eight characters in two groups of four.

The Yodel parcel label will contain the following information:

Boxes will also be printed as shown in the example above.

• The ‘To’ address in rows 13-21 refers to the delivery address of the shipment.
• The ‘From’ and ’Return’ addresses in rows 3-10 and 61-65 refers to the from location of the shipment.
• The count refers to the number of despatch units in the shipment.
• ‘EXPRESS’ is the product service type of the carrier from the gazetteer.
• ‘Handling’ will be the handling/feature text from the gazetteer.
• ‘Shipment No’ and ‘Shipment ID’ will be the shipment ID generated for the OMS reference of the shipment for the transport order if it has been consolidated into a shipment, otherwise it will be for the OMS reference of the transport order.
• ‘Consignee Ref’ will be the delivery point reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Sender Ref’ and ‘OUR’ will be the customer reference of the unconsolidated transport order or a transport order in the shipment
• ‘W COVENTRY’ is the name of the service centre of the delivery location.
• ‘HAMS HALL’ is the name of the sortation hub of the delivery location.
• ‘BARCODE1’ will be the routing barcode based on the service information in the gazetteer.
• ‘BARCODE2’ will be the licence plate barcode.
• ‘BARCODE3’ will be the carrier barcode.
• Text ‘CIM/DHL CAS 1.0 cbmc.co.uk’ will be replaced by ‘Calidus TMS by http://www.obs-logistics.com’.
• ‘WMS Ref’ will be the customer reference.
• ‘LPN’ will be obtained from the licence plate number set for ‘BARCODE3’.
• ‘OUR’ will be the customer reference.
• ‘Return Address’ will be the same as the despatching depot.

N.B. If a despatch-unit label is printed for a shipment then the despatch-unit quantities of the shipment will be used to decide how many labels will be printed. The ‘Consignee Ref’, ‘Sender Ref’, ‘WMS Ref’ and ‘OUR’ references will be blank because they pertain to the transport order. The shipment reference will then be the OMS reference of the shipment.

If it is printed for a transport order then the despatch-unit quantities of the transport order will be used to decide how many labels will be printed. The references for the transport order can then be displayed. The shipment reference will then be the OMS reference of the transport order.

DHL EXpress

The DHL TD parcel label will contain the following information:

Boxes will also be printed as shown in the example above.

• The ‘To’ address in rows 19-26 refers to the delivery address of the shipment.
• The ‘From’ address in rows 6-11 refers to the from location of the shipment.
• The counts refer to the number of despatch units in the shipment, or unconsolidated transport order.
• ‘ORIGIN’ is the collecting depot code for the ‘From’ address as maintained in the ‘Locations’ maintenance screen.
• ‘Sender’s Ref’ is the customer reference of the unconsolidated transport order or a transport order in the shipment
• The ‘Handling’ code may be calculated from the label specification and included in the block in inverse video.
• ‘OXF’ is the sortation hub for the delivery location of the order.
• ‘AIRWAYBILL’ is the tracking reference number for the despatch-unit level.
• ‘Service’ is the customs duty for exports (i.e. ‘DDU’ for ‘Delivered Duty Unpaid’).
• ‘Weight’ is the shipment weight (or the unconsolidated transport order weight).
• Text ‘CIM/DHL CAS 1.0 cbmc.co.uk’ will be replaced by ‘Calidus TMS by http://www.obs-logistics.com’.

N.B. If a despatch-unit label is printed for a shipment then the despatch-unit quantities of the shipment will be used to decide how many labels will be printed. The ‘Sender’s Ref’ reference will be blank because it pertains to the transport order. The shipment reference will then be the OMS reference of the shipment.

If it is printed for a transport order then the despatch-unit quantities of the transport order will be used to decide how many labels will be printed. The reference for the transport order can then be displayed. The shipment reference will then be the OMS reference of the transport order.

Movianto

The label is produced using barcode39 fonts and has the following format:

‘CCCC-XXXXXX-NNN-YYY’

For a ‘Glaxo’ (GSK) consignment this could read as follows:

GLAS-123456-001-PAL GLAS-123456-002-CTN (This would be a Scheduled order with both a Carton and a Pallet on it)

GLAU-123457-001-CTN GLAU-123457-002-CTN (This would be an Urgent order with 2 Cartons on it)

GLAV-123458-001-CTN (This would be a Vaccine order with 1 Carton on it)

N.B. The same format will be used for the ‘Vaccine’, ‘Urgent’ and ‘Scheduled’ examples from the ‘Cherwell’ depot except that the ‘Vaccine’ will have a ‘NORTH’ or ‘SOUTH’ indicator. An example of the ‘Vaccine’ label is shown in the subsequent sections.

N.B. The following ‘Movianto Spec’ example is the standard Movianto format and it will be used for deliveries not originating in the ‘Cherwell’ depot. These new formats will be used and the ‘Vaccine Example’ will follow these formats in the future.

N.B. If the service level is not found then it will print ‘Service Level Not Supported’ in the place of the service level.

Technical Examples

Vaccine Example

The Movianto parcel label will contain the following information:

Boxes will also be printed as shown in the example above.

• ‘CTN’ is the despatch unit type.
• The ‘To’ address in rows 4-8 refers to the delivery address of the shipment.
• The ‘Return’ address in rows 31-37 refers to the from location of the shipment.
• The counts refer to the number of despatch units in the shipment (or transport order).
• The barcode includes the shipment tracking reference displayed beneath.
• ‘00019837’ is the tracking number of the despatch unit.
• ‘1403351’ will be the shipment ID genertated for the OMS reference of the shipment for the transport order if it has been consolidated into a shipment, otherwise it will be for the OMS reference of the transport order.
• ‘Primary Sender Ref’ is the customer reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Primary Del Point Ref’ is the delivery point reference of the unconsolidated transport order or a transport order in the shipment.
• ‘Weight’ is the shipment weight (or the unconsolidated transport order weight).
• The ‘BLOCK’ will contain text to indicate chilled items (e.g. ‘CHILLCARE 2-8o’ for vaccines).
• ‘Sender’ and ‘Return Address’ are the from location of the shipment.
• Text ‘HCL v1.2a by cbmc.co.uk’ will be replaced by ‘Calidus TMS by http://www.obs-logistics.com’.

N.B. The new Movianto format includes ‘SCAN’ in the ‘Return Address’ section; the direction only is only displayed for ‘Vaccine’ orders; the tracking reference has a new format.

N.B. If a despatch-unit label is printed for a shipment then the despatch-unit quantities of the shipment will be used to decide how many labels will be printed. The ‘Primary Sender Ref’ and ‘Primary Del Point Ref’ references will be blank because they pertain to the transport order. The shipment reference will then be the OMS reference of the shipment.

If it is printed for a transport order then the despatch-unit quantities of the transport order will be used to decide how many labels will be printed. The references for the transport order can then be displayed. The shipment reference will then be the OMS reference of the transport order.

Parcelforce

N.B. Parcelforce labels will only be produced in the domestic-label format.

Service Code

If a consignment is due to be delivered on a Saturday, then the word “SATURDAY” needs to be printed on the label, as shown in the example below. All other aspects of the label for deliveries on Saturday are identical to the standard domestic label:

The service code will contain the label content service indicator for the corresponding Parcelforce service that the consignment is being shipped on, as shown in the following table:

Despatch Date

The despatch date will be the date on which Parcelforce will COLLECT the consignment for delivery.

Postcode Barcode

The postcode barcode (i.e. ‘BARCODE1’) should contain only the outward portion of the postcode. The postcode barcode value should be delimited by an asterisk on either side:

Consignment Barcode

The format of the consignment barcode (i.e. ‘BARCODE2’ and ‘BARCODE3’) content is:

• ‘PB’ Prefix
• Consignment Number (2 alpha, 7 digit)
• Parcel Number; 001, 002, 003, etc.

The Parcelforce label will contain the following information:

Boxes will also be printed as shown in the example above.

• The tracking reference is for the despatch unit.
• The ‘To’ address in rows 6-11 and 17-20 refers to the delivery address of the shipment (or transport order).
• The ‘From’ address in rows 25-29 refers to the from location of the shipment.
• The count refers to the number of despatch units in the shipment (or unconsolidated transport order).
• The barcodes will be in ‘Code 128’ format.
• ‘BARCODE1’ will use the postcode prefix.
• The ‘Saturday’ indicator will be printed for deliveries made on a Saturday only.
• ‘LPN’ is the licence plate number.
• ‘Sender’s Ref’ is the customer reference of the unconsolidated transport order or a transport order in the shipment
• Text will be ‘Printed: {SYSTIME} by Calidus TMS by http://www.obs-logistics.com’.

N.B. If a despatch-unit label is printed for a shipment then the despatch-unit quantities of the shipment will be used to decide how many labels will be printed. The ‘Sender’s Ref’ reference will be blank because it pertains to the transport order. The shipment reference will then be the OMS reference of the shipment.

If it is printed for a transport order then the despatch-unit quantities of the transport order will be used to decide how many labels will be printed. The reference for the transport order can then be displayed. The shipment reference will then be the OMS reference of the transport order.

Standard1

N.B. This label will be rotated 90 degrees clockwise when printed (i.e. the layout will be ‘Landscape’ and not ‘Portrait’ as for the other labels).

In this example, the sequence of the counts is shown below:

The ‘Standard1’ parcel label will contain the following information:

Boxes will also be printed as shown in the example above.

• ‘Shipment ID’ will be the shipment ID generated for the OMS reference of the shipment for the transport order if it has been consolidated into a shipment, otherwise it will be for the OMS reference of the transport order.
• ‘Route’ is the name of the route code of the trip.
• ‘Package Number’ is the package number derived from the number of despatch units within a shipment (or transport order): e.g. 1/6 = DU 1 of 6 DUs.
• ‘Pal’ is the number of pallets in the shipment (or transport order) derived from the total number of pallets: e.g. 1/2 = pallet 1 of 2 pallets.
• ‘Par’ is the number of parcels in the shipment (or transport order) derived from the total number of parcels: e.g. 0/4 = there are a planned number of 4 parcels but this particular DU is not one of them because it is in the pallet category.
• ‘Tracking Number’ is the tracking reference for the shipment (or unconsolidated transport order).
• The ‘Ship To’ address in rows 26-32 refers to the delivery address of the shipment.
• The ‘Sender’ and ‘Return’ addresses in rows 36-41 and 50-55 refer to the from location (i.e. collection address) of the shipment (or unconsolidated transport order) (which may not be the same as the despatching location of the delivery trip).
• The ‘Despatcher’ address in rows 43-48 refers to the despatching location of the delivery trip.
• The counts refer to the number of despatch units in the shipment (or unconsoldiated transport order).
• ‘Date’ is the latest delivery date and time of the order.
• ‘BARCODE’ is based on the combination of ‘{C-TMS Trip ID}-{Temperature}-{Cust / WMS Ref}-{Label Print Number}’ to make it unique.

N.B. ‘Pal’ and ‘Par’ will be defined by the new despatch unit category which will be ‘Pallet’ or ‘Parcel’.

N.B. The label will be printed when it is packed and it will include the information for the loading trip in the depot the packing operation will be performed: if the shipment is being trunked to, and unloaded at, another depot for collection by the parcel carrier on another trip then the labels will contain the trunking trip.

The ‘Sender’ will always be the ‘From Location’ of the shipment but the ‘Despatcher’ will be either the ‘From Location’ of the shipment (if it is not trunked) or the loading location of the shipment for the delivery trip.

N.B. If a despatch-unit label is printed for a shipment then the despatch-unit quantities of the shipment will be used to decide how many labels will be printed. The ‘Cust / WMS Ref’, ‘Del Point Ref’ and ‘Booking Ref’ references and ‘Special Instructions’ will be obtained from the first transport order in the shipment.

If it is printed for an unconsolidated transport order then the despatch-unit quantities of the transport order will be used to decide how many labels will be printed. The references and special instructions for the transport order can then be displayed.

Polarspeed

WMS (Unison) Ref / WMS Ref

Will show the Unison sales order number only on transport orders received via EDI in the customer reference.

Customer Ref / OUR

Will show the customer reference.

Consignee Ref

Will show the delivery point reference.

The Polarspeed parcel label will contain the following information

Boxes will also be printed as shown in the example above.

• The ‘To’ address in rows 20-27 refers to the delivery address of the shipment (or unconsolidated transport order).
• The ‘From’ and ‘Return’ addresses in rows 9-15 and 76-82 refer to the from location of the shipment.
• The count refers to the number of despatch units in the shipment (or unconsolidated transport order).
• ‘Consignment No’ is the shipment tracking reference and will be prefixed with ‘TMS’ instead of ‘CIM’.
• ‘Tracking No’ is the despatch unit tracking reference and will be prefixed with ‘DHL’.
• ‘BARCODE1’ is the despatch unit tracking reference.
• ‘Ship Date’ will be the despatch date of the trip.
• ‘Deliver Before’ will be the late delivery time of the shipment (or transport order).
• ‘BARCODE2’ is the carrier and country reference.
• ‘LPN’ is the ‘Label Printing Number’ from the database sequence number.
• Text ‘PointSpeed $ Revision: 1.0 $ by cbmc.co.uk’ will be replaced by ‘Calidus TMS by http://www.obs-logistics.com’.

N.B. If a despatch-unit label is printed for a shipment then the despatch-unit quantities of the shipment will be used to decide how many labels will be printed. The ‘WMS (Unison) Ref’, ‘Customer Ref’, ‘Consignee Ref’, ‘WMS Ref’ and ‘OUR’ references will be obtained from the first transport order in the shipment.

If it is printed for an unconsolidated transport order then the despatch-unit quantities of the transport order will be used to decide how many labels will be printed. The references for the transport order can then be displayed.

Parcel Label Trigger=

The carrier labels will be produced upon receipt of the ‘Pack Confirmation’ message from the WMS or manually by the user via a ‘Pack Confirm’ button in the ‘Orders’ screen in C-TMS.

The carrier labels may also be re-printed manually via a button in the new ‘Shipment Order Management’ form or via a button in the ’Orders’ form.

There will be the ability to re-print labels by order or shipment and once selected a range, or a specific label number, can be requested. For example, if there are 11 orders for a shipment a user should be able to re-print all 11 labels, or labels 3/6 or labels 1, 7 and 11. It is accepted that the ‘Label Print Number’ will be out of sequence for re-prints.

N.B. The ‘Reprint Label’ option will be available if the new ‘ORD_REPRINT_PACK_VISIBLE’ system parameter is set to ‘Y’.

Order Details

The ‘Pack Confirm’ and ‘Reprint Label’ buttons will be displayed if the new ‘ORD_REPRINT_PACK_VISIBLE’ system parameter is set to ‘Y’.

The ‘Order Detail’ screen will be changed to enable the user to print labels for the individual orders in the shipment.

This will be performed via a new ‘Reprint Label’ button:

New ‘Carrier’ and ‘Shipment ID’ fields will be added to the ‘Detail’ tab page of the ‘Order Details’ screen in the ‘ORDERS’ from, the ‘Carrier’ field will store a mandated carrier/haulier for manually entered transport orders (if a transport order is uploaded via a CSV import file or EDI file then the carrier will appear in this field); the ‘Shipment ID’ field will display the shipment ID generated for the transport order/shipment.

Pack Confirmation

CIPD Message

The structure of the ‘CIPD’ file generated by Unison is shown below:

An example of a ‘CIPD’ file generated by Unison is show below:

A new directory structure will be setup in the ‘EDI Maintenance’ screen.

A new database job will be created when started without a time interval to process the files received.

The ‘IMP’ package will be changed to import the file and generate the labels as required.

N.B. The files processed will be placed in failed or processed directories as appropriate.

The ‘SCH_ORD’ database table will be changed to include the packed date and will contain the system date and time when the packed quantity was updated:

The existing ‘T_SCH_ORD_AUDIT’ database trigger will be used for this purpose.

The ‘CIPD’ output from Unison will be mapped into C-TMS. Initially orders will be packed at order level, but as part of Prospero orders will be packed at shipment level requiring a shipment label when the final order has been packed.

Upon receipt of this file into C-TMS the transport order, or the shipment, DU type and quantity will be updated as per the values contained in the file. Changes and updates to the order line will be captured in the audit log for the order.

N.B. The ‘Pack No’ and ‘Shipment No’ will be stored as order sub-references for the shipment (i.e. ‘PACK_NO’ and ‘SHIPMENT_NO’.)

The ‘Carrier Code’ and ‘Service Level’ will not be stored in C-TMS because they are stored against the trip and carrier.

The ‘Carton Type’ will be used to update the despatch unit type of the order line of the shipment.

The ‘Carton Number’ will be used to update the despatch unit quantity (as a count of the carton numbers received) for the transport order or the shipment. It will contain the carton numbers used within Unison WMS and they will be unique within the transport order or the shipment; however, the carton numbers may not be sequential. (See section 3.8.4 for their storage.)

The ‘Tracking No’ will be generated as a tracking reference within C-TMS when the label is printed for the despatch unit (i.e. carton for the CIPD).

The carton’s dimensions will not be stored in C-TMS.

The ‘Order Number’ will correspond to the customer reference of the transport order stored as ‘SCH_ORD.EXTERNAL_REF’ in C-TMS. It will be stored with the carton number in which it is contained.

The ‘Order Line Number’ will be ‘000’ by default because the ‘CD01’ record refers to what is contained in the ‘carton’ and this information will not be stored in C-TMS.

The ‘Quantity’ will be ‘00000000’ by default because the ‘CD01’ record refers to what is contained in the ‘carton’ and this information will not be stored in C-TMS.

It is expected that one ‘CD01’ record will be received per ‘CC01’ record because the contents of the carton are not relevant at present.

N.B. Pre-Prospero packing in Unison WMS will be performed by sales order reference (i.e. transport order) and not by shipment, therefore, the sales order information needs to be stored in C-TMS for the associated tracking reference for the despatch units packed in the shipment.

N.B. If a ‘CIPD’ message is re-sent then the shipment will be updated with the new data and the labels will be re-printed automatically.