Traditional EDI
Orders
Scope
This order message is a preferred tool for automatically generated orders by the ERP/system of the customer. Due to its capability for more information, it can be the better choice for more complex scenarios, compared to API.
Format
EDIFACT
Frequency
Order Response
Scope
With this message Order Response (ORDRSP) the supplier informs the customer about the supplier’s sales order. In most cases, the order response is sent directly after creation of the sales order on supplier’s ERP. It is an asynchronous message which can be sent anytime based on the agreement between customer and supplier.
Additional to the usage as order confirmation it can be used when an order is changed on supplier’s side – customer’s and supplier’s ERP/systems get synchronized.
The message can be used in parallel to API.
Format
EDIFACT
Frequency
Dispatch Advice List
Scope
For receiving information about upcoming deliveries (one or more), Dispatch Advice List (DESADV) can be used. The message contains all details about the products in delivery. The data can be stored on customer’s ERP/system in advance and can be used to speed-up the incoming goods process and confirmation on customer’s site. It is always sent to the customer’s ERP/system in push mode. The message can be used in parallel to API.
Format
EDIFACT & XML
Frequency
Invoice
Scope
The INVOIC message contains all the data of the official legal invoice and can be used in eInvoicing as legal invoice. The customer can book the invoice automatically, after checking quantity, prices and payment terms with the original purchase order. Depending on the national legal rules, several solutions are in place. Please arrange with your supplier which solution fits best.
Format
EDIFACT, XML & CSV
Frequency
Payment Advice
Scope
To reduce administrational work on supplier’s side and for a better overview, a summary about the invoices which are paid in a payment run, the Payment Advice (REMADV), can be used. It is recommended for high volume of transactions between customer and supplier.
Format
EDIFACT
Frequency
The documentation of the industrial standard
Traditional EDI
This document describes the application of the EDIFACT subset EANCOM for the trade, particularly for the tire trade by the term “EDIWheel”. This industrial specific subset contains process chains beginning with an electronic product and price catalogue (PRICAT) to orders (ORDERS), confirmation of orders (ORDRSP), delivery dispatch (DESADV) up to electronic invoice (INVOIC).
UNA
UNB -┐
UNH -┐ |
BGM | first |
... | message |
UNT -┘ | interchance
UNH -┐ | envelope
BGM | second |
... | message |
UNT -┘ |
...usw. |
UNZ -┘
Any EDIFACT message consists of a determined structure. The specification of the delimiter – initial value UNA as well as the service segments UNB and UNZ having a similar function comparable to an envelope, is described in a separate documentation.
The following documentation describes structure and contents of the segment sequence UNH to UNT.
How to read the documentation?
Code values and code names in the column of coded data elements named ‘application’ are the only permitted values for the referring data element (see illustration).
The documentation uses status indications. The EDIFACT status indicators are C and M. In the documentation, The EDIFACT-status C is subdivided as follows:
- M + R: (must + required) – the data unit, e.g. a data element group, has to be used obligatorily.
- N (none) – the data unit, e.g. a data element group, must not be used.
- D (depending) – using this data unit depends on a condition, which is explained in the text.
- O (optional) – using the data unit is optional.
The sender is not obliged to send optional information. The recipient is not obliged to evaluate optional information or to save it, unless the documentation gives other advice. When both sides agree, it can be handled differently.
It is very important that data units are structured hierarchically. A subordinated data unit may have status M- must, but the superior data unit may have status O- optional. If a segment for example has status M and the superior segment group has status O, then the segment must be sent when the segment group has been sent.
The format indicators, e.g. an..14, specify the original EDIFACT-values furthermore if possible or necessary. They are indicators for the application format. The same is valid for repetition indicators of segments and segment groups. The sequence of particular segments in the documentation corresponds to the sequence of segments in the message to send.
Some examples illustrate of how to use particular segments. You cannot draw conclusions of the contents, since they are usually generated automatically.
In the segment description you often find the abbreviation BSU in the column ‘application’ and behind it the name/ description of business information that are transported with the corresponding data element.
Principles:
- In a physical file exactly one EDIFACT-transmission file is transported.
- In an EDIFACT transmission file there are 1 to infinite messages of exactly the same type, of the same EDIFACT-release and the same subset.
- The UNA-string with the standard delimiters of character set UNOA precedes the EDIFACT-transmission file. These three letters are succeeded by colon, plus, dot, question mark, blank character and inverted comma. Example: UNA:+.? ´
- Decimal character always is dot.
- The recipient of a message, of which the syntax is not correct, should reject it. You can check via Internet a concrete message referring to syntax and initial values of the EDIWheel-standard by your own.