291372

DHL C-TMS

Microlise Orders for Network Rail

FUNCTIONAL SPECIFICATION - 10.7

17/11/11 - 7.0
Reference: FS 291372 MS-8KNHJA

FUNCTIONAL OVERVIEW

Client Requirement

Create orders and plan into Microlise trip to cover capture of collection component repairs, misdirects and wrong stock orders returns.

Create service from Microlise task and rate i.e. put-away service.

Solution

There are two significant development changes that need to be made to the Microlise inbound message processing package to satisfy the clients requirements.

Note that it is assumed the outbound Microlise flow from C-TMS is unchanged. The outbound flow is a OBSL TripOrder XML format that represents an electronic manifest. This message is transformed by DHL Link into the Microlise journeyScheduleImport message. The electronic manifest is generated automatically at trip status ACCEPTED

Collection Orders (see section in the System Design Document):

C-TMS will be modified to allow collection orders (return of component repair, misdirects, wrong stock) entered by the drivers via the Microlise hand held terminal to be processed in C-TMS.

These will be passed back to C-TMS via the inbound PodPoc flow and will be used to generate orders in C-TMS and apply them to the trip currently being debriefed.

On investigation, it has been identified that currently, the driver interaction with the Microlise MDT (hand held terminal) to capture return orders is a site level Task mentioning the quantity of pallets and is not the ‘ad-hoc’ order creation function from the MDT dialogue that has been utilised in other examples of C-TMS / Microlise integration. The NR business requirement is to keep the Microlise instance and configuration ‘as is’ based on current use (for integration with Ethos) which implies C-TMS will be developed within the scope of this RIO to create return collection orders from a specific Task received from Microlise PodPoc message.

The order created will be from the MSP location to the Worcester depot. It will be assigned a system generated unique reference number prefixed ‘RET’ and then a unique number (using the C-TMS unique stop ID of the planned stop at the MSP location). The collection and delivery date/time windows will default from the trip schedule using the arrival and departure at MSP and at Worcester depot respectively. The order line will be created as product type RETURNS and DU type PALLETS and the quantity as provided by the Microlise Task information. There are no product details provided by the Microlise Task data so no item SKU details will be updated against the order. Once created, the collection order assigned to the trip and will be rated in the normal way using a suitable rate card which has been configured in C-TMS covering the journey. (Understood to be the Non-Heavy Standard Service Mode rate card).

Put-away Tasks (see section of the System Design Document):

C-TMS will be developed to allow an optional put-away task performed by the driver on site at each MSP for the delivery orders to be processed by C-TMS. On receipt of this task if marked as completed, C-TMS will be required to generate an associated service and surcharge. This surcharge will be visible on the first delivery order in C-TMS for the trip stop (drop at MSP) and the revenue transaction visible on the order payments screen.

Note that the put-away task is considered a single service and surcharge for all orders delivered at the MSP trip stop. As mentioned above, if the driver is delivering a number of orders on the same trip stop, only the first order on the stop will be assigned the put-away service surcharge.

Tasks

Within the current inbound PodPoc flow and the journeySummary interface flow from Microlise to C-TMS task updates are defined in the stop and trip level respectively. Both the developments mentioned above for collection order and put-away service surcharges will be derived from the PodPoc message for the stop.

Any duplicate services already created will be ignored from the journeySummary message; missing services will still be added in the event of PodPoc messages not being received for a specific location. This means when the journey summary message is received all orders on the trip will be checked to ensure that PodPoc messages have been received if any of these are missing they will be applied and the order will be debriefed. Any failures can be seen in the Interface Errors screen. If contents need to be changed this would need to be done in either in Microlise or DHL Link..More information on services can be found in the functional specification for MS - 8KNGFM Services.

For put-away, when the PodPoc message is processed in C-TMS, an audit record to show the service was performed by the driver will be created and visible on the additional references (additional details) of the first order delivered at the MSP.

The surcharge rating of orders will be explained in more detail in the functional specification for MS - 8KNGFM Services.

Loading and Unload Confirmation:

The SDD document contains a revised business requirement as follows;

Note that the operation do not want to confirm loading of product at Worcester at the beginning of trips but do want to confirm unloading of product at Worcester (collects and returns) at the end of trips using the Microlise HHT.

From investigation of current message flows from Microlise to Ethos, it is apparent that there is no PodPoc message generated for delivery of collection orders returned to Worcester depot, being the final stop of each trip (final site of each route).

C-TMS will be developed, based on a new configurable system parameter for the NR cost centre, to automatically confirm the delivered quantity for collection orders and set the POD flag once an actual arrival date and time is updated in C-TMS (from breach of the geofence for the Worcester depot) from the journeySummary Microlise message.

In other words, C-TMS will auto debrief confirm collection orders once the vehicle returns to the Worcester depot

Scope

This change will be applied to system version 10.7

SET-UP

Pre=Requisites

291360 MS-8KNGFM Services will be required for the surcharge rating of services related to orders/trips.

Data

• A new cost centre system parameter MIC_COLLECTION_ORDER_TASKS will be created to control the creation of new orders.
• A new cost centre system parameter MIC_SERVICE_TASKS will be created to control the creation of service task information.
• A new cost centre system parameter MIC_AUTO_CONFIRM_COLLECTION_ORDERS will be created to control the auto debrief of delivery of collection orders to the final delivery location (Worcester Depot)
• A new cost centre parameter MIC_DEFAULT_PRODUCT_TYPE will be created to indicate the default product type for returns/repairs
• Records will be inserted into the IMP_DECODE and IMP_DECODE_ENTRY tables to accommodate service task values.

Implementation Avice

A system super user will be required to ensure system parameters are correctly setup in the following screen.

FUNCTIONAL DESCRIPTION

Collection Orders

The inbound PodPoc Task interface from Microlise (via DHL link) will be used to create collection orders. A new cost centre based system parameter will be created MIC_COLLECTION_ORDER_TASKS which will control the creation of collection orders. This system parameter when set to value ‘Y’ will enable the following functionality.

When a Task at stop (site) is received in the Microlise PodPoc message as follows

<task taskName="Collections from MSP" taskStartTime="2011-10-24T12:02:22" taskEndTime="2011-10-24T12:02:32">
<activity activityName="Returns / Repairs" number="1.000"></activity>

DHL link will transform this data into the OBSL TripOrder XML segment for tasks at stop as follows;