Electronic Data Interchange (EDI) has been around since the late sixties. It was not until the mid-eighties that EDI became widely accepted. Loosely defined, EDI is the computer-to-computer transmission of business data in a standard format, which replaces a traditional paper business document. Over the years, various standards organizations have developed the standards used today. While there are many specialized standards (e.g., FORD, GM, HIPAA), the ANSI X12, USC, and UN/EDIFACT standards are the most popular. ANSI X12 and USC are popular in North America and UN/EDIFACT is used primarily in the European and Asian communities. These standards specifications were developed well before the advent of self-describing data structures (e.g., XML) and are therefore very cryptic to read and understand to the human eye.
In general, an EDI transaction can be described as a variable length, delimited flat file with a very strict structure. That said, the structure does allow for dynamic forms through the use of loops and repeating segments (see below for details on loops and segments). Additionally, the standards also describe things such as character sets, formats, and code lists which further define and describe the business document. For instance, a data element for “Unit of Measure” (UOM) may only contain values from a code list which further defines the UOM codes (e.g., EAC=each, CRT=cartone, etc.) Because of the complexity of the EDI standards, early development of EDI solutions was limited to a narrow set of developers. However, over the years, many software solutions have evolved which simplify the implementation of EDI transactions. The EDIFEC SpecBuilder product TIBCO OEM’s as part of our EDI solution is a best-of-breed example of this type of solution.
Following is a description of the pieces and parts of an EDI transaction. The examples provided use an ANSI X12 Product Registration (140 – said “one forty”) as a reference. All examples will be shown using SpecBuilder. The following screenshot, represents the high-level description of the Product Registration transaction set 140
The interchange control group is comprised of the “ISA” and “IEA” segments. These segments provide a set of envelope information that describe critical information for a given business document transmission. The interchange control group guideline can be defined at a global level for a given trading partner and used across all transactions for that trading partner, or it can be defined differently for every EDI transaction.
The interchange control header, or ISA segment, provides critical information such as, interchange sender and receiver IDS, address information, date and time the data was generated for transmission, the interchange control number, the segment terminator, and the data element separator.
The interchange control trailer, or IEA segment, indicates the number of Function Groups enclosed and matches the interchange control number of the corresponding ISA segment.
A functional group is a collection of one or more transaction sets of the same type (in this case a V4010 140). A functional group begins with the GS and ends with the GE segment.
The functional group header, or GS segment, indicates which type of transaction sets is enclosed. All transactions within the functional group must be of the same time. In addition, the functional group header also identifies the specific version, release, sub-release, and industry identifier of the EDI standard being used.
The functional group trailer, or GE segment, indicates the number of transaction sets enclosed and matches the Group Control Number sent in the corresponding GS segment.
Like the interchange control group, the functional group can be defined at a global level for each trading partner for a given transaction, or it can be defined differently for each transaction.
Multiple function groups can be sent within the same transmission.
A transaction set is comprised of a collection of segments in a predefined sequence that conveys the business information of a specific transaction to the receiver. A transaction set is always enveloped by the ST and SE segments.
The transaction header, or ST segment, indicates which transaction set is being sent, via the Transaction Set Identifier Code (in this case, it would be “140”) and relays a control number for the transmission.
The SE segment provides the closure for each transaction and provides a check of the integrity of the transmission. It contains a count of the segments in the transmission (including the ST and SE segments) and is the match to the control number sent in the ST segment.
The remainder of the transaction set is comprised of the defined segments which convey the business information of the transaction.
The example above provides one example of the use of loops. Another common example of the use of loops is the specification of line items for a purchase order.
A data segment is a collection of related data elements. In the above example the N1 segment (Name segment) is used to contain the Entity Identifier Code, Name, Identification Code Qualifier, Identification Code, Entity Relationship Code, and Entity Identifier Code elements.
Each segment begins with a segment identifier and ends with a segment terminator (defined in the ISA control segment).
Data elements within a segment are separated by the element separator (also defined in the ISA Control segment). The last element in a segment ends with the segment terminator.
Name | Dates | |
---|---|---|
Spotfire Training | Nov 05 to Nov 20 | View Details |
Spotfire Training | Nov 09 to Nov 24 | View Details |
Spotfire Training | Nov 12 to Nov 27 | View Details |
Spotfire Training | Nov 16 to Dec 01 | View Details |
Ravindra Savaram is a Technical Lead at Mindmajix.com. His passion lies in writing articles on the most popular IT platforms including Machine learning, DevOps, Data Science, Artificial Intelligence, RPA, Deep Learning, and so on. You can stay up to date on all these technologies by following him on LinkedIn and Twitter.