User Reference

XMLInterface User reference Version 1.0 GNT Group Authors: B2B & Web teams GNT Group XMLInterface Version 1.0

Version history

1.0 2007-05-29 Ricardas Kunevicius Initial version based on the XMLInterface version Ginta Kirkute 4.3.1 description by ArdyPitre and Ilona Laurila

Modified 2007.08.20 22:33 Page 2 of 28 GNT Group XMLInterface Version 1.0

Table of Contents

1 Introduction...... 4 1.1 New user reference: targets...... 4 1.2 XMLInterface overview...... 4 1.3 XML transaction descriptions...... 4 2 Implementation...... 5 2.1 XMLInterface definition...... 5 2.2 Sending request...... 5 2.2.1 Getting the domain name and forming the request...... 5 2.3 Getting response...... 6 2.4 Parallel request limitation...... 6 2.5 Schema information...... 6 2.6 Error handling...... 6 3 Purchase order transaction...... 7 3.1 General description...... 7 3.2 Order references ()...... 8 3.3 Parties...... 8 3.3.1 SupplierParty...... 8 3.3.2 BuyerParty...... 8 3.3.3 Delivery Party...... 8 3.4 Transport...... 8 3.5 Direct delivery...... 9 3.5.1 Additional fields that is used in DD orders...... 9 3.5.2 Ordering bundles in DD orders...... 9 3.6 Mailing list management...... 11 3.7 Order lines...... 12 3.7.1 Referring products...... 12 3.7.2 Price management...... 12 3.7.3 Ordering bundles...... 12 3.8 Order summary...... 13 3.9 Order response...... 13 4 Get Catalog transaction...... 15 4.1 GetCatalog Request...... 15 4.2 Catalog response...... 15 Example of Catalog response:...... 16 5 Product specification transaction...... 17 5.1 Product specification request...... 17 5.2 Product specification response...... 17 6 Get Statement Transaction...... 18 6.1 Statement request...... 18 6.2 Statement response...... 19 7 Order Action Transaction...... 21 7.1 Order Action Request...... 21 7.2 Order Action Response...... 21 8 Backlog transaction...... 22 8.1 Backlog request...... 22 8.2 Backlog response...... 22 Appendix I. Table of the function calls...... 24 Appendix II. Error codes...... 25 Order line specific errors 100 (AddOrderRow)...... 25 Line level errors 600...... 25 Delivery party details specific errors 200 (DeliveryInfo)...... 25 Invoicing info specific errors 300 (InvoiceInfo)...... 26 Confirm specific errors 400 (ConfirmOrder)...... 26 Generic Error codes:...... 26

1 Introduction

1.1 New user reference: targets Current document is created to increase XMLInterface usability and provide the latest update information structured way. The document versions are separated from actual XMLInterface version upload and it always will reflect the latest version features. The structure of this document is slightly changed to provide the better readability.

1.2 XMLInterface overview XMLInterface is developed as a set of XML messages to exchange business to business (B2B) information between trading partners. Most of transactions consist of two messages (request and response). The B2B logic is implementation independent and could work though HTTP. Current implementation is made on HTTP as an API for DBM e-commerce system. Each action is described as transaction. Each transaction consists of two documents: the action and the action response.

Transactions could be grouped into a few categories:

- Ordering: o Placing order/getting order response o Getting order status (Order request, backlog request) o Order actions (Deleting or altering the order) - Product catalog o Asking/getting for product catalog o Asking/getting for particular product specification - Finance o Asking/getting for the finance statement - Warehouse hotel management o The product hotel formation transactions are: o Add new product o Update an existing product o Remove a product o The store purchase order transactions are: o Add new order o Update existing order

1.3 XML transaction descriptions XML transactions are described starting from the chapter 3. There are some differences from previous versions of the documentation – detailed tag description is moved to separate mapping document and in there we are highlighting only main points and providing the working examples. So it’s better to use this document together with mapping document and also refer to the schema if needed. Mapping document contains the description of every tag used in the document. Some tags are not used but still here for future development of the compatibility reasons. They are collared in grey at the mapping documents. PurchaseOrder and OrderResponse mapping is combined in the single document because most of the tags are used in both of documents and the differences are showed in the separate columns.

2 Implementation

2.1 XMLInterface definition The current implementation of XMLInterface is an API to net store. It uses the same security model and the same price catalog as net store. Virtually it is the same if a client acts though web interface or though XMLInterface. The difference is that XMLInterface doesn’t support the baskets, so the client should keep it on this side and submit the completed order to XMLInterface. The client sends HTTP request to the system and gets XML message as the response to his request. XMLInterface consist several different processors. Every processor has it own URL to call. Each processor is documented in this document. The schema of implementation of XMLInterface transactions consists of two main steps: o To begin particular transaction user sends http request to some of the xml processing dll- extension; o If the request is correct user gets the particular response or error message as xml file.

2.2 Sending request

2.2.1 Getting the domain name and forming the request There are multiply servers in each country serving customer requests. Some of them couldn’t be available from time to time because of maintenance or other reasons. To assure 100% service the first step could always be asking for the available XML server. The following URL returns the available server name http://www.gnt.xx/scripts/MultiWeb.dll? GetXMLDomainName Use FI, LT, EE, LV, PL, NO, SE to get the domain in your country. For example this URL could return www1.gnt.fi for Finland and exact URL could be combined using URL table from Appendix I.

User can send request to a system only if he has the account in net store system and this account has the necessary rights. Then, the user has to send the http request to some of the XMLInterface processors. This processor checks the request. XML_Interface.dll processor requires some of following parameters: - MfcISAPICommand=Default – should be added for internal processing support - USERNAME - PASSWORD – the credentials provided by GNT admin - XML – the actual XML message - CHECK - parameter counted with md5 algorithm. Other dll-extensions do not require check parameter. Note: This feature currently not implemented in all instances

The POST method to send the request is recommended. All parameters should be placed to the request body.

Example: The user wants to send the request for getting the entire price catalog in html format. In this case his https request will be: POST /XML_Interface.dll HTTP/1.0 UserAgent: IE6 Content-Type: text/html Content-length: 523

MfcISAPICommand=Default&USERNAME=username&PASSWORD=pswdpswd&XML=200-07- 11T12:00:001.0 20290721&CHECK=XMKSJDJKHFKSJADHFLSDFN

2.3 Getting response The response is sent out as the standard HTTP response with contect type=text/xml.

2.4 Parallel request limitation Request sending to one server is monitored as follows. There can be unlimited amount of Purchase Order requests to one server. Simultaneously there can be one other request with the Purchase orders. There cannot be other simultaneus request to one server. So if there is: - 3 PurchaseOrders (all OK) - 3 PurchaseOrders + 1 SpecsRequest (all OK) - 3 PurchaseOrders + 1 SpecsRequest + 1 Catalog (last is rejected) - 1 SpecsRequest + 1 Catalog (last is rejected)

2.5 Schema information All transactions validate all incoming xml-files against predefined schemas even if the namespace declaration is missing from the xml root element. All schemas locate in http://www.gnt.fi/Schemas/name of the schema. There are following schemas: - XMLInterface_Order.xsd - XMLInterface_Catalog.xsd - WarehouseHotelProductDescribtion.xdr - StorePurchaseOrder.xdr - ArrivedPOProducts.xdr - 3rdDegProductBuffering.xdr - ParseErrors.xsd

2.6 Error handling There are a few possible error levels using XMLInterface: - Authentification error – wrong credenticials or not enough rights to proceed with action - XML message validity problems (not valid XML, schama validation fails) - Logical problems (e.g. product from PO line doesn’t exists)

If error occurs XMLInterface returns an error message with the particular error code. Error codes are listed in the Appendix II.

Error message example:

ProductSpecRequest 2007-05-30T07:43:18 /scripts/XML_Interface.dll?ProductSpecRequest 212440 Part number is not priced! 62 1

3 Purchase order transaction

3.1 General description The goal of this transaction is to place a purchase order. This chapter provides detailed instruction how to place a purchase order via XMLInterface. The purchase order request consists of 3 main tags: - tag includes common information about the order: date, currency, buyer, supplier, transport and others; - tag includes information about ordered products and quantities; - tag includes the additional information about the order. Purchase order and order response transactions use exactly the same schema (only the route tag differs). Order response also is generated if the order status is asked by OrderRequest. It also could be triggered by internal event as delivery date, price or allocation changes:

Table 1 Request Response PurchaseOrder OrderResponse OrderRequest OrderResponse OrderResponse

The complete message filed definition is provided in the separate file.

Simple order example: 2003-06-23 2003-06-23 123456 1 -1 First left 1 1 1 HP1200 2 1 THIS IS A TEST ORDER

3.2 Order references () Each purchase order gets unique number from the supplier (GNT). It’s enough to recognize the order and the customer could use it or if needed could add extra references for better linking to their internal systems. Order can be recognized by: - Order number from the system - Customer order number for end-user (DD only- should be filled in) - Customer’s order number

3.3 Parties To have the right order routing there should be at least 2 parties defined: - SupplierParty – referring to the supplier and always 1 (0 in some installations) - BuyerParty – unique customer ID in the supplier system must be communicated in advance. In the message only IDs could be provided, address information is sent back from supplier system and cannot be altered by XMLInterface.

3.3.1 SupplierParty Supplier party is mandatory. It describes GNT side. Field is essential here and its value meaning “GNT” is “1”.

3.3.2 BuyerParty Buyer party is mandatory. It describes buyer details. Main fields are:

- CRM customer ID in our system. - Customer purchase order number.

3.3.3 Delivery Party Delivery party is optional. If this party is not defined XML takes default delivery information from CRM. Field is Delivery Address Name. Mandatory if is not defined. You could use to assign delivery to some predefined delivery address name. TUUSULA You could also specify end users direct delivery address information. This expression is used with direct delivery info in OrderHeader to tell end users delivery address. Note that this feature needs direct delivery rights. Delivery address is placed as follows. 121212 Ahto Sima Sarviotsantie 3 Tampere 33700 [Ahto Sima][[email protected]]][$B]

3.4 Transport

Transport segment is optional. Segment contains transport details. - Carrier ID in DBM database carrier table. All possible values described in the map (excel file, sheet CarrierID). - ID in DBM database. All possible values are described in the map (excel file, sheet Shipping instructions). - describes consolidation:

- CONSOLIDATION NO =0; - CONSOLIDATION YES =1; - WAIT FOR CONSOLIDATION =2; - BACKORDER WAITS FOR CONSOLIDATION =3.

3.5 Direct delivery

The tag is necessary when placing direct delivery orders. Note that this feature requires rights. This is optional component.

Direct Delivery order structure

Normal SO from GNT to reseller, including: - order lines with GNT price to reseller - end user delivery address

Direct delivery info, including: - order lines - own part number - own description - own price (reseller price to end user ) - other DD info, described in segment

3.5.1 Additional fields that is used in DD orders

- All fields from segment - OwnPartNumber (from ) – part number of reseller. - OwnDescription (from ) – product description of reseller. - Price – reseller price to its end user. It is important to choose price type “D0” or “D” (according to Table 3).

3.5.2 Ordering bundles in DD orders

There is a possibility for reseller to create a bundle to its end user. To add bundle into direct delivery order these tags should be used:  - Bundle row id  - This is the RowID of mother product of the bundle  - If true, new bundle is declared In the first step we need to define new bundle. RowID has value “0”, since none of bundle lines in this segment are described;

BundleRowID is also 0, since it is the first bundle in the order. If there will be more then one bundle in the order, BundleRowID will have values 1,2,3 etc. = 1, then new bundle is declared. 0 0 1

In the part number field we enter any existing part number. Bundle code and bundle name that will be visible in the DD order are described in the fields and . It is also possible to set the quantity and needed price for bundle with fields and when its type is “D” or “D0”. Example: B 31915-4-M blablabundle Bundle name description 1 0 0 1 1000

In the next OrderLine segment we need to describe which products go to the bundle. We enter product code and mark RowID = 1 (it will be the first row of the bundle) and in the next OrderLine segment we enter second product with RowID = 2, describing second product of the bundle, we can enter as much products codes and RowID as we like. B 31915-4-M QtyRequested>1 1 0 0 66200 K-MN QtyRequested>1 2 0 0

Here is the example when more then one bundle is described in the order: B 31915-4-M blablabundle Bundle name description 1 0 0 1 1000 B 31915-4-M

1 1 0 0 66200 K-MN 1 2 0 0 0 -- the end of the first bundle 0001C001 blablabundle2 Bundle name2 description 1 0 1 1 1000 0001C001 1 1 1 0 0 0013N1107 1 2 1 0 0

3.6 Mailing list management

Email tag (in ) includes e-mail addresses in form: [NAME1][ADDRESS1][OPTION] [NAME1][ADDRESS1][OPTION]. Example: [Ahto Sima][[email protected]][$A]

Table 2 Option Description A GNT’s confirmation of order to reseller B Reseller’s confirmation of order to end user C GNT’s packing list to reseller D Reseller’s packing list to enduser

3.7 Order lines

tag includes attribute which specifies the type of the order line. All order lines in PurchaseOrder should be type P as “Purchase”. In OrderResponse there could be three types of Type: P (successful purchase order line), D (successful direct delivery order line) and I (invalid order line).

3.7.1 Referring products

Products are identified according to ProductID, PartNumber, EANCode. Must be at least one of these fields defined. All these fields used only in order response. - Product ID in TNIMIKE table - Part Number - EAN code.

Ordering product is required to fill quantity tag, field.

3.7.2 Price management

Prices are described in Order and OrderRSP with PrePrice and UnitPrice fields. In order there is tag Price and field , its type is taken as default C0 (GNT’s price to reseller without VAT). Example:

In Order response there is tag Price and its field , its type is also C0 as default.

Example: 1656.00

There are 4 types of UnitPrice tags inside Price. Table 3 Type Description C GNT’s price to reseller with VAT C0 GNT’s price to reseller without VAT D Reseller price to enduser with VAT (only in direct delivery orders) D0 Reseller price to enduser without VAT (only in direct delivery orders)

3.7.3 Ordering bundles

Bundle ordering in not direct delivery orders is pretty similar to single products ordering. All we need is to enter bundle product ID. For example we have bundle code “AEG BUNLDE” and its product ID is 395096. If we want to order bundle we enter bundle ID as standard product to List of order lines segment.

Example: 1 395096 3

3.8 Order summary

This tag includes the additional information about the order. This is required field only when order response action is “update”.

VAT 110.00 500.00 610.00 1 510.00 THIS IS A TEST ORDER

3.9 Order response

The order response request is almost the same as purchase order request. It has the structure similar the purchase order including the same main sections - - - .

The difference is in using of some internal tags. Here is the list of fields that have only Order Response: - Quantity information: , and - - order number in our CRM. - Buyer Party information – Address details of Buyer. - Supplier Party information – Address details of supplier. - type - there could be three types of Type: o P (successful purchase order line), o D (successful direct delivery order line) o I (invalid order line). - Fields , , , , , from OrderLine segment describes product information - - price in our system - Tax details: o , o o . -

Example of order response: 2003-06-23

2003-06-23 2003-06-23 2003-06-25 4551522 123456 Test Name Test Street Test City 33960 FI 123456 Test Name Test Street Test City 33960 FI 0 GNT Finland Hatanpäänvaltatie 48 Tampere 33900 FI 1 1 1 0 124451 HP1200 2 2 0 VAT 110.00 500.00 610.00 1 510.00 THIS IS A TEST ORDER

4 Get Catalog transaction

4.1 GetCatalog Request

The goal of this transaction is to get the product catalog based on full or filtered by different criteria. This transaction cannot be used for all products at one time, only for products with some criteria. There are three main tags in the Catalog Request: - tag specifies the date of catalog request - tag specifies catalog request addresses - tag specifies if any filters will be used or not.

Meanwhile can have 11 filters: - PartNumber - filtering based on the product part number; - VendorID – filtering based on the vendor ID; - ClassID – filtering based on the class ID; - Fragment - filtering based on the text fragment of the product description; - StockLevel - filtering based on the physical state of product; . OnStock - defines request for on stock products; . Transit – defines request for on stock and transit products (products on stock plus incomming) . All (default) – defines request for all possible products discarding stock level - Details – defines the detail level in catalog; . PriceQty – defines request for getting the catalog only with prices and quantities; . All (default) – defines request for getting the catalog with all the product details - PriceTimeStamp – defines all products which prices are updated since given date. - ProductTimeStamp – defines all products which information is updated since given date. - StockLevelTimeStamp – defines all products which stock levels are updated since given date. - DeletedTimeStamp – defines all products which are marked inactive since given date. - Price – defines if prices are reported in catalog with VAT or without VAT. . VAT – defines request for getting prices with VAT (default) . WOVAT – defines request for getting without VAT - EANCode – filtering based on a EAN code - WarehouseID . 1 - local (always on) . 2- summary of remote (how it is now) . LT,SE,FI - group warehouses one by one . KINGSTON - special kingston varehouse, ect

In the example customer wants to get catalog filtering by ClassID and he chooses product group ID = MNT. 2007-08-08T14:58:47-05:00 1001 1251 0

4.2 Catalog response

The catalog response provides the information requested by the catalog request document. It consists of two main tags: - PriceCatHdr - includes common information about the catalog: date, currency, language, description, filters, route addresses and others. - ListofCatalogDetails - includes information about requested products.

Example of Catalog response: 2007-08-20T10:18:14 XML Product Catalog 1001 0 1251 111645 0 0 864.114000 0

Note that not all prices are available depending from the business rules of the particular company. The current values for GNT are:

Table 4 Type Description C Client price

Language is declared as follows: Table 5 Option Description FIN Finnish ENG English SWE Swedish EST Estonian LAT Latvian LIT Lithuanian

WarehouseID attribute is declared as follows: Table 6 Option Description 1 Local warehouse inventory 2 Global LT,SE,FI group warehouses one by one i.e. Kingston special Kingston varehouse, ect

Detailed schema with all fields is in the excel file named CatalogTransaction.xls.

5 Product specification transaction

The goal of this transaction is to get information on particular product.

5.1 Product specification request

Main segments in this request are: - Date – the date of request - Route – from and to information - PartNumber – part number of the product that we want to get specification

Example shows request for product specs for ABITAT7. 2007-08-09T12:00:00 1251 0 66200 K-MN

5.2 Product specification response

The ProductSpec is returned as a list of all details of requested product.

ProductSpec contains: - ProductDetails - that contains detailed information about product, - CompatibleProducts - that contains list of all compatible products, - ProductLinks - that contains all links concerning this product.

Here is the example of order response: 271695 66200 K-MN 66200 K-MN HOB AEG 66200 K-MN … ELECTROLUX 4014891088449 http://www4.gnt.lt/productimages/AEG_66200K-MN.jpg 2 Metai 20 0 1696.757400 8.000000 120.000000 680.000000 600.000000 1 40 GRUPĖ (BUITIN Ė ELEKTRONIKA) AEG

Detailed schema of these messaged is provided in excel file named ProductSpecs Transaction.xls

6 Get Statement Transaction

The goal of this transaction is to get information about the particular open invoices or shipments.

6.1 Statement request

The statement request consists of 3 main tags and tag Filter has its own tags: - Date - tag specifies the date of the request; - Route - tag specifies the addresses of the request; - Filter - tag specifies the filters of the request. . InvoiceNumber - filtering based on the invoice number; . InvoiceDateFrom - filtering based on the date of invoice; . InvoiceDateTo - filtering based on the date of invoice; . DueDate - filtering based on the due date; . InvoiceDate – filtering based on the date of invoice; . Status – filtering based on the status of invoice. Available status values are 0 not closed invoices,1 all closed invoices, 2 overdue invoices.

. NewInvoices. Available value 1 will get at the first request all the invoices sent. After only the newest ones. . Price – shoving prices with out WAT, default is showing prices with WAT. Available value WOVAT

2007-08-09T23:00:00 1251 0

6.2 Statement response

The statement response provides the information requested by the statement request document. It consists of six main tags:

- StatementDate - includes the date of statement request; - BuyerParty - includes information about the buyer; - SupplierParty - includes information about the supplier; - Filters - includes filtering information to current document; - ListofInvoices - includes information about particular invoices; - StatementSummary - includes information about invoices: total amount, total overdue etc.

Status can have values: - 3 = In shipping - 4 = Shipped - 5 = Invoiced - 6 = Paid

The example of statement response

2007-08-09T16:08:51 1251 TESTINE COMPANY - NE PARDAVIMUI PIRMA TROBA KAUNAS 99999 LT 0 UAB "GNT LIETUVA" VERSLO 6, KUMPIŲ KM., DOMEIKAVA KAUNO RAJ. 54311 LT

6467103 568445 5 2007-03-26 2007-04-05 2007-03-26 0.12 0.00 0.12 USD 1251 TESTINE KOMPANIJA - NE PARDAVIMUI 1 AUKSTAS PALEMONO 7 KAUNAS 99999 LT 0 1389 1389 0.00 0 0 1 0 1118352 TEST 0 0.12 1 1 0.26 LTL

Detailed schema is provided in excel file named StatementTransaction.xls.

7 Order Action Transaction

The goal of this transaction is to delete particular order.

7.1 Order Action Request

- Date tag specifies the date of the request; - Route tag specifies the addresses of the request; - OrderNumber tag specifies the number of the requested order; - Action tag specifies the requested action. . Delete tag marks that the order should be deleted; . Deliver tag marks that the order should release from hold to production.

Only orders purchased with direct delivery information can be deleted via XMLInterface. Order can be deleted with supplier order number or buyer order number reported back to the client in direct delivery orders.

Example shows the request to delete order 1248423.

2007-08-10 1251 0 1248423

Detailed schema is provided in the excel file named OrderActionTransaction.xls

7.2 Order Action Response

The order status update response provides the information about the positive result of update, otherwise it provides error message. The update order status response consists of the main tags:

- Date tag specifies the date of the response; - Route tag specifies response the route addresses; - OrderNumber tag specifies the number of the requested order; - Confirmation tag specifies the positive result of the transaction

Example shows response. 2000-06-307T16:00:00 123456 1

1234567 The order 1234567 has been removed

8 Backlog transaction

The goal of this transaction is to get information all unshipped orders.

8.1 Backlog request

The BacklogRequest consists of 3 tags: - Date tag specifies the date of the request; - Route tag specifies the addresses of the request; - Filter tag specifies the filters of the request . BacklogTimeStamp. It is filtering based on an invoice date when the backlog line has been changed. It is possible to fetch only lines that are changed during the period between specified time in timestamp and current time

Customer wants list of products in Backlog updated since given date. So, the Backlog request will look like: 2007-08-13 1251 0

8.2 Backlog response

The Backlog is returned as a list of all unshipped orders. It differs from the PurchaseOrder because it has reduced order header. BacklogResponse contains: - BacklogHeader that contains date, route and filters information. - ListOfBacklogOrders that contains list of all < BacklogOrder> tags. - BacklogOrder that contains information about the orders:

Order status can have these values: - 2 = confirmed - 3 = in delivery

Example shows the response: 2007-08-13T16:41:11 0

1251 1248423 201938 2 0 395096 AEG KOMPLEKTAS 1 2 2007-08-13 2007-08-10 2161.80 1 1 1 271695 66200 K-MN 1 2 1990-01-02 2007-08-10 0.00 1 1 0 2 393531 B 31915-4-M 1 2 1990-01-02 2007-08-10 0.00 1 1 0

Appendix I. Table of the function calls

Transaction URL Parameters Note CatalogRequest http://wwwX.gnt.XX/scripts/XML_Interface.dl USERNAME, CHECK = l?Default? PASSWORD, XML, XML+KEY CHECK PurchaseOrder http://wwwX.gnt.XX/scripts/XML_Interface.dl USERNAME, CHECK = l?Default? PASSWORD, XML, XML+KEY CHECK OrderAction http://wwwX.gnt.XX/scripts/XML_Interface.dl USERNAME, CHECK = l?Default? PASSWORD, XML, XML+KEY CHECK BacklogRequest http://wwwX.gnt.XX/scripts/XML_Interface.dl USERNAME, CHECK = l?Default? PASSWORD, XML, XML+KEY CHECK StatementRequest http://wwwX.gnt.XX/scripts/XML_Interface.dl USERNAME, CHECK = l?Default? PASSWORD, XML, XML+KEY CHECK AddProductRequest http://wwwX.gnt.XX/scripts/VWarehouse.dll USERNAME, ?AddOrUpdateProduct? PASSWORD, XMLREQUEST UpdateProductRequest http://wwwX.gnt.XX/scripts/VWarehouse.dll USERNAME, ? AddOrUpdateProduct? PASSWORD, XMLREQUEST RemoveProductRequest http://wwwX.gnt.XX/scripts/VWarehouse.dll USERNAME, ?RemoveProduct? PASSWORD, XMLREQUEST SendStorePurchaseOrder http://wwwX.gnt.XX/scripts/StoreOrderInterf USERNAME, ace.dll?InsertStorePurchaseOrder PASSWORD, XML StorePurchaseOrderAction http://wwwX.gnt.XX/scripts/StoreOrderInterf USERNAME, ace.dll?UpdateStorePurchaseOrder PASSWORD, XML ArrivedPOProducts http://wwwX.gnt.XX/scripts/ArrivedPOProdu USERNAME, cts.dll?ArrivedPOProducts ? PASSWORD BufferProduct or increase http://wwwX.gnt.XX/scripts/XML_PdtBufferin USERNAME, buffer size gInterface.dll?ReqAndRes? PASSWORD, XML DecreaseBufferedProduct http://wwwX.gnt.XX/scripts/XML_PdtBufferin USERNAME, Size gInterface.dll?ReqAndRes? PASSWORD, XML DeleteBufferedProduct http://wwwX.gnt.XX/scripts/XML_PdtBufferin USERNAME, gInterface.dll?ReqAndRes? PASSWORD, XML BufferStatus http://wwwX.gnt.XX/scripts/XML_PdtBufferin USERNAME, gInterface.dll?ReqAndRes? PASSWORD, XML

Appendix II. Error codes Error codes are grouped by modifiers. Number indicates to which part of the message error is linked to. First message part specific errors, then a list of general errors that are applied to all parts of the message.

ORDER_LINE_ERROR_MODIFIER = 100 DELIVERY_PARTY_DETAILS_ERROR_MODIFIER = 200 INVOICING_INFO_ERROR_MODIFIER = 300 CONFIRM_ERROR_MODIFIER = 400

Order line specific errors 100 (AddOrderRow) Error codes:

1 AOSessionMissing, 2 AOInvalidPrice, 3 AOInvalidDate, 4 AODateBackwardShiftError, 5 AODateShiftError, 6 AODateTotalShiftError, 7 AODateChangeNotPossible, 8 AOInvalidQuantity, 9 AONoPrice, 10 AOProductNotFound

Line level errors 600

601 No mach found for the product ID 602 Predifined price differs from the price in database 603 Invalid delivery date information. Information is in invalid format or it is set too far to the future max. Is 21 days.

Delivery party details specific errors 200 (DeliveryInfo) Error codes: 1 DIMissingStakoEndUserExtra, 2 DIMissingShoppingBasket, 3 DIMissingBIDEndUser, 4 DIMissingEndUser, 5 DIWrongProductQuantity, 6 DILicenseError, 7 DILocksError, 8 DICheckDeliveryMethodFailed, 9 DISessionMissing, 10 DIMissingRights_I, 11 DIMissingRights_T, 12 DIMissingRights_S, 13 DIInvalidDate, 14 DIDateBackwardShiftError, 15 DIDateShiftError, 16 DIDateTotalShiftError, 17 DIDateChangeNotPossible, 18 DIMissingAddress, 19 DIMissingCustomerTerm, 20 DIDatabasePoolWait, 21 DIDatabaseError

Invoicing info specific errors 300 (InvoiceInfo) Error codes: 1 IISessionMissing, 2 IIMissingRights_I, 3 IIMissingInvoicingName, 4 IIMissingInvoicingAddress, 5 IIMissingOrderNumber, 6 IIMissingPaymentTermID, 7 IIInvalidDeliveryCosts, 8 IIInvalidHandlingFee, 9 IIInvalidInsuranceFee, 10 IIInvalidPaymentTerm, 11 IIMissingShoppingBasket 12 Invalid buyer number (new) (InvalidOrderNumber)

Confirm specific errors 400 (ConfirmOrder) Error codes: 1 COSessionMissing, 2 COInvalidPassword, 3 COInvalidPaymentMethod, 4 COMissingRights_T, 5 COMissingShoppingBasket, 6 COShoppingBasketUnchecked, 7 CODatabasePoolWait, 8 CODatabaseError, Possible cause: invalid buyer number 9 COMissingEndUserRights, 10 COMissingEndUserContact, 11 COCompanyRegistrationFailed, 12 CONoCredit, 13 COMissingPartialPaymentContract, 14 COPrepareOrderForIB, 15 COMissingOrderRows, 16 CODirectDeliveryCustomerInfoNotFound, 17 COOrderHandlerError 18 Error in direct delivery if bundle code is used 19 Undefined error when ordering a bundle.

Generic Error codes: 0 NO_ERROR 20 DATABASE_INIT_ERROR 21 CANNOT_INITIALIZE_DATABASE_CONNECTION 22 CRITICAL_PARSER_FAILURE 23 EMPTY_PARAMETERS 24 INVALID_TRANSACTION_REQUEST 25 INVALID_SESSION 26 INVALID_AUTHENTICATION_INFORMATION 27 XML_FILE_CANNOT_BE_READ 28 INVALID_LANGUAGE_INFORMATION 29 INVALID_BUYERS_DATA 30 INVALID_SUPPLIERS_DATA 31 EMPTY_SUPPLIERS_ID

32 DELIVERY_ADDRESS_DATA_CANNOT_BE_FOUND 33 INVALID_TRANSPORT_INFORMATION 34 INVALID_DD_INFORMATION 35 INVALID_LEASING_INFORMATION 36 DATE_INFORMATION_IN_ORDER_HEADER 37 XML_INTERFACE_ERROR_TRY_AGAIN_LATER 38 INVALID_PREFERED_SHIPPING_DATE 39 ORDER_CANNOT_BE_CONFIRMED 40 INVALID_ORDER_NUMBER_OR_INVALID_ORDER_LINES 41 DD_ORDER_CANNOT_BE_CONFIRMED 42 ORDER_LINES_CANNOT_BE_CONFIRMED 43 CLIENT_ID_INCORRECT 44 INVALID_SUPPLIERS_CLIENT_ID 45 INVALID_XML_STRUCTURE 46 INVALID_FILTER 47 NO_FILTERS_SPECIFIED 48 STATEMENT_DETAILS_UNAVAILABLE 49 CANNOT_GET_PRODUCT_DETAILS 50 SUPPLIERORDERNUMBER_OR_BUYERORDERNUMBER_ALLOWED 51 SUPPLIER_ORDER_NUMBER_NEEDED 52 ACTION_FUNCTION_ERROR 53 ORDER_ACTION_CAUSED_AN_ERROR 54 NOT_ENOUGH_RIGHTS 56 INVALID_XML_STRUCTURE_ORDER_NO_MISSING 57 DD_ORDER_LINES_CANNOT_BE_CONFIRMED 58 NO_ORDER_NUMBER_SPECIFIED 59 ESTIMATED_DELIVERY_DATE_NOT_FOUND 60 PRODUCT_CANNOT_BE_FOUND 61 NUMBER_REFERS_TO_BUNDLE 62 PART_NUMBER_IS_NOT_PRICED 63 CARRIER_MISSING 64 TRANSPORT_TAG_MISSING 65 DELIVER_CHANGE_METHOD_NEEDS_SUPPLIER_ORDER_NUMBER 66 INVALID_DATE_FORM_IN_FILTER 67 INVALID_DELIVERY_DATA 68 INVALID_DAN_ADDRESS_DATA 69 CANNOT_GET_CLIENTS_INFORMATION 70 QUERY_RETURNING_TOO_MANY_ITEMS 71 NO_ORDER_LINES_INCLUDED 72 INVALID_XML_FORM 73 INVALID_BUNDLE_ROW_VALUE 74 INVALID_PRODUCT_QUANTITY 75 INVALID_OWNER_SELECTION_VALUE 76 INVALID_TYPE_ATTRIBUTE 77 ERROR_CODE_IN_ORDER_LINE 78 ERROR_CODE_IN_DELIVERY_PARTY_INFORMATION

79 ERROR_CODE_NAME1_TAG_MISSING 81 ERROR_CODE_POSTAL_CODE_TAG_MISSING 82 ERROR_CODE_CITY_TAG_MISSING 83 ERROR_CODE_NAME_ADDRESS_TAG_MISSING 84 ERROR_CODE_CURRENCY_TAG_FAILURE 85 ERROR_CODE_TERM_OF_PAYMENT_DESCRIPTION_TAG_MISSING 86 ERROR_CODE_TAX_INCLUDED_TAG_MISSING 87 ERROR_CODE_FACTORING_TAG_MISSING 88 ERROR_CODE_INSURANCE_COSTS_TAG_MISSING 89 ERROR_CODE_HANDLING_FEE_TAG_MISSING 90 ERROR_CODE_ORDER_HOLD_TAG_FAILURE 91 ERROR_CODE_FREIGHT_AMOUNT_TAG_MISSING 92 ERROR_CODE_INVALID_ORDER_NUMBER 93 ERROR_CODE_INVALID_VIRTUAL_PICKING_INFORMATION

10 “Multiple simultaneously transactions not allowed!” There cannot be multible requets running on one server by same username.

1003 “DeliveryParty NameAddress field invalid!” Delivery address field is empty.

“Product can not be found.” Product code does not excist in database.

“Not enough rights to use this transaction.” Request user is tryiing if under right they dio not have.

“Unauthorized method. ClientID is incorrect.” There is a conflict between ClientID and username and password.

“Authentication error. Server in not OK or authentication information is invalid.” Username and/or password is wrong.

Modified 2007.08.20 22:33 Page 28 of 28