Anatomy of the Segment
Returning to our 990 example, the key information is contained within this line:
B1*ACME*339807*20220802*A~
Let's break this down.
First of all, although our example EDI file's lines are separated by carriage return characters, many EDI documents are not separated, and may arrive with no formatting whatsoever. Each line is, instead, delineated by a character. In this particular EDI file, that character is the tilde (~). However, this can vary.
The line begins with B1. B1
identifies a , and
it means "Beginning Segment for Booking or Pick-up/Delivery".
How do we know this? After all, nowhere in the document do the words "Beginning Segment for Booking or Pick-up/Delivery" appear.
This question is at the heart of what makes EDI more challenging than more modern document transmission formats such as XML or JSON. Much of the meaningful information contained within an EDI file is not contained within the file at all, but appears in other documents.
The X12 contains definitions for thousands of segments. This particular EDI file's release version is 00401. X12 00401 defines what B1 means within the context of the : the specific kind of document we are dealing with (in this case, the 990).
The is how a given trading partner has decided to use, or implement, the X12 transaction set specification.
You can think of the X12 release's specification as the make and model of a car, and the implementation as the colour and trim. Or to use more technical terminology, the release defines a schema, and the implementation is a subset of that schema.
A trading partner typically communicates the details of their implementation in a document that is often referred to as an or just a "guide".
Back to our example. We now know that this line:
B1*ACME*339807*20220802*A~
Contains the key information about whether or not Acme Trucking has agreed to deliver this shipment. Earlier we saw that the entire file is split into lines using tildes. Each line is split into . In this case, the elements are separated by asterisks (*).
As such, this line contains four elements. Using a typical labelling scheme, these are written out as:
B1-01: ACME
B1-02: 339807
B1-03: 20220802
B1-04: A
Just like the X12 specification defines what B1 means, it also defines what each element within B1 means. The fourth element in B1, B1-04, is the "Reservation Action Code". Here, we see an "A".
558 View element 558 (Reservation Action Code) in the X12 ReferenceOnce again -- you should be picking up on this pattern now -- the meaning of "A" is defined in the X12 specification. In this context, an "A" means "Reservation Accepted". In other words, Acme Trucking said "yes, we'll take it".
A "D" in B1-04, on the other hand, means "Reservation Cancelled" (i.e., declined): "no thanks".
It Gets Much More Complicated (But Don't Worry)
You now understand some of the basics of X12 EDI syntax. Unfortunately, it only gets more complicated.
For instance, EDI supports , which is what X12 calls repeating structures, i.e. collections or arrays. However, there is no syntax (such as brackets) in X12 EDI for defining collections. Whether or not one or more lines in an EDI file are a collection is solely determined by the X12 transaction set specification.
In other words, just like you can't tell what "A" means without referring back to the spec, you can't tell if you're looking at a collection without referring back to the spec.
The solution is to stop dealing with X12 EDI directly.