255520
255520 - NW-7JZJ2T/ Add Cross Docking to Fixed Routes Part 1
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
Change Request Details:
Add cross-docking functionality to Fixed Routes.
Utilising the RTE_USE_CROSSDOCK, when this is set to Y Fixed Routes should also consider Orders that have the Current Location field populated. For example, an Order from RDC02 to Customer01 would currently only be allocated to a Trip from a Fixed Route if both the From and To Locations match, with this change the Order would also be allocated if the From Location was RDC01 but it had been previously cross-docked to RDC02 and hence the Current Location on the Order is RDC02. Note that this means that Orders in a status of SCHED_COLL now need to be considered. Following this logic with the parameter set to "Y" the Orders should always be considered based on the Current Location and then, if null, the From Location. If set to "N" the functionality should be as current. Regarding time window validation, the collection window on the order needs to take into account the cross-dock time and therefore, based on the calculation currently carried out in MTS when cross-docking manually the same validation needs to take place now. I am not sure of the detail but the latest collection time on the order will probably still be valid, the earliest collection time will be the earliest time the order is available from the cross-dock (Current) location.
Note: This is required ASAP for Healthcare UK as it was understood that this code was already available, not sure when or why it was taken out (possibly by Cap Gemini). Any assistance in getting something working quickly will be much appreciated.
Benefits identified as a result of the change:
Improved product offering to existing and potential business. Cross-docking is a key requirement in many operations and the ability to incorporate this into part of an automated solution will be a key factor to the likes of Consumer Network and then also for Healthcare and potential customers in Poland and Portugal.
Solution
A change will be made to permit route types for cross-docking to be available for fixed route allocation of orders if the existing, but currently non-effective, system parameter ‘RTE_USE_CROSSDOCK’ is set to ‘Y’. If the system parameter is set to ‘N’ then the following functionality will not apply.
Incorporating this new functionality will involve changes to how they are assessed regarding the assignment of orders.
The fixed route allocation process will now consider orders for cross docking if the order is at status ‘SCHED_COLL’. This situation will apply to orders that have a current location as the stop type location of the route for pickup types of ‘PK’. The current location will thus be considered in preference to the ‘From’ location when the system parameter ‘RTE_USE_CROSSDOCK’ is set to ‘Y’.
If a trip is disbanded as it does not pass all validation criteria during its creation then the status of the order will be returned to ‘SCHED_COLL’ and not automatically to ‘UNSCHEDULED’ if the order was being cross docked.
Scope
These reports will be applied to system version 10.6 on HCRTST and once approved HCRPRD.
Data
The system parameter ‘RTE_USE_CROSSDOCK’ should exist in MTS and be set to ‘N’ for the commencement of testing and to prevent the new functionality being activated.
Functional Description
Description of Change - Set-up
The existing system parameter ‘RTE_USE_CROSSDOCK’ highlighted in Figure 1 will be utilised for this development:
Figure 1
The system parameter ‘RTE_USE_CROSSDOCK’ is currently not effective within MTS and will be used to consider orders that have been cross-docked to a depot location.
The trips may also be disbanded when reversing transport instructions and the system parameter ‘BKG_REV_TI_DISBAND_INV_FIX_RTE’ is referenced for this purpose as may be seen in Figure 2 below:
Figure 2
The trip status also has a flag called ‘PRT’ (‘PERMIT REVERSE TI’) that determines if the transport instructions may be reversed in the ‘BOOKINGS’ form, this flag is not set for any type of trip status (and is thus considered to be set to ‘N’) as may be seen Figure 3 below:
Figure 3
The setup for the fixed routes will not be changed until the proposed development for RIO ‘259841 NW-7JZJ2T Add Cross-docking to Fixed Routes Part 2’ is implemented, the ‘Stop Type’ will remain for ‘Location’ and ‘Region’ types only as may be seen in Figure 4 below:
Figure 4
Description of Change - Processing
Currently, the fixed routes will only assess orders at status ‘UNSCHEDULED’ and not ‘SCHED_COLL’ for orders that have been cross-docked; this change will enable the cross-docked orders to the incorporated into the order allocation process for fixed routes.
If the system parameter ‘RTE_USE_CROSSDOCK’ is set to ‘Y’ then the order allocation process for fixed routes will be changed to search for the current location of orders that have been cross-docked in preference to the source location. The current location will be used if it is not null, otherwise the source location will be used if the current location is null; i.e. the ‘NVL’ command may be used for this purpose.
The ‘Fixed Routes Execution’ process will not be changed as the existing parameters may be passed into the ‘SCHEDULE_ROUTES’ function in the ‘RTE’ package as may be seen in Figure 5 below:
Figure 5
The ‘SCHEDULE_ROUTES’ function will call the ‘PROCESS_STOPS’ function in the ‘RTE’ package to assess whether the order may be allocated or not.
The ‘PROCESS_STOPS’ function will be changed to enable orders that have been cross-docked to the current location to be selected in the cursor ‘C_ORDERS’ for the parameter ‘C_FROM_LOCATION’ passed in.
The current location may be obtained from the column ‘CURRENT_DEPOT’ on the table ‘SCH_ORD’ and the source location from the column ‘FROM_LOC’ on the table ‘SCH_ORD’. The current location will be used in preference to the source location in the ‘ADD_ORD_TO_TRIP’ function in the ‘TRM’ package.
The early and late times will be assessed differently for orders that have been cross-docked to those that are ‘UNSCHEDULED’: the arrival and departure times at the current location will be obtained from the columns ‘ACTUAL_ARRIVE’, ‘ARRIVE’, ACTUAL_DEPART’ and ‘DEPART’ on the table ‘SCH_TRIP_STOP’ instead of the early arrival and departure times of the order from the columns ‘EARLY_AVAIL’ and ‘EARLY_DEL’ on the table ‘SCH_ORD’ which will be for the source location.
If a trip is disbanded because it is invalid then the order will be returned to the original status of ‘UNSCHEDULED’ or ‘SCHED_COLL’ to reflect whether it had been cross-docked or not.
The function ‘DISBAND_INVALID_TRIP’ in the ‘RTE’ package will be changed for this purpose if a current location exists for the order as described above.
When the trip is disbanded the function ‘DELETE_SHA’ in the ‘TRM’ package will be run to delete the trip and set the current location of the order back to the location of the previous trip stop for the order; therefore, the current location should be retained if the order is not allocated to a trip for the fixed route using the existing functionality. The function ‘VALIDATE_ORDER’ in the ‘OMS’ package will be run to set the status of the order; therefore, the status of ‘SCHED_COLL’ should be retained if the order is not allocated to a trip for the fixed route using the existing functionality.
As the order allocation process for fixed routes will allocate an order to a trip, the transport instructions may not be reversed for an order with the expected setup; thus a change will not be required for this development for the function ‘DISBAND_INVALID_TRIPS’ in the ‘RTE’ package to reset the status of the order; it will be assumed that the existing functionality is correct. See Figure 3 for details about the expected setup.
If the system parameter ‘RTE_USE_CROSSDOCK’ is set to ‘N’ then the new functionality for this development and the proposed development for RIO ‘259841 NW-7JZJ2T Add Cross-docking to Fixed Routes Part 2’ will be inactive.
Summary of changes required:
- RTE.PROCESS_STOPS
- RTE.DISBAND_INVALID_TRIP
References
| EST-255520 NW-7JZJ2T Add cross-docking to fixed routes Part 1 v1.doc |
Document History
| Initial version |
Authorised By
| Matt Crisford | Development Manager | |
| Suk Sandhu | TMSCC MTS Product Manager |
