X12 EDI Definitions & Concepts

This document explains the basics of the EDI X12 standard format. 

What is EDI X12?

Just to put it simply - EDI X12 (Electronic Data Interchange) is data format based on ASC X12 standards. It is used to exchange specific data between two or more trading partners. Term ‘trading partner’ may represent organization, group of organizations or some other entity. In most cases it is just organization or company.
You will see term ‘trading partner’ used heavily in computer programs that perform actual data communication, and programs that tie data communication with specific translation.

EDI X12 standards and releases

EDI X12 is governed by standards released by ASC X12 (The Accredited Standards Committee). Each release contains set of message types like invoice, purchase order, healthcare claim, etc. Each message type has specific number assigned to it instead of name. For example: an invoice is 810, purchase order is 850 and healthcare claim is 837.

Every new release contains new version number. Version number examples: 4010, 4020, 4030, 5010, 5030, 6010, etc. Major releases start with new first number. For example: 4010 is one of the major releases, so is 5010. However 4020 is minor release.

Minor releases contain minor changes or improvements over major releases.
Understanding the difference between major and minor releases is important. Let say you have working translation for some messages for release 4010, and if you want to upgrade to 4020 you will notice only a few changes between the two, and if you want to upgrade to release 5010 you might need to make a lot of modifications to current translation.

At the time of this writing 4010 is most widely used release. It is the first release that is Y2K compliant. Most based systems know and use 4010. 5010 is next major release that is gaining popularity and will replace 4010 in the future.

Conclusion: to translate or validate EDI X12 data you need to know transaction number (message numeric name) and release version number. Both of those numbers are inside the file.

Trading Partner Requirements

EDI X12 standard covers number of requirements for data structure, separators, control numbers, etc. However many big trading partners impose they own even more strict rules and requirements. It can be everything: specific data format requirements for some elements, requirement to contain specific segments (segments that are not mandatory in EDI X12 standard being made mandatory), etc. Those specific trading partner requirements are usually listed in separate document called 'Specs'. It is essential to follow these documents to the letter when implementing EDI systems.

EDI X12 Dissected

Standard EDI X12 format data is text file separated by segment, element and sub-element delimiters (separators). You can open EDI X12 files using any text editor even standard Windows notepad.exe utility. Carriage return and line feed are not required characters by EDI X12 standard. If they are not present in the file after each segment separator you will see continues line of data in the typical text editor. It is very hard to read data formatted that way. In our examples we will use files with carriage return and line feed following segment separator, so each segment will be on a separate line.

Each segment is displayed on the separate line. In this example each segment ends with ~ (tilde). That is so called segment separator or segment delimiter. Each segment starts with 2-3 letter code that identifies it. Example: ISA, GS, ST, BHT are all segment identifiers. Each segment contains elements separated by element separator. In our example it is * (star).

While in our case separators are printable characters like tilde and star, they do not have to be. They can be other characters like <,> (greater than or less than signs) | pipe sign, also non-printable characters. Most translators detect separators for incoming EDI X12 files.

Some segments form EDI X12 envelope. They are common to all EDI X12 files and message types. Those segments are ISA, GS, ST, SE, GE, IEA. This set contains important information about trading partners (like Sender Id, Receiver Id, etc.). It also contains interchange, transaction group and transaction control  numbers, counts, transmission dates and times, and more.

These are traditional EDI X12 envelope segments at the beginning of the file.

These are traditional EDI X12 envelope segments at the end of the file.
Enveloping segments work in pairs. ISA-IEA represents an interchange. GS-GE is a group inside of  interchange and ST-SE is a transaction inside the group

Control Numbers

Each layer in the envelope contains specific control number. The processing software to identify successful and failed interchanges, groups and transactions uses control numbers. Acknowledgements (997) use control numbers to report back processing results.

These are control numbers for interchange, group and transaction.

Control numbers at the end of EDI X12 file have to match numbers at the beginning of the file.

Control numbers have specific format and length requirements. They must also be unique. They are not required to be sequential by the EDI X12 standard however some trading partners impose more strict rules in order to track data exchange.

Transaction number

Transaction number or message numeric name is always first element inside ST segment. Sometimes one EDI X12 file may contain number of transactions and those transaction numbers’ might also be different. For example: it may contain invoices (810) or purchase orders (850) with acknowledgements (997) in one and the same file. Usually files with combined mix of transactions in them are much harder to process especially if each interchange comes with separate set of separators (delimiters).

Common Transaction Types

810 - Invoice
832 - Price/Sales Catalog
845 - Price Authorization Acknowledgment/Status
850 - Purchase Order
852 - Product Activity Data
855 - Purchase Order Acknowledgment
856 - Ship Notice/Manifest
867 - Product Transfer and Resale Report
870 - Order Status Report
882 - Direct Store Delivery Summary Information
894 - Delivery/Return Base Record
895 - Delivery/Return Acknowledgement or Adjustment
940 - Warehouse Shipping Order
943 - Warehouse Stock Transfer Shipment Advice
944 - Warehouse Stock Transfer Receipt Advice
945 - Warehouse Shipping Advice
947 - Warehouse Inventory Adjustment Advice
997 - Functional Acknowledgment

Transaction Set Detail

Hierarchy of Relationship > Transaction Set > Data Segment >Data Elements

Standard File Structure

Data Elements

• The data element is the smallest named unit of information in the standard
• Each data element is identified by a number
• Data elements can represent a code, a value, or text (such as a description)
• Each data element has both a minimum and maximum length
• Data elements can be mandatory, optional, or relational

Data Element Types

There are seven types of data elements:

Data Element Use

Data Elements may be:

• M = Mandatory
• O = Optional
• X = Syntax note applies
• Z = Semantic note applies

Combinations may be applicable.

Simple and Component Data Elements

Data elements are identified as either:

• Simple
• Component
  • Used to form composite data structures -- a group of two or more component (simple) data  elements linked together to form a single data element
  • The component data elements may be optional, mandatory, or relational

Data Segment

The data segment is an intermediate unit of information in a transaction set.  Each data segment is composed of:

• A unique segment ID
• One or more logically related data elements

The data segment is used to convey a grouping of functionally-related user information.

Data Segment Characteristics

• Data is organized in a defined sequence within the segment
• Each data element in the segment is identified by a reference designator, composed of the unique  segment identifier and the element’s sequence number
• Each data element is separated by a data element delimiter character
• A segment terminator character identifies the end of the segment

Data Segment Diagram

Data Segment Diagram - Data Dictionary Format

Data Segment Notes

Three types of segment level notes:

• Syntax: Define dependencies based on the presence or absence of other data elements in the segment
• Semantic: Provide additional information about the data element including any dependence based  on the data value in another data element in the segment
• Comments: Clarify the intended use of the segment - comments are not part of the standard

Data Segment Loops

Example:

Nested Loops

• Loops may have subordinate loops nested within them.
• The name of the nested loop is indicated by the Loop ID which is named for the first segment in the subordinate loop.
• Nested loops cannot begin with the same first segment as the previous (or outer) loop
• Nesting may occur up to an indefinite number of levels
  
  

Transaction Set Table Diagram

• Identifies the purpose of the transaction set
• Identifies all the segments which comprise the transaction set in sequence by position number
• Identifies the structure of the transaction set as heading (table 1) or detail (table 2) or summary
  (table 3)
• Identifies the loop and nested loop structure
• Indicates which segments are Mandatory or Optional
• Indicates the maximum use of repeating segments

Transaction Set Composition