274131
274131 - MW-82GESU/ Tesco PO Order
Copyright OBS Logistics © 2011
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
Tesco require further development / information holding within MTS and sending via EDI to their own system.
New development of screens and functionality within the Trip order screens.
Solution
A new version of the xsd (MTSPurchaseOrder version 1.8) will be created (see Purchase Orders estimate for details – 274129 and also appendix A).
All of the following tags will be added to the ORDER_TRACKING section:-
LOAD_TYPE,
BOOKING_DU_QTY,
TRANSIT_DU_QTY,
TRANSIT_WEIGHT,
TRANSIT_VOLUME,
SUB_TRANSIT_DU_QTY
A new table called SCH_ORD_PO_DATA (SOPD) keyed by OMS_REF will be created.
(Any order generated from the PO will have one of these new records created by the GEN_TI process – see later).
More fields exist on this table which will be maintained on the trip form (see Trip estimate for details - 274132).
The main canvas on the orders form currently looks like :-
Add a new user function ‘ORD_Abort_Restore’ will be created.
Change ORDERS form (2.120) so that if the user is currently selecting an ABORTED order then when the ‘Cancel/Restore’ button is pressed then instead of checking for ‘ORD_Cancel_Restore' privilege it will check for ‘ORD_Abort_Restore’ privilege. It will then allow the order to be restored to ‘UNSCHEDULED’ status (as per existing trigger RESTORE_ORDER).
A new button will also be added called ‘PO Details’ available which when pressed will firstly check that the order currently selected is related to a PO record (SCH_ORD_PO_DATA – SOPD record exists).
If it does then a new canvas will be shown.
The Header section will show all of the relevant figures from the SCH_PURCHASE_ORDER table (including the PO Reference and the Load Type).
NB) It is assumed that only one order line (SCH_ORDER_LINE – SOL) will exist per order header (SCH_ORDER – SO).
The Details section will be a repeating cluster (1 line per related order – not ‘DELETED’ status) showing the related order figures as follows:-
OMS Ref from SO.OMS_REF
Load Type from SOPD.LOAD_TYPE
Booking QTY from SOPD.BOOKING_DU_QTY
Transit QTY from SOL.QUANTITY
Transit Weight from SOL.WEIGHT
Transit Volume from SOL.VOLUME
Sub Transit QTY from SOL.QTY_IN_CASES
The user can then amend existing lines (not OMS Ref), insert new lines (using new ‘+’ button, OMS Ref will be blank) and delete lines (using new ‘–‘ button).
On saving the data (new SAVE button). The form will then confirm that the totals of the figures of all of the lines match the figures from the original PO. An appropriate error message will be displayed and the data must be corrected before the record will be allowed to be saved.
If a new line has been added (OMS Ref on the line is currently blank) then the system will create the order header and line as per the existing code in POM.GEN_TI using the quantities from the new line.
If the line already has an OMS Ref and was amended then the process will update the quantities on the order (header and line).
If a line with an OMS Ref was deleted then the process will set the order to status ‘DELETED’ status (programmers’ note - to be stored internally in a comma separated string so can be identified for later deletion).
In all of cases the related SOPD table will be created/updated as required.
The extra fields will be used to populate the outbound file and subsequently the appropriate tags in the XML (as per Purchase Order estimate).
Also the additional fields will be required within the PO csv export.
Scope
This change will be applied to system version 10.5
FUNCTIONAL DESCRIPTION
Button Changes to Order Form
The main canvas on the orders form currently looks like :-
Currently when the ‘Cancel/Restore’ button is pressed then it checks to ensure that the user has the existing ‘ORD_Cancel_Restore' privilege.
This will be changed so that if the status of the currently selected order is ‘ABORTED’ then the process will check for the new ‘ORD_Abort_Restore’ privilege.
The code run for restoring ‘CANCELLED’ orders will be extended to be run also for ‘ABORTED’ orders.
NB) The code for cancelling an order will remain unchanged.
The extended code will then allow both ‘CANCELLED’ and ‘ABORTED’ orders to be restored to the appropriate status (as per existing trigger RESTORE_ORDER code).
In addition to these changes a new button will also be added to the main canvas called ‘PO Details’.
When pressed the button’s code will firstly check to ensure that the order currently selected has a related PO record (SCH_ORD_PO_DATA – SOPD record exists). If it does then a new canvas will be shown to display the additional PO data.
New Purchase Order Canvas
A new canvas will be written for the order form to display the Purchase Order that was used to generate the selected order and also any other orders that were generated from this same purchase order.
The Header section will show all of the relevant figures from the SCH_PURCHASE_ORDER table (including the PO Reference, Load Type and quantities).
The Details section will be a repeating cluster (1 line per related order – not ‘DELETED’ status) showing the related order figures as follows :-
OMS Ref from SO.OMS_REF
Load Type from SOPD.LOAD_TYPE
Booking QTY from SOPD.BOOKING_DU_QTY
Transit QTY from SOL.QUANTITY
Transit Weight from SOL.WEIGHT
Transit Volume from SOL.VOLUME
Sub Transit QTY from SOL.QTY_IN_CASES
NB) It is assumed that only one order line (SCH_ORDER_LINE – SOL) will exist per order header (SCH_ORDER – SO) so the quantities can be displayed directly of the SOL.
The user can then amend existing lines (not OMS Ref), insert new lines (using a ‘+’ button which will be provided - OMS Ref will be blank) and delete lines (using the ‘–‘ button provided).
On saving the data (new SAVE button). The form will then confirm that the totals of the figures of all of the lines match the figures from the original PO. An appropriate error message will be displayed if they do not match and the data will need to be amended before it can be saved.
If a new line has been added (OMS Ref on the line is currently blank) then the code will need to create a new order header and line as per the existing code in POM.GEN_TI using the quantities from the new line.
If the line already has an OMS Ref and was amended then the code will need to update the quantities on the order (header and line) to match the new figures on the line.
If a line with an OMS Ref was deleted then set the order to status ‘DELETED’ status (programmers’ note - to be stored internally in a comma separated string so deletion can take place)
In all of these cases the related SOPD table will be created/updated as required.
The extra fields stored in the SPOD table will be used to populate the outbound file and subsequently the appropriate tags in the XML (as per Purchase Order estimate).
Also some of these new fields may be required within the PO csv export. (To be confirmed later).
REFERENCES
Not Available
DOCUMENT HISTORY
| Initial version | ||||
| Reviewed and Issued |
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
