Interface - CTMS XML EDI Order Flow Guide

From CTMS

Aptean Logo.png







Aptean

Interface - CTMS XML EDI Order Flow Guide

Calidus TMS - 12.48

16th September 2025 - 3.03
Reference: INTERFACE











































Overview

Introduction

This document is designed to give a brief overview of integration methods into and out of the Aptean TMS - Calidus Edition (CTMS) for transport orders.

The transport orders can be created in CTMS from external systems using XML files based on a standard XSD file format for CTMS called 'TripOrder'.

The following sections will describe some of the sections that are available in the XSD file to create and amend transport orders.

The same XSD file format is used for files being sent by CTMS to external systems to provided information about the transport orders in CTMS and how they have been, or will be, transported between depots and sites.


XML Inbound Order File Structure

EDI Maintenance

The XML files for CTMS will be received into a directory structure and processed as may be specified in the 'EDI Maintenance' screen.

Multiple EDI flows may be active to process XML files from different source systems with different filename formats as required.

There are various EDI parameters that can be set to provide different levels of validation of the data that is extracted from the file.

There are also EDI parameters that can be used to set default values for when the data is not able to be provided in the file.

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


TripOrder File

<OBS_XML>
  <EVENT>
  <EVENT_HEADER>
  <EVENT_DETAIL>

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. Note 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>
<EVENT> 1.1 <EVENT_HEADER>
 <EVENT_HEADER> 1.1 <ALL ELEMENTS>
 <EVENT> 0.00 <EVENT_DETAIL>
 <EVENT_DETAIL> 1.1 <TRIP_HEADER>
  <TRIP_HEADER> 1.1 <TRIP_IDENTIFIER>
  <TRIP_HEADER> 0.1 <TRIP_TRANSACTION_DATE>
  <TRIP_HEADER> 0.1 <TRIP_ID>
 <EVENT_DETAIL> 0.1 <TRIP_DETAIL>
 <EVENT_DETAIL> 0.1 <STOPS>
  <STOPS> 1.00 <STOP>
   <STOP> 1.1 <STOP_HEADER>
    <STOP_HEADER> 1.1 <STOP_IDENTIFIER>
    <STOP_HEADER> 0.1 <STOP_ID>
    <STOP_HEADER> 0.1 <STOP_SEQ>
   <STOP> 0.1 <STOP_DETAIL>
   <STOP> 0.1 <ORDERS>
    <ORDERS> 1.1 <ORDER>
     <ORDER> 1.1 <ORDER_HEADER>
      <ORDER_HEADER> 1.1 <ORDER_TRANSACTION_DATE>
      <ORDER_HEADER> 0.1 <ORDER_TYPE>
      <ORDER_HEADER> 0.1 <WMS_WAREHOUSE>
      <ORDER_HEADER> 0.1 <WMS_OWNER>
      <ORDER_HEADER> 0.1 <SO_REF>
      <ORDER_HEADER> 0.1 <TMS_REF>
      <ORDER_HEADER> 0.1 <PO_REF>
      <ORDER_HEADER> 0.1 <BOOK_REF>
      <ORDER_HEADER> 0.1 <BOOK_DATE>
      <ORDER_HEADER> 0.1 <SPECIAL_INSTR>
      <ORDER_HEADER> 0.1 <ORDER_COMMENTS>
      <ORDER_HEADER> 0.1 <ORDER_HEADER_TMS>
       <ORDER_HEADER_TMS> 1.1 <EARLY_AVAIL_DATE>
       <ORDER_HEADER_TMS> 1.1 <LATE_AVAIL_DATE>
       <ORDER_HEADER_TMS> 1.1 <EARLY_DEL_DATE>
       <ORDER_HEADER_TMS> 1.1 <LATE_DEL_DATE>
       <ORDER_HEADER_TMS> 0.1 <TMS_GROUP_NAME>
       <ORDER_HEADER_TMS> 0.1 <TMS_DELIVERY_TYPE>
       <ORDER_HEADER_TMS> 0.1 <TMS_COST_CENTRE>
       <ORDER_HEADER_TMS> 0.1 <HAULIER>
       <ORDER_HEADER_TMS> 0.1 <TRANSPORT_MODE>
      <ORDER_HEADER> 0.1 <ORDER_HEADER_ADDRESSES>
       <ORDER_HEADER_ADDRESSES> 1.00 <ORDER_HEADER_ADDRESS>
        <ORDER_HEADER_ADDRESS> 1.1 <ADDRESS_TYPE>
        <ORDER_HEADER_ADDRESS> 1.1 <ADDRESS_ID>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_NAME>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_LINE1>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_LINE2>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_LINE3>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_TOWN>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_COUNTY>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_COUNTRY_CODE>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_POSTCODE>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_LOC_TYPE>
        <ORDER_HEADER_ADDRESS> 0.1 <ADDRESS_CUST_GROUP>
        <ORDER_HEADER_ADDRESS> 0.1 <OH_ADDRESS_CONTACTS>
         <OH_ADDRESS_CONTACTS> 1.00 <OH_ADDRESS_CONTACT>
          <OH_ADDRESS_CONTACT> 0.1 <ALL ELEMENTS>
      <ORDER_HEADER> 0.1 <CUSTOMER_ID>
      <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_DETAILS> 1.1 <ORDER_DETAIL>
       <ORDER_DETAIL> 1.1 <DETAIL_TYPE>
       <ORDER_DETAIL> 0.1 <DETAIL_ID>
       <ORDER_DETAIL> 0.1 <PRODUCT_TYPE>
       <ORDER_DETAIL> 0.1 <PRODUCT_TYPE_DESC>
       <ORDER_DETAIL> 0.1 <DU_TYPE>
       <ORDER_DETAIL> 1.1 <ITEM_IDENTIFIER>
       <ORDER_DETAIL> 0.1 <ITEM_DESCRIPTION>
       <ORDER_DETAIL> 0.1 <PALLET_ID>
       <ORDER_DETAIL> 0.1 <ITEM_AKA_CODE>
       <ORDER_DETAIL> 0.1 <ITEM_FACTOR>
       <ORDER_DETAIL> 0.1 <LIFTS>
       <ORDER_DETAIL> 0.1 <RPE_QTY>
       <ORDER_DETAIL> 0.1 <WEIGHT>
       <ORDER_DETAIL> 0.1 <VOLUME>
       <ORDER_DETAIL> 0.1 <ORDERED>
       <ORDER_DETAIL> 0.1 <TO_DELIVER>
       <ORDER_DETAIL> 0.1 <DELIVERED>
       <ORDER_DETAIL> 0.1 <PLANNED_CASES>
       <ORDER_DETAIL> 0.1 <LENGTH>
       <ORDER_DETAIL> 0.1 <WIDTH>
       <ORDER_DETAIL> 0.1 <HEIGHT>
       <ORDER_DETAIL> 0.1 <COMMODITY_ID>
       <ORDER_DETAIL> 0.1 <CLASS_ID>
     <ORDER> 0.1 <ORDER_HAZARDOUS_DETAILS>
      <ORDER_HAZARDOUS_DETAILS> 1.00 <ORDER_HAZARDOUS_DETAIL>
       <ORDER_HAZARDOUS_DETAIL> 0.1 <ALL ELEMENTS>

The XML items have the following definitions in the XSD file format:

Item Type Size Restriction CTMS Mandatory*
EVENT_PROCESSED STRING 1 E,N,Y Y
EVENT_SOURCE_TYPE STRING 4 New Value Y
EVENT_SOURCE_NAME STRING 10 Y
EVENT_DATE DATETIME Y
EVENT_TYPE STRING 3 Y
EVENT_ACTION STRING 1 A,C,D Y
TRIP_IDENTIFIER STRING 1 O,T Y
TRIP_TRANSACTION_DATE DATETIME
TRIP_ID STRING 12
STOP_IDENTIFIER STRING 1 O,S Y
STOP_ID STRING 51
STOP_SEQ INTEGER 6
ORDER_TRANSACTION_DATE DATETIME Y
ORDER_TYPE STRING 1
WMS_WAREHOUSE STRING 3
WMS_OWNER STRING 12 Y
SO_REF STRING 20 Y
TMS_REF STRING 20
PO_REF STRING 20
BOOK_REF STRING 20
BOOK_DATE DATETIME
SPECIAL_INSTR STRING 2000
ORDER_COMMENTS STRING 2000
EARLY_AVAIL_DATE DATETIME Y
LATE_AVAIL_DATE DATETIME Y
EARLY_DEL_DATE DATETIME Y
LATE_DEL_DATE DATETIME Y
TMS_GROUP_NAME STRING 12
TMS_DELIVERY_TYPE STRING 35
TMS_COST_CENTRE STRING 12 Y
HAULIER STRING 12
TRANSPORT_MODE STRING 30
ADDRESS_TYPE STRING 3 Y
ADDRESS_ID STRING 25 Y
ADDRESS_NAME STRING 50
ADDRESS_LINE1 STRING 50
ADDRESS_LINE2 STRING 50
ADDRESS_LINE3 STRING 50
ADDRESS_TOWN STRING 50
ADDRESS_COUNTY STRING 50
ADDRESS_COUNTRY_CODE STRING 3
ADDRESS_POSTCODE STRING 9
ADDRESS_LOC_TYPE STRING 12
ADDRESS_CUST_GROUP STRING 12
ADDRESS_CONTACT_TYPE STRING 1 L,O
ADDRESS_CONTACT_FORENAME STRING 50
ADDRESS_CONTACT_SURNAME STRING 50
ADDRESS_CONTACT_NUMBER STRING 50
ADDRESS_EMAIL STRING 100
ADDRESS_CONTACT_JOB STRING 50
CUSTOMER_ID STRING 12
CUSTOMER_NAME STRING 50
SUB_REF_IDENTIFIER STRING 50 Y
SUB_REFERENCE STRING 512 Y
DETAIL_TYPE STRING 1 D,S Y
DETAIL_ID STRING 30
PRODUCT_TYPE STRING 12
PRODUCT_TYPE_DESC STRING 50 Y
DU_TYPE STRING 12
ITEM_IDENTIFIER STRING 20 Y
ITEM_DESCRIPTION STRING 122
PALLET_ID STRING 100
ITEM_AKA_CODE STRING 30
ITEM_FACTOR STRING 12
LIFTS DECIMAL 8,2
RPE_QTY DECIMAL 10,2
WEIGHT DECIMAL 10,2
VOLUME DECIMAL 15,5
ORDERED DECIMAL 28,4
TO_DELIVER DECIMAL 28,4
DELIVERED DECIMAL 28,4
PLANNED_CASES INTEGER 8
LENGTH DECIMAL 10,2
WIDTH DECIMAL 10,2
HEIGHT DECIMAL 10,2
COMMODITY_ID STRING 256
CLASS_ID STRING 256
UN_NUMBER STRING 50 Y
HAZARDOUS_QTY DECIMAL 28,4 Y
HAZARDOUS STRING 1 N,Y Y
HAZARDOUS_DESCRIPTION STRING 40 Y
  • The mandatory flag for CTMS is only valid if the optional section has been provided in the file.

Note that an item quantity must be provided as 'ORDERED' or 'TO_DELIVER' depending which item is being used (as set by an EDI parameter).


Event Header <EVENT_HEADER>

 <EVENT_HEADER>
   <EVENT_PROCESSED>N</EVENT_PROCESSED>
   <EVENT_SOURCE_TYPE>SAGE</EVENT_SOURCE_TYPE>
   <EVENT_SOURCE_NAME>SAGE</EVENT_SOURCE_NAME>
   <EVENT_DATE>2015-05-31T12:52:13</EVENT_DATE>
   <EVENT_TYPE>ORD</EVENT_TYPE>
   <EVENT_ACTION>C</EVENT_ACTION> 
 </EVENT_HEADER>

The header section describes the fact that an event has occurred. Each event must generally create a new file and this complex type element must not repeat within the file.

Each of the simple type elements outlined above is mandatorily required.

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, within the System Configuration screen, 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.

Validation will exist to check that the transport order can be created, amended or deleted as directed.

The <EVENT_DATE> simple element must be in the format 'YYYY-MM-DDTHH:MI:SS'


Event Detail <EVENT_DETAIL>

<EVENT_DETAIL>
    <TRIP_HEADER>
    <STOPS>
       <STOP>
         <STOP_HEADER>
         <ORDERS>
            <ORDER>
               <ORDER_HEADER>
               <ORDER_DETAILS>
               <ORDER_HAZARDOUS_DETAILS>
            </ORDER>

The event detail section consists of complex type elements representing the 'Trip' - a CTMS planned transport movement representing a vehicle with one or more transport orders to one or more location.

The trip can have several 'stops' (a geographical location visited) against which one or more 'orders' can be handled for loading or unloading the vehicle at each stop.

Therefore, the <STOPS> and <ORDERS> may contain multiple stops and transport orders that exist on the trip.


Trip Header <TRIP_HEADER>

   <TRIP_HEADER>
     <TRIP_IDENTIFIER>O</TRIP_IDENTIFIER>
   </TRIP_HEADER>

The 'ORD' event type does not require trip header information, although this complex type is mandatory in the file, it is exempted by denoting the <TRIP_IDENTIFIER> with 'O' to represent that the file contains order data only.

The order data received is denoted as an 'unplanned' order, that is it has not been built into a vehicle movement and routed through one or more load and unload activities. This planning activity is handled within CTMS.


Stops <STOPS>

 <STOPS>
   <STOP>
     <STOP_HEADER>
       <STOP_IDENTIFIER>O</STOP_IDENTIFIER>
     </STOP_HEADER>

The ORD event type does not require any trip stop information and although the complex type is mandatory it is exempted by denoting the <STOP_IDENTIFIER> with 'O' to indicate that the file contains order data only.


Orders <ORDERS>

<ORDER>
   <ORDER_HEADER> ... </ORDER_HEADER> [1]
   <ORDER_SUB_REFS> ... </ORDER_SUB_REFS> [0..1]
   <ORDER_DETAILS> ... </ORDER_DETAILS> [0..1]
   <ORDER_HAZARDOUS_DETAILS> ... </ORDER_HAZARDOUS_DETAILS> [0..1]
</ORDER>

The orders complex type contains the core information that constitutes a transport order request in CTMS, that is, a unique instruction to collect and deliver a number of goods items of a particular type between two points at requested times.

The <ORDER> element can repeat to represent multiple orders within the same file; however it is recommended best practice when using the ORD event type to receive one per individual XML file.

The structure is made up of complex elements representing the higher level order header information which is none repeating and the lower level order details complex type element which may repeat.

The <ORDER_HEADER> complex type is mandatory and must occur once and only once.

The <ORDER_HEADER> complex type is optional.

The <ORDER_DETAILS> complex type is mandatory for transport orders and can repeat but must occur at least once.

The <ORDER_HAZARDOUS_DETAILS> complex type is optional.


Order Header <ORDER_HEADER>

 <ORDER_HEADER>

<ORDER_HEADER>
   <ORDER_TRANSACTION_DATE> ... </ORDER_TRANSACTION_DATE> [1]
   <ORDER_TYPE> ... </ORDER_TYPE> [0..1]
   <WMS_WAREHOUSE> ... </WMS_WAREHOUSE> [0..1]
   <WMS_OWNER> ... </WMS_OWNER> [0..1]
   <SO_REF> ... </SO_REF> [0..1]
   <TMS_REF> ... </TMS_REF> [0..1]
   <PO_REF> ... </PO_REF> [0..1]
   <BOOK_REF> ... </BOOK_REF> [0..1]
   <BOOK_DATE> ... </BOOK_DATE> [0..1]
   <SPECIAL_INSTR> ... </SPECIAL_INSTR> [0..1]
   <ORDER_COMMENTS> ... </ORDER_COMMENTS> [0..1]
   <ORDER_HEADER_TMS> ... </ORDER_HEADER_TMS> [0..1]
   <ORDER_HEADER_ADDRESSES> ... </ORDER_HEADER_ADDRESSES> [0..1]
   <CUSTOMER_ID> ... </CUSTOMER_ID> [0..1]
   <CUSTOMER_NAME> ... </CUSTOMER_NAME> [0..1]
   <ORDER_STATUS> ... </ORDER_STATUS> [0..1]
</ORDER_HEADER>

The order header structure represents the high level simple single attributes of the order which exist in isolation, such as references and who the transport order is being conducted on behalf of.

The <ORDER_TRANSACTION_DATE> simple element is mandatory and must be in the format 'YYYY-MM-DDTHH:MI:SS'

The <ORDER_TYPE> simple type element is mandatory and must be received with a value of 'O'.

The <WMS_OWNER> simple type element indicates the customer and must match the customer IDs setup on CTMS, this is a mandatory field.

The <SPECIAL_INSTR> simple type element captures any additional information that is presented to the driver on his hand held delivery device at that may be relevant to the transport planning.


Order Header TMS <ORDER_HEADER_TMS>

           <ORDER_HEADER_TMS>
             <EARLY_AVAIL_DATE>2015-05-24T17:00:00</EARLY_AVAIL_DATE>
             <TMS_GROUP_NAME>OBS</TMS_GROUP_NAME>
             <TMS_DELIVERY_TYPE>Standard</TMS_DELIVERY_TYPE>
             <TMS_COST_CENTRE>OBS</TMS_COST_CENTRE>
             <TRANSPORT_MODE>ROAD</TRANSPORT_MODE>

The order header TMS section contains additional information relevant to the order and is simply an extension to the main order header complex type.

Most of the simple type elements in the section are optional.

The <TMS_DELIVERY_TYPE> is used to receive the service level: this value must be populated and is validated against CTMS master data

The <EARLY_AVAIL_DATE> simple type element is mandatory and will be used to calculate forward the collection/loading date/time window and also the approximate delivery date/time window. It must be in the format 'YYYY-MM-DDTHH:MI:SS'.

The other 3 dates for the order may be omitted because they can be calculated from the early available date that is provided and the delivery type (i.e. service level) of the order, however, the configuration in CTMS (TBC) will determine the required level of data.

All elements in this section are validated against CTMS master data and therefore must match CTMS configuration.

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

  • AIR
  • ROAD

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.


Order Header Addresses <ORDER_HEADER_ADDRESSES>

        <ORDER_HEADER_ADDRESSES>
            <ORDER_HEADER_ADDRESS>
            <ORDER_HEADER_ADDRESS>
                <OH_ADDRESS_CONTACTS>

An <ORDER_HEADER_ADDRESSES> complex type element must always exist once per order.

It must include two instances of the <ORDER_HEADER_ADDRESS> complex type element, one for the loading/pickup location (i.e. 'DEP' address type) and one for the unloading/drop-off location (i.e. 'DEL' address type).


Order Header Addresses <ORDER_HEADER_ADDRESS>

           <ORDER_HEADER_ADDRESS>
               <ADDRESS_TYPE>DEP</ADDRESS_TYPE>
               <ADDRESS_ID>OBS</ADDRESS_ID>
               <ADDRESS_NAME>OBS Logistics</ADDRESS_NAME>
               <ADDRESS_LINE1>Southern Gateway</ADDRESS_LINE1>
               <ADDRESS_LINE2>Speke Boulevard</ADDRESS_LINE2>
               <ADDRESS_LINE3></ADDRESS_LINE3>
               <ADDRESS_TOWN>Liverpool</ADDRESS_TOWN>
               <ADDRESS_COUNTY>Merseyside</ADDRESS_COUNTY>
               <ADDRESS_COUNTRY_CODE>GB</ADDRESS_COUNTRY_CODE>
               <ADDRESS_POSTCODE>L24 9HZ</ADDRESS_POSTCODE>
               <ADDRESS_CUST_GROUP>OBS</ADDRESS_CUST_GROUP>  	
               <OH_ADDRESS_CONTACTS>

The <ORDER_HEADER_ADDRESS> complex type element includes the address attributes for either the initial point of collection/loading or the final point of delivery/unloading.

The <ADDRESS_TYPE> simple type element is mandatory and must be either:

  • 'DEP' - Indicates that the address represents the initial 'DEP'arture location of the order.
  • 'DEL' - Indicates that the address represents the final 'DEL'ivery location of the order.

The <ADDRESS_TOWN> item and <ADDRESS_POSTCODE> elements will not be validated and will be accepted regardless of data content.

The <ADDRESS_ID> item is mandatory and can be sent as a unique account identifier for the sender/recipient or it can be sent with the word 'UNKNOWN' which will allow CTMS to generate this unique address identifier where necessary.

The system will initially cross check the received Address Name and Address Postcode in the order file to see if any locations exist for that address name and postcode (to narrow down the number of records to validate), if so it will identify against all other address attributes (Address lines, town/suburb, county/state, country code) to see if there is an existing EXACT match.

If an existing EXACT address match is found the existing CTMS location code will be used against the received order - as the address detail matches all attributes. If any difference is found a new location is generated with the data received, generating a new location ID in the following format:

  • Characters 1 to 8: Characters 1 to 8 from <ADDRESS_NAME>
  • Character 9: '-'
  • Characters 10 to 12: Sequence number 001 to 999

The location ID generated will be a maximum of 12 characters, for example: 

<ADDRESS_ID>UNKNOWN<ADDRESS_ID>
<ADDRESS_NAME>OBS Logistics</ADDRESS_NAME>
<ADDRESS_POSTCODE>L24 9HZ</ADDRESS_POSTCODE>

Would create location code 'OBS Logi-001'.

Also note that new addresses for existing locations can be provided for each order and new locations can be created for the specific address that may be provided.

Once a location is created it will not be updated via the order upload process, any amendments can be carried out manually or via the import of a 'CSV' file.

New locations will only be created for the address details provided.


Order Header Address Contact <OH_ADDRESS_CONTACT>

 <OH_ADDRESS_CONTACT>
   <ADDRESS_CONTACT_TYPE>O</ADDRESS_CONTACT_TYPE>
   <ADDRESS_CONTACT_FORENAME>Yard Manager</ADDRESS_CONTACT_FORENAME>
   <ADDRESS_CONTACT_SURNAME></ADDRESS_CONTACT_SURNAME>
   <ADDRESS_CONTACT_NUMBER>0151 123 5678</ADDRESS_CONTACT_NUMBER>
   <ADDRESS_EMAIL>[email protected]</ADDRESS_EMAIL>

For each address an optional <OH_ADDRESS_CONTACT> complex type element can be received. This element must only occur once for within a <OH_ADDRESS_CONTACT>.

The <ADDRESS_CONTACT_TYPE> simple type element is mandatory where the <OH_ADDRESS_CONTACT> is used and indicates if the contact information is to be permanently associated to the address master data (value 'L') or whether it is only related to that particular address for the instance of that particular order (value 'O'). For this implementation 'O'rder type contacts should always be received.

If there is no contact information for the loading location then this element is not required for the "DEP" address type.

The other simple type elements are optional.

Order Sub-references <ORDER_SUB_REFS>

        <ORDER_DETAILS>
            <ORDER_SUB_REFS>
                <ORDER_SUB_REF> <ORDER_SUB_REF>
                    <SUB_REF_IDENTIFIER> ... </SUB_REF_IDENTIFIER> [1]
                    <SUB_REF_IDENTIFIER> ... </SUB_REFERENCE> [1]
                </ORDER_SUB_REF>
            </ORDER_SUB_REFS>
        <ORDER_DETAIL>

This <ORDER_SUB_REFS> section is optional, and allows you to store additional references for an order.

The section must include at least one instance of the <ORDER_SUB_REF> complex type element.

The <SUB_REF_IDENTIFIER> simple type must match up to a configured order sub-reference type. These are maintained by your system administrator in the CTMS Imports screen, on the Decodes tab, type "XML_REFERENCE". Include the CODE here, not the NAME.

The <SUB_REF_IDENTIFIER> simple type is the value you want to store against that reference. The value can be anything at all, but to 512 characters long. These values are not validated.

You can add as many order sub references as you need for the order.

Note Note:
  • If system parameter USE_XML_ORDER_SUB_REFS is set to "Y", sub references will be automatically generated from lane comments that begin with ORDER_REFS:", followed by a comma-delimited list of sub reference names and values. Otherwise this section will contain the order sub references for this order.
  • A sub reference of TRIP_TYPE may be automatically generated based on EDI parameter INC_TRIP_TYPE being set. In this case, the value may be set to
    • COL - if the from location is the load location of the trip stop and the load location type is not RDC
    • TRUNK - if the from location is the load location and the order to location is not the unload location
    • XDOCK_DEL - if the order to location is equal to the unload location, and there are onward trips.
    • DIRECT_DEL - if the order to location is equal to the unload location, and there are no onward trips.
  • If the sub-ref name DELIVERY_METHOD is present, the value will be translated for the carrier.

Several static sub-references are supported.

The following will automatically store data as order information, for contact purposes:

  • SMS_ADDRESS_1
  • SMS_ADDRESS_2
  • SMS_ADDRESS_3
  • SMS_ADDRESS_4
  • EMAIL_ADDRESS

Depending on which values you provide here, the order will be stamped with contact preferences:

  • E - Email only.
  • S - SMS Only
  • B - Both

Note Note: SMS sending from CTMS is supported at additional transaction cost per message.

The reference ORDER_WMS_STATUS may be used to update a source system status against the trip. Values are:

  • OPEN STAGED
  • IN PROGRESS STAGED
  • CLOSED STAGED
  • OPEN
  • IN PROGRESS
  • CLOSED



Order Detail <ORDER_DETAIL>

           <ORDER_DETAIL>
             <DETAIL_TYPE>S</DETAIL_TYPE>
             <PRODUCT_TYPE_DESC>CANTEEN</PRODUCT_TYPE_DESC>
             <DU_TYPE>20x9</DU_TYPE>
             <ITEM_IDENTIFIER>ABC004783</ITEM_IDENTIFIER>
             <ITEM_DESCRIPTION>CARTON</ITEM_DESCRIPTION>
             <ITEM_AKA_CODE>10*20*30</ITEM_AKA_CODE>
             <LIFTS>1</LIFTS>
             <WEIGHT>5.37</WEIGHT>
             <ORDERED>1</ORDERED>
             <TO_DELIVER>1</TO_DELIVER>
             <LENGTH>10</LENGTH>
             <WIDTH>20</WIDTH>
             <HEIGHT>30</HEIGHT>
             <COMMODITY_ID>DG</COMMODITY_ID>
             <CLASS_ID>2.1</CLASS_ID>
        </ORDER_DETAIL>

The <ORDER_DETAIL> complex element is mandatory and can repeat but must occur at least once to form a valid CTMS order.

The order details will be used to generate both the individual dispatch box/carton detail (per unique barcode) and also the higher level summary order detail line level.

The <DETAIL_TYPE> simple element is mandatory and must be received as either:

  • 'D' - Represents a CTMS order detail line - summary level of the total of unique package types.
  • 'S' - Represents a CTMS order detail item - the lowest level entry for each individual carton/box.

Note that the DU types (i.e. for the order lines) and its items, just the DU types (if items are not being recorded) or just the items may be provided.

If just items are provided then the DU types and thus the order lines may be generated automatically for the order based on the types of items that have been provided.

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

The <DU_TYPE> simple element is optional and 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_IDENTIFIER> simple element is mandatory and will not be validated although it must be a maximum of 15 alphanumeric characters.

The <ITEM_DESCRIPTION> and <ITEM_AKA_CODE simple type elements are an optional freetext tags and can be used as required.

One of the <ORDERED> and <TO_DELIVER> simple type elements will be mandatory and must be received with a numeric integer value. This represents the number of items reflected by the <ORDER_DETAIL> segment received

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.

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


Order Hazardous Details

          <ORDER_HAZARDOUS_DETAILS>
             <ORDER_HAZARDOUS_DETAIL>

The <ORDER_HAZARDOUS_DETAILS> complex type element is optional and can be provided if required.

If this element is used then one or more <ORDER_HAZARDOUS_DETAIL> complex type elements is mandatorily required.


Order Hazardous Detail

           <ORDER_HAZARDOUS_DETAIL>
<UN_NUMBER>1089</UN_NUMBER>
             <HAZARDOUS_QTY>1</HAZARDOUS_QTY>
             <HAZARDOUS>Y</HAZARDOUS>
             <HAZARDOUS_DESCRIPTION>CARBONYL SULFIDE</HAZARDOUS_DESCRIPTION>
           </ORDER_HAZARDOUS_DETAIL>

The <ORDER_HAZARDOUS_DETAIL> complex type element and all its simple type elements are mandatory. The elements are not validated against CTMS master data and will be stored as received.


XML Outbound Order File Structure

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.

Multiple EDI flows may be active to process XML files at different stages of processing.

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


TripOrder File

<OBS_XML>
 <EVENT>
 <EVENT_HEADER>
 <EVENT_DETAIL>

The same XSD file format is used for files from CTMS as per files into CTMS.

These files may contain more data in each section than are required in the inbound order files.

For example, an outbound file may contain data about the trip, its stops, each order on each stop and the DU types and/or items on each order.


Export depends on the events that are being exported, controlled by EDI Parameters on the API EDI process:

  • API_ARR
  • API_COL
  • API_DEL
  • API_DEP
  • API_ORD
  • API_TRP

Additional EDI parameters are also present (described in detail in the following sections):

  • INCLUDE_CDATA_TAG - affects variable text data entry from the execution level - should it be wrapped to prevent interface errors?
  • SEND_AND_FORGET - affects the basic interface - should the message be sent with no expectation of explicit acknowledgement back from the destination?
  • PRINT_STOP_PID
  • PRINT_ROUTE_CODE
  • INCLUDE_ORDER_STATUS
  • SEND_DEL_TYPE_CODE
  • EXPORT_SERVICES
  • INC_TRIP_TYPE
  • INC_TRIP_ACTION
  • INC_PACKED_TO_DEL
  • INCLUDE_SAP_LINE_NOS
  • INCLUDE_REASON_CODES
  • INCLUDE_NON_CON_CODES
  • INCLUDE_TRACK_REF
  • INCLUDE_ITEM_DELIVER
  • INCLUDE_REASON_TYPE

Export may also include debrief-level information, depending on the type of event, and where the order is up to.

The Export will be of Trip Type if related to a trip, and Order type (similar to the above) for Order-type events.

Trip type events:

  • TRP - any changes to or creation of a trip.
  • ARR - Arrival at any stop.
  • DEP - departure at any stop.

Order type events:

  • ORD - any changes to or creation of an order.
  • CAN - if an order is cancelled.
  • COL - if an order is collected.
  • DEL - if an order is delivered.

In general, trip-type events include everything that an Order-type event would include, but with the following additions:

  • TRIP_DETAIL
  • STOP_DETAIL
  • STOP_SIGNATURE (if LOTS_INC_STOP_SIGNATURE = "Y")
  • ORDER_HEADER_TMS


As an indication of what may change, please see the below sections.


TRIP_DETAIL

   <HAULIER> ... </HAULIER> [0..1]
   <HAULIER_NAME> ... </HAULIER_NAME> [0..1]
   <HAULIER_TYPE> ... </HAULIER_TYPE> [0..1]
   <TRACKING> ... </TRACKING> [1]
   <TRIP_SCHEDULE> ... </TRIP_SCHEDULE> [0..1]
   <DRIVER> ... </DRIVER> [0..1]
   <DRIVER_NAME> ... </DRIVER_NAME> [0..1]
   <DRIVER_CONTACT> ... </DRIVER_CONTACT> [0..1]
   <TRACTOR> ... </TRACTOR> [0..1]
   <TRACTOR_LAT> ... </TRACTOR_LAT> [0..1]
   <TRACTOR_LON> ... </TRACTOR_LON> [0..1]
   <COST_CENTRE> ... </COST_CENTRE> [0..1]
   <TRIP_STATUS> ... </TRIP_STATUS> [0..1]
   <TRIP_REF> ... </TRIP_REF> [0..1]
   <TRIP_TRAILER_ID> ... </TRIP_TRAILER_ID> [0..1]
   <TRIP_TRAILER_TYPE> ... </TRIP_TRAILER_TYPE> [0..1]
   <TRIP_DISTANCE> ... </TRIP_DISTANCE> [0..1]
   <FUEL_DRAWN> ... </FUEL_DRAWN> [0..1]
   <OWNING_DEPOT> ... </OWNING_DEPOT> [0..1]
   <CONTAINER_NO> ... </CONTAINER_NO> [0..1]
   <SEAL_NO> ... </SEAL_NO> [0..1]
   <EFX_NUMBER> ... </EFX_NUMBER> [0..1]
   <START_ODOMETER> ... </START_ODOMETER> [0..1]
   <END_ODOMETER> ... </END_ODOMETER> [0..1]
   <ACTUAL_TRIP_DISTANCE> ... </ACTUAL_TRIP_DISTANCE> [0..1]
   <ROUTE_CODE> ... </ROUTE_CODE> [0..1]
   <COST_PER_TONNE> ... </COST_PER_TONNE> [0..1]
   <COST> ... </COST> [0..1]
   <COST_REASON> ... </COST_REASON> [0..1]
   <AUDIT_ID> ... </AUDIT_ID> [0..1]
   <TRIP_SUB_REFS> ... </TRIP_SUB_REFS> [0..1]
Note Note:
  • Carrier will be modified if the carrier type is 3PL. This will be exported in the HAULIER tag.
  • TRACKING tag will only be populated from trips that are tracked through Microlise.
  • The information sent to MICROLISE is extremely limited in this section.
  • ROUTE_CODE will only be populated if the EDI parameter PRINT_ROUTE_CODE is populated or the TRIP_ORDER_XSD_VERS system parameter is "2.5". If the system parameter INCL_ROUTE_CODE is set, then this will be instead populated with the Baxter route code.
  • AUDIT_ID is a unique ID appended to the message for external tracking purposes.


TRIP_SUB_REF

<TRIP_SUB_REF>
   <SUB_REF_IDENTIFIER> ... </SUB_REF_IDENTIFIER> [1]
   <SUB_REFERENCE> ... </SUB_REFERENCE> [1]
</TRIP_SUB_REF>
Note Note:
  • If system parameter INC_TRIP_ACTION is "Y", a trip sub reference will be generated based on the action of the event.


STOP_DETAIL

   <STOP_REF> ... </STOP_REF> [0..1]
   <STOP_TYPE> ... </STOP_TYPE> [0..1]
   <STOP_LOCATION_TYPE> ... </STOP_LOCATION_TYPE> [0..1]
   <STOP_LOCATION_ID> ... </STOP_LOCATION_ID> [0..1]
   <STOP_LOCATION_NAME> ... </STOP_LOCATION_NAME> [0..1]
   <STOP_ADDR_LINE1> ... </STOP_ADDR_LINE1> [0..1]
   <STOP_ADDR_LINE2> ... </STOP_ADDR_LINE2> [0..1]
   <STOP_ADDR_LINE3> ... </STOP_ADDR_LINE3> [0..1]
   <STOP_TOWN> ... </STOP_TOWN> [0..1]
   <STOP_COUNTY> ... </STOP_COUNTY> [0..1]
   <STOP_COUNTRY_CODE> ... </STOP_COUNTRY_CODE> [0..1]
   <STOP_POSTCODE> ... </STOP_POSTCODE> [0..1]
   <STOP_CONTACT_NAME> ... </STOP_CONTACT_NAME> [0..1]
   <STOP_CONTACT_PHONE> ... </STOP_CONTACT_PHONE> [0..1]
   <STOP_BREAK_DURATION> ... </STOP_BREAK_DURATION> [0..1]
   <STOP_PREV_DIST> ... </STOP_PREV_DIST> [0..1]
   <STOP_ACTUAL_PREV_DIST> ... </STOP_ACTUAL_PREV_DIST> [0..1]
   <STOP_TRAILER_ID> ... </STOP_TRAILER_ID> [0..1]
   <STOP_LAT> ... </STOP_LAT> [0..1]
   <STOP_LON> ... </STOP_LON> [0..1]
   <STOP_PLANNED_ARRIVAL_DATE> ... </STOP_PLANNED_ARRIVAL_DATE> [0..1]
   <STOP_PLANNED_DEPARTURE_DATE> ... </STOP_PLANNED_DEPARTURE_DATE> [0..1]
   <STOP_ETA_DATE> ... </STOP_ETA_DATE> [0..1]
   <STOP_ETA_AT_DATE> ... </STOP_ETA_AT_DATE> [0..1]
   <STOP_EARLIEST_BOOKED_DATE> ... </STOP_EARLIEST_BOOKED_DATE> [0..1]
   <STOP_ACTUAL_ARRIVAL_DATE> ... </STOP_ACTUAL_ARRIVAL_DATE> [0..1]
   <STOP_ACTUAL_DEPARTURE_DATE> ... </STOP_ACTUAL_DEPARTURE_DATE> [0..1]
   <STOP_ODO_READING> ... </STOP_ODO_READING> [0..1]
   <STOP_FUEL> ... </STOP_FUEL> [0..1]
   <STOP_EMAIL> ... </STOP_EMAIL> [0..1]
   <STOP_BARCODE> ... </STOP_BARCODE> [0..1]
   <STOP_PID> ... </STOP_PID> [0..1]
   <STOP_COUNTRY_NAME> ... </STOP_COUNTRY_NAME> [0..1]
   <WAREHOUSE_LOAD> ... </WAREHOUSE_LOAD> [0..1]
Note Note:
  • Dates are in XML DateTime format.
  • ETA and ACTUAL Dates will be populated from execution-based systems.
  • STOP_PID will only be populated for LOTS and CIM flows in one format, or if EDI parameter PRINT_STOP_PID is set to "Y" in a different format. This second format should not be enabled for LOTS interfaces.


STOP_SIGNATURE

This section will only be generated if system parameter LOTS_INC_STOP_SIGNATURE is set to "Y". 

<STOP_SIGNATURE>
   <SIGNATURE> ... </SIGNATURE> [0..1]
   <SIGNED_BY> ... </SIGNED_BY> [0..1]
</STOP_SIGNATURE>


ORDER_HEADER

   <ORDER_TRANSACTION_DATE> ... </ORDER_TRANSACTION_DATE> [1]
   <ORDER_TYPE> ... </ORDER_TYPE> [0..1]
   <WMS_WAREHOUSE> ... </WMS_WAREHOUSE> [0..1]
   <WMS_OWNER> ... </WMS_OWNER> [0..1]
   <SO_REF> ... </SO_REF> [0..1]
   <ORIG_SO_REF> ... </ORIG_SO_REF> [0..1]
   <TMS_REF> ... </TMS_REF> [0..1]
   <PO_REF> ... </PO_REF> [0..1]
   <BOOK_REF> ... </BOOK_REF> [0..1]
   <BOOK_DATE> ... </BOOK_DATE> [0..1]
   <SPECIAL_INSTR> ... </SPECIAL_INSTR> [0..1]
   <ORDER_COMMENTS> ... </ORDER_COMMENTS> [0..1]
   <ORDER_HEADER_TMS> ... </ORDER_HEADER_TMS> [0..1]
   <ORDER_HEADER_ADDRESSES> ... </ORDER_HEADER_ADDRESSES> [0..1]
   <ORDER_HEADER_CONFIRM> ... </ORDER_HEADER_CONFIRM> [0..1]
   <CUSTOMER_ID> ... </CUSTOMER_ID> [0..1]
   <CUSTOMER_NAME> ... </CUSTOMER_NAME> [0..1]
   <ORDER_STATUS> ... </ORDER_STATUS> [0..1]
   <DESTINATION_ORDER> ... </DESTINATION_ORDER> [0..1]
   <DESTINATION_DRIVER> ... </DESTINATION_DRIVER> [0..1]
   <DESTINATION_VEHICLE> ... </DESTINATION_VEHICLE> [0..1]
   <ORDER_SERVICES> ... </ORDER_SERVICES> [0..1]
Note Note:
  • SO_REF will be populated with the External reference of the order. This may be modified to remove any rebooking suffix if system parameter ORD_RBO_PREFIX is set to "Y"
  • ORDER_STATUS will only be included if the EDI parameter INCLUDE_ORDER_STATUS is set to "Y". Further, if system parameter INCLUDE_FAILED_ORDERS is set to "Y" and the order status is FAILED, this will be changed to CANCELLED instead.
  • DESTINATION_ORDER, DESTINATION_DRIVER and DESTINATION_VEHICLE will only be present if order sub references exist of those names.


ORDER_HEADER_TMS

<ORDER_HEADER_TMS>
   <SHIPMENT_ID> ... </SHIPMENT_ID> [0..1]
   <TMS_ORDER_SCHEDULE> ... </TMS_ORDER_SCHEDULE> [0..1]
   <TMS_HAULAGE_ACTIVITY> ... </TMS_HAULAGE_ACTIVITY> [0..1]
   <TMS_HAULAGE_TYPE> ... </TMS_HAULAGE_TYPE> [0..1]
   <EARLY_AVAIL_DATE> ... </EARLY_AVAIL_DATE> [1]
   <LATE_AVAIL_DATE> ... </LATE_AVAIL_DATE> [1]
   <EARLY_DEL_DATE> ... </EARLY_DEL_DATE> [1]
   <LATE_DEL_DATE> ... </LATE_DEL_DATE> [1]
   <TMS_GROUP_NAME> ... </TMS_GROUP_NAME> [0..1]
   <TMS_DELIVERY_TYPE> ... </TMS_DELIVERY_TYPE> [0..1]
   <TMS_COST_CENTRE> ... </TMS_COST_CENTRE> [0..1]
   <SD_TEMP_COMBO> ... </SD_TEMP_COMBO> [0..1]
   <SD_POD_BY> ... </SD_POD_BY> [0..1]
   <KEY_CODE> ... </KEY_CODE> [0..1]
   <REVENUE> ... </REVENUE> [0..1]
   <COST> ... </COST> [0..1]
   <COST_PER_TONNE> ... </COST_PER_TONNE> [0..1]
   <HAULIER> ... </HAULIER> [0..1]
   <TRAILER_TYPE> ... </TRAILER_TYPE> [0..1]
   <ROUTE_CODE> ... </ROUTE_CODE> [0..1]
   <EFX_NUMBER> ... </EFX_NUMBER> [0..1]
   <TRANSPORT_MODE> ... </TRANSPORT_MODE> [0..1]
   <TRANSPORT_STATUS> ... </TRANSPORT_STATUS> [0..1]
   <RPE_QTY> ... </RPE_QTY> [0..1]
   <ACTUAL_RPE_QTY> ... </ACTUAL_RPE_QTY> [0..1]
   <WEIGHT> ... </WEIGHT> [0..1]
   <ACTUAL_WEIGHT> ... </ACTUAL_WEIGHT> [0..1]
   <VOLUME> ... </VOLUME> [0..1]
   <ACTUAL_VOLUME> ... </ACTUAL_VOLUME> [0..1]
   <FOOTPRINT> ... </FOOTPRINT> [0..1]
   <ACTUAL_FOOTPRINT> ... </ACTUAL_FOOTPRINT> [0..1]
   <TOTAL_PRICE> ... </TOTAL_PRICE> [0..1]
</ORDER_HEADER_TMS>
Note Note:
  • TMS_DELIVERY_TYPE is set to the full delivery type if the EDI parameter SEND_DEL_TYPE_CODE is set to "Y". Otherwise the short code associated to the delivery type is sent.


ORDER_SERVICES

This section is only populated if the EDI parameter EXPORT_SERVICES is set to "Y", or if this is set to "C" and the event is "CAN" or "DEL". 

<ORDER_SERVICE>
   <SERVICE_ID> ... </SERVICE_ID> [1]
   <SERVICE_NAME> ... </SERVICE_NAME> [1]
   <SERVICE_QTY> ... </SERVICE_QTY> [1]
   <SERVICE_VALUE> ... </SERVICE_VALUE> [1]
</ORDER_SERVICE>


ORDER_DETAIL

The details sent in this section are subject to configuration:

  • Order Lines are sent if LOTS_SEND_LINE_ITEMS = "Y", or the value is "N" and there are no order items.
  • Order Items are sent if LOTS_SEND_LINE_ITEMS = "Y", or the value is "N" and there are order items.
<ORDER_DETAIL>
   <DETAIL_TYPE> ... </DETAIL_TYPE> [1]
   <DETAIL_ID> ... </DETAIL_ID> [0..1]
   <PRODUCT_TYPE> ... </PRODUCT_TYPE> [0..1]
   <PRODUCT_TYPE_DESC> ... </PRODUCT_TYPE_DESC> [0..1]
   <DU_TYPE> ... </DU_TYPE> [0..1]
   <ITEM_IDENTIFIER> ... </ITEM_IDENTIFIER> [1]
   <ITEM_DESCRIPTION> ... </ITEM_DESCRIPTION> [0..1]
   <PALLET_ID> ... </PALLET_ID> [0..1]
   <ITEM_AKA_CODE> ... </ITEM_AKA_CODE> [0..1]
   <ITEM_FACTOR> ... </ITEM_FACTOR> [0..1]
   <LIFTS> ... </LIFTS> [0..1]
   <STACK> ... </STACK> [0..1]
   <RPE_QTY> ... </RPE_QTY> [0..1]
   <ACTUAL_RPE_QTY> ... </ACTUAL_RPE_QTY> [0..1]
   <WEIGHT> ... </WEIGHT> [0..1]
   <ACTUAL_WEIGHT> ... </ACTUAL_WEIGHT> [0..1]
   <VOLUME> ... </VOLUME> [0..1]
   <ACTUAL_VOLUME> ... </ACTUAL_VOLUME> [0..1]
   <FOOTPRINT> ... </FOOTPRINT> [0..1]
   <ACTUAL_FOOTPRINT> ... </ACTUAL_FOOTPRINT> [0..1]
   <ORDERED> ... </ORDERED> [0..1]
   <PACKED> ... </PACKED> [0..1]
   <TO_DELIVER> ... </TO_DELIVER> [0..1]
   <DELIVERED> ... </DELIVERED> [0..1]
   <SAP_LINE_NO> ... </SAP_LINE_NO> [0..1]
   <SHIPMENT_DETAIL> ... </SHIPMENT_DETAIL> [0..1]
   <REASON_CODES> ... </REASON_CODES> [0..1]
   <DIM_WEIGHT> ... </DIM_WEIGHT> [0..1]
   <ACTUAL_DIM_WEIGHT> ... </ACTUAL_DIM_WEIGHT> [0..1]
   <TRACKING_REFS> ... </TRACKING_REFS> [0..1]
   <DU_DESCRIPTION> ... </DU_DESCRIPTION> [0..1]
   <DU_CATEGORY> ... </DU_CATEGORY> [0..1]
   <PLANNED_CASES> ... </PLANNED_CASES> [0..1]
   <ACTUAL_CASES> ... </ACTUAL_CASES> [0..1]
   <SCAN_TYPE> ... </SCAN_TYPE> [0..1]
   <LENGTH> ... </LENGTH> [0..1]
   <WIDTH> ... </WIDTH> [0..1]
   <HEIGHT> ... </HEIGHT> [0..1]
   <COMMODITY_ID> ... </COMMODITY_ID> [0..1]
   <CLASS_ID> ... </CLASS_ID> [0..1]
   <WMS_LOCATION> ... </WMS_LOCATION> [0..1]
   <LONG_DESCRIPTION> ... </LONG_DESCRIPTION> [0..1]
   <ORDER_DETAIL_TYRE> ... </ORDER_DETAIL_TYRE> [0..1]
   <ITEM_PRICE> ... </ITEM_PRICE> [0..1]
</ORDER_DETAIL>
Note Note:
  • DETAIL_TYPE will be "D" if generated from Order Lines, and "S" if generated from Order Items.
  • For D lines
    • ITEM_IDENTIFIER will be the DU Type
    • ITEM_DESCRIPTION will the DU Type description for "D" lines
    • RPE_QTY will include Despatched and Packed REP if the EDI Parameter INC_PACKED_TO_DEL is set to "Y", other wise this will just be the Actual RPE and RPE qty.
    • PACKED will be populated if the order has been packed.
    • TO_DELIVER will be populated if the order has been collected.
    • DELIVERED will be present and populated if the order has been delivered to its final destination.
    • SAP_LINE_NO will only be present and populated if the EDI Parameter INCLUDE_SAP_LINE_NOS is "Y" and there is a SAP line number against the order line.
    • REASON_CODES will be included if there are non-conformity reason codes against the order line for the API interface.
    • REASON_CODES will be included for other flows if EDI Parameters INCLUDE_REASON_CODES and INCLUDE_NON_CON_CODES are set. Warning Warning: These should NOT be set against the API process.
    • TRACKING_REFS will be included if the EDI Parameter INCLUDE_TRACK_REF is set to "Y".
  • For S lines
    • ITEM_IDENTIFIER will be the Item Identifier, unless the customer has specified that an alternative item identifier is used and one is provided against the item. If system parameter USE_PALLET_ID_XML is set to "Y", then the Pallet ID of the item record will be used instead.
    • PALLET_ID will only be populated if system parameter SEND_PALLET_ID_XML is set to "Y".
    • ORDERED will only be present and populated if the value is not null.
    • TO_DELIVER will only be present and populated if the value is null i.e. the order item has been collected.
    • DELIVERED will only be present and populated if the value is not null i.e. the order item has been delivered and EDI parameter INCLUDE_ITEM_DELIVER is set to "Y", or this is sent through the API.
    • SAP_LINE_NO will only be present and populated if the EDI Parameter INCLUDE_SAP_LINE_NOS is "Y" and there is a SAP line number against the order line.
    • REASON_CODES will be included if there are non-conformity reason codes against the order line for the API interface.
    • REASON_CODES will be included for other flows if EDI Parameters INCLUDE_REASON_CODES and INCLUDE_NON_CON_CODES are set. Warning Warning: These should NOT be set against the API process.


TRACKING_REFS

TRACKING_REFS will be included if the EDI Parameter INCLUDE_TRACK_REF is set to "Y". 

<TRACKING_REF>
   <UNIT_TRACKING_REF> ... </UNIT_TRACKING_REF> [1]
   <UNIT_TRACKING_NO> ... </UNIT_TRACKING_NO> [1]
</TRACKING_REF>


ORDER_DETAIL_TYRE

For TYRE-based systems 

<ORDER_DETAIL_TYRE>
	<WPX_PRODUCT_ID> ... </WPX_PRODUCT_ID> [1]
	<POSITION> ... </POSITION> [1]
	<LOCATION> ... </LOCATION> [1]
	<PRICE> ... </PRICE> [1]
	<CUSTOMER_VEHICLE> ... </CUSTOMER_VEHICLE> [1]
	<AUTHORITY_CODE> ... </AUTHORITY_CODE> [1]
	<WORK_TYPE> ... </WORK_TYPE> [1]
	<PRESSURE> ... </PRESSURE> [1]
	<TREAD_DEPTH> ... </TREAD_DEPTH> [1]
	<CASING> ... </CASING> [1]
	<CASING_DESTINATION> ... </CASING_DESTINATION> [1]
	<NEW_REMOULD> ... </NEW_REMOULD> [1]
	<REGROOVED> ... </REGROOVED> [1]
	<TYRE_SERIAL_NO> ... </TYRE_SERIAL_NO> [1]
	<REMOVAL_REASON> ... </REMOVAL_REASON> [1]
	<WORK_TYPES> ... </WORK_TYPES> [1]
	<SERVICES_SUPPLIED> ... </SERVICES_SUPPLIED> [1]
	<BARCODE> ... </BARCODE> [1]
	<TORQUE> ... </TORQUE> [1]
</ORDER_DETAIL_TYRE>

ORDER_REASON_CODE

<ORDER_REASON_CODE>
   <RC_TYPE> ... </RC_TYPE> [1]
   <RC_CODE> ... </RC_CODE> [1]
   <RC_DESCRIPTION> ... </RC_DESCRIPTION> [1]
   <RC_COMMENT> ... </RC_COMMENT> [0..1]
</ORDER_REASON_CODE>
Note Note:
  • For reason codes included for Order Item non-conformities, RC_TYPE will only be included if EDI parameter INCLUDE_REASON_TYPE is set to "Y", and will always then be "NONC"


ORDER_HEADER_TYRE

For TYRE-based systems 

<ORDER_HEADER_TYRE> 
      <CUSTOMER_VEHICLE> ... </CUSTOMER_VEHICLE> [0..1]
      <AUTHORITY_CODE> ... </AUTHORITY_CODE> [0..1]
</ORDER_HEADER_TYRE>


ORDER_VEHICLE

For TYRE-based systems 

<ORDER_VEHICLE> - for TYRE-based systems only
      <VEHICLE_ID> ... </VEHICLE_ID> [1]
      <MAKE> ... </MAKE> [1]
      <MODEL> ... </MODEL> [1]
      <ODO> ... </ODO> [1]
      <DESCRIPTION> ... </DESCRIPTION> [1]
      <LAST_INSPECTION_DATE> ... </LAST_INSPECTION_DATE> [1]
      <VEHICLE_CONFIG_ID> ... </VEHICLE_CONFIG_ID> [1]
      <VEHICLE_CONFIG> ... </VEHICLE_CONFIG> [1]
      <EPOD_SERVICE_ID> ... </EPOD_SERVICE_ID> [0..1]
</ORDER_VEHICLE>


System Parameters affecting XML Production

System parameters affecting content in TripOrder XML

Parameter Description Level
CUST_UPDATE_ORDER_LINES Update Orders CUSTOMER
EPOD_SIGNATURE_STORAGE Store signature received from C-ePOD COST_CENTRE
IMP_OVERRIDE_SOURCE_REF Set source system and control additional functionality in ORD_LINE_ITM CSV order import SYSTEM
INCL_ROUTE_CODE Include Baxter Route code and delivery method COST_CENTRE
INCLUDE_FAILED_ORDERS Include Failed Orders as CANCELLED for API COST_CENTRE
LOTS_ADD_DEBRIEF LOTS Additional Debrief Details COST_CENTRE
LOTS_DEL_CUST_SIGNATORY Controls if DEL messages for LOTS require an actual signatory - Y to hold messages. COST_CENTRE
LOTS_INC_ORDER_HEADER_CONFIRM Includes the ORDER_HEADER_CONFIRM section in the DEL file for LOTS. SYSTEM - only LOTS, DEL event
LOTS_INC_STOP_SIGNATURE Indicates if the STOP_SIGNATURE section will be displayed in the DEL outbound files to LOTS. SYSTEM - only for LOTSC
LOTS_INC_STOP_TYPE_DESC Include STOP-TYPE_DESC tag in XML SYSTEM - ONLY FOR LOTS process
LOTS_SEND_WHEN_VEHICLE_SCANNED List of LOTS message types that will be held until a vehicle scan is received for the order. COST_CENTRE
MIC_ADD_STOP_BARCODE Include new tag STOP_BARCODE on Microlise outbound xml SYSTEM - only for process MIC
OMS_FOOTPRINT_FOR_VOLUME Will the footprint of the order line be include in the VOLUME item for the outbound XML file for the despatch units instead of the cubic volume (Y/N)? COST_CENTRE
ORD_NO_DEL_FOR_FAILS Controls if DEL messages are generated for FAILED orders - Y to prevent, C to send as CAN COST_CENTRE
ORD_RBO_PREFIX Is the rebook prefix stripped for LOTS? SYSTEM
ORD_TEMPERATURE_COMBO Use Temperature Combo to determine if the customer reference should be highlighted. COST_CENTRE
SEND_LINE_ITEM_TO_LOTS Send Line Item To LOTS. Y - send both Order Line (D) and Item (S) records. N - Checks for Items and, if there are any, sends Item (S) records, else Order Line (D) records. SYSTEM
SEND_PALLET_ID_XML Send Pallet ID tag in xml COST_CENTRE
STOP_PID LOTS - is STOP_PID included in the extract SYSTEM - only for LOTS/CIM
TIME_ZONE_ACTIVE Time Zone Active SYSTEM
TMS_OTBOUND_SO_REF Controls the outbound format for SO_REF in LOTSC CUSTOMER
TRIP_ORDER_XSD_VERS Version of TRIP XSD being used. SYSTEM
TRM_DESP_FOR_DEL Maintain the Actual Despatched Quantity for a Delivery Trip in Trip Debrief (Y/N). COST_CENTRE
UNI_LOCATION Location for Unilever SYSTEM
USE_ORDER_ADDRESSEE Will the addressee name be used for the order? (Y/N) COST_CENTRE
USE_PALLET_ID_XML Use Pallet ID instead of item identifier in XML Outbound files COST_CENTRE
USE_XML_ORDER_SUB_REFS Print order sub refs on outbound XML COST_CENTRE
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/MTS/index.php?title=Interface_-_CTMS_XML_EDI_Order_Flow_Guide&oldid=8006’