290935

DHL C-TMS

Create a New Scheduling Engine

FUNCTIONAL SPECIFICATION - 10.7

17/11/11 - 3.0
Reference: FS 290935 NW-8KEMH2

FUNCTIONAL OVERVIEW

Client Requirement

It is assumed that this RIO will be managed in conjunction with the Project Rigel System Requirements Document v1.0 or higher.

Create a new scheduling engine in C-TMS to automatically schedule orders into shipments using consolidation rules and shipments onto trips based on Carrier Routes and Route Templates.

Key points to be taken into account include cut off times of trips based on departure times, % cut off based on pre-defined capacity, management of Orders, Shipments and Trips based on statuses. Manual modification flags to be introduced Orders, Shipments and Trips. Carrier selection rules to be configured and maintained, Templates to hold core scheduling rules. Trunking schedule also to be maintained in C-TMS to allow cross-dock management.

Solution

A new scheduling engine will be created to automatically assign shipments to new and existing trips based on the new wholesale schedule route templates and carrier routes setup.

The following functionality is required within the new scheduling engine within C-TMS:

• Start / stop on demand
• Schedule Orders into Shipments (290936/NW-8KEMAG)
• Consolidate Shipments (290936/NW-8KEMAG)
• Consolidate Parcels onto Pallets
• Schedule Shipments onto Trips
• Consolidate deliveries into Trip Stops (by post code sector)
• Create Trips based on the Wholesale Schedule (standard HUK Transport Plan) which will be defined as Route Templates
• Ability to manually select multiple Orders and apply to a Shipment where rules do not drive automated scheduling (290936/NW-8KEMAG)
• Trip capacity to be governed by trailer type at Route Template level
• Collections to be scheduled as well as deliveries
• Trip Product compatibility (i.e. Chill) to be governed via Route Template
• Geographical feasibility of Trip to be driven from Route Template based on (From Loc, To Loc, Postal Region to first, second, third and fourth sector level, Planning Region)
• Capacity management at Route Template level, this is to manage the capability to add a parcel on top of a pallet even when the vehicle is 100% full based on its pallet capacity
• Limit drop capacity percentage at route template level

The following scheduling rules are required and must be user maintainable based on access control capability:

• Specified carrier & service level
• Validate shipments against own fleet route templates
• Overspill pallet shipments become unscheduled if they exceed the maximum capacity of the defined vehicle (by default largest capacity vehicle within database). This should be determined by priority of service level on the Shipment
• Any Shipment that contains Hazardous Goods that are not being scheduled onto a Parcel Carrier Trip should not be scheduled automatically, this should be done manually by a planner
• Include / exclude Client / Customer from automatic scheduling by Client / Customer and / or Cost Centre
• Cost based carrier selection based on consignment, weight and service charge via Contracts
• Carriers to be ranked by Client / Customer

The below list will form the basis of how the carrier selection engine will select and allocate carriers to orders/shipments.

1. Customer Owner? Or Client?
2. Product Type
3. Geography From & To Location
4. Service Type
5. Timings (loading cut-off, delivery window)
6. Resource
7. Cost - cost per pallet, shipment, distance,
8. Preferred ranking

Trip planning will be changed to enable multiple orders to be consolidated into a shipment and for the shipment then to be assigned to a new trip or an existing trip.

Where Orders and Shipments are allocated to a 3PL or Parcel Carrier the requirement will generally be to create a trunk leg only to the carrier’s hub location. This should be configurable by carrier as in some instances the actual radial delivery Trip will need to be created as well. These Route Templates will need to be configurable at Zone level (i.e. multiple post codes or countries grouped together) and Export work will need to be scheduled onto a specific Trip and excluded from integrated scheduling.

Where only a trunk is created there needs to be the capability to notify the carrier of any specific requirements such as Trailer Type constraints for the delivery location. This will need to be captured in any EDI interface and also output files from C-TMS.

It will be necessary to be able to hold trunking schedules within C-TMS such as the Baxter trunk schedule and any 3PL or Parcel Carrier trunk schedules so that these trips are created with the correct cut off times. Any allocation of Orders and Shipments to these carriers must adhere to the trunking schedule cut off times as well as any configured trunk vehicle capacities. These trunk legs will need to be created in any instance where the delivery or radial leg of a Trip departs from a location other than the From Location on the Order. A cross-dock order will need to be created and automatically scheduled onto the associated trunk leg. This should work for all Orders scheduled either via the new scheduling engine or via the Paragon Interface. ??

A new ‘Wholesale Schedule Maintenance’ screen will be developed within C-TMS to store the route template data for the standard HUK transport plan.

For Baxter the following process should be adopted in relation to the scheduling engine:

• When a new Order is created validate orders against scheduling process to allocate parcel carriers.
• If the latest delivery date is the same as the current date allocate to the carrier and map accordingly from the Delivery Method and Route Code tables. If the Trip status is less than ACCEPTED then add to the Trip otherwise create a new Trip. If the latest delivery date is later than the current date leave the Order unscheduled to be planned in Paragon.

The proposed automated scheduling engine should also consider the trunking requirements for Baxter and automatically schedule collections on trunks where applicable.

The current operational cycle is as follows:

• Monday - Plan
• Tuesday – Trunk stock from Baxter NDC to outbases
• Wednesday - Carry out deliveries and collections
• Thursday – Return stock to Baxter NDC on trunk

Based on this process the trunks could be created a day in advance to allow the scheduling of the return legs of the collections.

Scope

This change will be applied to system version 10.7.0

SET-UP

Pre-Requisites

291397- MS-8KNH8N Milk Round Processing 290936- NW-8KEMAG C-TMS Consolidation Process and Rules

Data

Insert a new record into ADM_FUNCTION(‘FN_NAME’,’DESCRIPTION’,’ACTIVE’) ‘AUTO_SCHEDULING_CONTROL’,’User allowed to control the auto scheduling process’

Implementation Advice

A super user will be required to set two cost centre parameters called ‘AUTO_SCHEDULING’ and ENGINE_RUNNING which can be set to Y or N for each cost centre. The parameter can be set in the system parameter maintenance screen. ENGINE_RUNNING should be set to ‘N’ for all cost centres.

FUNCTIONAL DESCRIPTION

A new scheduling engine will be developed for Healthcare based on the automatic assignment of shipments and orders to trips using carrier routes and a fixed route template. Out of scope for this RIO development is the new development to create a consolidation engine for generating shipments, although this functionality will be integrated into the schedule engine and its processes.

Scheduling Engine Data

Location Zones

Rigel locations are grouped together as Zones. A zone may cover several postal regions, a mixture of planning and postal regions, a mixture of regions and postcodes and specific locations. A new level will be added to the Location data to store a Zone against each location record. The new field will be displayed in the Locations Maintenance screen and a new screen will be created in the Business Data Maintenance screen to allow users to define Zones and assign locations to Zones.

An example of how the new maintenance screen may look is displayed below:

The user will select a zone; this will display all the locations that have been assigned to the zone. The user may enter a new record and select add to zone, to add the location type to the selected zone.

The location types available to be added to the zone are – LOCATION_ID, POSTCODE, POSTAL_REGION, PLANNING_REGION, COUNTRY. When the user selects a postal type, the system will identify all locations which match the location type and automatically update the ZONE field for each location identified.

If the user highlights a record and selects ‘Remove from Zone’, the system will select all location records which match the Location Type and clear the Zone field. The user will be able to select ‘No Zone’ to generate a CSV listing all active locations on the system which have not been assigned a Zone.

The zone field will be available as display only in the Locations maintenance screen. To change the zone on a location, users must go through the Location Zone Maintenance screen.

Cost Centre & Customers

A new cost centre parameter will allow the auto scheduling functionality to be switched on or off for a particular cost centre i.e. HUK/BAX.

Customers will be specifically included or excluded from using the scheduling engine. This will be achieved by the addition of a new flag in the Customer maintenance screen. If this is selected, the user will be excluded from the scheduling engine functionality. Users will be required to manually schedule orders for any customer excluded or for any shipments that are not automatically scheduled due to the carrier selection rules or fixed routes

Scheduling Engine Process

Shipments will be created in the order well and will be assigned the status UNSCHEDULED until they are scheduled onto a trip. All orders which are consolidated into a shipment will remain in the order well but will be assigned the status SHIPMENT. Once an order has been assigned a status SHIPMENT there will be no further processing of the order as all processing will be carried out on the shipment.

All order records which are at the status UNSCHEDULED will be considered for the SCHEDULING ENGINE. This will include:

• Parcel orders
• Single orders
• Shipments

Orders will be grouped together and consolidated into shipments (see RIO 290936 / NW-8KEMAG C-TMS Consolidation Process & Rules) by consolidation rules such as the same delivery location, product type and service type. Every order will become a shipment and assigned a shipment reference even if no consolidation takes place.

The scheduling engine will then plan the resulting shipment using FOUR distinct processes:

• Mandated Carrier
• Parcel Carriers
• Wholesale Schedule
• 3PL Carriers

Note that a new order in the order well will be considered for consolidation into a shipment that is already planned so long as the shipment status is ‘Open’.

Mandated Carrier

In this instance, an order is received into C-TMS with a carrier assigned. The order must be scheduled onto a trip for the mandated carrier and cannot be carried out by any other carrier. This will be the first process of the scheduling engine. If a mandated carrier is provided, the order is scheduled onto the carrier trip and the scheduling engine moves onto the next order. Note that manual intervention might be necessary to plan to an alternative carrier in exceptional circumstances operationally.

Parcel & 3PL Carriers

Carriers will be assigned a carrier type which may be Parcel or 3PL (or fleet). This will allow parcel carriers to be considered by the scheduling engine separately from 3PL carriers (and fleet).

When selecting a Parcel or 3PL carrier, there are several considerations for the scheduling engine:

Client Preferences

Customers may specify a list of carriers who they would prefer to transport their products. The carrier records will be ordered by ranking. A new table, ORG_CUSTOMER_CARRIER_PREFERENCES will be created to store the information and a new tab will be added to the Customer Maintenance screen to view and edit the information.

If a customer has stated a preference, the scheduling engine will identify the first carrier and consider if they are able to deliver to the schedule based on the following criteria:

• Carrier Rules
• Suitable Du Types
• Suitable Route

If a carrier is unable to deliver the shipment, the system will consider the next carrier in the preference list. As a default, Own Fleet will be added to every customer as the first preferred carrier. Where the system has exhausted the list of preferred carriers, any carrier will be considered.

The Customer Maintenance screen display will be changed to show the tab pages in the following order:

1. Params
2. Debrief
3. Preferences
4. Charges
5. Fuel Charges

Carrier Rules

Carrier rules dictate the shipment sizes, du types and product types that a carrier is able to deliver. The information will be stored in three new tables; CARRIER_RULES_SHIPMENT, CARRIER_RULES_DU_TYPE and CARRIER_RULES_PRODUCT_TYPE

For a carrier to still be considered to deliver a shipment or order, the shipment Size must fall within the minimum and maximum constraints.

For a carrier to still be considered, the shipment/order must be for DU TYPES stored against the carrier.

For a carrier to still be considered, the shipment/order must be for PRODUCT TYPES stored against the carrier.

Carrier Routes & Services

Carriers which are still available following the carrier rules will then be checked against route and scheduling rules. The final selection choice is based on routes and services offered by the carrier.

The carrier route services table will identify which carriers are able to deliver to the schedule of the required service level. The delivery location of the shipment/order will be checked against the destination field. The Destination Type field will indicate how the check should be done. If the destination type is set to Postcode then a direct match is required, planning region will require the planning region of the delivery location to match etc. Note that each carrier route service is maintained using the DHL service level sold to customers and the equivalent carrier service code for the available carrier service. Service level will be stored on the orders in the existing DELIVERY_TYPE field which is displayed in the Additional Information tab on the orders screen.

Carrier offers standard services across all sites. Once a carrier and route have been selected, the CARRIER_ROUTES table is used to establish what day and times the route runs. The route must run on the day and time required for the shipment/order. The carrier routes define the cut-off and depart times for the carrier. If the depart time is missed or a route is not available to satisfy the shipment delivery date, then the scheduling engine will then consider the next preferred carrier from the customer preference list.

Each route and service will be defined from the DHL loading location warehouse.

If more than one carrier is still available for consideration, the shipment will be costed for each available carrier based on the carrier contracts held on C-TMS. The cheapest carrier will then be selected as the carrier to deliver the Shipment.

Parcel & 3PL Carrier Trips

Once a carrier has been selected, the scheduling engine will search for an existing trip set up for the carrier route and schedule that can deliver the shipment. This will be dependent upon the collection times and the trailer type capacity. If an existing trip is available, the shipment will be scheduled onto the trip.

If an existing trip is not available then a new trip will be created for the schedule. Parcel Carrier trips will be created with a prefix PCL-, 3PL carrier trips will be created with the prefix TPL-.

The trips will be created based on the ”From” and ”To” locations on the shipments, and stops will be created for each delivery location.

New fields will be added to the haulage activity record to store further information about the stop activity:

In addition to the extra fields which are being populated, the planned arrive and depart times will be populated for the delivery stops based on the time constraints of the order windows.

Note that any delivery information or constraints for the attention of the carrier will be available from the order and location data, for example vehicle type due to access restrictions.

Baxter Processing

Shipments where the group name is BAX are identified as Baxter orders. Only shipments where the latest delivery date is the same as the current date should be considered for automatic scheduling with a Same Day parcel carrier.

For shipments where the latest delivery date is the current date, the carrier is selected based on the carrier rules. If a planned trip exists for the carrier, the shipment may be scheduled onto the planned trip. Where the trip is at status Accepted or above, a new trip is generated.

Shipments where the delivery date is later than the current date are excluded from the scheduling engine, to be planned by paragon. The engine will identify based on the Group name and latest delivery date whether a shipment should be considered for scheduling.

A new procedure will be created to select any SCHED_COLL Baxter shipments. Shipments at a status SCHED_COLL will be collections which have been returned to the out base. The new procedure will identify if a trunk trip is available to return the collections to the Baxter NDC and automatically schedule the shipments onto the trunk trip.

Wholesale Schedule

The existing Fixed Routes functionality will be amended to provide the Wholesale Schedule.

Current functionality will allow users to define cut off times and Fill factors are each stop. A new stop type will be created called Cross dock, when a stop is defined as a cross dock stop, the Region will be populated with the relevant Zone. Users will be able to select a Zone from a list of values. The location id will be used to define the Cross dock location.

Any orders which are collected at DHLCHER1 and delivered within ZONE 2 will be trunked to DHLTRAFF. A second route will be created to deliver the radial leg; users will be able to select a new stop type called Zone which will allow routes to be created to a zone.

Users may create multiple stops, linking to zones and specific locations. Current functionality generates trips for every route, including all stops on the trip. Stops which are not required are removed later.

The Wholesale schedule will be processed differently, when a route is identified as being available to deliver a shipment, only the stops required for the shipment will be generated. Stops on the route which are not required will not be generated.

As part of the Wholesale schedule process, once a route has been identified, the system will check if a trip has been generated for the route and if the stops have been generated for the route. The table below shows the different checks and actions the Wholesale schedule will take:

A second route will be created to deliver the radial leg; users will be able to select a new stop type called Zone which will allow routes to be created to a zone.

The wholesale schedule will not be used for scheduling the following shipments:

• Shipments with a mandated Carrier
• Shipments with hazardous goods
• Baxter Orders

The system currently allows users to assign a trailer type to a Fixed Route and this will be used to control the capacity on each trip. The trailer type will also control which product types can be assigned to a trip.

Manual Intervention

Users will still have the ability to manually schedule shipments onto trips and to remove shipments which have been scheduled by the scheduling engine. A new flag will be held at shipment order level called ‘Manual Scheduling’. If a shipment is removed from a trip or manually applied to a trip, this field will be set to Y.

Developer Notes, the system must be able to differentiate when a shipment has been scheduled by the scheduling engine or scheduled manually.

When the scheduling engine runs, any shipments which have this flag set to Y will be ignored and not scheduled. This functionality will ensure that any manual actions carried out by a user are not overwritten by the next run of the scheduling engine.

For shipments, the Manual Scheduling flag will be set against the shipment order and not the detail orders.

A new status of OPEN/CLOSED will be held at shipment level and will indicate if a shipment is still available to new orders.

Radial Trips

When a shipment has been allocated to a 3PL or Parcel carrier, the system will generate trip to the delivery location without times being calculated.

For some carriers, the scheduling engine may also be required to schedule the radial trip. A flag will be added to the Carrier Maintenance screen called ‘AUTO_PLAN_RADIALS’

When this flag is set, orders allocated to the carrier will be cross-docked at the carries hub location and the radial leg will also be planned from the hub location to the delivery point. The routes table for these carriers should include a route to the carrier hub and a route out of the carrier hub to the delivery locations.

Overspill Pallets

Multiple shipments of multiple service levels may be scheduled onto a trip. If a trip from the WHOLESALE schedule is identified as able to deliver a shipment, the shipment should be scheduled onto the trip even if this exceeds the maximum capacity of the vehicle assigned to the trip.

If the maximum capacity of the trip has been exceeded, the system should then order the shipments by service level and delivery date, un-scheduling the shipment with the latest service level. The service level will be stored in the delivery type of each order and only orders which are the same service level can be consolidated to a shipment.

If the shipments on the trip are the same service level, the smallest shipment which can be removed to keep the trip within the vehicle capacity should be unscheduled.

The unscheduled shipment will be available in the order well for planning onto another trip. If a shipment is unscheduled through the overspill process, a new field on the trip table called ‘OVERSPILL_TRIP’ will store the trip id of the trunk trip the shipment was unscheduled from. If this field is populated, the system will check if the route can generate more than one trip and generate a new trip to schedule the shipment onto.

Overspill pallets much take account of the cross docking. If a shipment is selected based on service type to be unscheduled from a trunk trip, it must first be unscheduled from the delivery trip.

Scheduling Engine Control

The scheduling engine will be created as 5 separate procedures,

1. Allocating mandated carriers
2. Allocating parcel carriers
3. Allocating to the Wholesale schedule
4. Allocating 3PL carriers
5. Baxter Trunk Scheduling

Developing the scheduling engine in this way will allow users to control the order in which the procedures are run and even exclude a procedure from the scheduling engine. A new maintenance screen will be available to allow users to include or exclude procedures and a numeric field will allow users to control the order in which the procedures are run.

A function will be created to control who is able to set the scheduling engine properties. Only users who have been assigned the function will be able to edit the data. The Scheduling process and Procedure name fields will not be editable, only the included and run order can be changed.

If a process is excluded, it will automatically be set a run order of 0.

A flag will be created at Carrier level which will allow users to exclude carriers from the auto_scheduling. The flag will be called AUTO_SCHEDULING and any carriers with this flag not set to ‘Y’ will be ignored during carrier selection.

Buttons will be available on the screen to stop and start the scheduling engine.

An additional tab will also be available within this screen to view audit information for up to 2 weeks after each run.

The diagram below shows the scheduling engine decisions when the scheduling engine has been set up to run the Mandated carriers, then the Wholesale schedule, Parcel carriers and finally 3PL carriers.

In the instance where the scheduling engine fails to allocate an order/ shipment to a trip, the order/ shipment will remain in the order well unscheduled and will be manually planned or sent to Paragon for planning.

Scheduling Engine Audit

The scheduling engine is split into 5 distinct processes which are run as five distinct procedures. If a procedure has completed successfully, a record will be written to a new table SCH_SCHEDULING_AUDIT. The record will store the name of the process which has run with a status SUCCESS and the run time. If a process is run successfully, the error message field will be blank.

Exceptions will be written in the code to deal with errors, as part of any exception a record will be added to the audit table listing the process which failed and the error message. If a process fails, the processes which are set up to run after the failed process will not run. This will prevent trips being scheduled by a process which should only run after the successful completion of the previous process.

A job will run daily to remove audit records from the table which are over 2 weeks old.

A new system parameter will be created called ENGINE_RUNNING. The value of the system parameter will be set to Y at the start of the scheduling engine code and will be set to N at the end.

Manual Order Scheduling

When an order is manually entered via the Orders screen, the user will be able to select the Pack Confirmation button to auto schedule the single order. The order will be scheduled using the scheduling engine code, however the scheduling engine will only process that specific order.

If the order fails to be scheduled onto a trip by the scheduling engine, a message will be displayed on screen to inform the user. The orders will only be auto scheduled if the scheduling engine is not currently running. This will be determined by the value of the system parameter ENGINE_RUNNING If the scheduling engine is currently running, a message will be displayed to inform the user. The user will wait a short length of time before trying the Pack Confirmation button again. While the scheduling engine is running, it would cause possible locking issues if the process is called again for a single order.

Where the scheduling engine is running as the order is saved, the order may be scheduled onto a trip before the Pack Confirm button has been selected. In this instance, when the user selects ‘Pack Confirm’, the system will check the status of the order and if the order is scheduled, the system will skip the auto scheduling process. The order may still display a status of UNSCHEDULED on screen until the record is refreshed.

The scheduling engine will be overloaded to allow the function to accept no parameters or a specific order parameter (OMS_REF). Where the scheduling engine is run without parameters, the code will process all relevant orders in the order well. (Relevant orders refer to orders which have not previously been processed by the scheduling engine and failed to schedule).

When the scheduling engine process is run for a specific order, the scheduling engine will run the processes of the scheduling engine as defined in the Scheduling Engine Control screen.

REFERENCES

Ref No	Document Title & ID	Version	Date
1	EST-290935 NW-8KENH2 Create a New Scheduling Engine v1.0	1.0	26/08/11

DOCUMENT HISTORY

Version	Date	Status	Reason	Initials
0.1	04/10/11	Draft	Initial version	SEW
0.2	05/10/11	Draft	Revised	MJC
1.0	05/10/11	Issue	Issued	MJC
1.1	06/10/11	Review	Reviewed and commented	DJM
1.2	31/10/11	Revised	Revised following client review.	SEW
1.4	04/11/11	Review	Review updated specification	PJH
2.0	04/11/11	Issue	Issued to client	PJH
2.1	17/11/11	Revised	Revised to add Manual Order functionality	SEW
2.1	17/11/11	Review	Review of latest version	PJH
3.0	17/11/11	Issued	Issued to client	PJH

AUTHORISED BY

Matt Crisford	Development Manager
Peter Greer	TMSCC MTS Product Manager