285532: Difference between revisions
(New page: {{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Stop Consolidation Options|Reference=FS 285532 KM-8DEH2P |Version=1.1|Date=|Sysver=10.6|Client=DHL MTS}} = Functional Overview = == Clie...) |
Middletong (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
{{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Stop Consolidation Options|Reference=FS 285532 KM-8DEH2P |Version= | {{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Stop Consolidation Options|Reference=FS 285532 KM-8DEH2P |Version=2.0|Date=|Sysver=10.6|Client=DHL MTS}} | ||
= Functional Overview = | = Functional Overview = |
Revision as of 13:36, 13 October 2011
DHL MTS
Stop Consolidation Options
FUNCTIONAL SPECIFICATION - 10.6
- 2.0
Reference: FS 285532 KM-8DEH2P
Functional Overview
Client Requirement
Change Request Summary: |
Requirement to Consolidate orders into one stop where the consecutive orders are for the same destination. If however the orders have a return to base leg within the trip these must not be consolidated.Stuart Foster/Milton Keynes/UK/NFC |
Change Request Details: |
Requirement to Consolidate orders into one stop where the consecutive orders are for the same destination. Logic required to apply 30 mins plus 2 minutes per lift to calculate the window. This will then pass the detail to Microlise, and when the geofence is broken it will cover all the orders in one message. If however the orders have a return to base leg within the trip these must not be consolidated. |
Benefits identified as a result of the change: |
Will assist with LOTS / Microlise solution |
Solution
Currently, when orders are consolidated at stops and there are no overlapping order windows, the stop times are set based on the latest order.
If the orders overlap the current functionality should be retained, however if the order windows do not overlap the stop times should be set based on the earliest order rather than the latest order.
Currently, the function STOP_WINDOW, determines the early arrive, late arrive, early depart and late depart for a stop based on the windows of the orders at the stop. To utilise the overlapping of windows, the greatest early arrive value is used. When orders do not overlap, this means that the latest order times are used,
Eg 1 |--------------x------------------------------|
|x-----------------------------------------------------------|
Eg 2|--------------------------------------| x
|x---------------------------------------------------|
In example 1 where the order windows overlap, using the latest early collection time allows both orders to be collected within the order windows.
In example 2 where the orders do not overlap, using the latest early collection time means the first order is always late.
Within this functionality, we must determine if all the orders overlap, if so the existing functionality is applied. However if not all of the orders overlap, the earliest order windows should be applied. After the stop window has been determined, a cursor will be run to select any orders with windows outside of the stop window. If any orders are found, the stop window will be determined using the earliest window, otherwise the stop window calculated will be retained.
The additional checks will be controlled by a system parameter.
NB Stop consolidation only occurs when more than one order has the same activity at consecutive stops i.e. 2 loads or 2 unloads. If there is a load and an unload activity at the same location id the stops will NOT be consolidated
Scope
This change will be applied to system version 10.6.
Set-up
Pre-requisites
None
Menu Structure
‘Unchanged’
Data
Insert into ADM_SYSTEM_PARAM (param_name, value)
Values (‘TRM_EARLIEST_STOP_WINDOW’,’N’)
Functional Description
The STOP_WINDOW procedure was created to allow consolidation of orders at stops. This code was created to identify a stop window which allows all orders to be collected and delivered on time.
To achieve this, the stop window is always based on the latest early collection time and the earliest late collection time. The additional functionality allowing orders to be consolidated even when the windows do not overlap has resulted in the latest order window being applied for stops where the order window times do not overlap.
A change will be made to this procedure. The change will be controlled by a system parameter called TRM_EARLIEST_STOP_WINDOW. The existing parameter TRM_CONSOLIDATE_STOPS must also be set to Y.
If this functionality is customer specific, then the flag to indicate that the earliest window should be applied will be held at customer level rather than database level. Please confirm the parameter level
If the new parameter is set to Y a new cursor will run which will compare the collection or delivery window for each order at the stop with the stop window . The cursor will identify any orders outside of the stop window. If the orders is at the stop to be loaded, the stop window will be compared with the collection window for the order. If the stop is for unload activity, the stop window will be compared with the delivery window for each order.
If the stop is a combination of Load and Unload activity and there is more than one order for either or both activities, the load and unload cursor will be run to identify any orders which are outside of the stop window.
If there are any records returned from the cursor(s) , the stop_window will be recalculated based on the earliest order rather than the existing calculation.
Once the process establishes that order(s) fall outside of the calculated stop window, another cursor will run to identify the earliest collection or delivery order window to be applied.
References
EST-285989 AD-8DQSF3 Develop Asset Tracking Functionality v1.0 | |||
Document History
Initial version | ||||
Reviewed and Issued | ||||
AUTHORISED BY
Matt Crisford | Development Manager | |
Peter Greer | TMSCC MTS Product Manager |