279481
DHL MTS
PO Status Validation
FUNCTIONAL SPECIFICATION - 10.5
- 1.0
Reference: FS 279481 MW-87RGA6
Client Requirement
Change Request Summary:
2 locks to be added to IILV to stop PO's progressing to Confirmed status without first being Approved (message sent to Tesco) and all date fields to have a 6 month prior and 12 month future restriction from the schedule date of the PO.
Change Request Details:
PO's progress out of Provisional to revised, approved or rejected status (initial booking) - an order should not go to Confirmed status without it first being set to Approved and a message sending to Tesco. We also require that all date and time fields within IILV look the schedule date and do not allow the user to save the record with a date that is either 6 months prior or 12 months in the future. This should stop date entries to Tesco that are year 2020.
Benefits identified as a result of the change:
If a PO does not go to Approved prior Confirmed then this does not update Tesco systems (fail in our 98% accuracy), if a date that is more than 2 years into the future, then this crashes the whole of the Tesco reports package.
Solution
The ‘Purchase Order’ maintenance screen will be changed to include extra validation when a purchase order is edited and its status changed to ‘CONFIRMED’: the status may not be updated to ‘CONFIRMED’ unless the current status is ‘APPROVED’ and the purchase order message has been generated for Tesco.
The message status will be checked that it is ‘SEND’, ‘SENDP’ or ‘SENT’ and not ‘SEND_FAIL’ to ensure that the message ‘MTS_POMO’ will be, or has been sent successfully, to Tesco.
The dates that may be entered for the purchase order, in the ‘Purchase Order’ maintenance screen and the inbound ‘POM’ message, will be restricted to no earlier than 6 months prior to the schedule date and no more than 12 months after the schedule date of the purchase order. For example, ‘Cargo Ready Date’, ‘Cargo Receipt Date’, ‘Delivery Date’ and ‘Docs Received Date’.
System parameters will be introduced to control this valid date window.
Scope
This change will be applied to system version 10.5
Set-up
Pre-requisites
Menu-Structure
Data
New registry settings, POM_DATE_START and POM_DATE_END.
Functional Description
Changes will be made on the Purchase Order screen to add validation to the process when changing the PO status.
Code will be added to ensure that the status of the PO can only be moved to CONFIRMED if the current status if ACCEPTED. If the current status is not ACCEPTED a warning message will be displayed indicating why the status cannot be changed.
This validation will also include a check on the PO Outbound message. The interface table will be checked for the PO in question, if a record exists at a status of ‘SEND’, SENDP’ or SENT then the PO status can be changed. However if the message status is ‘SEND_FAIL’ or no record exists for this PO then the user will be informed that the PO status cannot be changed until the message has been sent.
There are several date fields on the PO entry and update screens.
When entering a PO manually two dates can be entered, cargo ready and delivery date. At this point no schedule date has been entered as this is derived from the cargo ready date. Therefore the cargo ready date will be restricted based on the sysdate **** Need confirmation this is ok****.
The delivery date will then be restricted based on the date entered for the Cargo Ready Date.
When editing a PO the date fields that are updateable, will be restricted based on the schedule name of the PO.
The inbound POM process will also be changed to add validation on the dates being imported. These dates will have the same validation as dates that are entered in the screen.
The date restriction will be controlled by two new registry settings, ‘POM_DATE_START’ and ‘POM_DATE_END’. The registry settings will be in days and will restrict the PO dates to the number of days before and after the schedule date.
Additional changes not included in the estimate.
A new flag will be added to the customers screen called ‘Allow Trip Confirmation from Tendered’, a new column will be added to the ORG_CUSTOMER table called ‘TRIP_CONFIRMATION_VALIDATION’. This flag will control whether the trip can be set to Confirmed from Tendered. The default for this flag will be blank (‘N’).
When the trip status is changed to Confirmed from Tendered, this flag will be checked for the customers on the orders for the trip. If the flag is Y for any customer then the trip will be allowed to status Confirmed. If there are no customers with this flag set to Y then the current validation will take place.
NB the flag will only bypass the check on the current status; all other validation for moving to status Confirmed will still be in place.
Table Updates Required
Add column ‘TRIP_CONFIRMATION_VALIDATION’ varchar2(1)
Document History
| Initial version | ||||
| Review & Issue | ||||
AUTHORISED BY
| Dave Meir | Development Manager | |
| Suk Sandhu | TMSCC MTS Product Manager |
