272891
DHL MTS
Baxter Paragon Interface
Re-Spin
FUNCTIONAL SPECIFICATION - 10.6
25/01/2010 - 1.0
Reference: 272891 NW-7ZELNS
Client Requirement
Modify the HUK Paragon interface to allow updates.
The Paragon interface for HUK (for the new Baxter client) needs to allow modifications to take place based on a second additions run post initial planning. Once the orders have been scheduled in Paragon and interfaced back into MTS the first phase of planning will be complete, this will result in the majority of all orders having been planned in Paragon with some being manually allocated to 3rd party carriers in MTS.
On day 2 additional orders will be sent from WISE, via CIM, into MTS which will equate to approximately 10% of the total delivery volume. These orders will belong to the same schedule as the initial orders and will need to be exported from MTS and loaded into Paragon.
They will then be scheduled in Paragon which will result in the following changes to the initial plan:
New trips will be created.
New orders will be added onto existing trip.
The sequence of drops on existing trips will change.
Original orders will be taken off existing trips and added to new ones.
Original orders will be taken off existing trips and added to other existing trips.
This updated schedule of orders and trips will then be exported from Paragon and loaded into MTS where the trips will need to be modified accordingly, effectively synchronising MTS with Paragon. Any resultant orders that are not on trips will be left unscheduled so that they can be
manually planned in MTS.
Note that only trips in a status of ACCEPTED or lower should be modified, any trips that are EN-ROUTE or higher should not be modified in any way, these should error in the interface.It is not envisaged that orders would be moved to new outbases as the trunk legs would likely
have departed by the time the additions run takes place.
Note that whilst orders will not be moved to new outbases there will be new orders for the outbases and therefore the interface will need to cater for appending these to the relevant trunk with the latest departure time or create a new one if there is an available slot and all other existing, feasible trunks are full.
Solution
The solution described below is based on the following principle assumptions;
The second paragon file for the same schedule will contain the complete plan and not just the additions and changes resulting from the additions orders.
An order will never be changed from being delivered from one outbase on the first spin to an alternative outbase on the second spin.
Existing trips in MTS built from the first spin will have to be in either PLANNED or ACCEPTED status for the second spin to make any changes or additions.
It is possible, although unlikely, that a trip built from the first spin will need to be DELETED or ABORTED because all the orders originally allocated to delivery round trips have all been re-allocated to other existing or new delivery round trips.
The file created by Paragon for the second spin will contain route codes sequentially with no gaps in the sequence.
The second spin might present the same route in terms of orders and planned times but the carrier and / or vehicle type might have changed.
For additional orders, the second spin processing in MTS must consider that a possible trunk is ‘closed’ or even en-route. The assumption is that MTS can check real-time that if the second spin file is processed within 1 hour or after the planned departure time of a schedule trunk, that this trunk is closed for additions. The process will then consider the next trunk in the slots schedule later in the day. (The 1 hour will be a configurable system parameter).
The process for the first spin allocates all the orders for a particular radial delivery round to 1 trunk. It is assumed that this rule can’t automatically be satisfied for the second additions spin. This is because the orders from the main plan might already be picked, loaded and en-route on the first trunk to the outbase at the time that additions orders are being scheduled. The implication is that additions orders will potentially travel on a different trunk that the main plan for the same radial delivery round.
With the current solution, MTS radial delivery trips (processed from paragon routes) are generated to the schedule derived from the order schedule of the first order allocated to the trip. This will be changed so all new MTS trips will be generated into the schedule according to the SU date and time provided in the paragon file.
The scope of changes for the additions plan are understood to be
New radial delivery round trips can be created
New orders can be added to existing trips
The sequence of existing drops on existing trips can change
Existing orders can be taken off an existing trip and added to a new trip
Existing orders can be taken off an existing trip and added to another existing trip
An existing trip could be ABORTED if all the existing orders are taken off and moved to other trips
While the requirements describe a main plan file from Paragon and a second file including additions orders the next day, it is assumed that MTS might need to process more than just the main paragon file and one additions file as a second spin. The solution will allow as many files to be processed as long as each represents the full and complete plan of all orders for the schedule.
The solution will process using the following logic:
A pre-pass read of the Paragon import file will be performed to identify whether the file is original or additional for the MTS trip schedule.
If the file is deemed to be additional because the first (lowest value) route in the file already exists in MTS for the same schedule, a different upload function will be processed than if original.
For the additions run, the pre-pass will check all the orders contained are of status NEW, UNSCHEDULED, SCHED_COLL or SCHEDULED and that all the radial delivery rounds referenced (by schedule and paragon route code) are at status PLANNED or ACCEPTED. The pre-pass of the second spin will decide route by route whether any changes to the original trips created in MTS from the main plan are detected.
For the main pass and processing, each route is read sequentially from the paragon file. If the corresponding trip is seen as changed by the paragon file, all the orders covered by the paragon route will be de-allocated (back to UNSCHEDULED or SCHED_COLL status) from their MTS delivery trip. The process will then re-build the MTS trip using the revised orders and stop sequence described in the new paragon file.
For each MTS trip, whether the orders or stop sequence changes or not, the process will set the carrier and vehicle type based on the information contained in the new paragon file.
Once each trip is updated, MTS will automatically run the trip revalidate function so any errors will be highlighted.
Scope
This change will be applied to system version 10.6.
Set-up
Pre-requisites
Latest version of Paragon Interface is installed as specified under RIO NW-7Y2G6T.
Assumptions
If any trips are provided in the file by paragon that already exist in MTS (based upon the schedule and route code) then the whole file will be treated as a re-spin and will handled differently than an original file (as specified under the RIO NW-7Y2G6T).
The new code will process the file at order level only (i.e. it will not group the orders at radial trip level when planning the trunk trips) – this means additions orders will be added to existing trunk trips individually order by order.
Existing trunk trips will be unaffected by re-spin other than having new orders added as the existing scheduled orders will still be getting delivered from the same outbase.
Functional Description
All of the following changes are for Baxter only so will be coded under the existing system registry ‘PARAGON_INSTALLED’ being set to ‘HCR’.
Second Spin Check
Whenever a paragon file is received for processing by MTS then it will be necessary to determine if it is an original file or a second (subsequent) spin.
This will be achieved by looping through all of the PAR_TRIP_DTL records for the ID being processed and for every unique paragon trip it will check if the schedule (derived from the departure date/time from the delivery depot – see later) and the route code together already exist in MTS as a trip.
If any trips already exist in MTS then the whole file will be treated as a second spin.
It will bypass all of the existing code and run a new piece of code as specified below.
New Processing
For every unique paragon trip in the file the process will check to see if the radial trip already exists in MTS. If it does then it will also check the current status of the trip.
If the trip already exists in MTS and its status is not at either ‘PLANNED’ or ‘ACCEPTED’ then the process will not update this trip in MTS and an appropriate error message will be saved against all of the PAR_TRIP_DTL records associated to the paragon trip.
The process will then check that all of the orders against this paragon trip are in MTS and are at a suitable status.
As the orders may already be planned on existing trips then the validation will check the order status is either ‘UNSCHEDULED’, ‘NEW’, ‘SCHED_COLL’ or ‘SCHEDULED’.
If it is a new trip then the radial trip will be created at this point in the processing.
Currently the schedule for the radial trip is determined using the schedule from the first order that is assigned to the radial trip (as per the solution implemented at DSG). This causes issues when DHL where testing planning for orders from different schedules in one paragon file. The new functionality to handle creation of consolidated trunks uses the depart time from the depot to determine the schedule of the trip and it is proposed that the same logic, with departure date and time derived from the paragon file used to determine the schedule of the radial trips.
If the upload process finds an existing trip then it will perform a check to see if anything has changed on the trip (same stops with same orders) and if nothing has changed then again it will an appropriate message to all of the PAR_TRIP_DTL records associated to this paragon trip. No further processing would be done on this trip.
Once the trip passes all of the above validation, the process will then unscheduled all the orders interfaced in the paragon file route/trip being processed. Note that this means potentially un-scheduling order that might currently be on other MTS trips for the schedule, un-scheduling from the matching trip in MTS or actually finding the order already unscheduled or at new status because it is an addition order. The reason for this logic is to prepare all the orders in MTS to be re-scheduled to the revised (or new) paragon route/trip.
Any previous allocation of orders to trunk trips from the initial paragon spin and upload into MTS will remain unchanged. The trunking schedule will remain unaffected as it is assumed any re-planning in paragon will not change the delivering depot of an order.
Once this process is complete, any orders still assigned to the radial trip but no longer part of the same paragon route/trip will also be unscheduled, these represent orders that were originally on this trip but have been moved onto a later trip by the re-plan in paragon.
Each order line of the paragon trip will be processed as follows;
If the order in MTS is at status ‘NEW’ or ‘UNSCEHEDULED’ it will be considered for trunking to the delivery depot (outbase).
The process will check the paragon cross-docks records as now for the delivery location and if this fails it will check again using the delivery depot. If a cross dock record is found then it will loop through the paragon cross-dock locations getting each required trunk leg.
For each trunk leg it will then loop through all of the available slots for that delivery day (in start collect window order – earliest first).
An additional requirement at this point of the code is for a new system registry ‘PAR_SLOT_CUTOFF_TIME’ to indicate the number minutes before the trunk trip is due to leave that the process can still allocate orders to the trunk trip (slot).
Currently when assigning an order to a trunk trip, MTS does not take into account the current time (i.e. when the interface file is being processed). This means that if the file is received late (or is a second spin from paragon) then there may still be physically enough room for a radial trip’s orders on the slot (trunk trip) but it is too near the trunk trips departure time (or it may even already have left) for it to be loaded so it should use the next slot (trunk trip).
Slots will now only be selected if the start collect window time taking into account the offset days minus the ‘PAR_SLOT_CUTOFF_TIME’ system registry (converted to days) is before the current time.
For each slot that is potentially available it will then check to see if a TRIP_SLOT_USAGE (TSU) record exists for the delivery date.
If it does not exist then a new trunk trip will be created along with the TSU record.
If it does exist then it will firstly check the status of the associated trunk trip to ensure that it is still at either ‘PLANNED’ or ‘ACCEPTED’ status so that more orders are allowed to be added.
The process will then compare the total weight of all of the orders already assigned to the slot (totalling the TOTAL_WEIGHT from SCH_ORD for all orders that exist on the trunk trip that is identified using the TSU record) with the maximum weight allowed on the trailer type associated with the slot compared with the TOTAL_WEIGHT on the order itself.
If the order will fit on the trunk trip then it will be added otherwise it will need to check the next potential slot.
Once the order has been added to a trunk trip it will then move onto the next trunk leg.
Once all of the trunk legs for the order have had the order scheduled onto them then the order can be scheduled onto the radial trip.
Once all orders have been scheduled onto the radial trip then the radial trip can be updated including the times provided by paragon for each stop.
If any trips exist in MTS that were generated by the paragon interface for the delivery schedule being processed and they no longer have any orders assigned (orphaned trips) then the trip status will be updated to ’DELETED’ .
Add to Original
Some of the changes made to the second spin code also need migrating back into the original spin code.
This includes:
- Checking the times on the slots against the current time using the system registry ‘PAR_SLOT_CUTOFF_TIME’.
- Checking the current status of the trunk trips before using the slot.
- Assigning the schedule on the radial trip based upon the depot depart time.
Document History
| Initial version | ||||
| Reviewed & Issued | ||||
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
