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. & = &) 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:
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 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 Encoding Characters |
|
Encoded Symbol |
Represents |
& | & |
' | ' |
" | " |
< | < |
> | > |
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 |
PHASED OUT | Vendor has indicated availability is limited and soon to be discontinued |
ALLOC | Allocated, item is heavily back ordered and delivery time is uncertain |
COMPON | Component, a kitted item or component parts of an assembly item |
DIS-TD | Item that Tech Data has discontinued, remaining stock levels will be available, no back order available |
DIS-VN | Item that the vendor has discontinued, remaining stock levels will be available, no back order available |
SP-ORD | Special Order item requires special handling by the Tech Data Sales Team. |
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.
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 |
©2005 Tech Data Corporation. All Rights Reserved. | Tech Data proprietary and confidential |