261852
261852 PA-7P5MYX Standard Client iface Inbound
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 Client/MTS Interface Model (inbound). Produce a Standard Interface Model for use when creating an EDI link into a Customer system which includes all the required fields of information required to populate MTS in the most complete and comprehensive case. ie Include all the fields that would be required for normal Order creation, LOTS requirements down to line level.
Solution
A standard XML inbound process will be used to import and process xml files into the MTS system. The process will be controlled by database jobs which will provide the parameters to control the flow of data. The parameters will be entered in a new screen which super users will be able to modify and create new interfaces for new and existing clients.
A database job will run at a specified interval (normally 5 minutes) to handle the incoming transmissions. The database job will pass parameters details where the files are to be collected from and the filename prefix that will be accepted.
Files will be placed into the specified inbound directory. When the database job runs these files will be picked up in order and processed by the inbound xml packages. Only files that match the specified format will be picked up from the directory. The files will be loaded into an XML extract table ready for processing. Duplicate files (i.e. files with a name of a previously loaded file) will be rejected.
The data in this table will be validated at this point to ensure it can be loaded in the MTS system. The initial validation will be.
Early Available Date - Date must be valid
Late Available Date - Date must be valid
Early Delivery Date - Date must be valid
Late Delivery Date - Date must be valid
Booking Date - Date must be valid
From Location - Cannot be Null
To Location - Cannot be Null
Customer - Must exist in MTS
Cost Centre - Must exist in MTS
Source System - Must exist in MTS
Delivery Type - Must exist in MTS
Group Name - Must exist in MTS
Each order in the file will be validated separately, so if one order fails validation the others will continue to load.
If the order passes validation a record will be inserted into INT_XML_ORD_HEADER, and one or more records will be inserted into INT_XML_ORD_DETAIL.
Once the data from the file has been loaded into the interface table orders can be created. One order is created for each valid INT_XML_ORD_HEADER record.
Once all these steps had been taken, depending on the result, the xml file would then be moved to the successfully completed file area, or the file failed area, depending upon the result.
The files will be displayed on the XML INBOUND tab in the INT_ERR screen and this will show if the loaded successfully or not. If the file failed to load a reason will be displayed.
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 inbound 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
When these changes are released, standing data will be created to match the existing edi database jobs for the existing order upload process for Birdseye only.
Note that the dba_jobs for the ‘old’ processes will then be stopped and the records from the adm_system_param table will be deleted. Initially this will be the dba job running for Bird’s Eye,
A script will be released to insert default data into the new EDI_FLOW_TYPES table. Initially, this will be a single ‘ORD_XML’ option.
Functional Description
Inbound EDI Uploads
A new ‘EDI’ tab will be added to the Imports form to allow the user to specify and maintain Inbound upload processes.
Modification details of IMPORTS_EXEC screen
A new ‘EDI’ tab will be added to the imports screen:
- The ‘Process Id’ will be a unique system generated 8-digit number system generated from a new database sequence (EDI_PROCESS_SEQ).
- The ‘Process Name’ will be a free text field which the user will be able to use to describe the edi process being created, for example ‘Unison Orders’, ‘Jeyes Orders’ etc.
- The ‘Filename Format’ of the files to be uploaded, this will be the first few characters of the filename.
- The ‘Customer’ field will be a dropdown list of Customers on the system that the user creating the message is able to see.
- The ‘Cost Centre’ field will be a dropdown list of Cost Centre codes on the system that the user is able to see.
- The ‘Direction’ field will be a dropdown list set to either ‘I’ for inbound or ‘O’ for outbound.
- The ‘Flow Type’ will be a dropdown list of processes taken from a table maintained by OBS, for example ORD_XML will indicate an xml order process.
- Note that the ‘Parameters’ button shown within the form will not be displayed for Inbound Edi processes. This will be described in more detail within the specification ‘FS-261821 – PA-7PEFZ8 Standard Client Interface Outbound’.
- The Frequency Type will be a dropdown list that will either be set to ‘Interval’ or ‘Time’.
If the user chooses ‘Interval’, then the next field will be labelled as ‘Interval Length’. The user will specify a number in this field. The next field will be another dropdown list that will display either ‘Seconds’, ‘Minutes’, ‘Hours’ or ‘Days’ number of minutes between each poll. Note that the interval length specifies the length of time between the end of one poll and the beginning of the next.
If the user chooses ‘Time’, the next field will be labelled ‘Run Time’ and the user will specify the time of day the process is to be run. The user will then be able to either choose ‘All Days’ to specify that the job is to be run every day or choose certain weekdays by clicking the radio buttons for ‘Mon’, ‘Tue’ etc.
- The ‘Last Ran’ field will display the date and time the process was last run.
- The ‘Delivery Folder’ will be the directory pathname the files are to be uploaded from.
- The ‘Archive Folder’ will be the directory pathname the files are to be stored in after being processed successfully.
- The ‘Failures Folder’ will be the directory pathname the files are to be stored in after processing has failed. Details of failed uploads will be visible in the ‘Interface Errors’ screen as they are now.
- NB The above 3 folder locations should be provided by an MTS representative when the superuser is setting up the data.
Once the parameters for a new process have been successfully enter and saved, the ‘Start’ and ‘Stop’ functions will be enabled. If the user presses the start button, the program will check if the process is currently already running and issue an error if this is the case.
If a process is currently running, it will not be possible for the user to alter any of the setup data. The user will be expected to stop the process and wait for the running process to finish before they are able to adjust any of the setup parameters listed above.
Modification of the Inbound Orders process (INT_XML)
A new ‘INBOUND_XML_ORDER’ procedure will be created. This will be run via the dba_jobs record created in the form outlined above. The only receiving parameter will be the ‘Process Id’ outlined above. It will use this to retrieve the relevant EDI_PROCESS_HEADER created within the screen mentioned in the last section. Once the process has run, the LAST_RUN_DATE on the EDI_PROCESS_HEADER will be updated with the current date and time.
The process will then call the existing INT_XML_OUT.PROCESS_CIM_ORD_XML_IN procedure passing in the values from the table. Note that the i_list and i_script parameters need to have unique names for each process. They should be set to {flow_type}_FILES_{process_id}.lst and {flow_type}_SCRIPT_{process_id}.ksh respectively.
References
| EST-259410 PA-7MKDYG CN Loading Schedule Report Changes v1.doc |
Document History
| Initial version | ||||
| Reviewed and Issued |
Authorised By
| Matt Crisford | Development Manager | |
| Suk Sandhu | TMSCC MTS Product Manager |
