| We need to get some terminology straight first. I'm never quite sure whether to start at the bottom or the top when trying to explain the X12 EDI standards. Since this book is about XML and XML is about documents, let's start at the middle with X12's notion of a document. I'll note where the UN/EDIFACT standard uses different terminology. -
Transaction set : This is X12's notion of a document. In the strictest terms a transaction set is the actual instance document in a data stream. However, even in the standards the term is sometimes ambiguously used to describe the definition or designation of a document type in the standard rather than an instance of the type. Each transaction set type is oriented toward exchanging a specific type of business information. X12 defines standards for over 300 different types of transaction sets. A transaction set may be specified so as to convey just one logical business document, as is the case with most purchase orders. However, it may be specified to allow transmission of several logical business documents within one transaction set instance. An example is the Health Care Claim, which can convey several claims for several patients and several providers. (A real mess in my opinion, but I wasn't around when it was being defined and I'm not sure I could have been persuasive enough to change the outcome anyway.) Transaction set types are assigned three-digit numeric designations, such as 850 for the Purchase Order. A transaction set may be divided into header, detail, and summary areas. In a data stream a transaction set is enveloped within a transaction set header (the ST segment) and a transaction set trailer (the SE segment). In the UN/EDIFACT standard a document is a message , and it is enveloped by different segments. -
Segment : A segment is analogous to a record in a flat file or, more accurately, a row in a CSV file. Segments are variable length. A two- or three-character segment identifier (often referred to as a tag ) appears at the beginning of each segment and is commonly used as the name of the segment. The fields (or data elements as described below) within a segment are delimited by a data element separator . A segment ends with a segment terminator . In UN/EDIFACT the segment tag is analogous to X12's segment identifier. Special segments associated with envelopes, such as the interchange header and trailer segments, are called control segments in X12 and service segments in UN/EDIFACT. -
Segment group : Transaction sets may combine a sequence of several segments into a repeating group. In some places in the X12 standards and in common usage the term loop is also used to refer to these groups. Groups may contain other groups. There are a few different types of groups; the most common one is an unbounded loop . This is a group of segments identified by the starting segment of the group, which must appear if the group is used. A common example is an N1 loop that starts with the N1 Name segment. It is used to convey name, address, and other details such as contact information. -
Data element : A data element is similar to a field in a flat file record, although it is not quite so simple since there are three basic flavors of data elements. A simple data element is an atomic data item used on its own within a segment. A composite data structure (sometimes incorrectly referred to as a composite data element) is similar to a group field in flat file records. It is a reusable group of several simple data elements. An individual data element within a composite data structure is called a component data element . The component data elements within a composite data structure are delimited by a component data element separator . In UN/EDIFACT the term composite data element is correct and is analogous to X12's composite data structure. -
Functional group : For transmission one or more transaction sets are bundled together into a functional group. A functional group has a designated type associated with the business purpose of the enclosed transaction sets. Generally, each transaction set has a unique functional group type, so there will usually be only a single type of transaction set within any given functional group. However, there are a few exceptions. Some transaction sets may be used in several different types of functional groups, and a very few transaction sets are assigned the same functional group identifier. A functional group is enveloped by a functional group header (the GS segment) and a functional group trailer (the GE segment). The GS segment conveys several pieces of control information such as application sender and receiver identifiers, date and time stamps, and the X12 version and release of the enclosed transaction sets. Functional groups are mandatory in X12 but optional in UN/EDIFACT (which of course has different header and trailer segments). -
Interchange : For transmission one or more functional groups are bundled together into an interchange, which can be thought of as an envelope. An interchange starts with an interchange control header (the ISA segment) and ends with an interchange control trailer (the IEA segment). The interchange is the smallest unit of data transmitted between trading partners . Most EDI traffic, even now, is conveyed by private, third-party value-added networks ( VANs ) that function as store-and-forward EDI mailbox services. The ISA segment has sender and receiver identifiers used to route interchanges through these systems. In addition to other control information, the ISA segment also specifies the delimiters used in the interchange. UN/EDIFACT, as well as having a different set of interchange header and trailer segments, also has default delimiters. The default delimiters may be overridden with a set specified in the optional UNA segment that precedes an interchange. Those are the basic concepts and terms. There are, of course, quite a few more details, and I'll deal with some of them as the chapter progresses. I'll also present some examples. However, as I mentioned, I'm assuming that you know a little bit about EDI already and I'm not going to provide an extensive tutorial on the X12 syntax. If you need one please refer to my Web site (www.rawlinsecconsulting.com) or any one of the several good books on the subject (several are reviewed on my Web site). You can also consult the X12 standards (available for purchase from the ANSI Accredited Standards Committee X12 at www.x12.org). The standards most relevant to this book are listed below. -
X12.5, Interchange Control Structures : Deals with interchange structure and interchange control segments such as the ISA and IEA. -
X12.6, Application Control Structure : Defines the rest of the basic syntax features of X12 such as transaction sets, segments, data elements, and functional groups. -
X12.1, Transaction Set; X12.22, Segment Directory; and X12.3, Data Element Dictionary Standards : X12.5 and X12.6 define the syntax, such as the characteristics of a segment. The standards named in this bullet define the actual business content, such as the specific data elements that make up the N1 Name segment. These standards are published as a full set, with one major version and two minor releases per year. However, some individual standards are available. The versions are designated by a three-digit version number and a three-digit release number within the version. The major version has a release designation of 000. The preceding zeroes in the version are sometimes dropped in informal use. For example, people may refer to 4010 instead of 004010. In addition to X12's transaction set standards, most major EDI users publish so-called "implementation guides" for their trading partners. X12 defined the transaction set standards so they could be used by a very broad range of users. This is commonly (and somewhat derisively) known as the "kitchen sink approach" since they include "everything but the kitchen sink." For this reason, for most transaction sets quite a few segments and data elements are used only by specialized communities of users. Only a small set of items is used by all users. The implementation guides specify the subset of segments and data elements of the transaction set standards that the issuer expects to be used for particular data exchange situations. Now that we have this basic terminology in hand we can discuss the utilities and what they do. |
