292729

DHL C-TMS

Enable Communication with Smartphone

FUNCTIONAL SPECIFICATION - 10.7

03/11/11 - 1.0
Reference: 292729 BS-8MCHDK

Client Requirement

Openfield are planning to roll out Smartphone technology to all subcontractors however before a final decision is taken on the feasibility of this concept for the business, we need to pilot the concept with our own fleet and a few owner drivers (subcontractors), It is planned the pilot should commence on the 29th November to coincide with the delivery of the Phase2 development from mubaloo. To enable this we require the following:-

1. Upgrade of Industrial Openfield instance of CTMS to send the already developed smartphone message outbound at both Carrier and Driver level when a trip is set to 'ACCEPTED' from within the OPENFIELD specific 'Carrier Trip Planning' screen
2. The Inbound POD/POC message from the smartphone requires additional tags of "Gross_Weight" "Tare_Weight" "Net_Weight" and "Weighbridge_Ticket" adding into the schema and importing into CTMS
3. The Weighbridge_Ticket will need to be mapped into the same field as the Tokairo debrief Weighbridge ticket 'ADD REF 99" the "Net_Weight" will be mapped into the "Actual Weight" field, Vehicle Reg (Tractor) and Trailer Number will need to be applied and delivery and collection times all are required to be inserted into the Openfield Order Debrief screen and order status updated to 'delivered' and trip "Completed" if all orders on the trip have been delivered and all info has validated.
4. Two new field's will need adding to CTMS to hold the "Gross Weight" and "Tare Weight" from the POD/POC, these weights are to be used for calculating overweight vehicles in the future, the prefered location of these weights would be on the order screen in the general tab near the actual delivered weight.
5. Due to how Openfield operate vehicles at a 'Carrier' level we need to put a rule into CTMS which denotes that if the number of haulage units is 1 in the resource screen for a Carrier ID that CTMS will automatically set the Tractor Unit, Trailer ID and Driver which is associated to that Carrier ID enabling the CTMS Trip xml to be sent with this detail. The planner should be prompted if they attempt to brief/set a trip to 'ACCEPTED' to a carrier with smartphone enabled and there is no vehicle level detail available.
6. Upgrade CTMS and apply all relevant parameters to ensure the smartphone functionality works including update of statuses throught the trips lifecycle.

Solution

Implementation OBS will implement an instance of the Smartphone EDI interface, configuring the necessary server, system and database setup in the Industrial test (INPF – INDTST) and production (INLV – INDPRD) environments to enable both inbound and outbound XML message processing.

Automatic Trip Resource

A new trigger point will be added to the trip creation/update process which will automatically set the Trip header resources (Tractor ID, Driver ID) and the Trip Stop resources (Trailer ID) when a Carrier ID is assigned to the trip. This will remove/update the data if a carrier is removed or changed.

The values will be set based on the master data settings in the C-TMS Resource screen:

• The Tractor ID will only be set where a single Tractor ID is setup against the particular chosen Carrier ID. If multiple Tractor IDs are linked to the carrier or no Tractor IDs are linked to the carrier then the Tractor ID will remain blank.
• The Driver ID will only be set where a single Driver ID is setup against the particular chosen Carrier ID. If multiple Driver IDs are linked to the carrier or no Driver IDs are linked to the carrier then the Driver ID will remain blank.
• The Trailer ID will only be set where a single Trailer ID is setup against the particular chosen Tractor ID populated on the rules above. If multiple Trailer IDs are linked to the Tractor ID or no Trailer IDs are linked to the Tractor ID then the Trailer ID will remain blank.

The activation of this dynamic data population will be controlled by a new C-TMS system parameter at Cost Centre level: TMS_AUTO_DEFAULT_RESOURCE.

Outbound Journey Schedule Message (C-TMS  DHL Link)(TMS_SMA*.XML)

The SMA outbound message will include the following (existing) XML tag fields in the outbound Smartphone flow:

Driver details (<DRIVER>, <DRIVER_NAME>, <DRIVER_CONTACT>)

Tractor ID (<TRACTOR>)

Trailer ID (<TRIP_TRAILER_ID>)

The outbound message triggers from Smartphone are to operate as per current functionality and there is no change to the current outbound message structure.

This will not be parameter controlled.

Inbound SysEvent - ARR (DEP, STA, END)(DHL Link  C-TMS)(SMA_TMS_TMC_ARR*.XML)

The SMA inbound ARR message upload process will be changed to accept an additional XML tag field for Trailer ID (<TRIP_TRAILER_ID>) and the data provided in this field, along with the existing Driver (<DRIVER>), and Tractor ID (<TRACTOR> ) XML tag fields will be uploaded into the relevant C-TMS Trip Header/Trip Stop fields.

C-TMS stores only the Driver ID against the trip and requires the corresponding Driver ID on the master data table with an associated Driver Name. The Driver details must therefore be written to the C-TMS master data driver table on upload of the message in order to display the name against the trip.

The Tractor and Trailer will be processed without validation into the relevant fields against the Trip Header/ Trip Stops. These will not be stored in resource master data.

The provided value will always override any currently populated data against a trip for Driver, Tractor ID or Trailer ID.

The activation of this data update will be controlled by a new C-TMS system parameter: SMA_RESOURCE_UPDATE = Y or N.

Inbound POD/POC – DEL (DHL Link  C-TMS)(SMA_TMS_TMC_DEL*.XML)

The SMA inbound DEL message upload process will be changed to accept additional XML tag fields for Weighbridge Ticket, Net Weight, Gross Weight, Tare Weight.

The XML message will require an extra section where the Weighbridge Ticket will be uploaded into the existing Order Additional Sub Reference fields <ORDER_SUB_REFS> with a provided identifier ‘99’ in line with the current Tokairo DEL processing. This will upload into the existing order additional references.

The XML message will require an extra field in the existing <ORDER_DETAIL> section for the Net (Actual) Weight which will be uploaded into the existing Order Line Actual Weight field.

The current C-TMS ‘Trip Task’ functionality will be migrated into the Smartphone flow to give a range of possibilities for additional Trip header and Trip stop level storage values. The Gross Weight and Tare Weight will be received as Trip Stop Tasks within a new section of the POD/POC (DEL) message. These will be visible in the existing ‘Trip Stop Tasks’ tab in the current C-TMS Trip Debrief screen. This will function as per the current Microlise functionality.

Scope

There are no changes to be made to any C-TMS screens and no changes to be made to any C-TMS CSV or PDF reports.

An element of implementation and testing time is included in this estimate to provide advice/assistance, on request, during the initial testing phases as new order files are received.

In order for OBS to correctly resource the test and production server capacity for the inbound files to be received, an indication of average daily (weekday & weekend) file volumes to be sent to CTMS are required.

This document does not cover further application development. In the event of scope change identified as a result of the inbound/outbound order EDI testing additional development RIO/s will be required.

In the event of further implementation advice/assistance required as a result of EDI testing, beyond the time covered in this estimate, a further RIO would be required to cover this additional work. OBS will advise before the implementation time estimated on this RIO has been fully utilised.

This change will be applied to system version 10.7.0

Set-Up

Pre-requisites

FS-286729 AJ-8ELGEY Flag Required to Route Export Files

XSD TripOrder v2.15

CTMS_10_7_003_060

Menu Structure

No change

Data

2 new cost centre parameters will be created called TMS_AUTO_DEFAULT_RESOURCE and SMA_RESOURCE_UPDATE, which can be set to Y or N.

Implementation Advice

A super user will be responsible for setting the values of the cost centre parameters TMS_AUTO_DEFAULT_RESOURCE and SMA_RESOURCE_UPDATE to Y. This can be completed in the System Parameters Maintenance screen.

FUNCTIONAL DESCRIPTION

Implementation

The original functionality as described in RIO AJ-8ELGEY Flag Required to Route Export Files will be implemented onto Industrial Test and Industrial production prior to the development of this RIO. To implement the original development, the following modules are required:

XSD TripOrder Version 2.15 or above C-TMS Patch CTMS_10_7_003_060

INT_XML_SMA.sql	Smartphone specific XML code		5.2
TRG_SCH_TRIP_XML_INT.sql	Trip trigger	5.6	5.7
TRG_SHA_XML.sql	Haulage activity trigger	5.7	5.8
TRG_SOI_XML.sql	Order Items trigger	5.2	5.3
TRG_SOL_XML.sql	Order Line trigger	5.9	5.10
TRG_STS_XML.sql	Trip Stop trigger	5.5	5.6
AT_RES_CARRIER_286729.sql	Alter table script for carriers		5.0
AT_RES_PERSON_286729.sql	Alter table script for persons (drivers)		5.0
JOB_PROCESS_SMA_TRIP_XML_IN.sql	Script to create inbound database job		5.1
JOB_PROCESS_XML_OUTBOUND_SMA.sql	Script to create outbound database job		5.1
DATA_ADM_SYSTEM_PARAM_286729.sql	System parameters to control Smartphone functionality		5.0
RESOURCE.fmx	Resources Screen	2.60	2.75
TRIPSUM.fmx	Trip Manipulation Screen	2.217	2.218
TRIP_PLAN.fmx	Trip Planning Screen	1.117	1.118

PATH & NAME	SETTING VALUE	RESULT
SMA_OWNING_DEPOT	Y/N	‘Y’ Indicates that the Smartphone file is sent with owning depot in the filename. ‘N’ Indicates that the Smartphone file is sent with the Database name in the filename.
SMA_SEND_ACCEPTED	Y/N	Send ACCEPTED message to SMARTPHONE. Main parameter for turning on or off the smartphone functionality
SMA_SET_TO_COMP_CONF	Y/N	Update Trip Status once Smartphone has provided all quantities and times
SMA_INBOUND_ARCH	/u03/webint/mtstst/interface/SMA/IN/archive	Path for Smartphone XML archiving. This path needs changing when installing on different database.
SMA_INBOUND_FAIL	/u03/webint/mtstst/interface/SMA/IN/failure	Path for Smartphone XML failure. This path needs changing when installing on different database.
SMA_INBOUND_PATH	/u03/webint/mtstst/interface/SMA/IN	Path for yet to be processed XML files from Smartphone. This path needs changing when installing on different database.
SMA_LISTING_SCRIPT_NAME	SMA_TRIP_SCRIPT.ksh	Script name for SMA XML Trip inbound
SMA_INBOUND_LISTING_NAME	SMA_TRIP_FILES.lst	Filename for list of files in directory for SMA XML trip inbound
SMA_INBOUND_IDENTIFIER	SMA_TMS_*.XML	Pattern for SMA Trip inbound XML. Tells the system what inbound filename looks like
SMA_OUTBOUND_PATH	/u03/webint/mtstst/interface/SMA/OUT	Path for outbound Smartphone XML interface. This path needs changing when installing on different database.
SMA_OUTBOUND_FAIL	/u03/webint/mtstst/interface/SMA/OUT/failure	Path for failing outbound Smartphone XML interface. This path needs changing when installing on different database.
SMA_OUTBOUND_ARCH	/u03/webint/mtstst/interface/SMA/OUT/archive	Path for archiving outbound Smartphone XML interface. This path needs changing when installing on different database.
SMA_FTP_DESTINATION_USERNAME		Username for FTP of Smartphone Files. This needs setting, but the settings for the smartphone transfer have not been sent to us yet
SMA_FTP_DESTINATION_IP_ADDRESS		IP for FTP of Smartphone Files
SMA_FTP_DESTINATION_DIRECTORY		Directory for FTP of Smartphone Files
SMA_FTP_DESTINATION_PORT		Port for FTP of Smartphone Files
SMA_FTP_DESTINATION_PASSWORD		Password for FTP of Smartphone Files

To send or receive smartphone messages for a trip, the trip must be assigned a smart phone enabled carrier or driver. Drivers and Carriers are set up as smartphone enabled in the Resources maintenance screen.

The trigger points for sending an outbound message to a smart phone are listed below, where a trip has been assigned a SMARTPHONE enables resource.