But What does it Mean? X12 Semantics

The meaning of the data in an X12 Transaction Set is defined in several places in the X12 standard. The primary sources are the Data Element Dictionary (X12.3), the Segment Directory (X12.22), and the Transaction Set Tables (X12.1). A useful document that deals with semantics from a general perspective is the technical report on "Implementation of EDI Structures - Semantic Impact" (X12.59). Much of the content of this page is based on the work of X12C/TG3, which was performed in preparation for the technical report on how to express X12 semantics in XML syntax. For more information about that effort, please visit the X12C/TG3 page at ANSI ASC X12.

EDI translation software may validate the syntax of an interchange by checking it against a segment directory, transaction set tables, and data element dictionary to validate data types and code values for ID elements. However, the determination of the exact semantic meaning of a particular data element, that is, the location in the users database or file to which it corresponds, must ultimately be determined by the user and the trading partner. Syntax can be (and commonly is) validated by EDI translation software. Proper usage of semantics can not.

Context is Everything - The Dispersed Nature of X12 Semantics

The semantic meaning of a particular data element can usually not be fully determined without considering the full context of the data element, such as the Transaction Set, loop, and segment in which it appears. In a few cases it is also necessary consider the values in other elements in the segment. This attribute has been referred to as dispersed semantics.

For example, the sixth element of the N4 segment, N406 data element 310, is Location Identifier, and for example might have a value of "XYZ". However, we don't know this without considering GS08, which indicates the X12 version and release. By itself, Location Identifier does not mean much. It is qualified with N405 data element 309 Location Qualifier, which conveys the type of identifier. For example, "SN" in N405 indicates that the value in N406 is a Store Number. However, this still does not mean very much unless we consider that these elements appear in an N4 Geographic Location segment which appears in an N1 Name/Address loop. We don't know what kind of Name we are talking about unless we examine the code in N101, data element 98 Entity Identifier Code, which might indicate "ST" for a "Ship To" Name. So, we know are to ship to store number XYZ. However, if the N1 loop is in an 850 Purchase Order, we don't know if we ship the whole order to XYZ or just a line item unless we consider the segments that have come before the N4 and can determine that it is in the Header area of the transaction set or in a PO1 Line Item loop. The occurrence within an 850 Purchase Order transaction set sets an overall context for the exchange, and finally the group and interchange envelope segments complete the context by specifying the sender and receiver. Confusing, huh?

One more time, from the Bottom Up

At the lowest level, the meaning of a data element is defined by its name and description in the Data element dictionary.

If a data element is a component element of a composite data element, the meaning is further qualifed. For example Unit or Basis for Unit Measure (DE 355) is given further context and meaning by appearing in the composite data element Composite Unit of Measure (C001).

A data element (simple or composite) is further defined by the segment in which it is used. For example, the Amount data element (DE 610) has an entirely different meaning when used in the "Total Monetary Value Summary" (TDS) segment than when it is used in the "Adjustments to balances or services" (ADJ) segment. An element may be futher qualifed in a segment by:

• Pairing it with another element as a qualifer. For example, the sixth element of the PO1 segment, Product/Service ID Qualifier (DE 235) contains a ID value that tells what kind of product or service appears in the seventh element, Product/Service ID (DE 234). The value "VP" in PO106 tells us that PO107 is a Vendor Part Number.
• A Segment Semantic Note - There are four Amount elements (DE 610) in the TDS segment. Semantic notes tell us that the first is the total amount of the invoice, the second is the amount on which a discount is based, the third is the amount due if paid by the terms discount date, and the fourth is the total amount of terms discount.

The meaning of a segment is qualified by:

• Where it appears in the Transaction Set. The Administrative Communications Contact (PER) segment has a different meaning in the Invoice (810) in the header area just before the N1 loop than it does within the N1 loop.
• A value in a qualifier element, usually the first element in the segment. For example, "SY" in Reference Identification Qualifier (DE 128), REF01 of the Reference Identification segment, says that the whole REF segment describes a Social Security Number.

The meaning of a segment loop can often be qualified by a value in a qualifier element in the first segment. For example, "ST" in Entity Identifier Code (DE 98) in N101, says that the whole N1 loop is about the Ship To Name/Address.

Position vs. Occurrence, and other Fine Points

X12 experts will say that where a data element or segment occurs has no semantic meaning, but that position is all important. How do we resolve this seeming contradition? The answer is this: When designing a Transaction Set, the order of elements within a segment, and the order of segments (at the same level), within a Transaction Set, have no semantic significance. For example, it is not important that N1 Name comes before N3 Address Information. However, once the Transaction Set has been designed, it is essential that data streams coded to that transaction set definition observe the prescribed order. Translators are able to identify data elements and imply semantic meaning strictly by position in the data stream. So, during design position is not important, but when implemented position is everything.

A complication of this concept is found in many Implemention Conventions, but is not supported in the standard. That is when someone dictates that specific semantic meaning is assigned to a particular occurrence of a segment or element. For example, where we might have three occurences N1 Name/Address loop in the header area of an 810 Invoice (i.e. three occurences in the same position), we may be told to put the "Buyer" in the first loop and the "Bill To" in the second. We don't do this in the standards.

The only qualification to all of this is found in X12.59, with the notion of "Functionally Equivalent Data Over-ride". This means that if the same information appears in the header and detail areas of a data stream, that the information in the detail area takes precedence. For example, we may have a primary "Ship To" address in an N1 Name/Address loop in the header area of an 850 Purchase Order, but a "Ship To" address in an N1 Name/Address loop in a Baseline Item Data (PO1) segment loop in the detail area says that that line item should be shipped to a different address.

A Simple Example

The following is an example of data that might be found in a paper Purchase Order and the corresponding X12 Interchange. It illustrates how we get meaning from context.

For the highlighted data items:

• PO Date is in BEG06
• The Seller Name and Address are in the first N1 loop
• The Ship To Name and Address are in the Second N1 loop
• The Bill To Name and Address are in the Third N1 loop
• The unit price of the Widgets is in PO104

Please note that the ISA segment is wrapped over two lines for easier reading.

ISA*00*          *00*          *01*0011223456   *01*999999999*
    950120*0147*U*00300*000000005*0*P**<CR>
GS*PO*0011223456*999999999*950120*0147*5*X*003040<CR>
ST*850*000000001<CR>
BEG*00*SA*95018017***950118<CR>
N1*SE*UNIVERSAL WIDGETS<CR>
N3*375 PLYMOUTH PARK*SUITE 205<CR>
N4*IRVING*TX*75061<CR>
N1*ST*JIT MANUFACTURING<CR>
N3*BUILDING 3B*2001 ENTERPRISE PARK<CR>
N4*JUAREZ*CH**MEX<CR>
N1*AK*JIT MANUFACTURING<CR>
N3*400 INDUSTRIAL PARKWAY<CR>
N4*INDUSTRIAL AIRPORT*KS*66030<CR>
N1*BT*JIT MANUFACTURING<CR>
N2*ACCOUNTS  PAYABLE DEPARTMENT<CR>
N3*400 INDUSTRIAL PARKWAY<CR>
N4*INDUSTRIAL AIRPORT*KS*66030<CR>
PO1*001*4.95*EA*14850*TE*IN*525*VN*X357-W2<CR>
PID*F****HIGH PERFORMANCE WIDGET<CR>
SCH*4*EA****002*950322<CR>
CTT*1*1<CR>
SE*20*000000001<CR>
GE*1*5<CR>
IEA*1*000000005<CR>

About  |  Services  |  Resources  |  Contact

©Rawlins EC Consulting 2007