291614 - Revision history

Middletong at 14:45, 15 October 2012

2012-10-15T14:45:51Z

2012-10-15T13:50:28Z

← Older revision		Revision as of 15:50, 15 October 2012
Line 346:		Line 346:

	If it is not set to ‘Y’ then the order sub-reference section will continue to use the existing functionality to display the lane comments		If it is not set to ‘Y’ then the order sub-reference section will continue to use the existing functionality to display the lane comments


	==IMP Package==		==IMP Package==

2012-10-15T13:49:46Z

← Older revision		Revision as of 15:49, 15 October 2012
Line 334:		Line 334:

	'''N.B. The ‘POD’ flag of the transport order/shipment will not be updated to ‘Y’ because this process is not an official POD confirmation process.'''		'''N.B. The ‘POD’ flag of the transport order/shipment will not be updated to ‘Y’ because this process is not an official POD confirmation process.'''

			==INT_XML_IN Package==

			The ‘INT_XML_IN’ package will be changed to process the new inbound XML order files.

			==INT_XML_OUT Package==

			The ‘INT_XML_OUT2’ package will be changed to generate the new outbound XML files.

			A change will be required to ensure that the order sub-references are used correctly for the client: a new cost-centre level system parameter called ‘USE_XML_ORDER_SUB_REFS’ will be created and if it is set to ‘Y’ then the order sub-references will be included in the TripOrder XML file and they will be obtained from the ‘SCH_ORD_REFERENCE’ database table.

			If it is not set to ‘Y’ then the order sub-reference section will continue to use the existing functionality to display the lane comments


			==IMP Package==

			The ‘IMP’ package will be changed to process the new inbound XML order file from Unison.

			The file can contain the mandated carrier so a ‘CARRIER_ID’ field type will be required.

2012-10-15T13:36:31Z

← Older revision		Revision as of 15:36, 15 October 2012
Line 328:		Line 328:

	[[Image:291614_14.png]]		[[Image:291614_14.png]]

			It is expected that there can be multiple tracking references returned but only single values for the stop times, non-conformance description and signatory: this is because multiple tracking references can be scanned at the delivery location but the other information is specific to the trip stop itself.

			It is expected that a file will contain all of the despatch units delivered, but if despatch units are sent in different files then the first stop time, non-conformance description and signatory will be retained from the first file; only the delivered quantity will be updated for subsequent files processed for tracking references found for the same transport order/shipment.

			'''N.B. The ‘POD’ flag of the transport order/shipment will not be updated to ‘Y’ because this process is not an official POD confirmation process.'''

2012-10-15T13:35:49Z

← Older revision		Revision as of 15:35, 15 October 2012
Line 322:		Line 322:

	[[Image:291614_13.png]]		[[Image:291614_13.png]]

			A unique reason code of ‘CPOD’ (i.e. ‘Carrier POD’) will be created for the non-conformance descriptions advised by the carrier with a usage type of ‘PO_REASON’.

			The ‘SCH_ORD_NON_CONFORM’ database table is maintained for the order at the trip stop and will contain the following data:

			[[Image:291614_14.png]]

2012-10-15T13:34:49Z

← Older revision		Revision as of 15:34, 15 October 2012
Line 313:		Line 313:

	[[Image:291614_12.png]]		[[Image:291614_12.png]]

			A new database package called ‘INT_XML_CARPOD’ will be developed to process the inbound XML file in the new format.

			A database job will be created via the ‘Start’ button and it will call the new procedure ‘INT_XML_CARPOD.PROCESS_CARPOD_XML_IN’ to process the file.

			The procedure will update the database tables as follows:


			[[Image:291614_13.png]]

2012-10-15T13:33:47Z

← Older revision		Revision as of 15:33, 15 October 2012
Line 289:		Line 289:

	[[Image:291614_11.png]]		[[Image:291614_11.png]]

			Opening and closing tags will be required to enable the ‘ORDER_SUB_REF’ section to be accessed:

			*<OBS_XML>
			*<EVENT>
			*<EVENT_DETAIL>
			*<STOPS>
			*<STOP>
			*<ORDERS>
			*<ORDER>
			*<ORDER_SUB_REFS>

			The order sub-references will be populated because of the limited amount of data available from the carriers: the stop-level information will not be provided and the standard order references will be unknown (e.g. OMS, customer, delivery point or booking references).

			It is expected that the carrier will be able to provide the individual despatch unit tracking reference printed on the label, plus the actual delivered quantity, actual stop arrival and/or departure times and a description of a non-conformance.

			The transport order/shipment, trip and delivery stop will need to be obtained from the tracking reference provided: this assessment may be performed using the order tracking information that is stored against the OMS reference for each tracking reference generated during the production of the labels. The ‘SCH_ORD_TRACKING’ database table contains this information and a ‘REF_TYPE’ of ‘D’ indicates a despatch unit.

			In the future it may be possible for the carrier to return more information; therefore, the ‘TripOrder’ format may be used more fully.


			The XML tags will be validated and mapped to the following C-TMS database items:

			[[Image:291614_12.png]]

2012-10-15T13:30:01Z

← Older revision		Revision as of 15:30, 15 October 2012
Line 285:		Line 285:

	[[Image:291614_10.png]]		[[Image:291614_10.png]]

			The order sub-references in section ‘ORDER_SUB_REF’ will be used to store the carrier’s POD information for the despatch unit scanned by the carrier when it is delivered:

			[[Image:291614_11.png]]

2012-10-15T13:28:59Z

← Older revision		Revision as of 15:28, 15 October 2012
Line 272:		Line 272:

	[[Image:291614_9.png]]		[[Image:291614_9.png]]

			The filename format is expected to be:

			‘CARPOD_{CARRIER_ID}_{SEQUENCE_NUMBER}.XML

			‘CARPOD’ indicates a ‘Carrier POD’ message and the sequence number will be generated by DHL Link to form a unique filename.

			A check will be performed to ensure that a duplicate filename is not processed: if a duplicate file is received then the status of the interface record will be set to ‘FAILURE’ and the order data will not be updated.


			The file is expected to contain the following data in the XML tags for it to be identified and processed correctly:

			[[Image:291614_10.png]]

2012-10-15T13:27:59Z

← Older revision		Revision as of 15:27, 15 October 2012
Line 268:		Line 268:

	[[Image:291614_8.png]]		[[Image:291614_8.png]]

			The new flow type of ‘CARPOD_XML’ indicates the new limited data format and will be created for this development as follows:

			[[Image:291614_9.png]]