EDI Standardization.


EDI STANDARDIZATION

EDI standards describe the rigorous format of electronic documents designed by the implementer, to be independent of communication and software technologies. 

A standard is a method of coding data to facilitate Electronic Data Interchange (EDI).

EDI Standards provides:
  • Rules of syntax. 
  • Definition of the data organization. 
  • Editing rules and conventions. 
  • Published public documentation (i.e., a standards manual).

This provides the standards user with:
  • An open system—where trade is possible with anyone who uses the same standard. 
  • Reduced implementation effort—the implementation of a standard can, itself, be standardized. 
  • Third-party interfaces—software and network applications can be written that address specific business needs and conform to a single standard.
EDI MESSAGE
An EDI message provides a means of transferring data electronically from one partner to another. Each EDI standard defines many different types of message. 

How to read an EDI message?
  • An EDI message is, essentially, a computer file containing structured data. Usually it will contain characters which separate one piece of data from the next, but never any explanations of what the data represents. The standards explain fully what data may be transmitted in each document, and how the data is to be laid out in the file. If the standards are adhered to, then all partners using the same standards can decipher the data. 
  • First of all, the recipient should know beforehand which EDI messages he can expect to receive from his trading partners. This information is usually provided during initial trading agreements between the customer and supplier. It is usually the customer who dictates which standard is to be used, which messages from that standard will be exchanged, and what data is to be transmitted in those messages. 
  • Secondly, there is information within an EDI message that indicates which EDI standard was used to create it. Armed with the knowledge of which standard is being used and which message from that standard has been received, it is possible to use the message standard to read the message.
NEED FOR EDI STANDARDS: 

EDI documents are intended to be sent, received and interpreted by computers. For the interpretation to be successful, the data must be in a format that both computers can understand. Use of standards minimizes the difficulties and expenses that would result if each trading partner were to impose its own formats on every partner with which it does business. 


SOME EDI STANDARDS:
A number of EDI standards bodies exist, whose purpose is to develop and maintain sets of EDI messages (in EDI terminology, an EDI document is usually referred to as a message).

Some of these are:
  1. UN/EDIFACT
  2. The US standard ANSI ASC X12 (X12).
  3. GS1 EDI
  4. The TRADACOMS.
  5. The ODETTE standard.
  6. The VDA standard. 
  7. RosettaNet
  8. HL7, a semantic interoperability standard used for healthcare data.
  9. Edig@s (EDIGAS) is a standard dealing with commerce, transport (via pipeline or container) and storage of gas.


1. UN/EDIFACT

United Nations/Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) is the international EDI standard developed under the United Nations.  

In 1987, following the convergence of the UN and US/ANSI syntax proposals, the UN/EDIFACT Syntax Rules were approved as the ISO standard ISO 9735 by the International Organization for Standardization.  

The UN-recommended UN/EDIFACT is the only international standard and is predominant outside of North America.  

The work of maintenance and further development of this standard is done through the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) under the UN Economic Commission for Europe, in the Finance Domain working group UN CEFACT TBG5.

The EDIFACT standard provides:
  • A set of syntax rules to structure data.
  • An interactive exchange protocol (I-EDI).
  • Standard messages which allow multi-country and multi-industry exchange.
 

STRUCTURE

EDIFACT has a hierarchical structure where the top level is referred to as an interchange, and lower levels contain multiple messages which consist of segments, which in turn consist of composites. 

The final iteration is an element which is derived from the United Nations Trade Data Element Directory (UNTDED); these are normalised throughout the EDIFACT standard.

A group or segment can be mandatory (M) or conditional (C) and can be specified to repeat.

For example :
- C99 indicates between 0 and 99 repetitions of a segment or group
- M99 signifies between 1 and 99 repetitions of a segment or group 
 
 
SIX CHARACTERS FOLLOWING UNA IN ORDER:
1. Component data element separator (: in this sample).
2. Data element separator (+ in this sample). 
3. Decimal mark (. in this sample).
4. Release character (? in this sample).
5. Reserved, must be a space.
6. Segment terminator (' in this sample).

With the exception of the decimal mark, the special characters in the sample UNA segment above are also the default values.
The component data element separator and data element separator are the "first level" and "second level" separators of data elements within a message segment. Referring to them as + and : for brevity, the + separates top-level or composite data elements, and : separates second-level data elements nested within composite data elements. Trailing empty (or null) data elements and their leading separators are omitted to reduce message size.
The decimal mark is used to separate the integer from the fractional part of non-integer numbers. The optional nature of the UNA segment and the initial choice of the comma (",") as the default decimal mark provide a source of common confusion. Versions 1 through 3 of the ISO 9735 syntax rules specify the comma as the default; version 4 states that the decimal mark position in the UNA segment is to be ignored and that the comma and the dot (".") may be used indifferently in numeric data values. The UNB segment indicates which version of the syntax rules is in effect.


Release character (analogous to the \ in regular expressions) is used as a prefix to remove special meaning from the separator, segment termination, and release characters when they are used as plain text.

Segment terminator indicates the end of a message segment.
 
 
EXAMPLE

An EDIFACT message used to answer to a flight ticket (FRA-JFK-MIA) availability request:

UNA:+.? '
UNB+IATB:1+6XPPC+LHPPC+940101:0950+1'
UNH+1+PAORES:93:1:IA'
MSG+1:45'
IFT+3+XYZCOMPANY AVAILABILITY'
ERC+A7V:1:AMD'
IFT+3+NO MORE FLIGHTS'
ODI'
TVL+240493:1000::1220+FRA+JFK+DL+400+C'
PDI++C:3+Y::3+F::1'
APD+74C:0:::6++++++6X'
TVL+240493:1740::2030+JFK+MIA+DL+081+C'
PDI++C:4'
APD+EM2:0:1630::6+++++++DA'
UNT+13+1'
UNZ+1+1'
 
The UNA segment is optional. If present, it specifies the special characters that are to be used to interpret the remainder of the message. 

The line breaks after each segment in this example have been added for readability. There are typically no line breaks in EDI data.

UNH+1+PAORES:93:1:IA'- This is the message header segment which is required at the start of every message. This code specifies that the message name and version is PAORES 93 revision 1 and it was defined by the organisation IA (IATA).

IFT+3+NO MORE FLIGHTS' - This is an "Interactive Free Text" segment containing the text "NO MORE FLIGHTS".

UNT+13+1' - This is the message trailer segment. It indicated that the message sent contains 13 segments.

 2. ANSI ASC X12


The Accredited Standards Committee X12 (also known as ASC X12) is a standards organization chartered by the American National Standards Institute (ANSI) in 1979 that develops and maintains the X12 Electronic data interchange (EDI) and Context Inspired Component Architecture (CICA) standards along with XML schemas which drive business processes globally. 

The membership of ASC X12 includes technologists and business process experts, encompassing health care, insurance, transportation, finance, government, supply chain and other industries.

The name "X12" is a sequential designator assigned by ANSI at the time of accreditation. ASC X12 has sponsored more than 315 X12-based EDI standards and a growing collection of X12 XML schemas for health care, insurance, government, transportation, finance, and many other industries. ASC X12's membership includes 3,000 standards experts representing over 600 companies from multiple business domains.


STRUCTURE

  • Transaction Sets are defined for each document in the standard and are made up of segments. A Transaction Set is a single business document such as a Purchase Order, Invoice, or Shipment Notice. There are hundreds of Transaction Sets available in the ANSI ASC X12 standards. Each set of transaction data is identified by a three digit code number.
  • The standard states the sequence of the segments, which are mandatory, optional or floating (for older versions), how often they may repeat, and information about looping. 
  • Segments are a collection of data elements, whether simple or composite, in a defined order. The order is laid out in the data segment table. 
  • Data elements are sometimes paired as qualifier and value. A composite data element consists of two or more component data elements separated by sub-element separators. 
  • There are three levels of envelopes: transaction set, functional group, interchange. These levels help maintain transmission integrity through a system of control numbers and segment/ transaction/group counts. 
  • Functional Acknowledgements provide end-to-end status information on a document.


Many Transaction Sets have three parts. The segments that may be used in each of these parts, within a specific document (i.e., invoice), are specified in associated tables defined in the X12 Standards document. 

For example:



ORGANIZATION

ASC X12 is led by two groups. The ASC X12 Board of Directors (Board) and the ASC X12 Steering Committee (Steering) collaborate to ensure the best interests of ASC X12 are served. 

Each group has specific responsibilities and the groups cooperatively handle items or issues that span the responsibilities of both groups.

1. Subcommittees

ASC X12 is organized into subcommittees that develop and maintain standards for a particular set of business functions.
Subcommittees representing both private and public sectors in many industries use a consensus process to propose a new standard or changes to existing standards. 
 
  • 1.  X12C Communications & Controls - Responsible for EDI control structures, security, and architecture as well as the X12 XML Reference Model.
  • 2.  X12F Finance -It  is responsible for the development and maintenance of components of the ASC X12 Standards related to the financial services industry's business activities. ASC X12F also develops and maintains interpretations, technical reports and guidelines related to its areas of responsibility.

  • 3.  X12I Transportation- It is responsible for the development and maintenance of components of the ASC X12 Standards related to the transportation industry's business activities, including air, marine, rail, and motor freight transportation and Customs, logistics and multi-modal activities. ASC X12I also develops and maintains interpretations, technical reports and guidelines related to its areas of responsibility.

  • 4.  X12J Technical Assessment- Maintains the directory, dictionary and design rules for all the X12 standards. Also manages the process for requests for standards changes.
  • 5.  X12M Supply Chain- responsible for the development and maintenance of components of the ASC X12 Standards related to the supply chain industry's business activities, excluding transportation and finance, from sourcing to delivery. Supply Chain activities include Distribution Management, Inventory Management, Marketing Data Management, Materials Management, Procurement Management, Product Management, Production Planning Management, Sales.

  • 6.   X12N Insurance- is responsible for the development and maintenance of components of the ASC X12 Standards related to the insurance industry's business activities, including those related to property insurance, casualty insurance, health care insurance, life insurance, annuity insurance, reinsurance, and pensions. Health insurance activities include those undertaken by commercial and government health care organizations.

2. Caucuses


There are informal industry groups created to identify issues and activities in specific areas. In 2014, there were four caucuses.

  1. Clearinghouse- Created in October 2012 to support and improve EDI peer-to-peer connectivity, with a focus on health information exchanges.
  2. Connectivity- Created in January 2010 to support and improve EDI peer-to-peer connectivity, with a focus on value-added networks and clearinghouses.
  3. Dental -Focuses on X12 healthcare standards in relation to dentistry and the dental industry.
  4. Provider- Focuses on interests and concerns of healthcare providers regarding X12 healthcare standards.
3. GS1 EDI
GS1 EDI set of standards developed the GS1 predominant in global supply chain is for increasing the speed and accuracy of the supply chain. 

Examples of GS1 EDI standards include messages such as: Order, Despatch Advice (Shipping Notice), Invoice, Transport Instruction, etc. 

The development and maintenance of all GS1 standards is based on a rigorous process called the Global Standard Management Process (GSMP). GS1 develops its global supply chain standards in partnership with the industries using them. 

Any organization can submit a request to modify the standard. Maintenance releases of GS1 EDI standards are typically published every two years, while code lists can be updated up to 4 times a year. 

Implementation of GS1 EDI standards -GS1 EDI standards are globally used by companies and organizations from different sectors and applied in various processes like Retail Up- and Downstream, Transport and Warehouse Management, Healthcare, Defense, Finance, Packaging (collaborative artwork development), Cash Handling, public administration and much more.

 

STANDARDS

GS1 EDI standards are designed to work together with other GS1 standards for the identification and labeling of goods, locations, parties and packages. This means that the information and product flows can be combined to provide business with tool enabling traceability, visibility and safety. In EDI, it is essential to unambiguously identify products, services and parties involved in the transaction. 

GS1 developed the following sets of complementary EDI standards:
  • GS1 EANCOM - a subset of UN/EDIFACT, which comprises a set of internationally agreed UN standards, directories and guidelines for EDI. EANCOM is fully compliant to UN/EDIFACT.
  • GS1 XML- a GS1 set of electronic messages developed using XML, a language designed for information exchange over internet. GS1 XML is based on UN/CEFACT Core Component Technical Specification (CCTS) and UN/CEFACT Modeling Methodology (UMM).
  • GS1 UN/XML - GS1 has also developed its own profiles of four UN/CEFACT XML standards (Cross Industry Order, Order Response, Invoice and Despatch Advice), which are fully compliant with UN/XML.
These groups of standards are being implemented in parallel by various users, GS1 supports and maintains all of them. 


In GS1 EDI standard messages, each product, party and location is identified by a unique GS1 identification key,e.g.:
  • Products by Global Trade Item Number (GTIN)
  • Parties, such as buyer, seller, and any third parties involved in the transaction as well as locations by Global Location Number (GLN)
  • Logistic units by Serial Shipping Container Code (SSCC).
  • Other GS1 ID keys, used e.g. for shipment and consignment identification. Using the GS1 ID Keys enables master data alignment between trading partners before any trading transaction takes place. This ensures data quality, eliminates errors and removes the need to send redundant information in electronic messages (such as product specifications, party addresses, etc.).

4.TRADACOMS

The TRADACOMS standard developed by the ANA (Article Number Association now known as GS1 UK) is predominant in the UK retail industry.

It was introduced in 1982 as an implementation of the UN/GTDI syntax, one of the precursors of EDIFACT, and was maintained and extended by the UK Article Numbering Association (now called GS1 UK).
The standard is obsolescent since development of it effectively ceased in 1995 in favour of the GS1 EDI EANCOM subsets. Despite this it has proved durable and the majority of the retail EDI traffic in the UK still uses it.

TRANSACTIONS

There are 25 transactions defined in Tradacoms: 

1. The product information file.       2. The price information file.   
3.The customer information file.     4. The order file.             
5. The picking instructions file.       6. The delivery notification file.    
7. The delivery confirmation file.    8. The invoice file.
9. The credit note file.                     10. The statement/remittance details file.
11.The uplift instruction file.          12.The uplift confirmation file.    13.The stock snapshot file.
14. The stock adjustment file.         15.The availability report file. 
16. The general communications file.       17.The complex order file. 
18. The acknowledgement of order file.  19.The product planning report file. 
20. The payment order file.                       21.The debit advice file.        22.The credit advice file. 
23.The exception condition file.  24. The location planning report file.  25.The utility bill file.
There are additional transactions defined for use in the Insurance Industry which use the Tradacoms syntax, but with implicit nesting. The service is known as Brokernet and was established in 1986.
The UK Book Trade also has additional transactions defined for Orders, Issues, and Price & Availability Updates. There are industry message variants for the News Trade, Textiles and Home Shopping.

SYNTAX AND USAGE

The syntax is very similar to EDIFACT, with the following principal differences:
  • STX/END segments used instead of UNB/UNZ
  • BAT/EOB segments instead of UNG/UNE
  • MHD/MTR segments instead of UNH/UNT
  • The segment tag delimiter is an '=' rather than a data element separator
  • Explicit nesting is always used, but implemented as data elements rather than tag extensions
  • Only implicit decimals are used
  • The compression rules are less rigorous, being merely advisory.
  • The underlying GTDI standard uses SCH instead of UNA, but this is not implemented in Tradacoms. The default EDIFACT UNOA separators are used.
The use of qualifiers, and consequently of composite data elements, is minor compared to EDIFACT. In particular any segment can occur only once in a Tradacoms message definition, and so the segments tend to be very specific rather than generic with a qualifier to identify their function. Tradacoms is not a 'Lego' system in the manner of EDIFACT.

In EDIFACT a message is a transaction. Tradacoms uses 'Files'; with one or more examples of the message being preceded by a header message, and followed by one or more trailer messages. This avoids the duplication of common header and trailer information which can occur in a series of EDIFACT messages.

Tradacoms files are equivalent to industry EDIFACT subsets. They are not generic in the way UN/EDIFACT messages are. They are only supposed to be for use within the UK, since they make no allowance for currencies other than sterling and tax information is geared to UK requirements.

Sample Tradacoms Order

This is an example of a one line order. Some of the data content has been anonymised.
STX=ANA:1+5000000000000:SOME STORES LTD+5010000000000:SUPPLIER UK LTD+070315:130233+000007+PASSW+ORDHDR+B'
MHD=1+ORDHDR:9'
TYP=0430+NEW-ORDERS'
SDT=5010000000000:000030034'
CDT=5000000000000'
FIL=1630+1+070315'
MTR=6'
MHD=2+ORDERS:9'
CLO=5000000000283:89828+EAST SOMEWHERE DEPOT'
ORD=70970::070315'
DIN=070321++0000'
OLD=1+5010210000000++:00893592+12+60++++CRUSTY ROLLS:4 PACK'
OTR=1'
MTR=7'
MHD=3+ORDTLR:9'
OFT=1'
MTR=3'
END=3'

5.ODETTE

The Organization for Data Exchange by Tele Transmission in Europe is a group that represents the interests of the automotive industry in Europe. They are the equivalent of the Automotive Industry Action Group (AIAG) in North America. The organization develops tools and recommendations that improve the flow of goods, services product data and business information across the whole automotive value chain. ODETTE has been responsible for developing communications standards such as OFTP and OFTP2.0.


 6. VDA

VDA stands for Verband der Automobilindustrie, the German Automotive Industry Association. The VDA maintain a series of fixed format messages that describe business documents typically exchanged between automotive manufacturers and suppliers.

This organization develops standards and best practices to serve the needs of companies within the German automotive industry. The VDA has developed over thirty messages to meet the need of companies such as VW, Audi, Bosch, Continental and Daimler AG.  

The VDA combines the strengths of the automotive industry and consolidates the manufacturers of passenger cars, trucks, vans and buses, the suppliers of parts and accessories, as well as the makers of trailers and bodies. This high degree of networking reflects the strength of the German automotive industry – a model that sets the standard for other automotive nations.

SOME VDA document standards:

4902 Transport Label Barcode-enabled incl. VDA 4913
4905 Call off
4905/2 Call off – Delivery Instruction (Odette Message DELINS)
4906 Invoice
4907 Remittance Advice
4908 Credit Advice
4911 Prices
4912 Delivery Note incl. VDA 4913
4913 Delivery Note
4914 Odette specification for file transfer
4915 Detailed Call Off (JIT)
4916 Call Off Just-in-sequence
4918 Vehicle Identification and Transport Data
4919 Vehicle Arrival and Departure Notification
4920 Forwarding Instruction
4921 Delivery Data

Example VDA message format

55101 10993 0009200093961122
5520221 000095053961021 8L0 880 202 A 60114A41 000006 -000000080
55301000000952096112400160158961220000000560000I0000000000000000000000000000000 0 00000000000000000
55401841142 000000
560B961123 000000000 951025 000000000 951023 0000 01120 961025 000000450 961328 000000480
55701H.MEERSBUSCH 01536/9981-100 FAX-401 K.LARSEVEEN /204 088 212
55701I
559010000001000000100000010000001000000000000020000001

  7. RosettaNet

This consists of a consortium of major computer, consumer electronics, semi-conductor manufacturers, telecommunications and logistics companies working together to create and implement industry-wide, open e-business process standards. 

These standards form a common e-business language, aligning processes between supply chain partners on a global basis. The RosettaNet document standard is based on XML and defines message guidelines, business processes interface and implementation frameworks for interactions between companies. 

Using RosettaNet Partner Interface Processes (PIPs), business partners of all sizes can connect electronically to process transactions and move information within their extended supply chains.