290936

DHL C-TMS

C-TMS Consolidation Process & Rules

FUNCTIONAL SPECIFICATION - 10.7

07/11/11 - 2.0
Reference: FS 290936 NW-8KEMAG

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 rule based consolidation process in C-TMS which will primarily be automated but will allow a manual override. This should include rules based on a Client Compatibility Matrix maintained at Customer Level and a Product Compatibility Matrix maintained at Product Level.

Shipment status and other specified rules should also be considered including the user maintenance of these.

Solution

A new consolidation process will be created to combine similar transport orders into shipments for scheduling onto trips (but consideration will be required about whether functionality will be controlled by the cost centre).

N.B. In relation to scheduling it is envisaged that Baxter would be excluded from standard automated scheduling with the exception of sameday (order is due for delivery on current day) orders which would be scheduled to a nominated parcel carrier. There should then be an option to run the scheduling engine and include any BAX unscheduled orders. This should also work the other way around and enable HUK orders to be scheduled on BAX vehicles if required.

The consolidation process will be run as an EDI batch job to process orders automatically at set times per day, or the process may be run manually via a button in a new ‘Shipment Consolidation/Enquiry’ screen.

Some of the conditions will be:

• Orders must be in a status of UNSCHEDULED to be able to be added to a Shipment. ( just the order being added to the shipment; it is presumed that the order being added to the shipment must be UNSCHEDULED.)
• Shipment must be in a status of OPEN for automatic consolidation or PENDING / OPEN for manual consolidation to be able to have Orders added to it.
• Consolidation will primarily take place at Client / Customer level.
• If multiple Clients / Customers can be consolidated together this should be configured against the Client / Customer in question. This needs to be validated against the existing Client / Customer list within C-TMS. Flag to allow consolidation with other customers and then list of specific customers allowed.
• Unique ‘From’ Location on Orders must be the same.
• Unique ‘To’ Location on Orders must be the same.
• Delivery Date must be the same.
• Delivery time windows must at least overlap and then delivery should take place within the most constrained, feasible window. Delivery window will need to be set on the shipment record.
• A consolidation matrix is required for product types / temperature types.
• Orders must have the same Carrier if the Carrier is specified.
• Once Orders have been consolidated into a Shipment, when this is collected by the Carrier it should be on a single vehicle.
• Orders should be of the same DHL Service Level in order to be consolidated.

The ‘from’ and ‘to’ locations must be the same delivery point down to Ward / Department level as will be defined by the location ID.

There will be additional rules in place during consolidation to control the maximum size of a Shipment so that it cannot exceed the maximum capacity of a vehicle.

A “Manually Modified” flag will be added to the orders on the trip so that the new scheduling engine within C-TMS will not try automatically to reschedule any orders or shipments that have been amended manually. This flag will be set as soon as a user carries out a transaction such as unscheduling an order from a shipment so as to prevent the scheduling engine from trying to automatically reschedule the order. A user will have the ability to uncheck this flag if required in the ‘shipment’ screen accessed via the trip planning screens.

To be able to edit the details of a shipment it must be removed from a trip and be in a status of ‘OPEN’ or ‘PENDING’.

The status of the shipment may be one of the following:

• OPEN – Available for scheduling and manipulation
• PENDING – Status manually set by user to prevent the shipment from being automatically closed
• CLOSED – No more orders may be added to the shipment because its limit has been reached (e.g. capacity constraints)
• PACKED – Label Printed
• DESPATCHED – Trip is En-Route

A new database table called ‘SCH_SHIPMENT_STATUS’ will be required to store the description of the shipment status and a new column will be added to the existing database table ‘SCH_SHIPMENT’ to store the status set.

Shipment modification should be access controlled by two separate functions. This will enable any regression of status, if a user has the relevant access. Note that a shipment will not normally be regressed from Despatched as the re-book process will be used however the capability should be available.

To be able to edit the details of an order it must be removed from a shipment and be in a status of ‘UNSCHEDULED’.

If a shipment is modified after it has been picked and the labels produced there will be a requirement to be able to request new labels. In order to carry out this modification in the first place the shipment status must be regressed accordingly based on the rules stated above. . N.B. Once the transport orders have been consolidated into shipments the scheduling engine will be run automatically. (See RIO NW-8KENH2 for further details.)

The ‘EDI Maintenance’ screen will be changed to allow the entry of processes from which the consolidation process may be maintained and started as required. This screen will enable polling for other processes to be possible when they are developed. To allow a process to be run for a specific interval window the following changes will be required:

• A new ‘Direction’ of ‘Internal’ will be available
• A new ‘Frequency Type‘ of ‘Interval Window’ will be available
• A new ‘Flow Type’ of ‘PROCESS’ will be available
• A new field called ‘Interval Start Time’ will be displayed
• A new field called ‘Interval Stop Time’ will be displayed
• New ‘Process Values’ will be entered via the ‘Params’ button for the ‘PROCESS’
• A new database job will be created when the ‘Start’ button is pressed
• A new Package called DP_PROCESS will be created to control the processing of the processes.

Where orders are being keyed into C-TMS it is assumed that an interface mechanism is not in place and therefore Pack Confirmation must take place manually. A “Pack Confirm” button will be added to the manual order entry form, once pressed the order will be scheduled onto a shipment, and its trip, and a carrier label produced to the printer assigned to the user. The Pack Confirmation function should check to see if the order has been scheduled automatically (unlikely as it will just have been keyed in), if this is the case a label should be printed, if the order has not been scheduled then the scheduling engine should be triggered, the order scheduled and a label produced. There should also be the option to specify a carrier prior to Pack Confirmation.

Scope

This change will be applied to system version 10.7

SET-UP

Data

System parameter ORD_ALLOW_SHIPMENTS will be added. This can be configured at cost centre level.

A new Customer of CONSOL will be created as dummy value for consolidated orders that have different customers.

A new flow type PROCESS will be added to EDI_FLOW_TYPES. The COMMAND_SQL will call DP_PROCESS.RUN_PROCESS which is a new procedure. See 3.5

A new order status of CONSOLIDATED will be added to SCH_ORD_STATUS

New system parameters will be added to ADM_SYSTEM_PARAM

• CON_SAME_SERVICE_LEVEL – Is same service level required for consolidation
• CON_SAME_DEL_DATE – Is same delivery date required for consolidation
• CON_OVERLAP_TIME_WINDOW – are overlapping time windows required for consolidation.
• CON_SAME_TO_LOC – Is same delivery location required for consolidation
• CON_SAME_FROM_LOC – is same collection location required for consolidation.
• CON_MAX_VOLUME – maximum volume of a shipment
• CON_MAX_WEIGHT – maximum weight of a shipment
• CON_MAX_RPE – maximum RPE of a shipment

FUNCTIONAL DESCRIPTION

A new automated process will be created that will combine similar orders into a shipment or shipments. These shipments will then be available for scheduling onto trips.

The consolidation process will be run at set times and in addition a manual run will be available from the new Shipment Enquiry screen.

Consolidation will be controlled by a system parameter, which can also be configured by cost centre, there will also be additional rules at client / customer and carrier level. Initially consolidation will only be applied to own fleet but it must be an available option for Prospero. A new system parameter ORD_ALLOW_SHIPMENTS will be added to the ADM_SYSTEM_PARAM table. This can be set for the whole system, or configured for a cost centre.

Consolidtaion Rules

To allow the consolidation of orders certain rules will be used to determine whether consolidation is possible and whether an order can be included in a shipment.

The rules are:-

• Orders must be in a status of UNSCHEDULED to be able to be added to a Shipment.
• Shipment must be in a status of OPEN or PENDING to be able to have Orders added to it. The shipment status will move to CLOSED when set manually, once the maximum capacity has been reached or when a new batch job runs on a predetermined frequency automatically closing outstanding shipments.
• Consolidation will primarily take place at Client / Customer level.
• If multiple Clients / Customers can be consolidated together this should be configured against the Client / Customer in question. This needs to be validated against the existing Client / Customer list within C-TMS (see 3.7 for details).
• Unique ‘From’ Location on Orders must be the same.
• Unique ‘To’ Location on Orders must be the same.
• Delivery Date must be the same.
• Delivery time windows must at least overlap and then delivery should take place within the most constrained, feasible window.
• A consolidation matrix is required for product types (see 3.8 for details)
• Orders must have the same Carrier if the Carrier is specified. The carrier held against SCH_ORD_REFERENCE will be checked against the other orders in the shipment. If no carrier is specified the order can be included with orders that do contain a carrier.
• Once Orders have been consolidated into a Shipment, when this is collected by the Carrier it should be on a single vehicle.
• Orders should be of the same Service Level in order to be consolidated.

When considering an order for consolidation the Max RPE of the trailers or the Max DU size configured against the Carrier (see 3.9) will be used to determine whether the order can be included on the shipment. The RPE of the existing orders on the shipment and the order being consolidated must be below the Max RPE for the trailers.

Several system parameters will be setup to allow some of the consolidation rules to be switched on or off. The following parameters will be added.

• CON_SAME_SERVICE_LEVEL – Is the same service level required for consolidation
• CON_SAME_DEL_DATE – Is the same delivery date required for consolidation
• CON_OVERLAP_TIME_WINDOW – are overlapping time windows required for consolidation.
• CON_SAME_TO_LOC – Is the same delivery location required for consolidation
• CON_SAME_FROM_LOC – Is the same collection location required for consolidation.
• CON_MAX_VOLUME – maximum volume of a shipment
• CON_MAX_WEIGHT – maximum weight of a shipment
• CON_MAX_RPE – maximum RPE of a shipment.

These parameters will be taken into account when deciding whether an order can be included in a shipment.

Any orders that are included in a shipment will be locked and no changes will be allowed. If an amendment is required to an order the order must be removed from the shipment before editing.

To create a shipment a new order will be created using the From Location, To Location and Delivery date of the orders being included in the shipment. The delivery time windows on the order will be set as the latest Early Del and earliest Late Del for all the orders in the shipment. The collection windows will be set as per the new time derivation RIO (291212 NW-8KNCK4). The early collection date will be the date the order is created and the late collection date will match the late delivery date.

The status of the orders that have been consolidated will be changed to CONSOLIDATED to indicate that they are part of a shipment. No changes will be allowed to the order while it is part of a shipment.

Each order line from the orders that have been consolidated will be included in the lines of the shipment. A new column will be added to SCH_ORDER_LINE to store the original order reference. This will allow the orders included in the shipment to be tracked.

Consolidation Process

Creating Shipments

The consolidation process can be run manually or automatically. The two processes will work in the same way. A new package DP_SHIPMENT will be created that will contain all the program units required to maintain and run the consolidation process. A function RUN_CONSOLIDATION will be called to start the consolidation process. All unscheduled orders will be considered for consolidation, unless a specific schedule is selected.

Two new parameters will be added to control how many days in the past and future will be considered for consolidation. If a specific delivery date is passed into the consolidation process these parameters will determine which orders are to be consolidate. When running the process automatically the current date will be used.

• Schedule range
• From Location
• To Location
• Customer
• Delivery Date (which drives the range controlled by the parameter above)

These parameters are not mandatory and can be left blank.

The function will return a Boolean value to indicate if the run was successful. The function will allow the input of the following parameters

The consolidation process will loop through all the available orders. For each order a check will be made to determine if a shipment exists that can accommodate this order. The consolidation rules will be taken into consideration when looking for available shipments. If a shipment is available the order will be added to the shipment. The process will look for any Open shipments regardless of whether the shipments are scheduled onto a trip.

If a shipment is not available for this order, the process will then look for other orders that could be combined into a shipment with this order. Again the consolidation rules must be considered, for each order. If one or more orders match the order being processed, they will be combined to create a shipment.

If a shipment is available for this order the order will be added to the shipment by creating an order line on the shipment order that contains the details of the order being consolidated.

Where an order can be scheduled onto multiple shipments the one with the earliest delivery date and time should be selected.

When considering shipments that are currently scheduled onto a trip, if the shipment is crossdocked the capacity of the trailers for all trips containing this shipment must be considered.

When one or more orders have been found that can be consolidated into a shipment a new “Shipment" order will be created. The order header will contain a new unique OMS Reference, and the From Location, To Location, Sched Name and Cost Centre of the orders being consolidated. These should all be the same for each of the orders being consolidated. If all orders have the same customer then this customer will be assigned to the new shipment order. If the customer is different the customer against the shipment order will show as CONSOL.

Each order line from the orders being consolidated will then be assigned to the shipment order. All of the order line information from the consolidated orders will be stored as a line in the shipment order.

When the shipment is closed, a process will run that combines lines of the same DU Type into one line. The new line will have the combined quantity, weight, volume and RPE of all the lines that have been combined.