286735

DHL MTS

Additional Documentation

FUNCTIONAL SPECIFICATION - 10.6

- 1.0

Reference: FS 286735 DK-8EMF3R

Client Requirement

Change Request Summary:

Additional Documentation.

Change Request Details:

Trip Sheet / Delivery note (to suit Tokairo scan) - sheet per shipment, fax and e-mail.

Benefits identified as a result of the change:

Trip sheet must be scanable by the Tokairo system.

Solution

Fax & E-mail:

Hauliers (Carriers in C-TMS) will seldom come on site (i.e. to the planning offices) to be able to collect paperwork. It is, therefore, a requirement to ensure Driver Manifest sheets be made available to carriers via fax and/or e-mail.

Depending on the haulier’s preference, their preferred method of communication (i.e. fax or e-mail) and other relevant contact details to facilitate their preferred communication method will be maintained in C-TMS.

On confirmation of a load being allocated to a haulier (briefed by status change to ACCEPTED), the planner should be able to trigger a copy of the Driver Manifest be sent directly to the appointed carrier. This process should be triggered from C-TMS planning screens and executed automatically and additionally as a ‘one-click’ function for resend.

Integration into DHL provided e-mail and fax services forms part of the scope of this development.

For e-mail, it is assumed that the Driver Manifest is generated as a PDF document and sent as an e-mail attachment. A format and wording for the subject and body of the e-mail will be agreed with DHL.

DHL IT have suggested a DHL managed and maintained fax service is available called Zetafax. This service and communication to it will be investigated. To generate a fax the sending application has to create two files,

A “.SUB” file which is essentially a text file defining the subject and recipient information and the filename of the document to be faxed.

Then the image to be faxed as a “.g3f” file referred to from the “.SUB” file as shown by example above. The image file is understood to be a TIFF format file so some conversion is required in C-TMS prior to send to the fax service.

The estimate is provided into two parts to cover;

1. Development of Driver Manifest as an output from C-TMS
2. Integration of the Driver Manifest into the E-mail and Fax services provided by DHL

Scope

This change will be applied to system version 10.6

Set-up

Menu Structure

‘Unchanged’

Data

1. The Carrier will be expected to be defined within Message Maintenance and assigned a Message Type of ‘Zetafax’ with a medium of ‘Facsimile’. The Electronic Address will need to be defined with a medium of ‘Facsimile’ and the Fax number for the carrier. The Message Request will need to be set as TRIP_ACCEPT.
2. The external ftp address, username, password and upload directly for the zetafax server will be stored within new system level parameters in the ADM_SYSTEM_PARAMS table.
3. The ip address, port number, reports directory and reports server location will be stored within new system level parameters in the ADM_SYSTEM_PARAMS table.

Functional Description

Trip Level Trigger

The system will be changed so that whenever a trip is altered to status ‘Accepted’ the system will check the carrier on the trip and if it has been defined with a Message Type of ‘Zetafax’ then an event record will be written (into MSG_MESSAGE). This will be achieved by creating a new record in the ‘Message Requests’ tab within the Message Maintenance screen of type ‘TRIP_ACCEPT’.

Report Production

The standard events polling job (msg_job.p_check_event) will then pick up this message and run the ‘Driver’s Manifest’ report described in the Part 1 of the specification 286735 for this log number.

Developer Note: The production of the report will need to be performed within the MSG_PROCESSING.f_process_event process which then calls the f_get_msg_data procedure by searching for an event type of ‘Zetafax’.

For this event type, the Oracle reports server will be called directly using an http request. For this reason it will be necessary to define various new system level parameters in the ADM_SYSTEM_PARAM table containing the ip address, port number, reports directory and reports server location. In order to check if the report has been successfully produced, it will be necessary to check the utl_http.html_pieces output.

File Conversion

Once the Oracle Report pdf file has been produced, it will be necessary to convert the pdf that the system produces into a picture format compatible for the Zetafax server. This will be achieved by converting the file into ppm format first for each page of the pdf report. Each ppm will then be converted into a TIFF format file and then these TIFF files will be joined together into a single TIFF. This file will then be ftp’d onto the Zetafax server and the file extension will be altered to be G3F upon arrival if the ftp account has sufficient privileges to do so. Otherwise the file will be renamed before it is sent.

Along with the converted pdf file, a text file will be created. The file will contain the following fields:

%%MESSAGE	Hard-coded text
COVERSHEET:	Hard-coded text
DELETE: OK	Hard-coded text
FROM: DHL Openfield	Hard-coded text
USER:	User Id logged into the system
PRIORITY: NORMAL	Hard-coded text
FORMAT: TIFF-FINE	Hard-coded text
TO:	Name of the Carrier receiving the Fax
FAX:	Fax number defined in the Message Maintenance screen
ORGANISATION:	Hard-coded text
%%{FILE}	Pathname stored in ADM_SYSTEM_PARAM followed by the file name of the report, e.g. Driver_Manifest

Note that rpm installs will need to be performed for these conversion scripts on the C-MTS servers for both test and production.

Sending the Output

The converted file will be sent to the appropriate location. The external ftp address, username, password and upload directly for the Zetafax server will be stored within new system level parameters in the ADM_SYSTEM_PARAM table.

If an error occurs during the ftp process then this will become visible in the Message Monitoring screen. However if there is an error producing the Fax on the Zetafax system after the file has been sent, this error will not be visible on the C-TMS system.

References

Ref No	Document Title & ID	Version	Date
1	EST-286735 DK-8EMF3R Additional Documentation Part 2 v1.0.doc	1.0	15/04/11

Document History

Version	Date	Status	Reason	Initials
0.1	15/04/11	Draft	Initial version	RE
1.0	18/04/11	Issue	Reviewed and Issued	MJC

AUTHORISED BY

Matt Crisford	Development Manager
Peter Greer	TMSCC MTS Product Manager