Documentation::putEUOrders

Import method for new end user orders from dealers.

Input is a multidimensional array (struct) of tns:ordersEU, which is a complex structure best described in WSDL. There are some optional field in this structure, so read the WSDL comments carefully.

Output is an (in)complete 2D array of tns:ordersShort, which contains distributor's order number(s) with dealer's own number submitted on input.

Server Processing

Method processes all orders one by one, but stops processing on any error. Each head and row is checked first and each order is saved in an isolated transaction (which assures that every already processed order is saved), but there may occur any application or database error, while checking or saving each currently processed order.

If any check fails, processing is stopped, fault is returned and no more orders are saved (no new database transaction is started). Already processed orders are left saved, so client must ask for their numbers (which are not returned with fault) using getOrdersList method in addition to reporting the error to user.

If error occurs on database level, processing is stopped, fault is returned and no more orders are saved (database transaction saving currently processed order is rolled back).

If error occurs on application level (for example unhandled exception), processing is stopped, fault is returned and no more orders are saved (database transaction saving currently processed order is not executed).

When fault is returned, client is responsible for at least notifying the user that the SOAP transaction failed and must be re-processed. In addidition to this, client should ask server for numbers of already saved orders (using number_ext for pairing) and do not re-submit such orders again.

Some delivery options are available only in Prague, so they are not valid in other locations. Matching is done on address zip code.

Client Behaviour

Client should do all necessary checks before submitting each order or set of orders. Weak clients should submit each order as the only input, whereas strong clients should use full capabilities of the method.

Client may immediately re-submit orders, which was not processed due to a failure of any of previous transaction, but only those, which followed the faulty order.

Fault codes

Method returns SOAP fault (according to SOAP Version 1.2, section 2.3 Fault Scenarios) on failure or when no data found for client request. Database error may be returned with specific error prefix, when database is not ready or something unwanted happens.

If order position is returned, it starts with 0 (zero) for first order in request array. Optionally it may be followed by a semicolon delimited sequence of another numbers or tokens, so client must be able to divide the string before semicolon to get the invalid order number. For example 3;RAH-66 with error 202, means that in order 4 somebody wants Commanche helicopter and we do not have them currently in our ERP (probably because we do not have a contract with Boeing-Sikorsky).

Authentication

SOAP client must be capable of basic HTTP authentication to use this method.

Delivery codes

Payment codes

Reserved orders

If customer sends proforma payment method (33), type 1 reservation will be used. In that case, the goods will be reserved for 7 days, whether it's on stock or not.

If customer sends type 1 reservation and other payment method than proforma (33), goods will be reserved for 7 days, depending on every part of order being on stock. In other case, goods will be reserved for 1 day (until the workday ends, or until the next workday ends, in case of orders saved after 4:00 P.M.)

If customer sends type 2 reservation, order will be blocked for 7 days (however, we will NOT reserve the goods).

If customer doesn't send any reservation type, type 0 will be used as default, including proforma payment method (33) process logic.

Example request

Example response

Known bugs

SOAP fault is returned in ISO-8859-1 encoding, except of server header UTF-8 charset declaration.