TripOrder Interface XML - Revision history

Anw: Minor formatting change

2026-03-06T11:30:24Z

Minor formatting change

← Older revision		Revision as of 13:30, 6 March 2026
Line 1,185:		Line 1,185:

	= APPENDIX: XSD SECTIONS =		= APPENDIX: XSD SECTIONS =
	{\| class="wikitable"		{\| class="wikitable apt-searchable"
	!Parent		!Parent
	!Cardinality		!Cardinality
Line 1,463:		Line 1,463:

	= APPENDIX: Core Import XSD Elements =		= APPENDIX: Core Import XSD Elements =
	{\| class="wikitable"		{\| class="wikitable apt-searchable"
	!Item		!Item
	!Type		!Type

Anw: Added appendices showing sections and core import fields

2026-03-06T11:29:05Z

Added appendices showing sections and core import fields

Show changes

Anw: Added Webservice API EDI processes

2026-03-06T09:25:23Z

Added Webservice API EDI processes

← Older revision		Revision as of 11:25, 6 March 2026
Line 19:		Line 19:

	For example, the order time windows can be recalculated and the hazardous data can be defaulted.		For example, the order time windows can be recalculated and the hazardous data can be defaulted.

			=== Webservice API Imports ===
			This is controlled via the EDI Maintenance screen. See the section [[TripOrder Interface XML#EDI Trip Order XML Webservices Configuration\|EDI Trip Order XML Webservices Configuration]] below for details.


Line 666:		Line 669:

	= XML Outbound Order File Structure =		= XML Outbound Order File Structure =
	== EDI Maintenance ==		CTMS may provide updates to a customer’s source system, including how the order has been scheduled for delivery, when a vehicle is en-route and delivery details including successful delivery and reasons for a short delivery. The same TripOrder XSD will be used to generate the Trip file.

			==EDI Maintenance ==
	The XML files from CTMS will be generated and placed into a directory structure and processed as may be specified in the 'EDI Maintenance' screen.		The XML files from CTMS will be generated and placed into a directory structure and processed as may be specified in the 'EDI Maintenance' screen.

Line 673:		Line 678:
	There are various EDI parameters that can be set to provide different levels of validation to generate the files.		There are various EDI parameters that can be set to provide different levels of validation to generate the files.

			The trip/order outbound flows can generate standard flows via a webservice push to an endpoint, or can be sent out to the filesystem for FTP - See [[TripOrder Interface XML#Filesystem Server Requirements\|Filesystem Server Requirements]] below. This depends on the EDI processes generated.


			Further, more bespoke EDI exports can be generated - these still use the same TripOrder XML export structure, but are more focussed on different processes, such as tracking summary messages - these are not covered in this guide.

			=== Filesystem Server Requirements ===
			CTMS will push files to the OUT sub folder within the customer folder. From this folder CTMS will FTP the file across to the customer system. The customer must provide CTMS with the IP, PORT, Username , Password and Directory name. The customer will provide CTMS with access to the directory.<center>
			[[File:TripOrderXML-EDI-FTP.png]]
			</center>

			=== Webservice API Export ===
			Like Filesystem exports, this is controlled via the EDI Maintenance screen. See the section [[TripOrder Interface XML#EDI Trip Order XML Webservices Configuration\|EDI Trip Order XML Webservices Configuration]] below for details.

	== TripOrder File ==		== TripOrder File ==
Line 1,100:		Line 1,117:
	</pre>		</pre>



			== EDI Trip Order XML Webservices Configuration ==
			{{:EDI Trip Order XML Webservices Configuration}}

	==System Parameters affecting XML Production==		==System Parameters affecting XML Production==

Anw: Updated

2025-09-16T07:47:31Z

Updated

← Older revision		Revision as of 09:47, 16 September 2025
Line 29:		Line 29:
	The overall file structure consists of two complex type elements - the file header information and then the details. Each element must only exist once per file.		The overall file structure consists of two complex type elements - the file header information and then the details. Each element must only exist once per file.

	The different sections within <OBS_XML> can occur differently, the data in bold type is included in the text (N.~~B. not~~ all of the sections and elements that are available in the XSD file format are listed):		The different sections within <OBS_XML> can occur differently, the data in bold type is included in the text. {{Note}} Not all of the sections and elements that are available in the XSD file format are listed, just the most common use cases:

	<OBS_XML> 1.1 <EVENT>		<OBS_XML> 1.1 <EVENT>
Line 90:		Line 90:
	<ORDER_HEADER> 0.1 <CUSTOMER_ID>		<ORDER_HEADER> 0.1 <CUSTOMER_ID>
	<ORDER_HEADER> 0.1 <CUSTOMER_NAME>		<ORDER_HEADER> 0.1 <CUSTOMER_NAME>
			<ORDER> 0.1 <ORDER_SUB_REFS>
			<ORDER_SUB_REFS> 1.1 <ORDER_SUB_REF>
			<ORDER_SUB_REF> 1.1 <SUB_REF_IDENTIFIER>
			<ORDER_SUB_REF> 1.1 <SUB_REFERENCE>
	<ORDER> 0.1 <ORDER_DETAILS>		<ORDER> 0.1 <ORDER_DETAILS>
	<ORDER_DETAILS> 1.1 <ORDER_DETAIL>		<ORDER_DETAILS> 1.1 <ORDER_DETAIL>
Line 228:		Line 232:
	\|-		\|-
	\|CUSTOMER_NAME \|\|STRING \|\|50 \|\| \|\|		\|CUSTOMER_NAME \|\|STRING \|\|50 \|\| \|\|
			\|-
			\|SUB_REF_IDENTIFIER \|\|STRING \|\|50 \|\| \|\|Y
			\|-
			\|SUB_REFERENCE \|\|STRING \|\|512 \|\| \|\|Y
	\|-		\|-
	\|DETAIL_TYPE \|\|STRING \|\|1 \|\|D,S \|\|Y		\|DETAIL_TYPE \|\|STRING \|\|1 \|\|D,S \|\|Y
Line 306:		Line 314:
	The <EVENT_PROCESSED> is expected to have a value of 'N'.		The <EVENT_PROCESSED> is expected to have a value of 'N'.

	The <EVENT_SOURCE_TYPE> must be setup as a recognised source system within CTMS.		The <EVENT_SOURCE_TYPE> must be setup as a recognised source system within CTMS, within the [[System Configuration]] screen, [[System Configuration#Sources\|Sources]] tab.

	Although a number of <EVENT_TYPE> values can be received it is the 'ORD' event type which represents a transport order to be created or amended in CTMS, the <EVENT_ACTION> value of 'C' (for 'C'reate) will ensure a new order is generated, an event action value of 'A' (for 'A'mend) will update an order, and an event action value of 'D' (for 'D'elete) will delete an order.		Although a number of <EVENT_TYPE> values can be received it is the 'ORD' event type which represents a transport order to be created or amended in CTMS, the <EVENT_ACTION> value of 'C' (for 'C'reate) will ensure a new order is generated, an event action value of 'A' (for 'A'mend) will update an order, and an event action value of 'D' (for 'D'elete) will delete an order.
Line 437:		Line 445:

	The accepted values in the <TRANSPORT_MODE> simple type element are:		The accepted values in the <TRANSPORT_MODE> simple type element are:

	* AIR		* AIR
	* ROAD		* ROAD

Anw: Updated

2025-09-16T07:35:45Z

Updated

Show changes

Anw: Minor formatting change

2025-08-18T09:25:37Z

Minor formatting change

Show changes

Anw: Minor formatting change

2025-08-18T09:20:04Z

Minor formatting change

Show changes

Anw: Updated

2025-08-18T09:07:48Z

Updated

Show changes

Anw: Added much detail regarding exports in Trip Order XML format.

2025-08-15T14:30:11Z

Added much detail regarding exports in Trip Order XML format.

Show changes

Anw: Patch 48 SCR-CTMS-03557646-13 Get price on orders TS 3.5

2025-04-09T08:55:18Z

Patch 48 SCR-CTMS-03557646-13 Get price on orders TS 3.5

← Older revision		Revision as of 10:55, 9 April 2025
Line 420:		Line 420:

	This will be validated and the order file rejected if the value does not match.		This will be validated and the order file rejected if the value does not match.

			The <TOTAL_PRICE> element is optional and defines the TOTAL price of the order. If provided and populated, the value must be a valid decimal value, or an error will be raised. If not provided or null, the value will be set to 0.


Line 550:		Line 552:
	As this is at individual carton/box level then this is expected to always be 1 for this implementation.		As this is at individual carton/box level then this is expected to always be 1 for this implementation.

	The <WEIGHT>, <HEIGHT>, <WIDTH>, <LENGTH> simple type elements are optional.		The <WEIGHT>, <HEIGHT>, <WIDTH>, <LENGTH> simple type elements are optional.

	The height, width and length will be used by CTMS to calculate the carton/box level volume for each order item as per existing standard processing logic.		{{Note\|* The weight provided is a TOTAL weight of the item or line, not a UNIT weight.
			* The height, width and length will be used by CTMS to calculate the carton/box level volume for each order item as per existing standard processing logic.}}

	The <COMMODITY_ID> simple type element is optional and will be validated against CTMS master data to ensure it is a recognised value. An unrecognised value will cause the order upload to fail with applicable validation message recorded.		The <COMMODITY_ID> simple type element is optional and will be validated against CTMS master data to ensure it is a recognised value. An unrecognised value will cause the order upload to fail with applicable validation message recorded.

	The <CLASS_ID> simple type element is optional but must be received when a <COMMODITY_ID> element is provided which has a 'Dangerous' flag setting of 'Y' (in CTMS master data setup). The value will be validated against CTMS master data to ensure it is a recognised value. An unrecognised will cause the order upload to fail with applicable validation message recorded.		The <CLASS_ID> simple type element is optional but must be received when a <COMMODITY_ID> element is provided which has a 'Dangerous' flag setting of 'Y' (in CTMS master data setup). The value will be validated against CTMS master data to ensure it is a recognised value. An unrecognised will cause the order upload to fail with applicable validation message recorded.

			The <ITEM_PRICE> element is optional and defines the TOTAL price of the item. This applies only to Item detail type lines. If provided and populated, the value must be a valid decimal value, or an error will be raised. If not provided or null, the value will be set to 0.