The module described in this article has been marked as a legacy module. This means the following:
We don't create new features for this module or fix any bugs.
The module is not available anymore in Xentral instances (demo or licensed) created after 28-Sep-2022. If you as a new user have special requirements that could only be fulfilled by this module, please contact our customer support team to discuss a solution.
For more information, see also Why is Xentral deprecating some modules (Legacy modules) and what does this mean for you?
With the help of the Amazon Vendor interface, deliveries can be processed for the Amazon Vendor program. Prerequisite is the transmissions module.
For this purpose it is possible to receive and process orders from Amazon (ORDER). After completion of the delivery can be credited to Amazon (INVOICE).
The data transfer is done e.g. with SFTP. Alternatively AS2 can be used, a signed message procedure for which we can provide you in the form of an AS2 server if required - we also support you in the process of activation by amazon. Please contact our sales department for this.
EDI messages are divided into lines of code, each of which transmits precisely defined data.
Among other things, the UNB line defines the recipient and sender. The "other party" usually expects a "worldwide" unique identifier for the communication partner. There are various possibilities for this:
The quasi-standard here is a GLN (Global Location Number, formerly also ILN) from the GS1 system (formerly EAN system), which is managed in Germany by GS1.de. But this GLN UNB ID type "14" is only one possibility of many.
For a quick start and if the interface is developed by the company itself, type "9" can also be selected as the UNB ID. The DUNS number (also D-U-N-S, short for Data Universal Numbering System) is expected there, and can be queried at https://www.upik.de/upik_suche.cgi. All corporations are automatically assigned a DUNS number after registering with the appropriate authorities.
Finally, there is also the option of using the telephone number with intl. Finally, there is also the possibility to use the telephone number with intl. area code and as UNB-ID type "12".
With EDI/EDIFACT, almost everything is transmitted with code lists, because the protocol dates back to the 1980s when each byte was still expensive. There are some sources that explain the format and show how to use it:
a good and easy introduction can be found at https://www.stylusstudio.com/edifact/
a bit more complicated but very extensive https://service.unece.org/trade/untdid/d96a/trmd/orders_t.htm
The data transfer is done e.g. with SFTP exclusively by keyfile (ssh pub-key), alternatively AS2 is used. We can provide you with an AS2 server if required, please contact our sales department or the partner support. The EDI file itself is a plain text file, ideally encoded in UTF8 - but this is not mandatory in the standard. If the other party sends a file containing only one line, EDI can replace the punctuation ' (single quotation mark, which is defined in the UNA segment) by LF or CR/LF to make the structure very readable. Certain segments can occur several times in EDI and have then possibly a different meaning e.g. data in the header and on position level.
For a quick start into the topic we have summarized a few segments in an ORDER - so it can be quickly understood how an ORDER would be parsed.
BGM+220+4HQ7EBLG+9' → order with PO number 4HQ7EBLG, → the 9 at the end means the EAN/GS1 code lists are used DTM+137:20190107:102' → document date in format 102 DTM+63:20190111:102' → delivery date latest in format 102 DTM+64:20190107:102' → delivery date earliest in format 102
Required is the GLN directory from Vendor-Central so that the delivery addresses can be assigned.
NAD+BY+5450534000017::9' → Buyer, GLN coded NAD+SU+4016428000009::9' → Vendor, here the own UNB-ID is specified again NAD+DP+5450534002325::9+++++++DE' → Delivery address with country NAD+IV+5450534005838::9++AMAZON EU SARL:NIEDERLASSUNG DEUTSCHLAND+MARCEL-BREUER-STR. 12+MUENCHEN++80807+DE' → Invoice address as GLN and plain text must also be transmitted completely → in plain text in the INVOICE message.
In the following (from LIN) the positions begin, between NAD and LIN still further lines can come e.g. RFF (reference in each case to the current element) and CUX (here the currency is defined).
Each LIN defines the beginning of a new position (LIN+1, LIN+2, LIN+3 etc.) LIN+1++4016428352115:EN' → Article Pos 1 with article EAN, EN=data origin EAN, could possibly also be SA QTY+21:52' → Pos quantity in pieces PRI+AAA:55.9' → Price per piece net
The following frame data is mainly used for validation:
With UMS+S the sum block starts, which allows validation with the help of different sums.
If several documents should be contained a UNB transmission, these follow now by a UNH and/or BGM separated again with the document header.