286581

DHL MTS

Internal Charge Via Cross Dock

FUNCTIONAL SPECIFICATION - 10.6

23/03/2011 - 0.1
Reference: 286581 JC-8EKD99

Client Requirement

Change Request Summary:

Internal charging via Cross Dock currently treats each order individually the need has been identified to allow the system to consolidate internal charges where more than one order is being delivered to the same location.

Change Request Details:

When orders are applied via Cross Dock a Trunk Trip is created, currently when the status of this trip is changed to Accepted internal charges are generated. In addition to the current functionality the system would be required to check the To Location of all orders on the trip and where two or more orders had the same To Location it should consolidate the internal charge and divide it between the relevant orders based on the RPE quantity of each order. It is envisaged that this would work in a similar way to the current revenue consolidation process although Internal Charging consolidation would not take into account the customer of the order only the To Location of the order. This functionality would not need to be switchable as it is for the revenue generation functionality.

Benefits identified as a result of the change:

Currently 15 % of orders require manual amendment to take account of consolidation savings therefore any automation will result in a significant time saving.

Solution

OBS Assumptions

• Only applicable to Radial Charges
• System Parameterised
• Applicable to all internal contracts if the system parameter is set
• Radial charge will be distributed across the orders proportionally

Currently, when radial charges are generated, they are applied to each order individually based on the rpe quantity of each order. Within the RATE package

This change requires the charge to be generated based on a consolidated quantity and apportioned to the relevant orders. To achieve this, a new procedure will be created to calculate the quantity parameters.

A new system parameter ACC_CONSOL_RADIAL_COSTS will determine if the original procedure RATE.Set_Order_Qty_Params or the new procedure RATE.Set_Consolidated_Order_Qty_Params is run. The new procedure will sum the quantities of all the orders going to the same delivery point, only for radial charges. When calculating Trunk charges the old code will be used.

The consolidated quantities will lead to greater charges being applied to each order, however before the internal charging is completed another new procedure RATE.Apportion_Radial_Charges will run which will calculate the quantity for each order as a percentage of consolidated quantity for the trunk trip and apply this percentage to the internal charge created for each order.

	Qty	Consolidated qty	Consolidated charge	Final charge
Order 12345	5	15	150	50
Order 65747	10	15	150	150

This approach will result in the charge for the consolidated quantity being apportioned across the applicable orders. The second new procedure , RATE.Apportion_Radial_Charges will be controlled by the new system parameter.

Within the procedure a cursor will run to identify if there are multiple orders going to the same delivery location. This will be achieved by creating a select statement which counts the number of orders scheduled on the trunk trip going to each delivery location. If there is more than one order at any delivery location, they will be assumed to have been consolidated and the code will continue to apportion the order charge amongst the relevant orders. If there are no multiple orders at any delivery locations on the trip, the code will exit.

Once multiple orders have been identified, the order charge will be assigned across the orders based on the order quantities.

One issue that may have to be addressed is when penny charges on contracts. If we try to apportion a penny across several orders this will result in zero charges which will have to be handled

Testing must be comprehensive and cover ALL types of revenue and cost generation as the changes will be made to the Rating package and the impact must be assessed on the system.

Scope

This change will be applied to system version 10.6.0 on AAMTST and once approved AAMPRD.

Set-up

Pre-requisites

None

Menu Structure

‘Unchanged’

Data

Insert into ADM_SYSTEM_PARAM (param_name, value, description)

VALUES (‘ACC_CONSOL_RADIAL_COSTS’,’N’,’Indicates if radial charges are consolidated at delivery location’)

Functional Description

A new system parameter will be created called ACC_CONSOL_RADIAL_COSTS. When a group of orders are cross docked and the internal charges are generated, the value of this parameter will be checked.

If the value is N, the existing procedure RATE.SET_ORDER_QTY_PARAMS will be run to determine the qty which is sent to the CONTRACT package. Currently the qty is determined by the Customer setting (Planned, Delivered, Despatched) and the qty against each individual order.

If the parameter is set to Y, a new procedure will run RATE.SET_CONSOLIDATED_ORDER_QTY_PARAMS. This procedure will accept an OMS_REF as a parameter, but rather than get the total qty for the order, a cursor will run which will select all the orders on trip going to the same delivery point. The quantities for the group of orders will be summed, using the Customer setting (Planned, Delivered, Despatched) and sent to the CONTRACT package.

Order	Qty	Delivery Loc	Consolidated Qty
123	11	MERSBIRK	18
234	12	ROCHDALE	12
345	7	MERSBIRK	18
456	5	CUMBRIA	5

The two orders going to MERSBIRK will be rated for internal charges based on a qty of 18. This will result in two internal charges being created for a qty of 18, one held against order 123 and one against order 345. A qty of 36 has been charged, so an adjustment to the charge payments is required.

In the example above, 18 RPE generates a charge of 180.00. This has been generated against each order, resulting in a charge to the customer of 360.00.

A second procedure will be called based on the value of the new system parameter ACC_CONSOL_RADIAL_COSTS. Thos procedure will run with the RATE.CALC_RADIAL_ORDER_COSTS and will receive a TRIP_ID parameter. The code will run after all orders on the trip have been looped through and the initial charges generated.

The first process will be to identify if there is more than one order going to the same location scheduled on the trip. In the example above, this check would return (location, no of orders, qty):

If each order on the trunk trip is going to a different delivery location, the code will exit back to RATE.CALC_RADIAL_ORDER_COSTS as consolidation is not applicable.

MERSBIRK

2

18

ROCHDALE

1

12

CUMBRIA

1

5

In the above instance, we would run another cursor looking for all orders going to MERSBIRK to find the individual quantities. The related payment records will be identified using the event_ref field.

Calculating the order qty as a percentage of the consolidated qty will allow the charges to be apportioned across the orders. In the instance above, we would calculate the following:

Order	Consolidated qty	Order Qty	Percentage	Amount	Apportioned amount
123	18	11	0.61	180	110
345	18	7	0.39	180	70
TOTAL					180

The charge for a qty of 18, has now been applied and is apportioned to the two orders.

References

Ref No	Document Title & ID	Version	Date
	EST 286581 JC-8EKD99 Internal Charge Via Cross Dock v1.0	1.0	14/03/2011

Document History

Version	Date	Status	Reason	Initials
0.1	16/03/2011	Draft	Initial version	sw
1.0	16/03/2011	Issue	Reviewed and issued	prc

AUTHORISED BY

Matt Crisford	Development Manager
Peter Greer	TMSCC MTS Product Manager