View source for 261821

=261821 - PA-7PEFZ8/ Standard Client iface Outbound=

Copyright OBS Logistics © 2009

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


=Functiona Overview=

==Client Requirement==
Create a Standard MTS/Client interface model.

Produce a standard Interface code for transmission of data from MTS to client or WMS as 	appropriate. Base on current models with all anticipated fields.

==Solution==
The OBS solution to this is to take the current process used for the outbound processing of xml documents from the MTS System, consolidate this functionality to create a ‘generic outbound file handling framework’ that requires only parameter and variable inputs, able to be entered into the system by an application administrator, or other suitably qualified persons through new screens (forms) as explained below.

The high level description of how to perform this is described below:

This estimate is based upon a pre-requisite: PA-7P5MYX having been completed, as structures/frameworks created within that development are referenced here.

The output of XML documents throughout the order creation process is controlled through trigger points. These trigger points throughout the system will be specified as part of the software (functional) specification.

The assumption of this estimate is that there will be five trigger types through the system, including but not limited to:

Order Status Changes
Trip Status Changes
Order Assignments or De-assignments to a load
Trip Debrief information Entered (or changed.)  

Further trigger points indentified may increase this estimate or require further development in the future.

In the event that one of these events within the MTS system occurs, the trigger will be activated, the necessary parameters will be passed to a revised version of INT_XML (the inbound/outbound xml handling package).  

INT_XML will then read from a controlling table: INT_CONTROL created in RIO: PA-7P5MYX (Generic Inbound xml file handling framework), if an outbound file is needed to be created INT_XML will pass the necessary parameters through to a new procedure within itself called gen_outbound_file this will create the contents of the file using a fixed framework, and place it into an outbound area, for automatic transmission.

The administration of the generic outbound file ‘processes’ is to be performed through an existing screen (interface maintenance screen – created in PA-7P5MYX) modified to handle the requirements of the outbound framework.

Each file sent out to the client will be internally the same, and contain the same tags, however the data and file name will differ. 

==Scope==
The scope of this functional specification applies to changes to be made to system version 10.5 

The scope of this functional specification is dependent on the changes for the Inbound 	Specification FS-261852 – PA–7P5MYX – Standard Client Interface Inbound’ being developed. 	
It is also dependant on the Outbound XML documents being identical in structure to documents currently used within other (DHL) MTS file transmissions. The modification of the MTS system and/or the XML document handling framework and/or the XML files themselves to meet the requirements of the current XML document handling framework is outside the scope of this specification. 

==Set-Up==
===Pre-Requisites===
The maintenance tables: EDI_PROCESS_HEADER, EDI_PROCESS_TRIGGERS and 	EDI_FLOW_TYPES need to exist on the database(s) specified within the scope of this change

===Menu Structure===
Within the Administration -> File Interfaces -> Imports screen, a new ‘Edi’ tab will be created to 	allow the user to control edi processes for both inbound and outbound edi flows. It is expected 	that the tab will be setup to belong to a user group so that it is only available to superusers. 

==Data==
A script will be released to insert default data into the new EDI_FLOW_TYPES table. Initially, 	this will be a single ‘TRIP_XML’ option.

=Functional Description=
==Outbound EDI Orders==
As outlined in the specification FS-261852 – PA–7P5MYX, a new ‘EDI’ tab will be added to the 	Imports form to allow the user to specify and maintain edi order processes. For outbound flows, 	a ‘Params’ button will be become available. 

===Modification details of IMPORTS_EXEC screen===
A new ‘EDI’ tab will be added to the imports screen:

[[Image:261821_1.png]]

The purpose of the majority of the parameters within the above form is described within the FS-	261852 – PA–7P5MYX specification. 

Note also for outbound processes, upon pressing the ‘Params’ button, the user will be presented 	with a new canvas similar to the following:

[[Image:261821_2.png]]

The Process Id, Process Name, Direction and Flow Type will be passed in from the 	previous canvas described earlier. The ‘Level’ option will define the point at which 	the outbound edi messages are to be produced, this will either be ‘Order’ or ‘Trip’. 	The trigger option will determine the type of transaction that has to occur for the 	message to be produced. At first, the only option will be ‘Status’ indicating that a 	message is produced whenever an order or trip moves to a certain status.

===Modification of database Trip Level Triggers===
The existing TRG_SCH_TRIP_XML_INT_BEIG code will be moved into the more generic TRG_SCH_TRIP_XML_INT trigger. 

The TRG_SCH_TRIP_XML_INT will also be altered to allow a more generic outbound message to be created. A new section of code will check for the existence of an EDI_PROCESS_HEADER record created in the maintenance form described above. If one has been created with a flow type of ‘GEN_TRIP_XML’ and the current trip being changed contains an order for the customer, then the process will retrieve the EDI_PROCESS_TRIGGERS records for the PROCESS_ID in question. 

If a record exists for ‘TRIP’ level with a trigger of ‘STATUS’ and a value that matches the new value of the trip status, then further validation will be performed. A count of the number of INT_XML_CONTROL records will be made for matching the trip in question that have not yet been processed. If there are no records, then a new INT_XML_CONTROL record will be inserted. The EXTERNAL_SYSTEM will be set to match the ‘Customer’ value from the EDI_PROCESS_HEADER record and the EVENT_TYPE will be set to ‘TRP’.

Note that the EDI_PROCESS_HEADER record will not need to be running in order for the trigger to create these records. Also note that the xml files will not be sent to the client unless the EDI_PROCESS_HEADER is running and the next interval time is reached. For example, if the process is set to run once per hour then the physical message file will not be produced until the next hour interval time is reached.

===Modification of database Trip Stop Level Triggers===
The code from the TRG_STS_XML_BEIG trigger will be moved into the more generic TRG_STS_XML trigger. 

Similar, to the changes in the last section, the TRG_STS_XML will be altered to allow a more generic outbound trip stop message to be created. A new section of code will check for the existence of an EDI_PROCESS_HEADER record created in the maintenance form described above. If one has been created with a flow type of ‘GEN_TRIP_XML’ and the current trip being changed contains an order for the customer, then the process will retrieve the EDI_PROCESS_TRIGGERS records for the PROCESS_ID in question. 

If a record exists for ‘TRIP’ level with a trigger of ‘STATUS’  and a value that matches the new value of the trip status then further validation will be performed. The process will check if the arrival time or the departure time of the trip stop record has changed. If this is the case, and there are no INT_XML_CONTROL records matching the trip in question that have not yet been processed, then a new INT_XML_CONTROL record will be inserted. 

===Modification of database Trip Haulage Activity Triggers===
The code from the TRG_SHA_XML_BEIG trigger will be moved into the more generic TRG_SHA_XML trigger. 

Similar, to the changes in the last section, the TRG_SHA_XML will be altered to allow a more generic outbound trip stop message to be created. A new section of code will check for the existence of an EDI_PROCESS_HEADER record created in the maintenance form described above. If one has been created with a flow type of ‘GEN_TRIP_XML’ and the current trip being changed contains an order for the customer, then the process will retrieve the EDI_PROCESS_TRIGGERS records for the PROCESS_ID in question. 
If a record exists for ‘TRIP’ level with a trigger of ‘STATUS’  and a value that matches the new value of the trip status then further validation will be performed. A count of the number of INT_XML_CONTROL records will be made for matching the trip in question that have not yet been processed. If there are no records, then a new INT_XML_CONTROL record will be inserted. 

===Modification of Outbound Trip (INT_XML)===
A new ‘PROCESS_OUTBOUND_XML’ procedure will be created. This will be run via a dba_jobs record created in the form outlined in section 3.1.1 above. The only receiving parameter will be the ‘Process Id’. It will use this to retrieve the relevant EDI_PROCESS_HEADER. If the flow type of the record is set as ‘TRIP_XML’, then a new PROCESS_OUTBOUND_XML_TRIP procedure will be called.

This procedure will be similar to the existing 	INT_XML_OUT2.PROCESS_XML_OUTBOUND_BEIG. The process will retrieve all the INT_XML_CONTROL records with the EXTERNAL_SYSTEM matching the customer value on the EDI_PROCESS_HEADER record and the EVENT_TYPE set as ‘TRP’. The filename for the 	physical file being created will be taken from the ‘Filename Format’ and the directory will be taken from the ‘Delivery Folder’ parameters on the EDI_PROCESS_HEADER record. The procedure should then call the existing INT_XML_OUT2.GEN_TRIPxxxx procedures to create the xml tag data as the current BEIG process does. Note that the condition to ignore hub activity should not be present within the generic process. Also the check against the FROM_LOCATION on the sch_ord table should also be removed for the generic process. 


= References =

{| Border="1"	
| <center>'''Ref No'''</center>
| <center>'''Document Title & ID'''</center>
| <center>'''Version'''</center>
| <center>'''Date'''</center>

|-
| <center>1</center>
| Rio – Work Request.mht
| <center>0.1</center>
| <center>28/07/09</center>

|-
|<center>2</center>
| EST-261821 – PA-7PEFZ8 Standard Client Interface Outbound
| <center>1.0</center>
| <center>07/05/09</center>
|}

= Document History =

{| Border="1"	
| <center>'''Version'''</center>
| <center>'''Date'''</center>
| <center>'''Status'''</center>
| <center>'''Reason'''</center>
| <center>'''Initials'''</center>

|-
| <center>0.1</center>
| <center>28/07/09</center>
| <center>Draft</center>
| Initial version
| <center>RE</center>

|-
| <center>1.0</center>
| <center>04/08/09</center>
| <center>Review</center>
| Reviewed
| <center>MJC</center>
|}


= Authorised By =



{| Border="1"	
| '''''Matt Crisford'''''
| Development Manager
| 

|-
| '''''Peter Greer'''''
| TMSCC MTS Product Manager 
| 

|}