Jun 22, 2022
This post mentions Stedi’s EDI Core API. Converting EDI into JSON remains a key Stedi offering, however EDI Core API has been superseded by Stedi Core, an event-driven EDI system that allows you to configure integrations without being an EDI or development expert.
This document is the tl;dr of EDI. It won’t contain everything. It may not answer all your questions. It will only apply to X12. But it will save you a ton of time if you’re trying to decipher your first EDI document.
For this document, I’ll be using an 856 Ship Notice as an example. If you’re wondering what the heck an 856 Ship Notice is, you’re in the right place. Anyway, here’s the example.
What is EDI?
EDI a structured way for businesses to send documents back and forth. It can be:
a purchase order (“I want to buy this!”),
an invoice (“Pay me for this!”),
a ship notice (“I sent you this!”),
or any of 300+ other transaction types.
Think of it as a JSON Schema to cover all possible business transactions and details, but before JSON, or XML, or the World Wide Web were invented.
You might hear people talk about X12 EDI. This is just a specific format of EDI. Another common one is EDIFACT. We’ll focus on X12 EDI here.
You might also hear of 5010 or 4010 . These are specific versions (formally known as releases) of EDI. Think of a versioned API, which might have small but breaking changes as you increase versions. EDI is an old standard and it required some changes over the years.
Structure
Segments, elements, and separators
When you first look at the 856 Ship Notice, you’ll see the following:
This feels overwhelming. Don’t let it be.
Notice that the example of this particular EDI document is split into 5 lines. (The full document has 24 lines, as you can see at the start of the article.) Each line is called a segment. Each segment is broken into multiple elements.
Let’s start by breaking down what’s happening on line 1.
It starts with
ISA. This is the segment name. We’ll often refer to the segment by its name. “Ohh, they’re missing an ABC segment”, or “That’s an invalid value in the XYZ segment”. This is the ISA segment.There are a bunch of letters and numbers separated by
*. An asterisk serves as a separator between elements (technically, the fourth character—right afterISA—is the element separator, but it’s commonly a*). Elements are often referred to by their numerical index within a particular segment. For example, notice the200831near the end of the ISA segment. That is called ISA09 as it is the ninth element in the ISA segment. When you look at the definition of the segment, you’ll see that it refers to the Interchange Date in YYMMDD format. Thus,200831is August 31, 2020.
In the file we’ve looked at so far, each segment is on a different line. Sometimes you’ll get a file that’s all on one line. EDI documents will generally use ~ or a newline \n to distinguish between segments. (It’s technically the 105th byte in the ISA segment.) When reviewing a document, I find it much easier to split it into new lines based on the segment delimiter.
Common segments
Now that we know the basics of segments, elements, and separators, let’s look at some common segments. Specifically, we’re going to look at ISA, GS, and ST.
ISA
We looked at the ISA segment in the previous section. This will always be the first line in an EDI document. It’s called an interchange and contains metadata that applies to the document as a whole. This includes the document’s date and time, a control number (similar to an auto-incrementing primary key), whether it’s a test document, and more.
Typically, there’s only one ISA segment in a document, but some organizations combine multiple EDI documents into one.
GS
The GS segment will always be next. It’s the functional group and it includes additional metadata about the transactions within the group. The most important value is the last one (GS08) which indicates the X12 version that is used by the document. In the example above, the value of this element is 005010. That indicates it’s using the 5010 version.
The X12 spec allows multiple functional groups in a single document.
ST
The ST segment is for the actual transaction being sent. This is the star of the show and the reason we’re all here. It could be an invoice, a purchase order, or any other of the many transaction types.
Each functional group can have multiple transactions.
ST01 identifies the transaction type for the given transaction. In the example above, it says 856, which maps to a ship notice.
Other common transaction types are:
Closing segments
Finally, for each of these key sections, there is a closing segment (formally a trailer segment) to indicate when they end. These closing segments include a checksum and a control number.
The code fragment above shows the last three lines of our ship notice example. The SE segment indicates the end of the ST block. SE01 refers to the number of segments within the ST block. The value 20 indicates there were 20 segments in that transaction. SE02 is a control number that matches the control number from the ST segment.
Likewise, the GE segment indicates the end of the functional group, which started with GS. GE01 states how many transactions were included within the functional group, and GE02 is a control number for the group. Same thing with IEA which closes the ISA block.
Implementation guides
The X12 spec is expansive, and most companies don’t need all of it. Accordingly, companies will limit what they support. The terms may be dictated and standardized by the trading partner with the most market power, or it may be by mutual agreement between the two trading partners.
As a result, you may get an implementation guide indicating what is supported by a your trading partner. We’ll take a look at an example for a mapping guide for an 856 Ship Notice. There are two kinds of pages here: the overview page, and the segment detail page.
Overview
The overview page shows all the segments that are allowed in this particular transaction.
The Req column shows whether a segment is mandatory (M) or optional (O).
For this transaction, only two segments are optional.
The Max Use column shows the maximum number of times a segment can be repeated.
For example, the DTM segment can be used up to 10 times, which means a ship notice can have 10 dates associated with it.
A loop is a collection of segments that can be repeated, in this case up to 200 times.
A loop can also contain other loops.
Note that repeats are multiplicative. The top-level loop can be repeated 200,000 times and the inner loop 200 times, so the N1, N3, and N4 segment can be included 200,000 × 200 = 40,000,000 times.
Another look at the example document shows multiple iterations of the HL loop.
Details
The overview usually doesn’t take up more than a page or two. The rest of the implementation guide is made up of segment detail pages. Here’s one for the PRF segment.
The details page describes each element within the segment.
For example, the PRF01 segment is mandatory and can have at most 22 characters.
The PRF06 segment is optional and can have at most 30 characters.
At times, an element will accept a small number of codes that map to specific values, similar to an enum. You can see an example of that on the details page for DTM.
Transforming EDI
So far, we’ve looked at a raw EDI document and you may have noticed that the format is hard to use with your favorite programming language. It would take a lot of string parsing, array indexing, and other tedium. Stedi offers an EDI parser, converter, and validator called EDI Core.
We can take our EDI example and give it to EDI Core. EDI Core will return a JSON representation of the EDI that we call JEDI.
This is more verbose, but it’s much easier to deal with from code. You can see the EDI and the JSON side-by-side by using the Inspector. It’ll show an explanation of each segment, too.
Getting started
This is certainly not all you need to know, but it’s enough to get you started. Don’t forget to check out our blog for more information on working with EDI.