291358
DHL C-TMS
Order Addresses, DU & Del Type
FUNCTIONAL SPECIFICATION - 10.7
27/10/11 - 4.0
Reference: FS 291358 MS-8KNFRL
FUNCTIONAL OVERVIEW
Client Requirement
Create child address and association with NR node MSP on orders for final delivery location. Order stores collection location, NR Node MSP main address location and full delivery location. Capture NR cost code (as additional reference) for each order (all orders except non Heavy have to carry a NR cost centre to support finance reporting). Include weight for commodity product DU Type and calculate weight of order for planning.
Include product weight for commodity product DU Type and calculate weight of order for planning.
Derive the order delivery type based on lead time order received to collection date. Maintain delivery type rules as master data to allow C-TMS to automatically set as Emergency, Next Day , Normal based on lead time.
Extend Locations view in order to display contact name.
Function to split orders. Copy from original to make x new orders and set unit qty on each.
Interface and order maintenance must allow length to be defined and this length value to be visible in order well. Needed to differentiate rail lengths ordered and loading compatibility.
Additional status to set orders to On-HOLD. This disables the order from planning.
Required vehicle type will be necessary as an attribute of order. This required vehicle type will need to show on the order well for planners to see and assign the necessary equipment.
Solution
Addresses
Please see 291356 MS-8KNFBJ RIO: 1 - Order EDI & Order Quarantine for more details regarding changes for parent and child addresses to facilitate milk-round planning for DISC non Heavy orders. For Heavy orders (all non-Heavy accounts, the NR cost centre code will be captured using the Additional References functionality in C-TMS.
Product Weights
The Product Item table will be used to store the weight for a commodity / DU type. Alterations will be needed to store the DU type against this table and for the information to be used within the Order CSV and XML uploads and Manual Order Entry. The weight of the Order Item and the weight of the corresponding DU order line will be calculated based on weight for each unit quantity of product held in master data. The CSV import process will be enhanced for item weights to be calculated.
Delivery Types
The Delivery Type will be one of Emergency, Next Day or Standard C-TMS will be modified to calculate the appropriate Delivery Type based on the lead time of the order date time received to required collection date time. The rules to calculate the delivery trype are shown below. The Delivery Type drives the rating calculation, so for example Emergency is more expensive than Next Day or Standard.
The delivery types will be captured and maintained using the Schedule Rules functionality.
The Order CSV Import, Orders Manual Entry form and the XML Order Interface will be amended to use a new process to calculate delivery types. The new functionality will be controlled by a cost centre level system parameter so that when an order for the specific TMS cost centre is created, then the setting of delivery type will be controlled dynamically.
Orders Form
In addition to the above development change to the Orders Form, the Location Detail Tab (LOC Detail) will be modified to display address contacts, this will be a small scroll area containing First Name, Surname and Phone # derived from the location contacts table, this area will allow entry of new contacts. This will be applied to both the collection and delivery addresses.
Furthermore, the comments sections in both sections of the LOC Detail tab will be made larger to allow greater visibility of any address comments, again these will be development to allow insert and amendment. This information will be stored on a new table which will contain all contact information related to the locations of the order.
Split Orders
A development change is required to the Order Summary Screen to allow orders to be split on demand by the planning team. The reason for needing to split orders is where the weight or quantity of items ordered for transport exceeds the capacity of a vehicle. Only orders at UNSCHEDULED status will be allowed to be split. The user will be requested to confirm how many orders including the original to create. All the original order header details will be copied forward and each order will be rated or re-rated . The original quantities and weights will be split evenly across all the orders with any remainder amount added to the last order No order ‘merge’ functionality has been requested.
An example to illustrate the requirement is that an order could be received for 1000 sleepers that need to be split over 20 loads for planning and execution.
The external customer reference for each split will be suffixed by a numerical split sequence number. The sequence will be in the format S01, S02 etc.
Copy Orders
Orders at any status will be available to be copied. The function will allow the user to confirm how many orders including the original to generate. All the original order header, qty details and items will be copied forward and each order will be rated or re-rated.
When copying orders the collection and delivery times for the new orders must be specified before the order is copied.
All orders generated by splits or copies will be created in an UNSCHEDULED status.
The external customer reference for each copy will be suffixed by a numerical split sequence number. The sequence will be in the format C01, C02 etc.
Order Status
A new order status of ‘ON-HOLD’ will be created, this will be available from a right click menu within the Order Summary screen and the Trip Manipulation, Trip Planning and Trip Execution unscheduled order segments. The option will only be available to users that have the correct level of access (i.e. system function: Allow_Hold_Orders promoted to their user group). The new order status ‘ON-HOLD’ will also be added as an exclusion to the Trip Manipulation, Trip Planning and Trip Execution unscheduled order segments so that ON-HOLD orders will be unavailable for planning. Additional status checks will also be required when adding orders to trips to ensure ON-HOLD orders are not planned.
The Order Summary screen will allow a further right-click menu option to ‘Release from Hold’. This function will only be available for orders at ‘ON-HOLD’ status. The query panel will allow orders at ON-HOLD to be selected.
Vehicle Type
A requested Vehicle Type will be added to the Order Header section of the Orders Form. This will also be added as a configurable item on the Unscheduled Order windows in the Trip Manipulation, Trip Planning and Trip Execution Forms.
The requested vehicle type will optionally be uploaded from EDI, CSV and the field, supported by a lookup list of values, will be available to be keyed in manual order entry.
Scope
This change will be applied to system 10.7
SET-UP
Pre-Requisites
291356 MS-8KNFBJ Order EDI and Order Quarantine this RIO includes functionality for the Addresses and Vehicle Types.
Data
- A DU Type column will be added to the PRD_PRODUCT_ITEM table.
- A New cost centre bases system parameter AUTO_SET_DELIVERY_TYPES will be created.
- A New cost centre based system parameter ADDITIONAL_ORDER_VALIDATION will be created.
- A New system function ALLOW_HOLD_ORDERS will be created
- A New system function ALLOW_SPLIT_ORDERS will be created.
- A record will be inserted into the SCH_ORD_STATUS table for ON-HOLD status
- The SCH_ORD_INFORMATION table will be amended to add columns which will contain the Location comments and location contacts for the locations of an order
- The SCHEDULE_RULES table will be amended to add a Service column to contain the Delivery Type.
Implementation Advise
A system super user will be require to ensure the correct system parameters are set up
A system super user will be required to ensure the correct function access is applied
FUNCTIONAL DESCRIPTION
Product Weights
The DU type will be added to the PRD_PRODUCT_ITEM table this will then be displayed in the products form in the product items tab see below
The DU type will also be included when a record is added to the table or an existing record is amended see below
The DU Type must be validated to ensure that it exists in the RES_DESPATCH_UNIT_TYPES table. The button at the top of the DU Type column will be used to sort the data displayed by the value in this column.
A new cost centre based system parameter ADDITIONAL_ORDER_VALIDATION will be created this will control the validation of the weight of Network Rail products. The weight value entered will be used to calculate the weight of an order line and then in turn the weight of the complete order within the order imports. If no weight is entered when the record is captured or amended and the ADDITONAL_ORDER_VALIDATION parameter is set a warning message will be displayed informing the user no weight has been entered for this particular item. The user will then be able to choose if a weight should be entered or not. When importing orders in either the CSV or XML formats the parameter will be checked and if set the weight of the order line will be calculated from the kg weight and the quantity ordered.
Rules Maintenance
The Delivery type will be one of Emergency, Next Day or Standard . A new cost centre based system parameter AUTO_SET_DELIVERY_TYPES will be created to control the setting of delivery types.
Delivery Type rules will be set up using the Schedule Rules screen. An example of the current screen is shown below to illustrate rule set up, the early and late times are optional and will not be required for delivery type functionality.
The schedule rules table will be amended to add a Service level column. The schedule rules maintenance screen will be amended to allow the capture of the new service level column i.e. Emergency Next Day, Standard. A suggested layout is shown below. Viewing/amending the Service type field will be based on the AUTO_SET_DELIVERY_TYPES being set.
Upon entry to the screen the only services displayed will be for the cost centre of the current user. Services will then be created for the Network Rail Cost centre based on the following rules
- Early collection Date = Order received date before or after 16:00 delivery Type Emergency
- Days between Early collection and order received 1 current time before 16:00 delivery Type Next Day
- Days between Early collection and order received 1 current time after 16:00 delivery Type Emergency
- Days between Early collection and order received 2 current time before 16:00 delivery Type Next Day
- Days between Early collection and order received 2 current time after 16:00 delivery Type Next Day
- Days between Early collection and order received 3 current time before 16:00 delivery Type Next Day
- Days between Early collection and order received 3 current time after 16:00 delivery Type Next Day
- Days between Early collection and order received 4 current time before 16:00 delivery Type Next Day
- Days between Early collection and order received 4 current time after 16:00 delivery Type Next Day
- Any other value Delivery Type Standard
Delivery Types
When an order is received either by one of the order imports or by manual input into C-TMS the parameter will be checked, if the parameter is set to “Y” then a new method of setting the delivery type of the order will be called.
A new function will be created in the OMS package GET_DELIVERY_TYPE the function will accept the early collection time of the order and the customer as parameters and return the appropriate delivery type as a character string.
The information will then be used to derive the number of days between the current system date and the early collection date . The value returned by the calculation will then be used to obtain the value for the customer using the stored Schedule Rules information. The number of days will be stored in the offset, the cut off time for a before order will be 16:00 and for an after order will be 16:01. The cut off time should then be compared against the current time to establish which service is required. For example if the number of days between the dates is 0 the the delivery type is Emergency regardless of the current time of day. If the number of days is 1 and the current time is before 16:00 the delivery type is Next Day if the current time is after 16:00 the delivery type will be Emergency.
Orders Form
In the Location Detail tab of the orders form the details of the contact for the collection and delivery locations will be added. This will be a scrollable area containing the name and phone number details from the GEO_CONTACT table for the specified location id. A suggested layout is displayed below.
A small tabbed canvas (shown below) will be added to the end of the LOC Detail tab, this will contain the details of contacts and comments from the SCH_ORD_INFORMATION table specific to the order in question There may be more than one contact for a location and this information should be concatenated for display purposes. A suggested layout is shown below.
The information displayed is not updateable if the contact information requires change the Edit button should be selected. When the Edit button is selected a new pop window will be displayed to allow the user to add or amend the details as required. A suggested layout is shown below
There may be numerous contacts for a given order and each should be displayed and the user can add or amend the details as required. There will be three buttons on the screen
- Save will save the changes made
- Cancel will discard any changes and return to the main screen
- Exit will return to the main screen.
If the location comments are to be amended the Edit button should be selected, this will display a new window in which the user can amend the comments as required. A suggested Layout is shown below
There will be three buttons on the screen
- Save will save the changes made
- Cancel will discard any changes and return to the main screen
- Exit will return to the main screen.
Split Orders
A new facility to split orders is required which will be called from the order summary screen.
Access Control/Restrictions
A new system function ALLOW_SPLIT_ORDERS will be created and if the user has access to this function a new right click option will be displayed in the menu to invoke the split functionality see below
Only orders at unscheduled status will be allowed to be split. If an order is selected at any other status an appropriate error message will be displayed. Orders can only be selected individually for splitting.
Split Processing
Once an order has been selected and requested to be split a new popup window will be displayed asking the user to confirm the number of orders including the original to create. A suggested layout is shown below
The OMS ref will be passed from the Order Summary screen and will not be modifiable.
The No of Orders must be a numeric field indicating the total number of orders required including the original. If the number of orders field is omitted when the process button is selected an error will be displayed. If the number of orders field is greater than the total order qty an appropriate error will be displayed.
The screen will contain 3 buttons
- Process – this will validate the information entered and call the OMS.SPLIT_ORDER function passing in the relevant information. If the process is successful and the function returns true, an information message should be displayed informing the user the order split has been successful. If the function returns false the split was unsuccessful and the error returned from the function should be displayed back to the user to inform them of the issue.
- Cancel will return to the order summary screen and discard any information the user has keyed in.
- Exit will close the popup window.
As mentioned above the new process will prompt the user for the number of orders the original order should be split into. It will then evenly split the quantities and weights on the original order including details from the order lines (DU level) and order items (SKU/Pallet Level) across all of the orders including the original. For example if the original order has a quantity of 202 and the split function is required to make 10 orders including the original the first nine orders would have a quantity of 20 and the tenth a quantity of 22. All orders will be validated and rated as they are created
Each new order created will be given a new OMS ref and the EXTERNAL_REF of the original order will be carried forward and updated each time to add a numeric suffix e.g. EXTREF_S01 , EXTREF_S02 etc. All new orders will be created at UNSCHEDULED status.
This process will be repeated until all the required orders have been completed. If any orders fail the validation or rating process all changes will be discarded and the function should return an error message which will be displayed to advise the user of the issue. If no errors are found the function will continue and confirm the split process was successful.
Copy Orders
A new facility to copy orders is required which will be called from the order summary screen. A new function will be added to the OMS package titled DUPLICATE_ORDER which will accept an OMS ref ,number of orders and collection and delivery time information as parameters and return a TRUE or FALSE value and an error message if needed.
The original order will remain unchanged by the copy.
The order will be copied the specified number of times. Each new order will be given a new OMS reference and the EXTERNAL_REF of the order will be updated each time to add a numeric suffix e.g. EXTREF_C01, EXTREF_C02 etc e.g. if the original customer ref was ABCDEFG then the copied orders would have ABCDEFG_C1, ABCDEFG_C2 all new orders will be created at UNSCHEDULED status. The collection and delivery time information passed in as parameters will be used to populate the relevant fields on the new orders.
Once an order has been created the validate order function will be called for the new order to validate and rate the order. This process will be repeated until all the required orders have been created. If any orders fail the validation or rating process all the changes should be discarded and the function should return FALSE and an error message included which can be displayed to advise the user of the issue. If no errors are found the function should return a TRUE value.
A new system function ALLOW_SPLIT_ORDERS will be created and if the user has access to this function a new right click option will be displayed in the menu to invoke the copy functionality see below.
Orders at any status can be selected for copying. Once the copy order item is selected a new popup window will be displayed to confirm the number of copies required and the collection and delivery windows. A suggested layout is shown below
The OMS ref will be passed from the calling screen and can not be updated. The number of orders indicates the total copies (including the original) required. The collection and delivery times must be populated and these will be used to update the collection and delivery windows on the new orders. The number of orders is a numeric field and must be entered. if any of the fields are omitted when the process button is selected an error should be displayed.
The screen will contain 3 buttons
- Process – this will validate the information entered and call the OMS.DUPLICATE_ORDER function passing in the relevant information. If the process is successful and the function returns true, an information message should be displayed informing the user the order copy has been successful. If the function returns false the copy was unsuccessful and the error returned from the function should be displayed back to the user to inform them of the issue.
- Cancel will return to the order summary screen and discard any information the user has keyed in.
- Exit will close the popup window.
Order Status
A new order status of ON-HOLD will be introduced this will prevent any orders at this status being planned onto a trip. The function CHANGE_STATUS in the OMS package will be amended to include the new ON-HOLD status only orders currently at INVALID or UNSCHEDULED can be set to ON-HOLD. Additionally the function will be amended to allow orders currently at ON-HOLD to be set to UNSCHEDULED.
The order summary screen will be amended to add an additional item “Set Order to On Hold” to the current right click menu
A new system function will be created called: ALLOW_HOLD_ORDERS and only users with access to this function will be allowed to set orders to On Hold. If the current user does not have this function access the menu option should not available for selection. Only UNSCHEDULED or INVALID orders can be set to a status of On Hold.
When the menu option is selected a message should be displayed asking the user to confirm the status change. When confirmation is received the OMS.CHANGE_STATUS function should be called passing the required OMS_REF and a status of ON-HOLD. If the function can not change the status an appropriate error should be displayed to the user.
An additional item “Release from Hold” will also be added to the menu, access to this functionality will be controlled by access to the ALLOW_HOLD_ORDERS system function. Only orders currently at On Hold status are valid to be selected for this action, if an order is selected at any other status an error message should be displayed. When a valid order is selected a message should be displayed asking the user to confirm the status change. When confirmation is received the OMS.CHANGE_STATUS should be called passing the required OMS_REF and a status of UNSCHEDULED. If the function can not change the status an appropriate error should be displayed to the user. The option to set an Order to On Hold should also be added to the right click menu in the order well of the Trip Planning, Trip Manipulation and Execution screens an example of Trip Planning is shown below the Trip Manipulation and Execution screens will have a similar menu.
The access should be controlled in the same way and the functionality processed in the same way as for the orders screen. Orders at ON HOLD status can not be planned on to a trip and once an order is set to this status it should no longer be available in the order well. The TRM package will be amended to not allow orders at ON-HOLD status to be added to a trip.
Vehicle Type
The vehicle will be loaded if present by the CSV and XML uploads. It can also be manually keyed using the orders form. If entered using the orders form the value should be selected form a list built from the RES_TRAILER_TYPE table. A suggested layout is shown below.
The vehicle type will also be added to the configurable layout in the order well of the Trip Planning, Trip Manipulation and Execution forms. As with all other fields in the configurable layout it is a display only field. An example of the configurable layout in Trip Planning is shown below, the Trip Manipulation and Execution screens will have similar functionality and will need to be changed accordingly.
REFERENCES
| EST-291358 MS-8KNFRL Order Addresses DU and Del Type |
DOCUMENT HISTORY
| Initial version | ||||
| Reviewed | ||||
| Revised | ||||
| Revised | ||||
| Revised | ||||
| Reviewed and Issued | ||||
| Create table changed to Alter table | ||||
| Changes after review by S Allen | ||||
| Reviewed and Issued | ||||
| Revised | ||||
| Reviewed and Issued | ||||
| Revised | ||||
| Reviewed and Issued |
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
