291356

DHL C-TMS

Order EDI & Order Quarantine

FUNCTIONAL SPECIFICATION - 10.7

21/10/11 - 3.0
Reference: FS 291356 MS-8KNFBJ

FUNCTIONAL OVERVIEW

Client Requirement

Consulting on message formats and implementation support. Scope covers DISC order flow and implementation of flow from spreadsheet input via DHL Link. All orders that fail validation in EDI will be available to be viewed and changed / corrected in interface errors. A reload function will be developed to allow orders to be re-validated and loaded into the order well.

Orders to be processed via DHL Link, or form a CSV file. Development of new Order correction facility to allow the correction and re-loading of new orders.

Solution

EDI Orders import (non Heavy):

Non Heavy Orders from DISC WMS will be received in an XML format file transferred and mapped via DHL Link. The orders will be presented to C-TMS in the OBSL TripOrder XML schema format.

The interface will be developed to allow the milk-round day and route code to be uploaded into C-TMS from DISC.

This order interface will provide orders for C-TMS once shipments have been picked and packed in DISC and the interface will contain the LPN pallet numbers for each product. The LPN number is an important update because this drives the final revenue calculation for the transport service charged to NR. The LPN numbers will need to be stored and displayed against the order item lines in C-TMS.

Although a requirement for Heavy orders which will be uploaded into C-TMS using the CSV import functionality, for completeness, the EDI flow will be modified to allow a requested vehicle type to be optionally interfaced. This will be satisfied by extending the OBSL XML schema to allow a vehicle type to be included at order header.

The C-TMS interface processing will be modified to created locations as ‘child’ addresses of the master MSP (Material Supply Point). This function covers the scenario where a delivery location is provided in the interface to the known main MSP code (node) but the address varies. Operationally, the driver might actually drop the delivery some miles away from the main MSP and this has to be catered for in terms of storing the actual delivery address down to postcode and association with the MSP. The location codes for the MSP addresses will be setup in C-TMS as for example NR_UG. The UG value defines the specific MSP. Child addresses created from the through the interface will be coded using the same master MSP code suffixed with a sequence number, for example NR_UG/00001.

Note that the master location code provided in the interface will be used to derive the appropriate delivery drop on the milk-round day and route, for example NR_UG. The suffix address will be used as the delivery address of the order and a stop for this will be generated in the milk-round trip. It is possible that, for example, 3 deliveries to NR_UG are provided as orders through the interface and if these all have different addresses, then 3 distinct DL stops will be generated into the milk-round trip.

DISC WMS will not create duplicate orders (amendments) through the interface to C-TMS. An order can be released from DISC to C-TMS over a number of days or weeks and these orders will have the same customer reference which will be stored in the Customer Ref field in C-TMS but will contain a different shipment number each time which will be stored in the Del Point Ref field in C-TMS.

To allow this processing a new EDI parameter (DUPLICATE_SHIPMENTS_ALLOWED) will be created within the EDI flow. If an order fails validation as a duplicate (Customer Reference already exists in C-TMS) and this parameter is set to ‘Y’ a further check will be made to ensure that the Del Point Ref field on the stored order is not the same as the shipment number on the interface record. If this check fails i.e. a duplicate is found the interface order will be rejected and processing will continue to the next order on the file. Otherwise, for these subsequent shipments against the original customer order, C-TMS will generate a numeric suffix to uniquely identify the order and store this against the Customer Ref in C-TMS ; the original Customer Ref will not have a suffix, then the subsequent shipment will be suffixed /02 then /03 and so on.

When order items are created the ITEM_IDENTIFIER (product code) will be validated to ensure that it exists in the PRD_PRODUCT_ITEM table (this table will be the product code master list maintained in C-TMS) and that the PRODUCT_TYPE and DU_TYPE for this item are correct for the order line record. This validation will depend an a new parameter setting against the customer account in C-TMS. For non Heavy orders interfaced from DISC, the product codes will be stored on the order but not validated against a master list. The Product Master list will be used to validate Heavy orders.

All other interface checks and validation will be performed as normal and any failures highlighted in the transactions in the interface errors screens.

Once the order is successfully loaded the PRODUCT_TYPE (commodity) will be updated on the order header according to the order lines. For non-Heavy, it is assumed that all orders will be received with product type AMBIENT.

When the EDI upload process for DISC orders completes, C-TMS will the auto-plan the order to the appropriate milk-round. A new system parameter will be included to support this development called OMS_ADD_ORDER_TO_MILK. A new field will be added to CUSTOMERS so that the non-Heavy account can be flagged for auto-planning.

Orders Length:

There is a requirement to capture and store a length value on the order line of an order optionally. This is to satisfy a requirement for Rails. The planner needs to have an understanding of the rail lengths ordered as there are some constraints in planning certain different lengths together on one vehicle. The orders screen has the ability to flip the volume field by click to a field called footprint on the form. This footprint field will be used to store the length value and the label will be configured for NR to be Length. This information will be made available for Heavy orders through the CSV upload.

Order correction from Interface Errors:

Orders that fail interface validation and so are not uploaded into C-TMS can be viewed in the Interface Errors XML Orders tab; this tab page will be modified to include a button titled Correct Errors and a button titled Re-Process.

These buttons will be displayed depending on the value of a new EDI flow based system parameter. When this Correct Errors button is selected, the user will highlight the order containing the errors they wish to correct by mouse click to bring the specific row into focus. Once this button is selected the form will navigate to a new screen which will display all errors for the selected order and order line and order items. The user will then be able to selectively overtype the fields with new values. The new values entry will be supported by list of values against master data where appropriate. The new values will be validated immediately and only valid new entries will be saved. Once the user has completed any changes necessary, the changes screen will be closed and the user can then select the reprocess button to upload the order into C-TMS.

Note that it will be possible to re-process orders that have failed in the interface to cover the scenario where for example the resolution to the problem was to add in additional master data, for example the order interfaced was for a DU type that was unknown to C-TMS.

CSV Import:

Heavy (and Ad-hoc etc.) orders will be uploaded into C-TMS using the CSV imports functionality. Orders placed and authorised in the DHL provided web order portal will also be uploaded into C-TMS using the same functionality.

The CSV import functionality relies on a template being maintained in C-TMS master data that describes the data in each column of the presented CSV for upload. Many different variations of template can be created, each named separately, to allow differently formatted CSV formats to be uploaded. Ideally though, the order data received by DHL Control Tower should be presented to C-TMS in a consistent format regardless of source.

The CSV import functionality for orders will be developed and enhanced to allow the following additional capabilities;

The CSV file will include values to define the order header, order line and order item.

The child location processing described above for EDI needs to be managed and processed consistently for data uploaded from CSV imports.

The CSV file import will provide new fields to allow the NR cost-centre and the requested vehicle type to be uploaded into C-TMS. The NR cost centre will be stored as an additional reference for the order. The CSV upload will be modified to write to the Additional References tab in orders for this data. The requested vehicle will saved in a new field added to the order header in C-TMS and will be made visible in the order detail screen and the planning screens.

The CSV import function will also be modified to process the subsequent shipments and customer reference suffix and duplication checking as described above for EDI.

When orders are uploaded using the CSV import function, the PRODUCT_TYPE (commodity) of the order lines will be updated against the order header.

Note that standard error checking and validation will be used to upload CSV order files into C-TMS. Any failures are notified and a failures CSV file created of the invalid records. The failures CSV file can be reworked on the user desktop and re-submitted to C-TMS.

Scope

This change will be applied to system version 10.7.0

SET-UP

Pre-Requisites

MS-8KNH8N Milk Round Routes

MS-8KNFRL Order Addresses & DU & Del Type

Implementation Advice

The EDI maintenance screen will be used to define the new Orders EDI flow for Network rail.

The super user who sets up the EDI flow will be responsible for assigning the following four parameter records, all set to Y.

A super user will be responsible for setting the values of two new cost centre parameters called OMS_ADD_ORDER_TO_MILK and ORD_LINE_LENGTH. The parameter values will be set in the System Parameter Maintenance screen as displayed below.

FUNCTIONAL DESCRIPTION

Non Heavy Order records will be received from DISC to be loaded into C-TMS. Non Heavy orders will be received in XML format, transferred and mapped via DHL Link. Heavy orders will be received via manual CSV import. Orders will be identified as Heavy and Non-Heavy from the CUSTOMER stored on the order header.

New Order Information

There is a requirement for new fields to be created at Order Header and Line. The interface schema file (XSD) will be amended to include the following new fields specifically for Network Rail and fields will be created in the relevant order tables (see 291358 MS-AKNFRL Order Addresses and Du and Del Type):

To process the new fields added to the interface schema, additional corresponding new fields will be added to the Interface control tables:

Order Header Control Table

The route code and route day will be received in one field in the interface files, ORDER_HEADER_TMS.ROUTE_CODE. Part of the interface process will be to extract the data for each and populate in the separate interface fields ROUTE_DAY and ROUTE_CODE.

The orders comments and contacts will relate to the order FROM_LOC or TO_LOC locations. When comments and contacts are received the data will be written to a new SCH_ORD_INFORMATION table keyed by the OMS_REF and LOCATION_ID.

Order Details Control Table

For non Heavy orders, the order interface file will be processed and generated from DISC once product is picked and packed. The interface file will allow the pallet numbers (LPN) to be saved against order lines as the order is initially created in C-TMS. Note one large order could be packed to many pallets so many LPN per order. Many small orders can be packed to one pallet.

Order Contracts Control Table

The value of the address_contact_type can be O or L in the interface. This value will indicate where the comment and contact details should be stored. If the type is set to L, the contact information will be processed as usual and added to the master location record. If the type is set to O, the contact level information (forename, surname, number, email, job) will be loaded into the new SCH_ORD_INFORMATION table with the OMS_REF and LOCATION_ID. This new feature allows comments and contacts to be stored against an order for the either the collection location or delivery location or both.

Comment and contact records will be populated in the following format on the new SCH_ORD_INFORMATION table:

Order Tasks Control Table

The TASK_NAME will identify the type of order tasks that are being sent through the interface. For Network Rail, the task name will be set to SERVICES and the data will be mapped to the SCH_ORD_SERVICES table.

Locations

The interface will be amended to process child addresses sent in from DISC. A child address will be identified as having the same location id as the parent address (MSP) but the address details will be different.

An example of the Parent (MSP) / Child data sent in XML

The parent (MSP) and child records will be uploaded from DISC via the XML interface with the same Location id. There are three checks that the system will perform before the location is processed and saved to the C-TMS database:

C-TMS will first establish if the location id already exists in C-TMS. Where a location does not exist, it will be created based on the existing EDI parameter CREATE_UNKNOWN_LOCS.

Where the location already exists in C-TMS, based on the new EDI parameter CHILD_LOCATIONS, C-TMS will be required to identify whether the location details in the XML file differ from the parent location details stored on C-TMS.

If the details are the same, then the order is to be delivered to the parent location.

Where the details differ, the order is to be delivered to a child location which must be created in C-TMS. However, the system must first check if the child location has previously been created in C-TMS. Where the child location has been created, the location id on the delivery location will be updated to the child location id.

Child locations will be created with location ids which are based on the parent location id. In the data example above, the child location will be created with the location id NR_MK/000001. The next time a child location is received for NR_MK, it will be created as NR_MK/000002.

All child records will be created based on the location id of the parent record followed by a sequence. The sequence will be incremented per parent location