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: