267283: Difference between revisions
Middletong (talk | contribs) (New page: =255571 - PA-7JYD35 Tracking Screen Date Range filter= Copyright OBS Logistics © 2009 The information contained herein is the property of OBS Logistics and is supplied without liability...) |
Middletong (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
= | =267283 - JB-7TYCEX Invoicing Process at Planned or Actual= | ||
Copyright OBS Logistics © 2009 | Copyright OBS Logistics © 2009 | ||
| Line 10: | Line 10: | ||
==Client Requirement== | ==Client Requirement== | ||
New message flows implemented for the LOTS project have impacted on the process for invoicing the customer for plts transported. | |||
Bawtry invoice customers on planned load fill. Previously if customer requests order for 26 pallets , this would upload to MTS and stock shortages in the warehouse would not affect the number of pallets. Now LOTS interfaces mean that Unison sends updates at marshalled and loaded which MTS uses to update the planned pallet volumes , so if stock shortages have occured , we may only invoice customer for 24 plts (for example). | |||
Approach: | |||
- OBS could split line level from DU level for events after order receipt and only modify case / line level so correct line detail gets sent to Microlise but DU level stays at planned numbers on MTS. As is done currently there is some reconciliation on debrief to be done. | |||
- There is already a flag on customer level to define how charges made to customer , planned , despatched , greatest etc , the flag is not currently set , would need to be setup as planned. This would allow us to change approach for different implementations. | |||
- If orders affected can be identifed then it is possible we could modify them before billing which is done monthly and we are currently in week 2 (I think) | |||
==Solution== | |||
With the introduction of the enhanced Unison to MTS orders interface, MTS is receiving line level qty updates at marshal and load events from WMS (and can receive allocation although this is not currently configured). | |||
It is important that the actual line level case qty is received into MTS representing the actual load cases so that these values are passed to Microlise and appear on the driver hand held terminal. | |||
The problem, as a consequence of recalculating MTS DU level pallet and weight quantities from allocation, marshal and load events is that the revenue calculation is changed automatically for the order. Any short picks or unavailable stock is being reflected into reduced MTS DU values as actuals, then being re-calculated from the customer tariff as lower revenue. This is ok for customers charged by actual despatch qty but wrong where the customer is charged on order planned qty | |||
The interface process will be modified when processing allocation, marshal and load messages from Unison. The interface will continue to update the qty to deliver at the order item line level – this is the qty that is messaged to Microlise. | |||
The recalculation of the Order DU values will be conditional on the Order Revenue Charging Type value in CUSTOMERS. This field has a drop down list of values being Planned, Greatest, Actual Despatched and Actual Delivered. The default if no value is set is assumed to be Planned. | |||
The | |||
If | The solution will be to program the allocation, marshal and load interface process to reference the Order Revenue Charging value. If the value is Planned (or no value) or Greatest, the DU values will not be updated and will remain as calculated by the original order interface. Otherwise, the current update method will continue. This results in - if the value is Planned or Greatest, the DU values will be set from the order items ORDERED case qty; otherwise the DU values will be set from the order items TO_DELIVER case qty. | ||
For reference, see screen shot below which shows where the Order Revenue Charging Value is maintained for Customers. | |||
[[Image:267283_1.PNG]] | |||
It is understood by the business that the order qty derived pallet count will appear on loading lists and other paper documents if revenue is configured to be charged on planned. This is no change from the prior situation where the previous csv based interface from Unison to MTS only handled ordered qty. | |||
==Scope== | ==Scope== | ||
N/A | |||
==Data== | ==Data== | ||
N/A | N/A | ||
| Line 40: | Line 46: | ||
=Functional Description= | =Functional Description= | ||
Not Required | |||
= References = | = References = | ||
N/A | |||
= Document History = | = Document History = | ||
N/A | |||
= Authorised By = | = Authorised By = | ||
| Line 110: | Line 61: | ||
{| Border="1" | {| Border="1" | ||
| ''''' | | '''''Matt Crisford''''' | ||
| Development Manager | | Development Manager | ||
| | | | ||
Latest revision as of 14:55, 9 October 2009
267283 - JB-7TYCEX Invoicing Process at Planned or Actual
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
New message flows implemented for the LOTS project have impacted on the process for invoicing the customer for plts transported.
Bawtry invoice customers on planned load fill. Previously if customer requests order for 26 pallets , this would upload to MTS and stock shortages in the warehouse would not affect the number of pallets. Now LOTS interfaces mean that Unison sends updates at marshalled and loaded which MTS uses to update the planned pallet volumes , so if stock shortages have occured , we may only invoice customer for 24 plts (for example).
Approach: - OBS could split line level from DU level for events after order receipt and only modify case / line level so correct line detail gets sent to Microlise but DU level stays at planned numbers on MTS. As is done currently there is some reconciliation on debrief to be done. - There is already a flag on customer level to define how charges made to customer , planned , despatched , greatest etc , the flag is not currently set , would need to be setup as planned. This would allow us to change approach for different implementations. - If orders affected can be identifed then it is possible we could modify them before billing which is done monthly and we are currently in week 2 (I think)
Solution
With the introduction of the enhanced Unison to MTS orders interface, MTS is receiving line level qty updates at marshal and load events from WMS (and can receive allocation although this is not currently configured).
It is important that the actual line level case qty is received into MTS representing the actual load cases so that these values are passed to Microlise and appear on the driver hand held terminal.
The problem, as a consequence of recalculating MTS DU level pallet and weight quantities from allocation, marshal and load events is that the revenue calculation is changed automatically for the order. Any short picks or unavailable stock is being reflected into reduced MTS DU values as actuals, then being re-calculated from the customer tariff as lower revenue. This is ok for customers charged by actual despatch qty but wrong where the customer is charged on order planned qty
The interface process will be modified when processing allocation, marshal and load messages from Unison. The interface will continue to update the qty to deliver at the order item line level – this is the qty that is messaged to Microlise.
The recalculation of the Order DU values will be conditional on the Order Revenue Charging Type value in CUSTOMERS. This field has a drop down list of values being Planned, Greatest, Actual Despatched and Actual Delivered. The default if no value is set is assumed to be Planned.
The solution will be to program the allocation, marshal and load interface process to reference the Order Revenue Charging value. If the value is Planned (or no value) or Greatest, the DU values will not be updated and will remain as calculated by the original order interface. Otherwise, the current update method will continue. This results in - if the value is Planned or Greatest, the DU values will be set from the order items ORDERED case qty; otherwise the DU values will be set from the order items TO_DELIVER case qty.
For reference, see screen shot below which shows where the Order Revenue Charging Value is maintained for Customers.
It is understood by the business that the order qty derived pallet count will appear on loading lists and other paper documents if revenue is configured to be charged on planned. This is no change from the prior situation where the previous csv based interface from Unison to MTS only handled ordered qty.
Scope
N/A
Data
N/A
Functional Description
Not Required
References
N/A
Document History
N/A
Authorised By
| Matt Crisford | Development Manager | |
| Suk Sandhu | TMSCC MTS Product Manager |
