285937

DHL C-TMS

BAT C-TMS Paragon Integration

FUNCTIONAL SPECIFICATION - 10.6

- 1.0

Reference: FS 285937 PL-8DWKXF

Client Requirement

Assign OBS resources to participate in BAT transport improvement project between Feb 2011 and April 2011, that main objective is to deploy Paragon and integrate Paragon with C-TMS. Area of Scope for this request includes:- Project management- integration (Paragon <-> C-TMS) configuration- integration training- UAT and Post go live support (remote)- consulting services during implementation

Solution Scope and Summary

This RIO has been raised to request OBS Logistics to provide resource to support project work initiated in Feb 2011. The principle objective of the project is to implement Paragon routing and scheduling for the BAT contract and for OBS to implement a two way interface to integrate this with the Polish instance of C-TMS.

Meetings were held at the DHL Office in Warsaw on the 10^th and 11^th attended by DHL Operational and IT staff, Paragon and OBS to kick-off the project.

OBS will provide services on a T&M basis covering Project Management, Consulting Services, Integration Configuration and Training, Development of the interface where required, UAT and post go-live Support of the C-TMS and Paragon integration.

The integration between C-TMS and Paragon will be configured using the OBS software solution in use in a number of UK DHL transport contracts, and in particular the solution supporting the planning and scheduling for Baxter Healthcare.

There will be some minor development changes to include additional data into the export file used to move location and order information from C-TMS to Paragon and to remove superfluous data fields not adding any value for BAT.

The interface and planning activity using Paragon is expected to commence 1^st April.

Scope

This change will be applied to system version 10.6.0 on EURTST and once approved EURPRD.

Set-up

Pre-requisites

The Paragon Interface export and import form of C-TMS is implemented in the Poland C-TMS server environment. The required Import Template ‘Paragon Trip Detail’ is set up in the Import form.

Menu Structure

Administration / Interfaces / Paragon Interface enabled.

Data

No new data will be required to be captured in C-TMS. The definition of the CSV interface file formats is defined in Appendix A below.

Functional Description

Overview of Process & Background Information

The planning cycle for BAT is understood to be DAY-1 for DAY-2. This means orders will be received from the customer during the day from e-mails and faxes. Orders are uploaded into C-TMS from a spreadsheet file maintained by the operation. The cut-off for orders is 17:00. The route planning and scheduling starts at 17:00 and is completed a few hours later. The plan is completed in the evening of DAY-1 for DAY-2 execution.

The planning team for BAT will be centralised and a single instance of Paragon will be used to plan the contract orders for the whole country.

Planning will cover both Primary and Secondary movements and this means some integration of routes might be considered across these two transport operation movement types.

There are three BAT factories at AUG and TER and JAW from where line-hauls and deliveries will be planned. DHL will operate two x-dock / depots additionally at POZ and TOR. (short codes for place names in Poland).

DHL will manage the deliveries from these five locations to over 250 wholesalers and retailers across the country.

Primary trunks tend to take about 30 mins to turnaround and about 45 minutes at wholesaler / retailer delivery points.

Orders are already generated in C-TMS for part of the operation and planned manually. On investigation of these orders, it is apparent that the delivery time window is captured – this is really a scheduled delivery time with 1 hour added so C-TMS has a delivery time window of 1 hour.

The DU unit is measured in master cases, each of which relates to approximately 5114 sticks (or individual cigarettes). In addition, the number of pallets (EURO or INDUSTRIAL) is known and captured and this is entered as a second DU order line in C-TMS. The master case is understood to be the main measure that will be utilised in Paragon to plan effective utilisation of the vehicles.

The business has plans to use bigger vehicles and less of them to maintain the delivery schedule (which is fairly fixed and static).

Some modelling has already been done on Paragon to create a fixed schedule and verify.

The operation will on a daily basis export the BAT orders from C-TMS to Paragon. The orders will be routed and scheduled and Paragon will export routes and trips and stops and the sequence of order on the drops for C-TMS to upload. C-TMS will create a trip for every Paragon route and will allocate the orders to the trips automatically from the upload processing.

Further clarification is required to understand whether orders will be raised on C-TMS that will be planned on a line-haul and on a final (radial) delivery leg, for example an order is raised from JAW, planned on line-haul to POZ and included in a delivery trip from POZ. If orders are raised this way, the C-TMS function to automatically generate trunk trips will be utilised. This functionality in summary references master data set into the location slots that defines a schedule of daily trunk departures from one depot to another. This could be a single trunk or many trunk vehicles per day as required and dictated by volume of product being trunked. (Note – the term line-haul and trunk can be interchanged for the purpose of this narrative). In this operational scenario, Paragon plans the radial delivery trips (secondary) and C-TMS automatically generates the trunk legs (primary).

Otherwise, bulk line-haul orders will be raised in C-TMS to plan the line-haul movements and separate delivery orders will be raised in C-TMS to plan the radial delivery trips. Paragon would then plan both primary and secondary.

Maintenance

The Import template will be modified to match the paragon upload format described in Appendix A

Where C-TMS will be utilised to automatically generate trunking trips (line-haul) to satisfy secondary planning in Paragon, the Location slots data will be set-up as per the following example.

The example above shows that up to two trunk trips can be generated each evening from DHLBAXT (being the origin loading depot) to DHLTRAFF (being the receiving depot). The trailer type master data defines the maximum capacity of the vehicles.

C-TMS will be configured to manage the allocation of orders to trunk trips based on the pre-planned radial delivery rounds (secondary) uploaded from paragon and this will be constrained by maximum volume of master cases.

Assuming that the 250 wholesalers will not be set up as Cross Dock Locations rather the intention is to use the delivery depot at the cross-dock location. Therefore the following data will need to be setup in the paragon cross-dock locations maintenance as follows :-

For example an order from the AUG factory being delivered out of POZ to a wholesaler will need to be cross-docked via POZ presumably with a POZ carrier.

NB) the above assumes that there are going to be 5 carriers based at each of the 5 locations (3 factories and 2 cross-dock locations).

Export Orders

Each evening the orders for BAT will be exported based on a delivery schedule and customer code using the export screen shown below.

In addition, a new selection field (with drop-down) will be added to allow a specific depot of orders to be exported.

The export process will create a CSV format file that can be named and saved by the planner to a specific directory either on the paragon PC or a shared network drive. C-TMS takes care of the file transfer from the C-TMS server to the local filename. The file will be formatted with the data columns as described in Appendix A below.

It is anticipated that the order set will be exported each evening from C-TMS. The CSV file will be uploaded into Paragon and then Paragon will we used to optimally plan and schedule the required routes.

Note that the export file format described in Appendix A has an array of DU Type and QTY fields which means for an order both the CSV file.

The existing system registry 'PARAGON_INSTALLED' will be set to ‘BAT’ for the Poland database.

The procedure ‘Write_Orders_to_Paragon’ within the ‘CSV’ package will need changing so that if the system parameter is set to ‘BAT’ then it will run the new code.

The new code will firstly create the column headings to match the new requirements (for details see Appendix A).

It will then loop though the orders that meet the entered selection criteria (also checking the status as only ‘USCHEDULED’ orders will be selected).

For each order it will then loop through the order lines (up to 5 times) storing the DU Type and the Quantity.

It will then create a line per order based upon the retrieved data and the required format (see Appendix A for details).

Finally it will update the status of the order to ‘NEW’ so that it cannot be amended within C-TMS whilst it is being planned within Paragon.

Import Trips

Once the transport plan is finalised in Paragon, Paragon will generate a local CSV file of the routes, trips, stops, order sequence, trailer type and all the significant trip times required for C-TMS to create the respective trips inside C-TMS. The objective is to synchronise the plan data between the two systems.

The planner will use the C-TMS Paragon import form shown below to browse the local drive to find the CSV file.

The planner will define the schedule that the import relates to in C-TMS.

C-TMS then transfers the file across the DHL network to the C-TMS database server. The file is then checked to ensure that this is a new file which has not previously been processed. The content of the file is then validated. The planner then has the choice to upload the file and generate trips in C-TMS.

Once the process is complete the trips are available for view (and/or change) in C-TMS. Every trip created using this method is prefixed with PAR-. Note that a C-TMS schedule can have both MAN- (manually created trips) and PAR- trips generated from the Paragon interface.

The layout for the inbound message will have been changed in the import maintenance to match the new requirements (see Appendix A for more details) and the data extraction be taken care off automatically by the IMP package.

This package will then call the standard paragon processing procedure ‘Process_Paragon_Data’ within the ‘PAR’ package.This code will already check the system parameter 'PARAGON_INSTALLED' and if it is set to ‘BAT’ then it will need to run the new code.

As no re-spins will be allowed then the code will firstly call a pre-pass for determining the trunks required.

Technical Notes: This will either be an updated version of ‘Alloc_HCR_Trunk’ taking into account the RPE quantity rather than the weight or will be a copy of the procedure called ‘Alloc_BAT_Trunk’.

Most of the code within this procedure will be duplicated but the practicalities of adding the new code to the existing procedure without breaking the HCR code will need to be addressed by the developer.

This code will then create the necessary trunk trips based upon the paragon cross-dock tables, the slots, the cut-off time and the available remaining space (RPE quantity) on the trunk trip.

The sort sequence will be changed to be in RPE descending order rather than weight descending and keeping the orders on the same radial trips together on the same trunk trips.

It will then assign the orders to the trunk trips.

The code will then loop through all of the orders again creating the radial trips as required and assigning the orders to these trips.

It will then update the information on the trips and orders accordingly utilizing as much of the existing code as possible.

Interface Management

The Trip Export and Trip Import forms shown above display the history of file interface activity. The import process will generate a file of any errors that can be viewed on screen and saved back to the local PC. The planner has the option to load or reject a file with errors. In this circumstance, the valid records will be loaded to C-TMS and the failures separated into a failures file of the same format. The assumption is that the planner will either correct the failures file or setup additional master data in C-TMS then reload the subset of failures a second time using the same mechanism.

Example Trip

The trip manipulation form shown below is included to illustrate what a route created in paragon and uploaded to C-TMS will look like. Note the PAR- prefix to the trip.

The paragon upload function will create the trips at planned status including the trip, stops, sequencing of orders on the stops, the scheduled drive time, loading and unloading times. It is assumed that the planners will appoint carriers once the route schedule is complete and uploaded into C-TMS. This probably means that Paragon will assign a dummy carrier and this will be over-written in C-TMS by the appointed carrier once that decision is made operationally.

Note that the trips are created in C-TMS from the paragon upload in the same format as if the trips were manually planned in C-TMS. This means all C-TMS functionality to rate, execute and debrief trips can be used as standard with PAR- trips.

C-TMS – Paragon Interface Format

Export File definition (Orders)

Field	Field Name	Size and format	Paragon keyword
1	Location ID	Alphanumeric (Max 16)	CUST.ID
2	Name	Alphanumeric	CUST.NAME
3	Street address	Alphanumeric (lines of the address separated by commas)	CUST.LONGADDR
4	Town	Alphanumeric	CUST.SHORTADDR
5	Post Code	Alphanumeric	CUST.POSTCODE
6	Latitude	Numeric, positive or negative relating to north/south	CUST.LAT
7	Longitude	Numeric, positive or negative relating to east/west	CUST.LONG
8	Vehicle acceptability	Alphanumeric in a binary format, where 1 is acceptable, and 0 is unacceptable (e.g. ‘10011’). Alternatively you can use Y/N. {Each of the vehicle types needs to be mapped to a byte position on this string}	CUST.TEXT01
9	Run key	Alphanumeric	CALL.TEXT01
10	Location ID	Alphanumeric (16), same as the customer ID above	CALL.ID
11	Weight in kg	Integer	CALL.MEASURE1
12	Volume in cm3	Integer	CALL.MEASURE2
13	Depot ID	Alphanumeric (Max 16) {Means the depot to delivery from or collect into}	CALL.DEPOTID
14	Earliest delivery date and time	yyyymmdd hh:mm	CALL.TEXT02
15	Latest delivery date and time	yyyymmdd hh:mm	CALL.TEXT03
16	Variable unloading time	Integer (minutes)	CALL.USER01
17	Fixed unloading time	Integer (minutes)	CALL.USER02
18	Order type (delivery or collection)	Alphanumeric (1), D=delivery, C=collection	CALL.TYPE
19	C-TMS order reference	Numeric	CALL.USER03
20	Customer order reference number	Alphanumeric	CALL.TEXT04
21	Product type (chilled or ambient)	Alphanumeric	CALL.TEXT05
22	Delivery type, carrier type	Alphanumeric	CALL.TEXT06
23	Special instruction	Alphanumeric	CALL.TEXT08
24	Phone number	Alphanumeric	CALL.TEXT09
25	E-mail	Alphanumeric	CALL.TEXT10
26	Delivery unit type	Alphanumeric	CALL.TEXT12
27	Quantity	Numeric	CALL.USER12
28	Delivery unit type	Alphanumeric	CALL.TEXT13
29	Quantity	Numeric	CALL.USER13
30	Delivery unit type	Alphanumeric	CALL.TEXT14
31	Quantity	Numeric	CALL.USER14
32	Delivery unit type	Alphanumeric	CALL.TEXT15
33	Quantity	Numeric	CALL.USER15
34	Delivery unit type	Alphanumeric	CALL.TEXT16
35	Quantity	Numeric	CALL.USER16

Import File definition (Route Trips)

Field	Field Name	Size and format
1	Paragon route number	Numeric
2	Paragon trip number	Numeric
3	Paragon drop number	Numeric
4	Paragon trip position	Numeric
5	C-TMS order reference	Numeric
6	Customer order reference	Alphanumeric
7	Vehicle type	Alphanumeric
8	Location ID	Alphanumeric
9	Depot Code (Call.DepotName)	Alphanumeric
10	Vehicle group name (Carrier)	Alphanumeric
11	Arrival at call	yyyymmdd hh:mm
12	Departure from call	yyyymmdd hh:mm
13	Route start time	hh:mm
14	Trip start time	hh:mm
15	Departure from depot	hh:mm
16	Return time to depot	hh:mm
17	Trip end time	hh:mm
18	Route end time	hh:mm
19	Total break duration from previous call	minutes
20	Total break duration at this call	minutes
21	Total break duration until next call	minutes

References

Ref No	Document Title & ID	Version	Date
1	EST-285937 PL-8DWKXF BAT C-TMS Paragon Integration v1.0	1.0

Document History

Version	Date	Status	Reason	Initials
0.1	13/2/2011	Issue	Reviewed and Issued	DJM
0.2	14/02/2011	Draft	Review and add technical details.	DRM
1.0	24/02/11	Reviewed	Reviewed and Issued	MJC

AUTHORISED BY

Matt Crisford	Development Manager
Peter Greer	TMSCC MTS Product Manager