Print Using This Manual


Overview

This manual provides information for each of Tech Data’s XML web service transactions. The submission and response structures, content and constraints are provided as well as example documents. Each field of all documents are detailed in easy to use tables.

Each XML message type received by Tech Data's XML web service will cause a response message to be sent back to the originator.  Each transaction (Availability, Price and Availability, Order…) has its own unique submission and response document format. The Order Status message can generate one of two different response formats depending on the content of the PurposeCode element of the Order Status submission.

Each response format contains elements for possible error messaging that may need to be returned to the sender.  The <ErrorInfo> elements are optional in each of the response formats since it is not anticipated that error message data will need to be returned in each response message.  In some instances, a response will contain both valid expected data and error message data within the same message.  For example, a customer submits a Price and Availability request containing three different item numbers.  The Price and Availability response contains Price and Availability data for the first and third item numbers submitted, but indicates that the second item number submitted is invalid by including error message data in the <ErrorInfo> elements.

The contents of the following chapters will document message type in the following manner:

Each submission and response document is made up of three primary elements:  Header, Detail, and Summary.  If an element is comprised of one or more subordinate elements, the subordinate elements are indented under the higher level element.  A subordinate element which itself is made up of multiple elements is denoted in the documentation table with a border surrounding the element and its subordinate elements. If an element can occur more than once within the message, this characteristic is noted.  Elements ('parent elements') made up of multiple subordinate elements can also be distinguished in the documentation table because they will not contain any entries in the Optional Required, Data Type, or Max Length columns.

Note:
  The DTDs in this manual are available in electronic form from the EC Implementation Team and are sent out after the completed XML Trading Partner Agreement has been received.  To begin the process, fill out and fax the XML Customer Profile Form & Trading Partner Agreement, available here.
Note:
  Special characters.  Some XML parsers have difficulty interpreting extended characters (i.e. the ampersand, the greater-than sign).  Check your documentation to see if a translation (e.g. &amp; = &) is required to successfully import the messages sent from Tech Data.  You can always opt to strip the special/extended characters out of the data you submit.

The following lists the values found and their meanings for each column of the detail element level DTD documentation tables:

User’s Guide DTD Field Definition Values

COLUMN NAME DESCRIPTION VALUE DEFINITION
Element Name Each element name contained in the DTD (Document Type Definition) in the order in which it appears.    
Optional Required Indicates if the element is required to have content value or not. R Required.  Element content cannot be blank or NULL.
    O Optional.  Element content is not required. See Note 1 below.
Description Definition of the elements purpose and expected content values.    
DataType   A Alphabetic.  Only characters Aa - Zz are valid.  
    A/N Alphanumeric.  Letters, numbers, and special characters.
Max Length   N Numeric.  Decimal places are noted within parentheses in the Max Length column, e.g. 5(2) means a total of 5 numeric digits with the two rightmost digits being expressed decimal places.  The decimal point character (.) is included in the content of the element.
Note 1
This definition should not be confused with the element declaration contained in the actual DTD which specifies if the presence of an element is required or not within the message.  For example, an element may be defined as required in a DTD, i.e. its element name is not followed by the question mark (?) character, but its content is considered optional when the message is submitted to Tech Data's XML Service or sent to the customer in a response.  The element is still expected to be included in the message although it will have no content value, e.g. <WhseCode></WhseCode> or <WhseCode/>.

DTD Element Symbols

DTD Element Modifier Symbols

Symbol

Definition

* Element can occur zero or more times
+ Element must occur one or more times
? Element can occur zero or one time
  No modifier means the Element must exist one time

XML Character Encoding

The following is an abbreviated list of encoded characters commonly encountered. Please refer to the W3C standard for a comprehensive list and explanation.

XML Encoding Characters

Encoded Symbol

Represents

&amp; &
&apos; '
&quot; "
&lt; <
&gt; >

Item Status Codes

Throughout this manual item status codes are referenced. Refer to the following table for item status codes and their meanings.  

Item Status Codes

Code Definition
NEW Recently released by vendor and stock levels could be uncertain
ACTIVE Item is readily available
PHASEDOUT Vendor has indicated availability is limited and soon to be discontinued
ALLOCATED Allocated, item is heavily back ordered and delivery time is uncertain
COMPONENTS Component, a kitted item or component parts of an assembly item

Message Level and Detail Level Tracking

The <Header> element in each of the submit message contains an element named <TransControlID>.  Its purpose is to allow the customer to assign a unique identifier to each message submitted to Tech Data.  This identifier value is returned in the response message exactly as it was received in the submit message.  Although the contents of the element are not validated by Tech Data to insure each submission is unique, its use in this manner is highly recommended for tracking purposes.

Similarly, the <AssignedID> element in the Availability, Price and Availability, Price List, and Order submit messages can be used for tracking purposes at the line (item) level too.

<NumberOfSegments> Element

This element is being phased out, while it remains mandatory in various DTD’s it does not need to contain data, the following example is a valid submission of the <Summary> element.

<Summary>
    <NumberOfSegments/>
</Summary>

Error Messaging

The text of error messages contained within the <ErrorDesc> element of the various response messages are subject to change periodically.  Customers are strongly advised to not code their systems to reference specific error numbers or parse through the error description text looking for pre-defined character strings. 

Note:
 It is recommended that the error message in whole should be passed back to the application initiating the XML request
©2015 Tech Data Corporation. All Rights Reserved. Tech Data proprietary and confidential