291364

DHL C-TMS

Commodity Planning

FUNCTIONAL SPECIFICATION - 10.7

21/10/2011 - 3.0
Reference: FS 291364 - MS8KNGX5

Client Requirement

Order header changed to store commodity, this information then needs to be displayed in the order well in the trip manipulation form, carrier trip planning and Execution screens. The product type description is also required to be displayed in the carrier trip planning and trip planning screens.

Benefits identified as a result of the change:

Ability to plan NR orders by commodity

Solution

Note on Terminology:

The commodity referred to in the NR business will be stored in the existing 12 character field PRODUCT_TYPE. PRODUCT_TYPE has a 35 character PRODUCT_DESCRIPTION. This means, for example, a PRODUCT_TYPE of ‘SERVICEM’ could be created with PRODUCT_DESCRIPTION ‘Service Materials’.

The product codes will be stored in the 20 character field ITEM_IDENTIFIER and the description of the product will be stored in the 122 character field ITEM_DESCRIPTION. This means, for example, an ITEM_IDENTIFIER ‘S057/068117/0004’ could be captured for an order with ITEM_DESCRIPTION ‘SLEEPER SERVICEABLE F40 CONCRETE SIDING’

Orders:

A 12 character alpha-numeric column PRODUCT_TYPE (commodity) will be added to the Order Header table. This column will be used to store the product type of the lines of the order. Usually a transport order will only be for one product type and this product type will then be saved in the new field on the order header. If there are multiple order lines with different product types, the new field on the order header will be set to ‘MIXED’. The function to set the PRODUCT_TYPE in the order header will be triggered automatically on insert, update or deletion of order lines. This will cover all methods of input, EDI, CSV and manual entry and amend of orders. This functionality must be controlled by a Cost Centre Parameter.

Resources:

The Carrier Lane Table in Resources will be modified to include COST_CENTRE and VEHICLE_TYPE. The form will be modified to allow Lanes to be defined for a specific COST_CENTRE and for a specific VEHICLE_TYPE. The lanes selection in Carrier Trip planning will be modified to only consider Lanes for the user’s COST_CENTRE and for the requested VEHICLE_TYPE.

(Note – There is no requirement to define Carrier Lanes by PRODUCT_TYPE (commodity) but the business might want to consider this as a future enhancement)

Execution Screen:

The PRODUCT_TYPE (commodity) column from the order header will be included into the configurable layout function. This will allow the column to be displayed in the orders panel of the form. A filter will be added for the PRODUCT_TYPE (commodity) in the heading of the form.

Trip Planning/Trip Manipulation:

The PRODUCT_TYPE (commodity) column from the order header will be included into the configurable layout function. This will allow the column to be displayed in the order well section of the screen (bottom panel of the form). A new filter for PRODUCT_TYPE (commodity) will be included in the Order Filter popup. Note that the PRODUCT_TYPE (commodity) filter will allow UNSCHEDULED or SCHED_COLL status orders in the order well to be selected; The filter will allow more than one commodity type to be selected The filter will not function on trips in the trip list.

Carrier Trip Planning:

The new PRODUCT_TYPE (commodity) column from the order header will be included in the main carrier trip planning screen. This will be included in the configurable layout and have a button at the top of the column to allow sorting by this column. The PRODUCT_TYPE (commodity) will also be included in the filters at the top of the screen. The filter will allow more than one commodity to be selected.

When viewing orders and trips, only the records appropriate to the User’s COST_CENTRE will be displayed. When selecting a carrier, only the lanes appropriate to the User’s COST_CENTRE will be displayed.

As trips are briefed using the combine and brief or single and brief functions, currently the method of sending the driver’s manifest is automated to email or Fax depending on carrier and message configuration. A system parameter will be included and this function developed so that for NR, the planner will be requested to choose the method from fax, email, print or Microlise. If a fax number or email address is known for the Carrier from Message Maintenance, these values will default for the planner to then confirm before sending. Otherwise, the planner will be required to key in the number or address as appropriate and these values will be saved in Message Maintenance as a default for the next trip briefed to the same carrier.

The costing functionality in the carrier Trip Planning is based on entry of cost per tonne. A Cost Centre Level parameter will be introduced to allow this to function at total net cost for NR. In other words, spot rate override will be entered as a total net cost not a cost per tonne.

Note that where cost is derived from a rate card, the system needs to know the vehicle type. This means VEHICLE_TYPE will be added to the lanes table as mentioned above. If the order is provided with a required vehicle from EDI or CSV upload, this will ‘drive’ the costing calculation. The planner will be able to select a vehicle type in the carrier selection if this information is not already available from the order.

Product Description:

The product codes will be stored in the ITEM_IDENTIFIER field and the product description stored in the ITEM_DESCRIPTION of order items.

There is no requirement to display the product codes and descriptions in the planning screens. The planner will drill through to the order items from the order well or from the stop activity to see the product code and product description of the order.

The changes described above are designed to allow planners to work on specific commodities by display and filter of the PRODUCT_TYPE field in C-TMS. It is understood there are approximately 30 different product types covering several hundred product codes for the Heavy business.

Scope

This change will be applied to system version 10.7 on INDTST and once approved INDPRD.

Set-up

Pre-requisites

None

Menu Structure

Unchanged

Data

A new PRODUCT_TYPE column will be added to the SCH_ORD table.

The VEHICLE_TYPE and COST_CENTRE_NAME columns will be added to the RTE_HAULIER_LANE table.

The ‘Cost Centre’ field will need to be added to the ‘Import Maintenance’ column list for the ‘Carrier_Lane’ record type.

Functional Description

Business Data

A new PRODUCT_TYPE column will be added to the SCH_ORD table.

This will allow the user to select orders by PRODUCT_TYPE if an order only contains a single value. In addition, the TRAILER_TYPE and COST_CENTRE_NAME columns will be added to the RTE_HAULIER_LANE table.

Order level Trigger

The Order level database trigger will be altered so that whenever an order is updated, the Product Type (e.g. Commodity code such as ‘SERVICEM’) against the SCH_ORD record will be recalculated. This will be done by calling a new package to check the number of different PRODUCT_TYPE values that exist on the SCH_ORDER_LINE records for the order in question. If only one exists then the Product Type will be set as the same value. If there are multiple values, then the Product Type will be set as ‘MIXED’.

Resources Screen

This screen will be altered to display the TRAILER_TYPE and ‘Cost Centre’ columns mentioned above in the ‘Carrier Lanes’ tab.

The fields will be labelled ‘Cost Centre’ and ‘Trailer Type’ and will be added to the end of the cluster by default. The column will include a button at the top to allow the data to be sorted by either COST_CENTRE or TRAILER_TYPE.

The filters at the top of the screen will be altered to include ‘Trailer Type’ as a new selection criterion. The possible values for the drop-down list to filter by will be generated by listing all of the possible Trailer Types the user is able to view.

The ‘Refresh’ button will be altered to filter by the Trailer Types the user enters as part of their selection criteria. In addition, it will be changed to select records that belong to cost centres that the user in question is able to view (or records that have blank cost centres).

The screen will also be changed to populate the Cost Centre Code with the value that the user enters whenever a new record is created.

Imports Maintenance

The list of available columns for import for the inbound ‘Carrier Lane’ upload process will be increased to include the ‘Cost Centre’ field. The user will be expected to include the value for the Cost Centre whenever a new csv file is uploaded for carrier lanes. The existing carrier lanes will have to be updated to reflect the correct cost centre and any existing imports would need the cost centre parameter added.

Execution

This screen will be altered to display the new order level ‘Product Type’ column in the right-hand side of the form against the order details. The PRODUCT_TYPE column will also be added to the list of configurable items when the user chooses the ‘Configure Layout’ option.

In addition, a filter will be added to the top of the screen to allow the user to filter records by ‘Product Type’. Multiple Product types can be selected each product type will have a list of available values to filter by will be generated by selecting from the PRD_PRODUCT_TYPE table which is displayed in the ‘Product Type’ tab of the ‘Product Maintenance’ form. The option of ‘MIXED’ should also be added to the List of Values.

Trip Planning/Trip Manipulation

In similar fashion to the Execution screen, the ’Trip Planning’ screen will be altered to include the ‘Product Type’ field in the order level cluster on the left hand side for the Trip ‘Planning Screen’ and the bottom of the ‘Trip Manipulation’ screen. When the user chooses the ‘Configure Layout’ option, the ‘Product Type’ will also appear as one of the fields available for display. If the user presses the ‘Order Filter’ button in either of the two screens, the ‘Product Type’ will appear as an additional option. This is expected to appear below the current ‘Order Status’ option.

Contracts

A new function will be developed similar to the existing GET_RATE that will pass in the Trailer Type assigned to the trip in question. This will search for a contract setup between the Cost Centre and Carrier Code that applies to the Trailer Type passed in. If a trailer-type specific contract is not found, then the function will return the same value as the current GET_RATE procedure. The GET_RATE procedure identifies the correct contract for the cost centre/carrier combination. This information is then used to identify the correct rate/tariff that should be applied to the trip, For the new functionality the contract will be identified by carrier and cost centre but will also use the trailer type to identify the correct rate/tariff.

Carrier Trip Planning

In the initial order level canvas in the screen, the new ‘Product Type’ column will be added for display. A button will be added to the top of the column to allow the data to be sorted by ‘Product Type’. The column will be added to the list of available columns when the user right-clicks and chooses ‘Configure Layout’.

The ‘Product Type’ will also be added to the list of filters at the top of the screen. The possible values for the list will be the same as for the Execution screen mentioned above. Multiple product types can be selected.

The screen will be changed so that only orders and trips are listed that match the Cost Centre(s) the user is able to view. The screen will also be changed to match the Cost Centre when searching for appropriate Carrier Lane records to match the order number selected.

In addition, the ‘Total Cost’ field in the Carrier level cluster will be displayed by calling the new function in the Contracts package described in the last section. This will be based on a new cost centre level parameter ‘TRIP_CHARGING_METHOD’. If this parameter is set to ‘F’ for ‘Fixed’ then the ‘Total Cost’ will be displayed using the new function described in the last section. Otherwise it will be displayed as now.

The current ‘Cost/Tonne’ field will not be displayed at the top of the screen if the LANE_CHARGING_METHOD’ is set to ‘F’. Instead, a ‘Payments’ button will be displayed and the user will be prompted to create a one-off manual fixed payment for the trip. This will work in similar fashion to the ‘Fast Payment’ option called from the Execution screen: When the button is selected a new popup window will be displayed and example is shown below this will then be used to enter the payment information.

The Save button will then create the payment using the ACC package the cancel button will close the window without saving any changes.

In addition, when a trip is briefed (via either the ‘Single’ or ‘Combine’ functions), the form will be changed to prompt the user for a method of notification for sending the driver’s manifest to the carrier. If the carrier assigned to the trip has fax or email details stored they will be displayed to the user the details can then updated if required. If no details are found the user will be able to choose from ‘Fax’, ‘Email’ or ‘Print’. For email, they will be prompted for a valid email address and for fax they will be prompted for a valid fax number. This will also be required when the user chooses to re-brief a trip and the carrier manifest is reproduced at this point.

Once the user has chosen an option for a carrier code, the details of the fax number or email address will be updated in the database then when the next trip is briefed or re-briefed using the same carrier the form will use these details as a default. However, it will be possible to modify this default setting by changing the record for the Carrier in the Message Maintenance screen.

Table Updates Required

[[Image:]][[Image:]]

[[Image:]][[Image:]]

Modules to be changed

Module Name	Module Type	Notes
IMP.sql	Package	Add cost centre to lanes
RESOURCE.fmb	Form	Add details to lanes
HAUL_TRIP_PLAN.fmb	Form	Add new functionality
TRIP_PLAN.fmb	Form	Add new fields to order well
TRIPSUM.fmb	Form	Add new fields to order well
TRIPSUM_JRL	Form	Add new fields to order well
EXECUTION	Form	Add new fields to order well
CNT.sql	Package	Add new functionality

References

Ref No	Document Title & ID	Version	Date
1	EST-291364 – MS-8KNGX5Commodity Planning	1.0	23/09/11

Glossary

Term or Acronym	Meaning
C-TMS	Calidus TMS

Document History

Version	Date	Status	Reason	Initials
0.1	4/10/11	Draft	Initial version	RE
0.2	05/10/11	Draft	Reviewed	MJC
0.3	06/10/11	Draft	Revised	CAK
1.0	11/10/11	Issue	Reviewed and Issued	MJC
2.0	11/10/11	Issue	Fixed Total Days	MJC
2.1	21/10/11	Draft	Revised after review by S Allen	CAK
3.0	21/10/11	Draft	Reviewed, left tracking on to allow ease of visibility of changes to be cleared before posting to RIO	MJC

AUTHORISED BY

Matt Crisford	Development Manager
Peter Greer	TMSCC MTS Product Manager