269356
269356 - JB-7VXTB4 / Amendments to Birdseye flow
Copyright OBS Logistics © 2010
The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied
FUNCTIONAL OVERVIEW
Client Requirement
BEIG are moving warehousing to new location. Require modification to depot message triggering and modification of filenames and directories, plus one new flow.
Current MTS messaging for BEIG is inbound T_ORD and outbound T_LOAD , this will remain without change but as the WMS source is changing we will need to change file directories for depositing the files and the filename will also change.
We also have a requirement for MTS to handle a new flow called T_CONF. When MTS sends a T_LOAD to the new WMS (Partner Logistics MLS) , it will respond with a confirmation message stating success / failure and reason code. Initial conversations with Dave Meir suggest using the existing email functionality to email a defined distribution list if specific error or errors occur.
Solution
It is assumed for this estimate that data will be passed through the ESI data interface, and will be presented in OBS’s ‘standard’ XML format (xsd v2.3).
Changes to System Parameters:
The following system Parameters will need to be changed from DAI to MLS:
(Parameters needing data changed indicated in Green, Data changes highlighted in Red. Screenshot taken from the Consumer Test system on 21/9/2009 with confidential data omitted.)
A new inbound and outbound file location will be required on the database server. The new file structure will be: /webint/<databasename>/interface/MLS/…
The inbound file identifier will require to be re-named to MLS_TMS_BEIG_ORD_*
Changes to “T_LOAD” (TMS to WMS) outbound message flow:
Database object: PROCESS_XML_OUTBOUND_BEIG will need to be changed to reflect the new order pickup/startup location: formerly DHLBEHH, the new warehouse location needs to be advised. The outbound filename hardcoded into PROCESS_XML_OUTBOUND_BEIG will need to have it’s name suffix changed from TMS_DAI_... to TMS_MLS_... The Oracle database triggers which generate the data to be placed in the outbound files also need to be re-hardcoded to the new pickup/startup location. There are three triggers in total that need to be changed. (It is assumed by the estimate author that the warehouse location will not change again; hence the use of hardcoded values has been continued, rather than the use of dynamic or new system-parameter values.)
Changes to “T_ORDER” (WMS to TMS) inbound message flow:
Database object: PROCESS_BEIG_ORD_XML_IN does not require to be changed to facilitate the new ‘MLS’ file name in regards to file input. The control of the inbound files is completed via name recognition, which is addressed in; “Changes to System Parameters” (previous). It is expected that a new SOURCE_SYSTEM of ‘WBWMSBEIG’ will replace the existing value of ‘HHWMSBEIG’. The value WBWMSBEIG will need to be added to MTS Standing Data.
Addition of “T_CONF” (WMS to TMS) inbound message flow: It is envisaged that the T_CONF message flow will be a return (a bounce back) of the T_LOAD information but with a current timestamp in the event header, and processing confirmation included against each order. (A generic XML file is shown below with the added information boxed in green. The horizontal lines are where tags have been collapsed.). It is expected that only order information will be supplied which will simplify the message mapping.
The extra information will then be processed by a new handler in PROCESS_BEIG_ORD_XML_IN designed for confirmation information. As per normal inbound XML flows, this information (success or failure) will then be available through the Interface errors screen, under a message type of CON.
In regards to the ORDER_HEADER_CONFIRM section of the XML, the conf. comment 1 is: Accepted (Y/N), conf. comment 2 is the two digit error code, and conf. comment 3 is the text description as to why the error has occurred. The text description will be generated at ESI with a maximum length of 256 chars.
Addition of email outbound message flow:
When a file (or files) are rejected by the Partner Logistics WMS and a corresponding T_CONF message is sent back with an “Accepted” = “N” flag on an order, an email will be collated with all the orders and errors for that inbound file handling process.
The email messages will be sent out as soon as the T_CONF process is completed.
It is envisaged that all the error messages for a particular T_CONF message will be bundled into one email message summarising an individual message run. Suggested format is as follows:
Ie:
Email 1
From: MTS_OWNER (Do Not Reply)
Subject: T_CONF: MLS_TMS_BEIG_ORD_xxxxxxxxxxxxxxxxxx.XML
Trip MAN-00111111
Order yyy – Failed, Reason Code 00, Reason Text:
Order zzz – Failed, Reason Code 00, Reason Text:
Trip MAN-00222222
Order yyy – Failed, Reason Code 00, Reason Text:
Order zzz – Failed, Reason Code 00, Reason Text:
This is an automated email, please do not reply.
Email 2
From: MTS_OWNER (Do Not Reply)
Subject: T_CONF: MLS_TMS_BEIG_ORD_yyyyyyyyyyyyyyyyyy.XML
Etc…
Only Trips with Failed Orders will be included in the email(s). Only failed orders will be displayed in the message.
The text as per the above example will collected into a temporary CLOB (large text) object, during processing and then once finished a non-html / Plain Text email will be sent to [email protected]
The MTS system has basic email functionality built in, however, it requires a modification to capture this T_CONF information and send it automatically.
The recipients of the email will be setup via the Message Maintenance Screen.
Once initially setup, this list of email recipients can be fully user managed.
The contents of the messages will not be able to be edited by users at this stage of the development, if in the future more information is added to the email, then some information may be able to be turned off or on via a ‘Displayed’ Flag (see screen MSG_MAINT), however, the message format as above, is the smallest and most concise that is required for the message, and so initially, all the data is required.
Scope
This change will be applied to system version 10.5
FUNCTIONAL DESCRIPTION
To accommodate the change from DAI to MLS the following parameter’s values will need to be changed from referencing DAI to referencing MLS. (Current values taken from CONTST). The changes required are highlighted in red.
BEIG_INBOUND_PATH /webint/contst/interface/DAI/IN
BEIG_INBOUND_FAIL /webint/contst/interface/DAI/IN/failures
BEIG_INBOUND_ARCH /webint/contst/interface/DAI/IN/archive
BEIG_OUTBOUND_PATH /webint/contst/interface/DAI/OUT
BEIG_OUTBOUND_FAIL /webint/contst/interface/DAI/OUT/failures
BEIG_OUTBOUND_ARCH /webint/contst/interface/DAI/OUT/archive
INBOUND_BEIG_IDENTIFIER DAI_TMS_BEIG_ORD_*
New inbound and outbound directories will be created on the server to store the received and sent files. The new folders will be:
/webint/<dbname>/interface/MLS
/webint/<dbname>/interface/MLS/IN
/webint/<dbname>/interface/MLS/IN/archive
/webint/<dbname>/interface/MLS/IN/failures
/webint/<dbname>/interface/MLS/OUT
/webint/<dbname>/interface/MLS/IN/archive
/webint/<dbname>/interface/MLS/IN/failures
The inbound process (T_ORDER) will not require any changes as the procedure references the above parameters to determine the location and name of files for processing. Once these parameters have been changed the inbound flow should work as it does now.
The T_LOAD process contains hard-coded values for the location DHLBEHH. These will need to be changed to the new location ID to be confirmed by DHL. The following items will need to be changed.
INT_XML_OUT2.PROCESS_XML_OUTBOUND_BEIG
TRG_SCH_TRIP_XML_INT_BEIG
TRG_SHA_XML_BEIG
TRG_STS_XML_BEIG
The outbound file name will be changed from TMS_DAI to TMS_MLS.
A new flow, T_CONF, will be created as a confirmation of the T_LOAD message into MLS. The T_CONF message will be a simplified version of the existing T_ORDER message and will contain the event header information and the order header information along with the order confirmation section (currently not used).
The order confirmation section will be identified by the tag <ORDER_HEADER_CONFIRM>. Within this tag will be 5 further tags.
<CONF_DATE> Date of confirmation
<CONF_USER> User
<CONF_COMMENT_1> Y/N denoting whether T_LOAD file has been accepted.
<CONF_COMMENT_2> Reason Code
<CONF_COMMENT_3> Description
A new job will be created to process the incoming confirmation files. It is assumed that these file will go into the same inbound folder as the existing inbound order files.
If an order is rejected via the T_CONF message there is a requirement for an email to be sent. An event will be created that will be triggered when the T_CONF message is processed and a failure is present.
The email will contain the Trips that contain orders which have failed, only failures will be shown in the email.
The existing email sending procedures will be modified to create and send this email. The message maintenance screen will be used to control the recipients of the email.
REFERENCES
Not Applicable
DOCUMENT HISTORY
| Initial version |
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
