Electronic Data Interchange
Transaction Set (ASC/X12)

The Transaction Set describes how data is to be laid out in a document to support the intent of transmitting a single business transaction, such as a Purchase Order or Invoice.  It defines each business transaction in an organized and ordered set of data segments.  Its structure defined broadly so that it can serve as a template to be used across businesses and industries, but at the same time remain unique and unambiguous, and kept within the scope and purpose of that business transaction, so that when a company sends a document using a Purchase Order transaction set, there can be no question that the information received is a Purchase Order.  Likewise, no two transaction sets can support a single business transaction, that is, you can't use a Purchase Order transaction set to transmit an Invoice, or vice versa.  This unique property is reinforced by a unique number, the Transaction Set ID, that is assigned to each transaction set designed for a business transaction.  In ASC/X12, a Purchase Order is assigned an identifier of 850, and the Invoice is assigned 810.

The transaction set begins with the Transaction Set Header Control Segment (ST), and ends with the Transaction Set Trailer Control Segment (SE), and at least one data segment in between.  Normally more than one data segments in between comprehensively define the heart of the business transaction.  The transaction set ID, which identifies the business transaction, is recorded in the transaction set header, so that its purpose is immediately recognized.  Additionally, it holds the Control Number that uniquely identifies this single transaction from other transactions in the same document.  For example, say a document holds 3 Purchase Order transactions.  In order to keep each Purchase Order separate from the other, a unique control number is assigned to each.  By necessity, the transaction set trailer exists to mark the end of a transaction set in the document, and it must hold the same control number as the transaction set header that begun the transaction.  This way, the control number identifies the header and trailer that envelopes and naturally bounds the single business transaction that separates it from the rest of any other transactions that may exist in the document.

As previously mentioned, the data segments between the transaction set header and trailer contain the heart of the business transaction.  They are organized and grouped to provide the best purpose and function into how business data can be relayed.  A single data segment or a contiguous block of data segments, interrelated and visibly grouped can give a semantic meaning to some business entity.  Consider the data segment PER (Administrative Communications Contact), by itself it can describe a contact information of a company president or an administrator; include this data segment with data segments N1 (Party Identification), N3 (Party Location) and N4 (Geographic Location) then it describes either a ship-to address or a bill-to address of a company.

In some instances, multiple instances of the same data segment can occur.  If a single data segment can occur multiple times in the same ordinal position, it is defined to have a Usage count greater than zero, meaning it can be used multiple times in the same position and can be seen as a contiguous series of lines in the document.  All data segments have their usage count defined as either 1, or some finite number greater than one -- none are defined to have a usage count of zero.  For example, the data segment PER in a Purchase Order is 3, which means up to 3 contacts can be specified in the document.  For an unknown number of occurrence, the usage count is defined as ">1" (greater than one).  The data segment REF (Reference Information) is defined to have an infinite number of occurrence in the Purchase Order, which allows the trading partner the flexibility to include as many reference data in the Purchase Order document as possible.

Loops

Then there is the overwhelming occurrence of Loops in a transaction set.  A transaction set without a loop is rare, and most can have loops that range from simple to very complex, containing loops nested in loops.  In a nutshell, a Loop is a contiguous block of segments that, as a group, is defined to occur, or "loop", multiple times.  They can be defined anywhere in the transaction set.  The data segments of every loop instance occur in the same order that they have been defined.  The groups of segments that make up the loop are normally interrelated and represent an entity that occur repeatedly in a business, for example inventory items.  For these types of items, the number of times they can occur are not known from one trading partner to the next, and so the number of times they can occur is defined as ">1" (greater than one).  In a Purchase Order, there is a block of segments that carry address information that are defined to occur 200 times.  It is not known how businesses will put 200 addresses in a Purchase Order or even if that is even possible, but normally of the 200, one can use two addresses most common in Purchase Orders: the bill-to address, and the ship-to address.

Instances of a loop can occur inside another loop in a condition known as nesting.  A loop can be nested by another loop, which in turn can also be nested by another loop, and so on.  The loop that is nested is known as the inner or child loop, and the loop containing the nested loop is the outer or parent loop.  There is no limit as to how deep a loop can be nested, each nest being assigned a level number that increases as the nest deepens.  That is, the outermost segment group starts with a loop level of zero, and its child loop has a level of 1, whose child loop in turn has a level of 2, and so on.

The most common loops found in transaction sets are unbounded loops.  Like all loops, the data segment group in an unbounded loop can occur multiple times, but the start of each instance of the loop is indicated by the occurrence of the first data segment in the group.  The first data segment in the segment group that define a loop is called a Trigger Segment, and it MUST exist if an instance of the loop is to exist.  Each presence of this segment in the document "triggers" a new instance of the loop; without its presence, the instance of the loop does not exist even if all remaining data segments in the loop appear to exist, the loop is deemed absent.  Furthermore, the following additional properties of the trigger segment play an important role in an unbound loop:

• The data segment ID of the trigger segment is unique in the segment group.  This is important to maintain that a presence of the trigger segment indicates another instance of a loop.  If another data segment in the loop has the same identifier then it would be impossible to determine whether the presence of the data segment is the start of a new loop instance or just a presence of a data segment in the loop.  Furthermore, data segments of any and all loops nested by this loop cannot have the same identifier as this loop's trigger segment.  Simply put, no data segment, trigger or otherwise, in inner loops can have the same segment ID as the trigger segment of its outer loop.
• The data segment ID of the trigger segment is the identifier of the loop by default.  However, a different loop identifier can be assigned to the loop which may be different from the identifier of the trigger segment.
• The usage count of the trigger segment is always one (1).  This is also important to maintain that a presence of the trigger segment indicates another instance of a loop.  A loop instance always has to have the presence of the trigger segment even if it is the only data segment in the loop.  In this scenario, two data segments, one immediately following the other and having the same identifier means that there is two instance of the same loop.  If the usage count of the trigger segment was specified as 2 then it would be impossible to tell if the second segment was the second occurrence of the first data segment, or if the second segment marked another instance of a loop.
• The requirement designator of the trigger segment specifies the required presence of the loop as a whole, not just the trigger segment.  Normally, the requirement designator specifies the required presence of the data segment at the defined position in the transaction set, but for a trigger segment, it specifies the required presence of the loop in the transaction set.  Currently, only two designator are allowed: mandatory (M) or optional (O).  If the trigger segment has the requirement designator of "M" then the loop MUST exist at the defined position of the transaction set; otherwise a requirement designator of "O" means the loop does not have to exist.  Note that the requirement designator of a data segment in a loop other than the trigger segment applies to that data segment only.

All inner loops must end before the end of the segment its outer loop, or end on the same segment as its outer loop.  Specifically, an unbounded loop ends when 

• it encounters another loop, 
• encounters a data segment belonging to the parent loop, 
• encounters a new area, or 
• when it encounters the end of the transaction set.  

Bounded loops are similar to unbound loops except that they are "bound" within control segments LS (Loop Start) and LE (Loop End).  The loop begins with the data segment LS and ends with the data segment LE; both control segments must exist if one or the other exists.  This makes it possible for bounded loops to begin with a data segment whose identifier is not restricted to being unique.

The required presence of a loop is determined by the requirement designator specified in the trigger segment for an unbounded loop, or in the LS segment for a bounded loop.  In a bounded loop, the designator in the LS segment must be the same as the designator of the first data segment after the LS segment.  A loop that is specified as mandatory must exist at the defined position of the transaction set.  Furthermore, all data segments and loops with a mandatory specification must also be present; optional segments and loops are not required to be present.  A loop that is specified as optional is not required to exist at the defined position.  If the loop is not present, all child structures such as data segments in the loop's segment group, as well as all nested loops cannot be present.  However, if the optional loop is present, all child structures specified as mandatory must be present; that is, all mandatory data segments in the loop's segment group, as well as all mandatory loops must also be present.

The data segments may all be grouped into discrete blocks that subdivide the transaction set into functional tables (or areas).  The tables are labeled numerically with the first table starting with the number one.  Although, there is no limit as to how tables are configured, the typical transaction set is commonly broken up into three distinct tables: 1, 2, and 3, which are also referred to as the heading, detail and summary areas respectively.  These tables function as follows:

• The heading (table 1) provides general information about the entire transaction.
• The detail area (table 2) provides the individual line items involved in the business transaction.
• The summary (table 3) provides general summary information such as hash calculations, subtotals, or totals.

Each data segment in a transaction set is assigned a sequential position number that makes the occurrence of the data segment semantically meaningful at that assigned position.  It is also assigned a requirement designator to indicate its required presence at that position, as well as the number of times it can occur repeatedly at that same position.  The incremental progression of position numbers across tables can follow one of either of the following incremental schemes:

• Either it can continue to increment sequentially at the end of one area and into the beginning of the next area;
• Or, the position number can reset with the beginning of each area starting with the first position number. 

A transaction set can apply only one method of either numbering scheme -- not both.

The fundamental strength of the transaction set guideline lies in the principle under which it is constructed.  Businesses, industrial organizations, and government agencies contribute to its development under an open and democratic forum, headed by the Accredited Standards Committee (ASC) X12 standards body.  For these businesses and organizations, the motivations behind the contributions to the development of the transaction set is first and foremost to facilitate more efficient transactions to their operations, a necessity to compete and reduce cost.  The ongoing discussion and submission of ideas continue to refine the definition of the transaction set and continue to reinforce its purpose.