252145

252145-NW-7GECJY HHT POC/POD Validation

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

Where debrief data is managed in MTS there is significant validation that takes place to ensure that the data is correct and will not fail subsequent validation within SAP. This validation is not currently applied to data received from the HHT's and so needs to be introduced based on the following rules:

- HHT data will overwrite manual data unless the manual data has been sent to SAP and has either received a successful acknowledgement or is awaiting receipt of an acknowledgement, in which case the manual data will be retained and the status of the HHT message should be displayed as failed in the Interface Errors form. If the manual data has failed validation then it will be overwritten by the HHT data and a new outbound message to SAP generated.

- If the HHT data is to be used to debrief the Trip in MTS all of the data within the message should be validated based on the current validation of manual data and any failures displayed in the HHT Detail tab of the Interface Errors form. Note that the data should be fully validated and all failures displayed. If the HHT message does fail the user should be able to right click on the detail and amend the data, save the changes and then re-process the message, at which point either the status of the message should be updated to RE-PROCESSED or a new message should be created with a status of MAN_RE-PROC. Note that this ability should be controlled by a new user group function.

- If a second or duplicate message is sent from the HHT it should overwrite the first unless the data from the first has been sent to SAP and has either been acknowledged or is awaiting acknowledgement. If the original data has received a failure acknowledgement from SAP it should be overwritten by the new data and a new message sent to SAP.

Solution

Within the HHT message processing (INT_MSG.READ_HHT_FILE) before it allows the updates of the actual trip stop times and before sending any POC/POD data to SAP then additional validation will be added as follows :-

If any orders are being collected (initial collection point only, not cross-dock locations) or delivered (final delivery point only, not cross-dock locations) then it will ensure that the date in the HHT file is later than any ASN dates on the associated orders.

It will also check for any collection orders that the date is before any actual delivery dates that have been entered for the orders and that no POC data has been sent to SAP which is either still waiting to be sent, waiting to be acknowledged or already acknowledged as OK (including already done error messages).

For any delivery orders then it will ensure that the date is after any actual collection dates that have been entered for these orders and that no POD data has been sent to SAP which is either still waiting to be sent (including waiting on POC or waiting on trip to be completed), waiting to be acknowledged or already acknowledged as OK (including duplicate error message).

Ensure that before sending any POC/POD data to SAP it will also check that the despatched quantity/delivered quantity are populated and badge number is populated for POD.

Also ensure that for FCN’s then all of the required data is populated first before generating a non-conformity (must have actual arrival date/time populated).

Within the interface error message screen whenever a failed HHT exists then a double click will allow the detail data to be amended and saved.

A new re-process button will be added to the header to allow failed files to be run again.

As part of this change the code will be segmented into stand-alone pieces for each type of HHT message in order for the same code to be used by both the existing EDI upload and the re-process functionality. This will ensure that the data produced by the re-process will exactly match that from the standard EDI HHT flow.

Scope

This change will be applied to system version MTS V10.6.0 for Saudi Aramco.

FUNCTIONAL DESCRIPTION

HHT EDI Flow

The READ_HHT_FILE procedure within the INT_MSG package will be changed to include the additional validation that has already been added to the Trip Debrief form (TRIPDTL) to ensure that the data passed by HHT is valid and that no corrupt data gets into the MTS system and subsequently passed on to SAP through the POC/POD interfaces.

There are currently effectively 7 different formats for the inbound HHT file :-

TRIPSTAT has 2 formats (for ‘SU’ stops and ‘CL’ stops) :-

1) ‘SU’ is used to update Driver, Odometer Start, Trailer and Tractor information as well as the actual arrive and depart date/time for the first stop on the trip.
2) ‘CL’ is used to update Driver, Odometer End, Trailer and Tractor information as well as the actual arrive and depart date/time for the last stop on the trip.

TRIPMIL has 4 formats (2 for ‘PK’ stops and 2 for ‘DL’ stops) and TRIPPOC has just one (for ‘PK’ stops only).

3) TRIPMIL (‘PK’ stop with no booking details) is used to update the arrival date/time for this collection stop.
4) TRIPMIL (‘PK’ stop with bookings) is used to update the despatched quantity, Du type on the corresponding order and also the departure date/time for this collection stop. All of the detail booking records will have the same date/time so it only needs to be update trip stop date/time once using the first record. It is also used to create non-conformities (goods not available etc.) when the quantity is zero and a reason code is provided.
5) TRIPPOC is used to update the despatched quantity and DU type on the corresponding orders and also to mark them as ready to send the POC data to SAP.
6) TRIPMIL (‘DL’ stop without bookings) is used to update the actual arrival date/time on the delivery stop. 
7) TRIPMIL (‘DL’ stop with bookings) is used update the delivered quantity and badge number on the corresponding orders and also the departure date/time for the delivery stop. Again all of the booking detail records will have the same date/time so only need to update the actual departure date/time on the delivery stop using the first detail record. It also sends the POD details to SAP.

This code is currently all mixed together and will be separated (and duplicated were necessary) in order to provide a separate piece of code for each process which can then be called by the re-process functionality (see later).

The following checks will be added to the existing validation before the data is used to update the trip information or send any POC/POD data to SAP.

For collections and deliveries (1, 2, 4, 6 and 7) then check that the date in the HHT file (HHT_INBOUND_DETAIL.ACTUAL_DATE and ACTUAL_TIME combined into a standard date format field) is after the ASN date (SCH_PRODUCT_SUMMARY.ASN_DATE) for any of the orders that are either being collected or delivered at this stop (using the stop number provided in the header).

NB) Only need to do this for the first detail record as the rest will all have the same date/time. i.e.) If the HHT date/time matches an already set actual date/time then it will not need to update it so it will not need to check the ASN values so no error will be returned. The following checks can also be ignored when the date/time already matches the value on file.

If HHT date/time differs from the actual date/time and a later ASN date exists for one of the orders then update the HHT detail record with an appropriate error and continue to the next detail record. This update applies to all of the following errors also.

For collections (3 and 4 only) then check that the date on the HHT file is before any entered actual dates/times for the final delivery stop for every order that is being collected from this stop. i.e. the date that would be sent on the POD to SAP.

Also ensure that no POC’s are ready with SAP for all of the orders. i.e.

Waiting to be sent (INT_SAP_POC_OUTBOUND.RECORD_STATUS = ‘NEW’), 
waiting for a SAP acknowledgement (No INT_POC_POD_ACK record with a created date/time after the created/updated date/time on corresponding  INT_SAP_POC_OUTBOUND record), 
successfully acknowledged (INT_POC_POD_ACK.STATUS_CODE = ‘OK’) or
acknowledged with an error that indicates POC is already OK in SAP (status message like ‘%already done%’).

Before sending the POC data to SAP (5 only) then ensure that all of the required data (despatched quantity, actual collection date/time etc.) are all populated and also repeat the above check that no POC’s are ready with SAP but just for this order not all orders being collected at the stop.

For deliveries (6 and 7 only) then check that the date on the HHT file is after any entered actual date/times for the original collection stop for every order being delivered to this stop. i.e. the date that would be sent on the POC to SAP.

Also ensure that no POD’s are ready for SAP for all orders being delivered at this stop. i.e.

Waiting to be sent (INT_SAP_POC_OUTBOUND.RECORD_STATUS = ‘NEW’),
waiting for POC (RECORD_STATUS = ‘WAIT POC’),
waiting for completion of delivery trip (RECORD_STATUS=‘WAIT TRIP’)
waiting for an acknowledgement (No INT_POC_POD_ACK record with a created date/time after the created/updated date/time on corresponding  INT_SAP_POC_OUTBOUND record), 
successfully acknowledged (INT_POC_POD_ACK.STATUS_CODE = ‘OK’) or
acknowledged with an error that indicates POC is already OK in SAP (message = ‘Duplicate POD’).

For sending a POD to SAP (7 only) then also ensure that all of the required data (delivered quantity, actual delivered date/time, badge number etc.) is populated

NB) If the HHT date/time already matches the actual date/time on the delivery stop then you only need to check the POD details ready with SAP for the current order not all orders being delivered at this stop.

Only if the data passes all of this validation will it then update the date/times on the trip stop and then try to send the POC/POD data to SAP.

Re-Process

There is an Interface Errors form (INT_ERR) that has a tab to show the records processed as part of the HHT EDI flow and it currently looks like :-

The header section will include a new re-process button for failed records as well as showing the error message for the currently highlighted record.

The re-process will loop through the failed detail records for the header and call the appropriate (depending on HHT format 1 to 7 as described previously) HHT processing code in the INT_MSG package.

If re-process of all details is successful then the header will move to ‘RE-PROC’ status.

The detail section at the bottom will be adjusted as currently it does not show the status and most of the important data is in the small scroll section at the end of the line with the fixed fields on the left mostly being blank.

The detail error message for the currently highlighted line will also be added.

A new double click option will be available on failed records (RECORD_STATUS=’FAILURE’) only and this will show all of the detail data for the current detail record on a new form which can then be saved if required.

This new feature will be limited by a new function so that only certain groups will be allowed to view the details in full, amend them and re-process them.

Any that are still ‘FAILURE’ will be re-queried and the new error message can be used to determine and fix the data as needed.

Ref No	Document Title & ID	Version	Date
No documents referenced

Document History

1a 08/07/08 Draft Initial version DRM 1b 19/08/08 Draft Change to re-processing DRM 2 26/08/08 Issue Reviewed and Issued DJM

Version	Date	Status	Reason	Initials
1a	08/07/2008	Draft	Initial version	DRM
1b	19/08/2008	Draft	Change to re-processing	DRM
2	26/08/2008	Issued	Reviewed and Issued	DJM

Authorised By

Dave Meir	Development Manager
Suk Sandhu	TMSCC MTS Product Manager