294633
DHL C-TMS
Modify Decodes to Map Location Details
FUNCTIONAL SPECIFICATION - 10.7
12/01/12 - 1.0
Reference: FS 294633 NW-8PNK44
FUNCTIONAL OVERVIEW
Client Requirement
Given that DHL Link are not mapping the multiple Unison client locations into single codes within C-TMS, this activity will need to be carried out via the ‘Decodes’ in C-TMS.
The intention is to use the existing decodes functionality to map circa 750,000 locations in Unison down to circa 75,000 locations within C-TMS. This data will potentially need to be loaded as part of this RIO due to the volume of data.
In addition to this the following process will be adopted operationally and needs to be supported by C-TMS:
- Order file sent from Unison to C-TMS via DHL Link and processed within C-TMS.
- Where a location map does not exist in the ‘Decode’ table and an identical location ID does not exist in C-TMS, the order record should fail and not create an order - note that if the file contains multiple records only the individual record should fail, not the whole file.
- A configurable alert should be generated to send a message via either e-mail, SMS or both that records have failed in the file (name and time to be specified).
- The failed record(s) can then be manually corrected and re-processed.
Solution
The ‘CN_LOCATION_MAPPING’ decode name will be used to store the mapping of the Unison locations as a source value and the C-TMS locations as a target value.
The ‘CN_LOCATION_MAPPING’ decodes will have their source and target values uploaded via a ‘DECODE’ import type from a comma-delimited ‘CSV’ file provided by Healthcare UK.
N.B. The number of records involved will require a separate process to be developed by OBS Logistics for use instead of the standard import process.
The process will be run as a data upload using temporary external tables that will then be used to replace the ‘IMP_DECODE_ENTRY’ database table. The existing data will be stored as a backup beforehand and then re-added afterwards.
The standard import process may still be setup for smaller files to be processed in future.
The processes to import transport orders into C-TMS using ‘CSV’ or ‘XML’ files will be changed to assess whether the ‘from’ and ‘to’ locations provided are valid locations in C-TMS or exist as decoded locations: if they are not valid or do not exist then new locations will not be created in C-TMS and the transport order will not be uploaded.
Should a transport order in the file fail to upload then a configurable alert message will be sent to the relevant user. This alert will be sent as an e-mail and/or an SMS message as setup in the ‘Messaging Maintenance’ screen with a new message type and a new event type.
Scope
This change will be applied to system version 10.7.0.
SET-UP
Pre-Requisites
The import types will need to be setup.
FUNTIONAL DESCRIPTION
Location Import Maintenance
A location import for import type ‘LOCATION’ and record type ‘LOCATION’ will be setup in C-TMS for the Healthcare UK locations, for example:
Decode Import Maintenance
A new decode import for import type ‘DECODE’ and without a record type will be setup in C-TMS for the Healthcare UK locations, for example:
The import files will use commas as delimiters.
The ‘Source Value’ for ‘Field Type’ ‘DECODE_NAME’ would be ‘FIXED’ as ‘CN_LOCATION_MAPPING’ for Healthcare UK.
The ‘Decode Name’ ‘CN_LOCATION_MAPPING’ for ‘Decode Type’ ‘LOCATION’ will be setup with the valid ‘Source Value’ and ‘Target Value’ from the ‘Decode’ import files, for example:
The ‘Customer ID’ will be optional but may include the customer of the transport orders for Healthcare UK.
N.B. The ‘Decode Name’ ‘CN_LOCATION_MAPPING’ will be used because it is currently not used by Healthcare UK and it will not require any code changes where it is used currently in C-TMS.
The location code provided will be mapped as a source value to a target value and the target value will be used within C-TMS for the transport orders uploaded.
The mapping will be reversed when generating an output file so that the source value is obtained from the target value so that the original location code is exported as the <WMS_WAREHOUSE> in a ‘TripOrder’ XML file, for example.
N.B. The number of records involved will require a separate process to be developed by OBS Logistics for use instead of the standard import process.
The process will be run as a data upload using temporary external tables that will then be used to replace the ‘IMP_DECODE_ENTRY’ database table. The existing data will be stored as a backup beforehand and then re-added afterwards.
The standard import process may still be setup for smaller files to be processed in future.
Messaging Maintenance
A new ‘Message Type’ of ‘NEW_OMS_FAILURE’ will be created in the ‘Message Config’ tab page of the ‘Messaging Maintenance’ screen, for example:
The description of the message type will be:
‘Notification of failure to upload a transport order.’
A new ‘Event Type’ of ‘NEW_OMS_FAILURE’ will be created in the ‘Medium Maintenance’ tab page of the ‘Messaging Maintenance’ screen, for example:
The data may be setup as follows, for example:
N.B. The message will be as described in the ‘Format’ field and it may be maintained as required.
This setup will ensure that there is no restriction on the times that a failure notification message may be sent, however, times may be entered if required.
The values to display in the message may be maintained in the ‘Medium Items’ screen accessed via the ‘Lookup’ button, for example:
The data may be setup as follows, for example:
N.B. The ‘ORDER_REF’ item will be the transport order reference provided in the failed upload of the order file because an OMS reference will not have been generated in C-TMS.
The recipient of the failure notification message will be setup in the ‘Recipient Config’ tab page of the ‘Messaging Maintenance’ screen, for example:
The ‘Recipient Type’ will be the user who imports or uploads the transport order and the ‘Message Type’ will be ‘NEW_OMS_FAILURE’ (displayed as ‘Notification of failure to upload a transport order.’).
The message type will be setup for all of the media for which the message will be generated (e.g. ‘E-Mail’ and ‘SMS’) in the ‘Message Requests’ tab page and the actual address will be set in the ‘Address Value’ field for the ‘Medium’ in the ‘Electronic Address’ tab page.
A new message medium of ‘SMS’ will be created in the ‘MSG_MEDIUM’ database table to enable a ‘SMS’ message to be sent as well as an ‘EMAIL’ message:
Multiple e-mail or SMS addresses may be created for the recipient user.
The existing system parameter called ‘SMS_SERVICE_BOX’ will be used to store the e-mail address of the service box used to send the message to the SMS addresses:
CSV Order Processing
An event message will be inserted when the transport order fails to be imported successfully.
The processes to import transport orders into C-TMS using a ‘CSV’ file will be changed to assess whether the ‘from’ and ‘to’ locations provided are valid locations in C-TMS or exist as decoded locations: if they are not valid, or do not exist, then new locations will not be created in C-TMS and the transport order will not be imported.
The ‘ORDER_REF’ will be stored in order of preference:
- Customer Reference
- Booking Reference
- Delivery Point Reference
Therefore, the event reference will be one of the transport order references provided.
N.B. If one of the transport order references is not provided then a failure notification cannot be sent and a message event will not be written.
The order import ‘CSV’ file can contain the transport order references as follows:
The ‘IMP.PROCESS_TI_ORDER’ function will be changed to write the message event if a recipient exists for the ‘NEW_OMS_FAILURE’ event type.
XML Order Processing
An event message will be inserted when the transport order fails to be uploaded successfully.
The processes to import transport orders into C-TMS using a ‘XML’ file will be changed to assess whether the ‘from’ and ‘to’ locations provided are valid locations in C-TMS or exist as decoded locations: if they are not valid, or do not exist, then new locations will not be created in C-TMS and the transport order will not be uploaded.
The ‘ORDER_REF’ will be stored in order of preference:
- Customer Reference
- Booking Reference
- Delivery Point Reference
Therefore, the event reference will be one of the transport order references provided.
N.B. If one of the transport order references is not provided then a failure notification cannot be sent and a message event will not be written.
The order upload ‘XML’ file can contain the transport order references as follows in the <ORDER_HEADER> section:
The ‘INT_XML_IN.PROCESS_ORD_XML_IN’ procedure will be changed to write the message event if a recipient exists for the ‘NEW_OMS_FAILURE’ event type.
Message Processing
Should a transport order in the file fail to upload because of an invalid address then a configurable alert message will be sent to the relevant user. This alert will be sent as an e-mail and/or an SMS message as setup in the ‘Messaging Maintenance’ screen with a new message type and a new event type.
The import and upload processes will write an event message and an existing database job will process the record.
The message event record will be as follows, for example, where ‘ORDER123’ is a transport order reference received:
The ‘created by’ user will be used to access the recipient of the failure notification message, therefore, the ‘NEW_OMS_FAILURE’ message request and the ‘EMAIL’ and/or ‘SMS’ electronic address needs to be setup in the ‘Message Maintenance’ screen.
The ‘MSG_PROCESSING.F_GET_MSG_DATA’ function will be changed for the new message event type.
A new procedure called ‘MSG_PROCESSING.P_PROCESS_NEW_OMS_FAILURE’ will be created to process the new message event.
REFERENCES
| EST-294633 NW-8P9K44 Modify Decodes to Map Location Details v1.0.doc |
DOCUMENT HISTORY
| Initial version | ||||
| Reviewed and Issued |
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
