TripOrder Interface XML

From CTMS
(Redirected from Trip/Order Interface XML)

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 (N.B. not all of the sections and elements that are available in the XSD file format are listed): 

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

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

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_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_TRANSACTION_DATE>2015-05-31T12:52:13</ORDER_TRANSACTION_DATE>
     <ORDER_TYPE>O</ORDER_TYPE>
     <WMS_OWNER>OBS</WMS_OWNER>
     <SO_REF>45012345678900</SO_REF>
     <BOOK_REF>ANX793427404</BOOK_REF>
          <SPECIAL_INSTR>Please call Dave on arrival</SPECIAL_INSTR>
          <ORDER_HEADER_TMS>
          <ORDER_HEADER_ADDRESSES>

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

       <ORDER_DETAILS>
           <ORDER_DETAIL>

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

It must include at least one instance of the <ORDER_DETAIL> complex type element, for the order to contain at least one detail line/item.


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.

Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/MTS/index.php?title=TripOrder_Interface_XML&oldid=7687’