General information

  • The format for orders of industry standard is OpenTrans 2.1 used.
  • to download the OpenTrans 2.1 documentation and sample files
  • The MimeType must be application / xml.
  • Sending works only via HTTP POST.
  • In the POST body, only the ORDERs can be in OpenTrans 2.1 format and encoded as UTF-8.
  • An order can only be sent directly to a single distributor, so a new OpenTrans order has to be created for each distributor

A list of distributors and their master data can be retrieved via API. The Supplier-> ID is the unique in ITscope number of distributors.

The order is subject to a number of validations before it is actually sent

  • Validation to valid OpenTrans 2.1 format
  • Validation, whether the individual position is also available in our catalog for the above-mentioned distributor
  • NO validation on valid price or availability
  • Validation of whether the sum of the individual items and the quantities match the final total
  • For project orders: Validation whether the specified project number is included in your project list that is configured at

When submitting, it is also possible to make mistakes or synchronous error messages from the system of the distributor.

The API always returns appropriate error messages and HTTPCodes> 400

If an order is sent completely, the HTTPCode 200 is sent and a response with the following data:

  • The new OrderID
  • The current status of the order


Structure of the order

Our system receives an order in an XSD valid OpenTrans Version 2.1 format .

Order number (ORDER_ID):

  • We re-generate these for each API import and copy the customer order number sent to us by the foreign system into the field CUSTOMER_ORDER_REFERENCE-> ORDER_ID
  • Ie in the ORDER sent to us, we copy the ORDER_ID to CUSTOMER_ORDER_REFERENCE-> ORDER_ID and generate an ITscope order number in the ORDER_ID

Participants (PARTIES):

  • Distributor as a supplier with the PartyID which is deposited in your system for the distributor.
  • Buyer therefore Invoice recipient PARTY_ROLE-> buyer with the PartyID which is stored in your system as customer number for the customer at the distributor.
  • Delivery recipient delivery, may differ from buyer, possibly due to dropshipment


  • Set this field if the order is to be sent in partial deliveries
  • The field is defined as a mandatory field in OpenTrans, so it must be set to false

Dropshipment (UDX.DROPSHIPMENT):

  • Set this field when Dropshipment is desired. Must be coordinated with the distributor.
  • The UDX fields are optional fields



  • This field is the number that the end customer receives as an order number
  • The UDX fields are optional fields


  • This field is the number that the buyer can assign for himself (internal company order number)
  • The UDX fields are optional fields

Distributor Product number (SUPPLIER_PID type = "supplier_specific"):

  • We search for the item to be ordered from this number.


Sending a test order

On the live system partner Test can be sent via the API test orders on a landscaped by ITscope test suppliers with names ITscope.This test has the supplier LieferantenID 10000735 You need an additional release of ITscope to be able to see this test supplier and thus also to order it there.

Whether the test supplier is released can be easily checked in two ways:



Automatically generate the Responsedocuments

So that you can also test realistically whether your system can also process response documents from us (order confirmation, shipping notification and invoice), you have the option of specifying the documents to be generated and their number.

Note: The number of documents to be generated is limited to 6 each.

You can control this with the order number or order ID. Simply add a "§" sign to the order number, followed by the parameters listed below. The parameters are given as follows:

§<shortcut1><count1><shortcut2><count2> usw.

These shortcuts (case insensitive) are available to generate the appropriate document:

Shortcut Action Genererated Document
R reject order ORDERRESPONSE
C confirm order ORDERRESPONSE
I invoice order INVOICE


Example for an orderId:


Our system will immediately issue 3 order confirmations (C3), 1 delivery note (A1) and 2 invoices (I2) for an order with this order number.


For an order with this order number, our system will issue 1 response document (R1) in which the order is rejected.


Without specifying parameters, just the test order is triggered without generating response documents.

Sending an order to a supplier

The order document must be created, validated and then sent to the respective distributor by means of its ID as in the above sections.

The sending must be done via HTTP POST and the contents of the POST is the pure ORDER as XML. The content-type of the post should be placed in the form of application / xml; charset = UTF-8.


Note: This page has been translated with the Google Translation Service.

Have more questions? Submit a request