266486
266486 AA-7PPF4C Stops Consolidation in Trip
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
MTS does not consolidate all the orders in one stop (location) if collection / delivery date windows is not same for all the orders in a trip and MTS displays the stops separately and does not consolidate. This request is for MTS to consolidate the stops when the same stop exist in a trip.
Increase the HHT usage at the time of POC-POD
Solution
Current Functionality:
When orders are applied to a trip or if trips are merged, a check is first done to see if the trip has stops that match the ‘from’ and ‘to’ location of the order you are applying or trips you are merging. If this is the case, then a check is done to ensure the order you are applying to the trip or the trips you are merging have Collection and Delivery Windows that overlap. If this is the case, the order will be consolidated onto a stop that already exists on the trip however if the time windows do not overlap, then a new collect and deliver stop will be created on the trip.
Issue Raised:
The creation of extra collect and deliver stops on an trip when time windows do not match, instead of consolidating orders on existing stops on the trip, has been raised as an issue.
Proposed Solution:
The check to see whether time windows overlap is performed within function F_CHECK_STOPS_ORD_WINDOW in package TRM. Currently if the time window of the order being applied to the trip does not overlap with an existing stop on the trip, or if the trip being merged does not have stops with overlapping time window, then FALSE is returned from this function and the trip will continue to create new stops. If overlapping time windows are found within this function then TRUE is returned and the order/merged trip will be consolidated on existing stops.
OBS proposes to control this functionality by a new parameter called TRM_CHECK_TIME_WINDOWS_OVERLAP. If this is set to ‘Y’ then the functionality will perform as normal. If this is set to ‘N’ then the code within this function, to check whether time windows overlap, will be skipped and TRUE will always return, forcing the trip to always consolidate the order being applied or trip being merged onto existing stops, without checking overlapping of time windows.
Additional Notes:
When switched off (e.g. new parameter set to ‘N’), this functionality will exist throughout the system when manipulating trips Applying orders to trip/merging trips will consolidate orders onto existing stops regardless of time windows however the trip may have errors around missed collection and delivery windows (Errors tab within Trip Detail tab in TRIP screens) When orders added to trip or trips merged, stops will always be in sequential order e.g. 1, 2, 3, 4, 5 not 1, 3, 5 as detailed in attached document about HHT consolidation
Scope
These changes will be applied to system version 10.4.7 on SARTST and once approved SARPRD.
SET-UP
Pre-requisites
None
Menu Structure
Unchanged
Data
Include new parameter that will control functionality. Setting to Y will retain original functionality. Setting to N will switch off check on whether Time Windows overlap when adding orders to a trip or merging trips. This will be set to N when released as the request is to not include this functionality.
INSERT INTO ADM_SYSTEM_PARAM (param_name, value, data_type, max_length, displayed, user_modifiable, description, config_by, config_by_value)
VALUES ('TRM_CHECK_TIME_WINDOWS_OVERLAP','N','S',3,'Y','Y',
'Set to Y/N depending on whether to check Time Windows overlap when adding orders to trip or merging trips',
'SYSTEM','NONE');
FUNCTIONAL DESCRIPTION
Current Functionality
Below will outline current functionality around check on Time Windows.
Order 996626 created going from EXELBAWT to EXELWHIT. The Time Window on this is 22/06/09 to 25/06/09:
Order 996627 created same as previous e.g. going from EXELBAWT to EXELWHIT but this order has time windows 17/06/09 to 19/06/09:
Order 996627 was applied to a trip. Then order 996626 was applied to same trip. Trip created as below, with new pick up and deliver stop for second order as time windows do not overlap, even though they are going from and to the same location.
New Functionality
When the new functionality is released to SARTST, and the previous steps were performed e.g. set up 2 orders going from and to the same location but with time windows that do not overlap. When the second order is applied to the trip, the trip should be created as below, with both orders consolidated on the same stop regardless of time windows:
PACKAGE AMENDMENTS
TRM package amendments
The TRM.sql package will have function F_CHECK_STOPS_ORD_WINDOW updated to check what the parameter TRM_CHECK_TIME_WINDOWS_OVERLAP is set to. If it is set to Y, the code will process as normal, so there will be no change to functionality. If the new parameter is set to N, the code within the function will be skipped so as not to check whether the Time Windows overlap. TRUE will always be returned in this situation, so any time the function is called, it will return that it is TRUE that the Time Windows overlap, therefore allowing orders to be consolidated onto the same stop.
References
| Stop Consolidation in MTS v2.0.doc | 2 | ||
| EST-266486 AA-7PPF4C Stops Consolidation in Trip v1.0.doc | 1 | 30/06/2008 |
Document History
| Initial version | ||||
| Reviewed and Issued |
Authorised By
| Matt Crisford | Development Manager | |
| Suk Sandhu | TMSCC MTS Product Manager |
