EDIFACT

UN / EDIFACT is the abbreviation for United Nations Electronic Data Interchange For Administration, Commerce and Transport. EDIFACT is a cross-industry international standard for the format of electronic data in business transactions. EDIFACT is one of several international EDI standards. Responsible for the EDIFACT standard, a UN agency called CEFACT, the UNECE is affiliated.

EDIFACT Directories

The different EDIFACT versions are called directories.

This EDIFACT directories are revised two times each year on 1 April and 1 October, to accommodate new EDIFACT messages or update existing ones. EDIFACT directories have names like D.03B

EDIFACT subsets

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

  • CEFIC - Chemical industry
  • EANCOM - Consumer Goods Industry
  • Edi @ Energy - Power and Gas ( valid for Germany )
  • EDIBDB - building materials industry
  • EDIFICE - High Tech Industry
  • EDIFOR - freight forwarding industry
  • EDIFURN - Furniture industry
  • EDIGAS - gas pipeline business
  • EDILEKTRO - Electrical Industry / Electrical Wholesale
  • EDILIBE - bookshops
  • EDIPAP - paper manufacturer / wholesale / processing industry
  • EDITEC - sanitation sector
  • EDITEX - Textile industry
  • EDITRANS - Transport Economics
  • EDIWHEEL - tire and wheel manufacturers (including AdHoc EDI)
  • ETIS - telecommunications (for invoice)
  • ODA / ODIF - General document formats
  • ODETTE - Automotive
  • RINET - Insurance Industry

EDIFACT message types

Understanding standardization concept of EDIFACT is that there is uniform message types whose English name United Nations Standard Message ( UNSM ) is. In so-called subsets message types can be specified industry-specific deeper into their forms. Below is a selection of the most common types of messages that always contain exactly all of a nickname on the length of six capital letters:

Service messages

For confirmation / rejection of a message CONTRL and APERAK messages are sent.

Test steps:

Data exchange

  • DELFOR - delivery schedule ( delivery forecast)
  • DELJIT - JIT containing detailed provisions regarding delivery sequence and timing ( delivery just- in-time )
  • DESADV - ASN ( dispatch advice message)
  • IFCSUM - Bordero (International forwarding and / or transport Consolidation Summary Message )
  • IFTDGN - Dangerous Goods Advisory ( dangerous goods notification message )
  • IFTMBC - booking confirmation ( transport booking confirmation )
  • IFTMBF - Booking inquiry ( transport booking request)
  • IFTMIN - Transport-/Speditionsauftrag ( instructions of transport )
  • IFTSTA - Status message to a transport (status of transport )
  • INSRPT - Test report ( inspection report)
  • INVOICE - Invoice ( invoice message)
  • INVRPT - Inventory Report ( inventory report)
  • MSCONS - counts ( metered services consumption report message)
  • ORDCHG - notification of change of an order (purchase order change message)
  • ORDERS - Order ( purchase order message)
  • ORDRSP - in response to an order ( purchase order response message)
  • QUOTES - quotation (offer production)
  • PAYMUL - remittances in payment transactions (multiple payment order )
  • PAYORD - money order ( payment order message)
  • PRICAT - Price / Sales Catalogue (price catalog message)
  • PRODAT - product data (product data message)
  • RECADV - Goods receipt message ( receipt advice )
  • REMADV - Remittance ( remittance advice )
  • REQOTE - Request for Quotation ( offer inquiry )
  • UTILMD - master data for customers, contracts and reporting points ( utilities master data message)

EDIFACT structure

Each message consists of an envelope ( envelope - English ) that wraps the message content of a similar envelopes. This envelope consists of the segments UNB and UNC. In this envelope are each agreed code numbers for the sender and receiver, as well as news content, hours of tracing, and inspection routines. A message itself is composed of segments, data element groups and data elements. In the following example, these terms are explained in detail.

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

Delimiter default UNA Optional ( Service String Advice)   ----- Transfer File Header Data Required UNB (Interchange header)   | --- Functional group header data UNG Optional ( Functional Group Header)   | | - Message header data UNH Required (message header)   | | | Data segments as needed (User Data Segments)   | | - Message Termination Required UNT (Message trailer )   | --- Function group 's degree UNE Optional ( Functional Group Trailer)   ----- File transfer completion UNC Required (Interchange trailer ) UNA UNB     UNG        UNH                  UNT        ...        UNH                  UNT     UNE     ...     UNG        UNH                  UNT        ...        UNH                  UNT     UNE UNC Functional groups ( UNG- UNE ) and messages ( UNH -UNT ) are repeatable. UNT in the number of segments of the message is given (including the UNH -UNT segments) for testing yet.

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 codes is as follows:

  • DTM is an identifier (english day) and is the mark that it is for the following data for date / time information. ( DTM stands for Date / Time ).
  • 11 is a data element (abbreviated element). This example describes a qualifier which type is meant by time. The code 11 means: sending time (eg delivery of goods ).
  • 200606200730 is another element. Here it represents the date in the spelling YYYYMMDDhhmm
  • 203 is also an element. 203 is an identifier for the date format. In this example, 203 means that the date in the format YYYYMMDDhhmm ( ie 4 digits for the year, 2 for month, 2 for the day, followed by the time using 2 digits for the hour and 2 digits for the minutes) is indicated.
  • The entire block is 11:200606200730:203 data element group (English composite elements, in short, composites ) called (identified by the delimiter colon instead of plus).

A complete UN / EDIFACT Interchange, the example here contains an order according to the standard from the spring of 1996, might look like this:

UNA: . ? ' UNB UNOC: 3 transmitter identification Empfaengerkennung 060620:0931 1 1234567' UNH 1 ORDERS: D: 96A: UN ' BGM 220 B10001 ' DTM 4:20060620:102 ' NAD BY customer name street city 23436 xx ' LIN 1 Product screws: SA ' QTY 1:1000 ' UNS S ' CNT 2:1 ' UNT 9 1' UNC 1 1234567' It should be noted that this message will no line breaks have been inserted in this example for readability packed. Whether is transmitted with or without a break, is to be agreed between the partners. Most EDI converter can deal with both. In all UN / EDIFACT interchanges UNA sets: . ? 'As the first segment of the message Advise the delimiter determined. The colon ( ":") is the component separator, the plus sign ( " ") to the element separator to dot (". " ) Is defined as the decimal separator, the question mark ("?" ) For Release Indicator, the space character ( " " ) is a space, and the apostrophe ( " '") is the segment terminator. The release indicator is necessary so that the meaning of a separator is removed to represent, for example, a plus sign in free text ( escape sequence ). Then follow the UNB Interchange Header each message, starting with UNH and UNT stop. Is rarely used, the ability to group messages. This is done by means of the UNG and UNE segments. A UNC - segment ends the Interchange, repeated the number and summed the number of messages, such as the UNT segment the number of segments are summed within a message.

Transmitter and receiver identifier is transmitted as a Global Location Number ( GLN). Products with its Global Trade Item Number ( GTIN ) or European Article Number ( EAN ), which corresponds to the information printed on the goods bar code is transmitted.

Data format

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

Originally EDIFACT was the domain of value-added networks ( VAN ) or was used on leased lines. There were projects that EDIFACT messages transported via diskette or magnetic tape. EDIFACT is now also used on the Internet, such as communications protocols such as X.400, e-mail, AS2, MBS / IP, FTP, or OFTP2.

Either, the application program involved in the ability to generate or process EDIFACT messages, or a converter is interposed, which converts the data accordingly. As the data is converted, will be configured. Are produced with the so-called mapping tables, which are supplied to the converter. Conversion of EDIFACT in an XML format and vice versa is possible. This additional control is used, which takes over the communication process of the partner management, table management, the logging and archiving fully automatic. Some companies employ such software on site, let others do the conversion service centers perform ( EDI outsourcing). There are some open source converter.

UN / EDIFACT is a format that describes the vast majority of all business documents. It is necessary between the partners (trading partner ) to make accurate descriptions of data content, which defines the optional fields and required fields in selected segments. Frequently, there is private code ListExtensions will be necessary to accurately reflect the real course of business. From this code ListExtensions arise industry standards that are standardized in subsets. For application fields where industry standards are missing or these agreements are special processes are used, for example, defined bilaterally on an EDI agreement.

254508
de