252651
252651 NW-7GEHZS Reprocess Function for SAL
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
FUNCTIONAL OVERVIEW
Client Requirement
Add a re-process function to the SAL tab of the Interface Errors form. This should allow a user to re-process the currently selected record if it is in a status of FAILURE. Once the file has been re-processed a message should be displayed to denote whether it has been successful or not, if yes the status should be updated to PROCESSED, if not the status should remain at FAILED. The ability to re-process from this tab should be controlled by a new User Group Function.
Solution
The ‘SAL’ tab page of the ‘Interface Errors’ screen will be changed to include a new button called ‘Reprocess’ in the ‘Header’ section. This button will be used to re-process files received that exist with a ‘Header’ record at a status of ‘FAILURE’ and if the record highlighted does not exist at the correct status then the record may not be re-processed and the user will be informed of the reason accordingly (e.g. ‘THE RECORD IS NOT AT STATUS FAILURE’).
If the user does not belong to a group that is permitted to re-process records then the record may not be re-processed and the user will be informed of the reason accordingly (e.g. ‘YOU DO NOT HAVE ACCESS’). It is expected that the permitted user ‘Group Names’ for the existing controlling function called ‘INT_REPROCESS_SAL’. The permitted user ‘Group Names’ will be maintained in the ‘Access Groups’ screen for this function name will be: ‘ADMIN’, ‘IMPLEMENTORS’, ‘IT SUPERUSERS’ and ‘SITE SUPERUSERS’.
If the record is re-processed then the file that was originally sent will be re-assessed and uploaded as appropriate; if the file is invalid again then the original record will be reset to status ‘FAILURE’ at the ‘Header’ and ‘Detail’ levels and no order and trip details will be updated and applied; if the file is valid then it will be processed and a trip generated and the orders applied, the status of the records re-processed will then be updated to ‘PROCESSED’ at the ‘Header’ level and ‘SUCCESS’ at the ‘Detail’ level.
When the re-process button is pressed (and validation is correct, i.e. permissions are correct and status is correct), the original file will be copied from the failed directory to the working directory and suffixed with “_rpnn” where “nn” is the number of reprocessing attempts. Example
| Record Id | Status | Created Date | Success | Failed |
| SAL0000000443.CSV | FAILURE | 08-JUL-08 13:30:08 | 0 | 1 |
| SAL0000000443.CSV_rp1 | FAILURE | 08-JUL-08 18:30:08 | 0 | 1 |
| SAL0000000443.CSV_rp2 | PROCESSED | 10-JUL-08 10:30:08 | 1 | 0 |
This method will give a full audit trail, currently there is a column on the table which holds the created_by user this will displayed on the tab page of the INT_ERR screen. The new columns UPDATED_BY and UPDATED_DATE will also be displayed.
| Record Id | Status | Created Date | Created By | Updated Date | Updated by |
| SAL0000000443.CSV | REPROCESSD | 08-JUL-08 13:30 | MTS_INTERFACE | 08-JUL-08 18:30 | QADIRA |
| SAL0000000443.CSV_rp1 | REPROCESSD | 08-JUL-08 18:30 | MTS_INTERFACE | 10-JUL-08 10:30 | QADIRA |
| SAL0000000443.CSV_rp2 | PROCESSED | 10-JUL-08 10:30 | MTS_INTERFACE |
The above shows original file was reprocessed by QADIRA on 08-JUL-08 18:30, the reprocess still caused a FAILURE, then changes made and the file was reprocessed for a second time which allowed the file to be processed.
The validation that exists for the inbound ‘SAL’ message will be incorporated into a new procedure called ‘PROCESS_SAL_RECORD’ in the ‘DP_INT_MSG’ package that will be processed from the ‘SAL’ tab page of the ‘Interface Errors’ screen when the ‘Re-process’ button is activated.
As the upload requires all ‘Header’ and ‘Detail’ lines to be valid then the status of the ‘Header’ line will be ‘FAILURE’ even if only a ‘Detail’ line is invalid, therefore, ‘Header’ lines at status ‘FAILURE’ may be re-processed for the ‘SAL’ message unlike other message types.
An information message will be issued to the user about whether the file was successfully re-processed (e.g. ‘File not processed:’ or ‘File processed successfully :’).
As per existing functionality, acknowledgement file(s) will not be generated for the ‘SAL’ message when it is re-processed.
Scope
This change will be applied to system version MTS V10.6.0 for Saudi Aramco.
The scope of this development excludes any data changes to the SAL file received from the HHT from the MTS application. The objective is to allow either master resource data or trip plan information to be entered, updated or corrected so that the SAL information can be reprocessed successfully. For example, a SAL file might include a vehicle reference that is correct but not set-up in MTS. A SAP file might contain a booking that has been physically collected and is being planned out of a DC by the SAL application but on MTS the collection trip has not been processed – In this scenario MTS functionality can be utilised to process the collection trip and ‘ready’ the booking data in MTS for the SAL message to be reprocessed.
Pre-requisites
None
Menu Structure
‘Unchanged’
Data
The table ADM_FUNCTION and ADM_FN_ACCESS tables will need to be populated and the relevant groups who will have access to the new function INT_REPROCESS_SAL.
FUNCTIONAL DESCRIPTION
Validate user Access
User will be checked to see if they have the permissions to run reprocessing function.
IF NOT ADM.FN_ACCESS( 'INT_REPROCESS_SAL’', NULL, NULL ) THEN
MESSAGE('You do not have sufficient access to reprocess SAL files');
ELSE
DP_INT_MSG.PROCESS_SAL_RECORD(:int_sal_header.int_record_id,v_errmsg);
END IF;
Validate record status
The record status will be checked to ensure the reprocessing function applies..
IF (:int_sal_header.record_status <> ‘FAILURE’ THEN
MESSAGE('This file is not at failed status’');
ELSE
DP_INT_MSG.PROCESS_SAL_RECORD(:int_sal_header.int_record_id,v_errmsg);
END IF;
Reprocess (DP_INT_MSG.PROCESS_SAL_RECORD)
•Strip off any suffix (if necessary) to find original file name.
•Count how many occurrences of filename (including suffixed files) and add 1.
•Copy original file from failed directory to working directory, with added suffix.
Existing functionality will now process SAL inbound file.There will be a time constraint of 30mins between reprocessing to allow for the reprocessing function to complete.
Archiving of operating system files
Currently files on the production machine are zipped after 2 days and then removed after another 9 days, this will effect all files in directory /webint/sarprd.interface/SAL/INBOUND/failed. This process will be removed for this specific directory to allow files to be accessed (no time limit to be set on zip and deletion).
APPENDIX A: TABLE UPDATES REQUIRED
UPDATED_BY and UPDATED_DATE columns will be added to the INT_SAL_HEADER table.
References
| No References. |
Document History
| Initial version | ||||
| Change to re-processing |
Authorised By
| Dave Meir | Development Manager | |
| Suk Sandhu | TMSCC MTS Product Manager |
