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;
C-TMS will generate a return order from the trip stop MSP to the final depot on the trip (Worcester) on receipt of a PodPoc task of ‘Collections from MSP’
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 times windows will default from the trip schedule using the arrival and departure at MSP and at Worcester depot respectively.
The product type will be obtained from the MIC_DEFAULT_PRODUCT_TYPE cost centre parameter. This is expected to be set to ‘RETURNS’ for Network Rail.
Developer Note the product type should be created before the parameter
Note the task value will be used to set the pallet quantity and the DU will be set to PALLETS.
Once created the collection order will be automatically allocated to the plan loading at the MSP and unloading at the final depot of the trip.
The collection order will then rate if a rate card covering the journey is found for the quantity of pallets advised from Microlise.
Put-away Tasks
A new cost centre system parameter will be created MIC_SERVICE_TASKS.
If configured to value Y this system parameter will enable the following functionality.
When a Task at stop (site) is received in the Microlise PodPoc message as follows
<task taskName="Put Away at MSP" taskStartTime="2011-10-24T12:27:39" taskEndTime="2011-10-24T12:27:44"> <activity activityName="Put away at MSP" passed="1"></activity>
DHL link will transform this data into the OBSL TripOrder XML segment for tasks at stop as follows;
If the task name is recognised to create a service surcharge, this achieved through configuration of a decode in C-TMS to translate ‘Put Away at MSP’ to a service, the services functionality will be processed.
If the task value 1 (1 will equate to Yes 0 will equate to No.) is received, this indicates the put-away service has been performed by the driver and the service surcharge will then be calculated for the first order of the orders being delivered to the MSP stop. If the task value is zero no putaway service has been performed and no service charge should be created
See RIO MS - 8KNGFM Services for more information of the service surcharge calculation and the related audit trail. Note that a audit record of the service being generated will be made visible on the additional references tab of the order.
Note that the service surcharge for put-away will be configured to be a revenue surcharge charged to customer. Because the put-away is done by a driver from own-fleet, there is no automatic cost surcharge required.
Developers Note - The changes will be made in the INT_XML_MIC.process_mic_trip_procedure. The insert script attached to this document for decodes only contains one service - all services will have to be inserted into the table during development.
Collection Confirmation of Delivery to Depot
If the new system parameter MIC_AUTO_CONFIRM_COLLECTION_ORDERS is set to value Y, the following functionality will be active.
When Microlise debrief updates from journeySummary for arrival to the final depot of the trip, all collection orders on the trip unloading at that location will be auto-debrief confirmed and the order POD flag set to Y. This will mean that all orders on the trip will be fully debriefed, their delivered quantities, delivery date and time and proof of delivery flag set to Y, the Order’s status can then be set to Delivered and if all orders on the Trip are at the same status the Trip Status will be updated to Completed.
REFERENCES
| EST-291372 MS-8KNHJA Microlise Orders for Rail |
DOCUMENT HISTORY
| Initial version | ||||
| Reviewed | ||||
| Revised | ||||
| Reviewed | ||||
| Reviewed and Issued | ||||
| Revised and Re-issued | ||||
| Revised and Re-issued | ||||
| Revised and Re-issued after webex review 25/10 | ||||
| Revised | ||||
| Reviewed and Issued (Increased FS time to match actual time spent) | ||||
| Revised | ||||
| Reviewed & Issued | ||||
| Revised | ||||
| Reviewed and Issued |
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
