291356 - Revision history

Middletong: /* Consolidation at Delivery Stop */

2012-10-16T14:53:44Z

Consolidation at Delivery Stop

← Older revision		Revision as of 16:53, 16 October 2012
Line 352:		Line 352:

	In the example above the revenue should be apportioned to orders 12345 and 67891, as these are the only orders which have chargeable pallets. The rating should be applied as follows:		In the example above the revenue should be apportioned to orders 12345 and 67891, as these are the only orders which have chargeable pallets. The rating should be applied as follows:

			[[Image:291356_24.png]]

			Currently, the system will error if an order on a shipment returns 0, code must be added to the rating engine to allow orders with non chargeable lines to return 0.

			==General Addition Points==

			Note that the CSV upload format will allow NR cost centre to be uploaded into order additional references and will also allow the required / requested vehicle type to be uploaded into the order header.

			The Web Portal Order entry application will provide a CSV format file that will be manually uploaded into C-TMS and this will take the same format as the Heavy Order CSV upload described above.


			=REFERENCES=

			{\| Border="1"
			\| <center>'''Ref No'''</center>
			\| <center>'''Document Title & ID'''</center>
			\| <center>'''Version'''</center>
			\| <center>'''Date'''</center>

			\|-
			\| <center>1</center>
			\| EST 291356 MS-8KNFBJ-Order EDI and Order Quarantine
			\| <center>1.0</center>
			\| <center>23/09/11</center>
			\|}


			=DOCUMENT HISTORY=

			{\| Border="1"
			\| <center>'''Version'''</center>
			\| <center>'''Date'''</center>
			\| <center>'''Status'''</center>
			\| <center>'''Reason'''</center>
			\| <center>'''Initials'''</center>

			\|-
			\| <center>0.1</center>
			\| <center>11/10/11</center>
			\| <center>Draft</center>
			\| Initial version
			\| <center>SEW</center>

			\|-
			\| <center>1.0</center>
			\| <center>13/10/11</center>
			\| <center>Issue</center>
			\| Reviewed and Issued
			\| <center>DJM</center>

			\|-
			\| <center>1.1</center>
			\| <center>14/10/11</center>
			\| <center>Draft</center>
			\| Changes made following referral
			\| <center>SEW</center>

			\|-
			\| <center>2.0</center>
			\| <center>14/10/11</center>
			\| <center>Issue</center>
			\| Reviewed and Issued
			\| <center>MJC</center>

			\|-
			\| <center>2.1</center>
			\| <center>20/10/11</center>
			\| <center>Draft</center>
			\| Revised
			\| <center>SEW</center>

			\|-
			\| <center>3.0</center>
			\| <center>21/10/11</center>
			\| <center>Issue</center>
			\| Reviewed and Issued
			\| <center>MJC</center>
			\|}


			=AUTHORISED BY=



			{\| Border="1"
			\| '''''Matt Crisford'''''
			\| Development Manager
			\|

			\|-
			\| '''''Peter Greer'''''
			\| TMSCC MTS Product Manager
			\|

			\|}

Middletong: /* CSV Import */

2012-10-16T14:27:25Z

CSV Import

← Older revision		Revision as of 16:27, 16 October 2012
Line 313:		Line 313:

	[[Image:291356_22.png]]		[[Image:291356_22.png]]

			==LPN Order Update via EDI==

			The order interface will send an order to C-TMS once as a shipment is picked and packed in DISC. There will no update / amend flow.

			Each non Heavy order will be created in C-TMS and an order item record will be created for each product code and pallet Id combination.

			Uploading the data in this format means;

			*Order items within an order could have a repeating product code (item_identifier) each with a different pallet Id – relevant for pallet picks in DISC.

			*Order Items within an order could be associated with the same pallet Id – relevant for part picks to same pallet

			*A pallet Id could feature on item lines across a number of order – relevant where small orders are picked to a single pallet.

			Any combination of these order line configurations can be possible for an order uploaded into C-TMS from DISC.

			C-TMS will automatically create an order line to define the media and qty. Two DU types will be used to define media, namely ‘PALLET Chargeable’ and ‘PALLET non-Chargeable’ and these will be defined as parameter attributes against the customer (Non Heavy).

			C-TMS will count the distinct pallet Ids within the order item lines and create a PALLET Chargeable DU order line for the qty. If the pallet Id has already been included in a PALLET Chargeable qty on another order, C-TMS will create a PALLET non-Chargeable DU order line and set the qty accordingly – usually 1 but could be more than 1.

			For these order lines for non Heavy customer, the product type will always be set to AMBIENT and default this value from the order item records uploaded from the DISC interface.

			The rating engine will be configured to only rate for PALLET Chargeable DU type on order lines.

			Note that by comparison, for Heavy orders, the CSV upload format will allow order lines in orders to be generated with a specific product type (corresponding to the commodity) and the DU type will default automatically according to the product type. As an example, the product type provided in the interface might be ‘SLEEPSTL’ meaning ‘Sleepers Steel’ and the default DU associated might be ‘SLEEPER’. The CSV upload format will then allow the order item line to be generated with a specific product code that will be validated against product master data. As an example the product code might be ‘0057/068567/001’ with an item description of ‘SLEEPER/Steel Sleeper W560 UTX-S 113a’

			==Consolidation at Delivery Stop==

			Orders will be consolidated at delivery stop and re-rated based on the combined quantities. Network Rail rate orders by lines to capture chargeable and non-chargeable pallets. Currently the system consolidates orders at header level and new functionality will be required to rate orders by line level. When consolidating a group of orders for delivery, the system will refer to the orders as a shipment.

			Two new procedures will be created in the Rating engine to firstly calculate the quantities per du type in the shipment, then to rate the shipment and apportion the revenue back to the orders in the shipment.
			An example of the how the new consolidation must work is described below:

			[[Image:291356_23.png]]

			has been returned, this must be apportioned back to the relevant orders. The relevant orders are identified as those orders that have contributed to the rate.

			In the example above the revenue should be apportioned to orders 12345 and 67891, as these are the only orders which have chargeable pallets. The rating should be applied as follows:

Middletong: /* CSV Import */

2012-10-16T14:23:33Z

CSV Import

← Older revision		Revision as of 16:23, 16 October 2012
Line 309:		Line 309:

	In addition to the new fields added to the database being available to import to, the following fields will also be available		In addition to the new fields added to the database being available to import to, the following fields will also be available

			[[Image:291356_21.png]]

			[[Image:291356_22.png]]

Middletong: /* CSV Import */

2012-10-16T14:20:13Z

CSV Import

← Older revision		Revision as of 16:20, 16 October 2012
Line 289:		Line 289:
	<center>LINE ITEMS (ITEMS)</center>		<center>LINE ITEMS (ITEMS)</center>
	<center>LINE ITEMS (ITEMS)</center>		<center>LINE ITEMS (ITEMS)</center>



	The REC_TYPE field will be populated in the first column of the CSV file and will indicate the record type for each record.		The REC_TYPE field will be populated in the first column of the CSV file and will indicate the record type for each record.

Middletong: /* CSV Import */

2012-10-16T14:19:57Z

CSV Import

← Older revision		Revision as of 16:19, 16 October 2012
Line 269:		Line 269:

	The data in the CSV file must be received in the following structure:		The data in the CSV file must be received in the following structure:



	<center>'''ORDER HEADER (ORDER)'''</center>		<center>'''ORDER HEADER (ORDER)'''</center>

Middletong at 14:16, 16 October 2012

2012-10-16T14:16:13Z

← Older revision		Revision as of 16:16, 16 October 2012
Line 250:		Line 250:

	The new screen will include a Save and Close button. The close button will return the user to the XML_Orders tab of the Interface Errors screen.		The new screen will include a Save and Close button. The close button will return the user to the XML_Orders tab of the Interface Errors screen.

			===Re-Process===

			When the user selects the new Re-Process button, the re-validate and reprocess functionality will be applied to the current record highlighted in the XML_Orders tab.

			The status of the record in the Interface header control table will be set to New, ensuring the record is processed on the next run of the EDI flow.

			When an order has been successfully processed, the validate order code will be called and if this process returns no errors the order will be loaded into C-TMS and considered for auto planning.


			==CSV Import==

			The CSV data will be sent to C-TMS as Order headers, lines and items. This is the first example of CSV data being received in this format. Currently users send order CSV data in Order and Lines OR Orders and items.

			To accommodate the change in structure a new IMPORT TYPE called ORD_LINE_ITEM and 5 new record types will be created, ORDER, ORD_LINES, ITEMS, ORD_TASKS and ORD_ SUB_REFS. The ORDER, ORD_LINES and ITEMS will be based on the format of the Order_and_Line and Line record formats.

			[[Image:291356_20.png]]

			The data in the CSV file must be received in the following structure:

			<center>'''ORDER HEADER (ORDER)'''</center>

			<center>Order Tasks (Ord_Tasks)</center>
			<center>Order Tasks (Ord_Tasks)</center>

			<center>Order Sub References (Ord_Sub_Refs)</center>
			<center>Order Sub References (Ord_Sub_Refs)</center>

			<center>''ORDER LINE(ORD_LINES)''</center>

			<center>LINE ITEMS (ITEMS)</center>
			<center>LINE ITEMS (ITEMS)</center>

			<center>''ORDER LINE (ORD_LINES)''</center>

			<center>LINE ITEMS (ITEMS)</center>
			<center>LINE ITEMS (ITEMS)</center>

			The REC_TYPE field will be populated in the first column of the CSV file and will indicate the record type for each record.

			Currently, if a CSV import provides item data, the line data is created as a consolidation of the items. This consolidation will not be required as the line records are being provided in the data file.

			A new procedure will be added to the IMP package called PROCESS_ORD_LINE_ITEM.
			In addition to processing the order, line and item records, the data will be validated in the same way as described for the EDI (See section 3.2 and 3.3) The validation will include:

			*Locations and the creation of Child Locations
			*Order Location Contacts and Comments
			*Order Tasks mapped to services
			*Duplicate Customer References
			*Line and Item validation (Product type and Du type)
			*Product Type update on the Order Header

			When uploading a CSV format order file, validation will check the content. Any validation failures will be notified in a generated CSV format results file and any failures will be included in a failures file in the same format as the file was presented in. The failures file can then be amended and changed on the user desktop and re-submitted to C-TMS.

			In addition to the new fields added to the database being available to import to, the following fields will also be available

Middletong at 14:04, 16 October 2012

2012-10-16T14:04:48Z

← Older revision		Revision as of 16:04, 16 October 2012
Line 162:		Line 162:

	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		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

			==Order Validation==

			Currently in C-TMS, if an order is uploaded with an external reference which already exists in C-TMS, the upload of that order will fail (or will be interpreted as an amendment depending on the configuration of the interface flow). Orders can be released from DISC to C-TMS over a number of days and these orders will have the same external reference but different shipment numbers.

			To allow these orders to load, a new EDI parameter will be created called DUPLICATE_SHIPMENTS_ALLOWED. Where an external reference is found to already exist in C-TMS, if this parameter has been set to Y, the system will continue processing the record and will check the value of DEL_POINT_REF.

			The DEL_POINT_REF field will store the value of the shipment and if this is unique to the CUSTOMER_REF, the system will allow the order to be processed with an existing EXTERNAL_REF value. If this check finds the DEL_POINT_REF is not unique, the order will fail to be processed and considered a duplicate.

			Where more than one shipment is processed for an external_ref, the external_ref will be altered in C-TMS as shown in the table below:

			[[Image:291356_12.png]]

			The external reference will be retained for the original order processed on C-TMS. For all subsequent orders with the same EXTERNAL_REF, the external reference will be amended to include a suffix.

			Order items will be validated to ensure the ITEM_IDENTIFIER exists in the PRD_PRODUCT_ITEM table depending on configuration of the customer account. A new parameter will be included on the customer master screen that will allow validation of products in orders against the product master to be performed or not. The system will also check the DU TYPE and PRODUCT TYPE are valid for the order line record by reference to the respective master data maintained in C-TMS.

			[[Image:291356_13.png]]

			When the order is successfully validated and uploaded into C-TMS, the product_type on the order header will be updated based on the Product Type of the lines. Non Heavy orders are expected to be received with the product type Ambient. If the order has multiple order lines, each with a different product type, the order header value will be set as ‘MIXED’.

			==Milkround Processing==

			The Milk Round is a template of fixed routes used for generating trips each day. All fixed routes will be created using MSP locations. Where an orders delivery location is a child location, to schedule the order, C-TMS will find the route which references the parent (MSP) location and create a new stop in the trip for any / each child location.

			Milk Round routes will be identified based on the MSP location, but stops will be created based on the delivery locations, which may be child locations.

			A new cost centre parameter called OMS_ADD_ORDER_TO_MILK will be created and will control which cost centres are available for auto planning. A new field will be added to the customer maintenance parameter screen called Auto_Planning. The field will be displayed as a flag in the parameters tab on the customer maintenance screen and will allow users to control which customers are considered for auto planning to Milkround Templates.

			[[Image:291356_14.png]]

			If the cost centre and customer indicate that the order can be auto planned, a final check will be run to ensure collection and delivery locations (FROM_LOC and TO_LOC) have latitude and longitude coordinates value set. Latitude and Longitude will be automatically set by existing C-TMS integration with NAVTEQ to support the planning logic.

			Where the locations are missing the lat long information (NAVTEQ fails to provide the information), the order will not be auto planned and will be left unscheduled in the order well for manual intervention.

			Before auto planning starts, the system will check that the Milk Round has been processed for the SCHED_NAME on the order. This check will be based on a count of MFR prefixed trips for the specified schedule. If there are no trips available, the system will call the Milk round process, passing in the ROUTE_DAY, SCHED_NAME and FROM_LOC from the order table. The procedure to create the Milk Round is stored in the RTE package, called Schedule_Milkround. This logic is designed to check whether the trips defined by the milk round template have already been generated for the schedule. If they haven’t, the process will generate all the trips so orders can be assigned to them. Operationally, the schedule of milk round trips might be created some days in advance of execution to allow manual planning of non DISC orders into the milk round trips.

			C-TMS will auto plan all orders with the relevant cost centre, customer and lat long information. First C-TMS will identify if a valid trip exists. A valid trip will be identified using the Schedule name, concatenated ROUTE_DAY and ROUTE_CODE and TRIP_ID starting with MFR.

			[[Image:291356_15.png]]

			The above checks are based on the schedule name on the order being derived from the Early Collection date. It will also be necessary to compare the from location of the order with the owning depot on the trip, to ensure segregation is maintained if in future another warehouse location is introduced. Currently, all DISC orders are pick, packed and despatched from the one location at Worcester.

			C-TMS trips generated from the Milk Round processing will be pre-fixed with MFR-.

			If a suitable trip is identified, TRM.ADD_ORD_TO_TRIP will be called to schedule the order onto the trip. VALIDATE_TRIP will be called to ensure the Order does not cause any issues on the trip.

			Where a suitable trip cannot be found, the order will remain unscheduled in the order well and will be available for manual planning

			==Order Length (Heavy)==

			A length value will optionally be interfaced at order line level; this is to satisfy requirements for rails, where the planner needs to know rail lengths ordered as an operational constraints exist when planning certain incompatible lengths on vehicles. C-TMS will be developed to allow the lengths value to be visible but will not constrain the planner actions in any way to satisfy and length loading compatibility – this will be a manual planning decision.

			[[Image:291356_16.png]]

			Currently, in the order lines, users are able to right click the Volume field to enter Footprint information. Based on a new Cost Centre parameter ORD_LINE_LENGTH, the FOOTPRINT field in Order lines will be used to store the length data and the label will be updated from Footprint to Length.

			Currently, the footprint is summed at Order Header level as shown in the screen shot below:

			[[Image:291356_17.png]]

			Based on the value of the cost centre parameter, ORD_LINE_LENGTH, the TOTAL_FOOTPRINT field at Order header will be updated to the MAX(LENGTH) rather than a sum of the length fields.

			This will allow planners to know the largest rail length on the order. To aid the planning process, TOTAL_FOOTPRINT will be added to the configurable items in the Order well on the Trip Manipulation, Trip Planning and Execution screens. Based on the value of the cost centre parameter ORD_LINE_LENTH, the TOTAL_FOOTPRINT field will be labelled MAX_LENGTH in the configurable layout and on the order well.

			[[Image:291356_18.png]]

			==Order Correction From Interface Errors Screen==

			Currently any order failures are available to view in the XML_Orders tab of the Interface Errors screen. Order details received through EDI are at Line level or Item level, which is indicated by a D for lines or an S for items.

			Network Rail DISC interface will be send order details at line and item level, any failures will be report at both levels. To achieve this, the DETAIL_TYPE from the INT_XML_ORD_DETAILS table will be added to the screen at detail level, after the Line no. This will allow users to view both Line and items records and any associated errors

			[[Image:291356_19.png]]

			The DETAIL_TYPE will be displayed based on the value of a new EDI flow based system parameter. This system parameter will also be used to control the display of two new command buttons, ‘Correct Errors’ and ‘Re-Process’.

			===Correct Errors===

			In the screen shot of the interface errors screen above, the user can see that one order header record is selected and this record is highlighted yellow. When a user selects the new ‘Correct Errors’ button, a new screen will be displayed which will allow any errors to be corrected.

			This will display all the information which has been stored in the interface control tables for the failed orders. Users will be able to overwrite any value which has failed validation and caused the order processing to fail.

			For one order header record there will be multiple detail records and the screen will be developed to show a single header record and the related detail records.

			Fields that are validated on the values of reference master tables in C-TMS will be supported by lists of values lookups. Users will only be able to select data from the list of values, for example Product Type, Du Type, Customer etc.

			The new screen will include a Save and Close button. The close button will return the user to the XML_Orders tab of the Interface Errors screen.

Middletong at 13:22, 16 October 2012

2012-10-16T13:22:53Z

Show changes

Middletong: New page: {{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Order EDI & Order Quarantine|Reference=FS 291356 MS-8KNFBJ|Version=3.0|Date=21/10/11|Sysver=10.7|Client=DHL C-TMS}}

2012-10-16T12:52:08Z

New page: {{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Order EDI & Order Quarantine|Reference=FS 291356 MS-8KNFBJ|Version=3.0|Date=21/10/11|Sysver=10.7|Client=DHL C-TMS}}

New page

{{Doc_Title|System=FUNCTIONAL SPECIFICATION|Title=Order EDI & Order Quarantine|Reference=FS 291356 MS-8KNFBJ|Version=3.0|Date=21/10/11|Sysver=10.7|Client=DHL C-TMS}}