What is it?
ANSI ASC X12 stands for American National Standards Institute Accredited Standards Committee X12. This messaging standard defines over 300 message types for all kinds of different sectors, including retail, transportation and insurance. There are also many parallels with EDIFACT – largely due to the fact that X12 is a predecessor to EDIFACT.
However, this predecessor is still widely used, particularly in the USA, but also in Australia (among other territories). The X12 committee itself runs X12 as a national standard and refers to international standards on a page belonging to the UN/CEFACT, which itself references UN/EDIFACT in turn. All of which might make you think you don’t need to pay any attention to all this X12 stuff, since EDIFACT is recognised as an international standard. Unfortunately, things aren’t as simple as that. Anybody who deals with business partners outside Europe will generally also come into contact with X12 sooner or later. For that reason, we have provided a little more detailed information below:
Here, you can see an example of a small X12 file containing an order (in which the first line crosses a line break):
ISA* * * * *ZZ*SENDER *ZZ*RECEIVER *041201*1200*U*
N3*111 Buyer St
N1*SE*Foo Bar Sellers
If you haven’t read the article on EDIFACT yet, you should go back and do so now, as the logic behind the order of the segments is very similar. By way of clarification, the screenshot to the right shows part of the structure of message type 850 (purchase order) displayed in Lobster_data:
Although what EDIFACT calls segment groups (SG1 to SGx) are called “loops” in X12, the logic remains the same. Individual segments can be repeated. Whenever a group is repeated, the first segment in the group (or loop) always indicates that it is starting again from the beginning. And here too, once we have passed a particular point in the structure, we can’t go back again.
The details - Differences
X12 differs a little from EDIFACT when we examine it in detail:
- First of all, there is no equivalent to the UNA segment. Instead, the separators used are identified by virtue of their position in the ISA segment:
- The character directly following “ISA” is the field separator (in the example, the character used is *).
- Position 105 is where we find the separator for values within components (aka composites – in this case the separator character is ^).
- The character after that is the segment separator. In our case, the segment separator is a line break.
- The decimal separator is not specified, and there is no escape character either. The entire ISA segment is structured like a fixed record.
- One thing that has recently been introduced to EDIFACT but is not used there, is the “repetition character”. This appears in position 83. In the example on the left, you can see a “U” there, which stands for “unused”. If this character is used, a field or an entire composite can be repeated multiple times within a segment, with the individual repetitions separated by this character. This needs to be specified within the message description, however – something that doesn’t happen all that often.
- There are no subsets in X12. The X12 committee takes a parsimonious approach here, and charges a fee for the format descriptions of each new version.
- The message types are identified by their numbers (850 in the example). The more meaningful “PO” (for purchase order) in the GS segment is not directly equivalent to this, since it refers to a functional group – and therefore might refer to multiple message types that belong together thematically. For example, the “SO” functional group contains ten different message types (version 006040).
- Segment identifiers do not need to be three characters long, as in EDIFACT. Two can sometimes be enough as well.
The details - Commonalities
- As we have just seen, X12 features segments, standard fields and composites (also known as components), while loops are equivalent to segment groups.
- X12 also has a wide range of control segments that introduce files or bracket messages:
- ISA functions broadly as a combination of UNA and UNB, and includes information such as the parties involved, the date/time, and the most important special characters. There is no required character set, since this is set to ASCII in X12.
- GS and GE work similarly to UNG and UNE, and bracket groups of thematically associated messages (functional groups). In the example above, the “PO” in the GS segment stands for purchase order.
- ST and SE bracket messages in the same way as UNH and UNT do in EDIFACT. In the ST above, the code 850 stands for the message type, which is a purchase order.
- At the end of the file comes the final IEA segment, which works in the same way as the UNZ in EDIFACT. Groups are mandatory in X12, so this segment contains the number of groups in the file (GS/GE).
- The ISA/IEA, GE/GE and ST/SE pairs also contain identification numbers to ensure that they are associated with each other. SE also contains a counter for all the segments in the message, including the SE segment itself. As such, GE also contains the number of messages (aka transaction sets) within its group.
Of course, X12 has evolved over time. The versions are named differently, however. For example, version number 006040 stands for:
version 6, release 4, sub-release 0.
Incidentally, the end of the GS segment (and also the ISA segment) in our example message indicates that the message is written in X12 version 003050. That makes it a little outdated by now…