EDIFACT

UN / EDIFACT ( U nited N ations E lectronic D ata I nterchange f or A dministration, C Ecommerce and T ransport ) is a cross-industry international standard for the format of electronic data in commercial transactions. EDIFACT is one of several international EDI standards. A UN organization called CEFACT , which is affiliated with UNECE, is responsible for the EDIFACT standard .

EDIFACT directories

The different EDIFACT versions are called directories .

These EDIFACT directories are revised twice a year on April 1st and October 1st to include new EDIFACT messages or to update existing ones. EDIFACT directories have names like D.03B

EDIFACT subsets

Due to the complexity, so-called subsets of EDIFACT have developed branch-specifically. These subsets are subsets of EDIFACT and only contain the functions relevant for certain user groups.

CEFIC - Chemical Industry
EANCOM - consumer goods industry
Edi @ Energy - electricity and gas (only valid for Germany)
EDIBDB - building materials industry
EDIFICE - electronics, software and telecommunications industry
EDIFOR - forwarding industry
EDIFURN - furniture industry
EDIGAS - long-distance gas business
EDILEKTRO - electrical industry / electrical wholesaling
EDILIBE - book trade
EDIPAP - paper manufacturer / wholesaler / converting industry
EDITEC - sanitary industry
EDITEX - textile industry
EDITRANS - transport industry
EDIWHEEL - tire and wheel manufacturer (incl. AdHoc EDI)
ETIS - telecommunications (only for account)
ODA / ODIF - General document formats
ODETTE - automotive industry
RINET - insurance industry

EDIFACT message types

The basic standardization concept of EDIFACT is that there are uniform message types , the English name of which is United Nations Standard Message ( UNSM ). In so-called subsets, the message types can be specified in more detail for each branch. The following is a selection of the most common message types, all of which have exactly one short name made up of six capital letters:

Service messages

CONTRL and APERAK messages are sent to confirm / reject a message.

Test steps:

CONTRL- Syntax check and feedback about the arrival of the message (syntax and service report messages for automatic EDI processing, English control )
APERAK - Technical error messages and acknowledgment (Application error and acknowledgment message)

Data exchange

CREMUL - multiple credit advice
DELFOR- delivery schedule (delivery forecast)
DELJIT- JIT delivery schedule with precise specifications regarding the delivery sequence and time specifications (delivery just-in-time )
DESADV- ASN (despatch advice message)
IFCSUM- Bordero (International Forwarding and / or Transport Message Consolidation Summary)
IFTDGN- Dangerous announcement ( dangerous goods notification message )
IFTMBC - Transport booking confirmation
IFTMBF - booking order (transport booking request)
IFTMBP - Booking request (provisional booking message)
IFTMIN - Transport / forwarding order (instructions of transport)
IFTSTA - Status message for a delivery (status of transport)
IMBNOT - Status message for a transport in the gas industry (status of transport; imbalance notification)
INSDES - instruction to despatch message
INSRPT - inspection report
INVOIC- invoice (invoice message)
INVRPT- Inventory report
MSCONS - Consumption meter values (metered services consumption report message)
ORDCHG- change notification of an order (purchase order change message)
ORDERS - purchase order message
ORDRSP - Reply to an order (purchase order response message)
QALITY - Results of a quality test (quality data message)
QUOTES - Offer production
PAYMUL- Transfers in payment transactions (multiple payment order)
PAYORD- Payment order message
PRICAT- Price list / catalog (price catalog message)
PRODAT- Product data (product data message)
RECADV- Receiving advice (receiving advice)
REMADV - Remittance advice
REQOTE - request for quote
SLSRPT - Sales report
UTILMD - Master data on customers, contracts and metering points (utilities master data message)

EDIFACT structure

Each message consists of an envelope ( English envelope ) which covers the message content similar to an envelope. This envelope consists of the segments UNB and UNZ . This envelope contains the agreed code numbers for the sender and recipient, as well as the message content, times for tracing and checking elements. A message itself consists of segments , data element groups and data elements . The following example explains these terms in more detail.

The optional segment UNA plays a special role as it defines the segment and element separator as well as the decimal separator for all subsequent data.

        Trennzeichen-Vorgabe               UNA  Optional          (Service String Advice)
 ┌───── Übertragungsdatei-Kopfdaten        UNB  Erforderlich      (Interchange Header)
 │ ┌─── Funktionsgruppe-Kopfdaten          UNG  Optional          (Functional Group Header)
 │ │ ┌─ Meldungs-Kopfdaten                 UNH  Erforderlich      (Message Header)
 │ │ │  Daten-Segmente                          Wie benötigt      (User Data Segments)
 │ │ └─ Meldungsabschluss                  UNT  Erforderlich      (Message Trailer)
 │ └─── Funktionsgruppe-Abschluss          UNE  Optional          (Functional Group Trailer)
 └───── Übertragungsdatei Abschluss        UNZ  Erforderlich      (Interchange Trailer)

UNA
UNB
   UNG
      UNH
         <Datensegmente>
      UNT
      ...
      UNH
         <Datensegmente>
      UNT
   UNE
   ...
   UNG
      UNH
         <Datensegmente>
      UNT
      ...
      UNH
         <Datensegmente>
      UNT
   UNE
UNZ

Function groups (UNG-UNE) and messages (UNH-UNT) can be repeated. In the UNT, the number of segments of the message is also specified for checking purposes (including the UNH-UNT segments).

example

An excerpt from an EDIFACT message could look like this:

DTM+11:200606200730:203'

This whole line is called a segment . The meaning of the individual codes is as follows:

DTMis the segment identifier ( English day ) and is the indicator that the following data are date / time information. (DTM stands for Date / Time).
11is a data element (short: element ). In this example, a qualifier describes what kind of point in time is meant. Code 11 means: time of dispatch (e.g. a delivery of goods).
200606200730is another element . Here it represents the date in the notation JJJJMMTThhmm.
203is also an element . 203 is an identifier for the date format. In this example, 203 means that the date JJJJMMTThhmmis specified in the format (i.e. 4 digits for the year, 2 for the month, 2 for the day, followed by the time with 2 digits for the hour and 2 digits for the minutes).
The entire block 11:200606200730:203is Data Element ( English composite elements briefly: composites ) called (recognizable place plus the delimiter colon).
The data element groups (blocks) are separated from one another by a plus sign. There is only one data element group here, separated from the introductory segment identifier DTM by a plus.

A complete UN / EDIFACT interchange, B. contains an order according to the spring 1996 standard, could look like this:

UNA:+.? '
UNB+UNOC:3+Senderkennung+Empfaengerkennung+060620:0931+1++1234567'
UNH+1+ORDERS:D:96A:UN'
BGM+220+B10001'
DTM+4:20060620:102'
NAD+BY+++Bestellername+Strasse+Stadt++23436+xx'
LIN+1++Produkt Schrauben:SA'
QTY+1:1000'
UNS+S'
CNT+2:1'
UNT+9+1'
UNZ+1+1234567'

Please note that this message is packed without any line breaks, which were inserted in this example for readability. The partners must agree whether to transmit with or without a break. Most EDI converters can handle both. In all UN / EDIFACT interchanges, UNA:+.? 'the first advise segment of the message defines the separator. The colon (" :") becomes the component separator , the plus sign (" +") becomes the element separator , the point (" .") is used as a decimal separator , the question mark (" ?") becomes the release indicator , the space (" ") remains Space and the apostrophe (" '") is segment terminator . The release indicator is necessary so that the meaning of a separator is canceled, for example to display a plus sign in free text ( escape sequence ). The UNB interchange header is then followed by the individual messages, which begin with UNH and end with UNT. The ability to group messages is rarely used. This is done using the UNG and UNE segments. An UNZ segment ends the interchange, repeats its number and adds up the number of messages, just as the UNT segment adds up the number of segments within a message.

Sender and recipient identification are transmitted as Global Location Number (GLN). Transfer products with their Global Trade Item Number (GTIN) or European Article Number (EAN), which corresponds to the barcode printed on the goods .

Data format

EDIFACT is a standard for the data format , not for the transmission of data , which means that in principle EDIFACT messages can be exchanged via any medium (see publication form ) that can be used for the transmission of electronic data. EDIFACT is independent of the transmission protocol used .

EDIFACT was originally the domain of value-added networks ( VAN ) or was used on leased lines . There were projects that transported EDIFACT messages by diskette or magnetic tape . EDIFACT is meanwhile also used over the Internet , for example with transmission protocols such as X.400 , e-mail , AS2 , MBS / IP , FTP or OFTP2 .

Either the application programs involved are able to generate or process EDIFACT messages, or a converter is interposed to convert the data accordingly. How the data is converted is configurable. So-called mapping tables can be created with an editor and fed to the converter. It is possible to convert EDIFACT into an XML format and vice versa. A controller is also used here, which takes over the communication process from partner management, table management, logging and archiving fully automatically. Some companies use such software on site, others have the conversion carried out by third parties (EDI outsourcing ). There are some open source converters.

UN / EDIFACT is a format that describes the vast majority of all business papers. It is necessary to make precise agreements between the partners ( trading partner ) about data content, which defines the optional and mandatory fields in selected segments. In addition, private code list extensions will often be necessary in order to precisely map the real business process. Industry standards that are standardized in subsets arise from these code list extensions . For fields of application in which there are no industry standards or special processes are used, these agreements are defined bilaterally, for example via an EDI agreement .

Norms and standards

based on EDIFACT syntax, version 3.0

DIN ISO 9735 (Note: without part number; from 2002)
DIN 16557-3
DIN 16560-1 and -4
DIN 16568-3

based on EDIFACT syntax, version 4.0

DIN ISO 9735 parts 1 - 10 (note: always with part number; from 2004)
DIN 16557 parts 4 - 5
DIN 16560 parts 15 - 17

Web links

Individual evidence

↑ A complete list can be found at https://www.unece.org/trade/untdid/d01b/trmd/trmdi2.htm
↑ http://www.unece.org/trade/untdid/d01b/trmd/deljit_c.htm
↑ Description of the DTM segment

[1] A complete list can be found at https://www.unece.org/trade/untdid/d01b/trmd/trmdi2.htm

[2] ttp://www.unece.org/trade/untdid/d01b/trmd/deljit_c.htm

[3] Description of the DTM segment