Electronic Data Interchange
The Message (UN/EDIFACT)

The Message defines an ordered set of data segments structured to support the intent of a single business transaction.  Each message is uniquely identified and created to uniquely, and unambiguously, support a business function, such as purchasing, invoicing, payment, etc.  No two messages supports a single business function.  

The message must begin with the Message Header Service Segment (UNH), and it must end with the Message Trailer Service Segment (UNH), and at least one data segment in between.  The header and trailer bounds the transaction set data in the document and separates it from other transaction sets and other data segments used to control the document.  Furthermore, both header and trailer are bound together by a common control number that is unique to each grouped message in the document.  Between the control header and trailer are the layers of data segments that form the heart of the business transaction.

The data segments can be grouped in contiguous blocks whereby data segments within the group are related to form a semantic business entity, such as a business contact, billing address, ship-to address, or inventory item.  These segment groups are the essential elements of the message; they are the artifacts upon which the purpose and function of the message is built upon to create that business intent.  Each instance of these segment groups is called a Loop , and depending on the context under which it is used, the segment group can loop at a maximum number of times -- or it may loop infinitely.  A loop may also contain another loop, in a state that is known as "nesting": the contained loop is "nested" by the containing loop; the subordinate or child loop is contained or "nested" by the parent loop.  Furthermore, the nested loop can itself nest another loop which can nest another, and so on -- there is no limit as to how deep a loop can be nested.  The presence a loop in a document is indicated by the first data segment of the segment group.  Also referred to as the Trigger Segment, the properties of the first data segment represents the properties of the entire group as a whole.  Such as:

• The occurrence of the trigger segment triggers another presence of the entire segment group, and, without it, a loop cannot exists -- the entire segment group is deemed absent;
• The requirement designator of the trigger segment indicates the required presence of the entire segment group, either mandatory or optional.  If the trigger segment is mandatory then the presence of a loop instance is mandatory at the assigned position; otherwise, if optional, the presence of a loop is not required.  If a loop of an optional segment group exists, then the presence of all mandatory data segments, as well as mandatory nested groups, are required.
• The segment identifier of the trigger segment is the identifier (or Tag) of the segment group as a whole.  A different loop identifier may be assigned to the segment group which may be different from the trigger segment identifier.

On a larger scope, the data segments may all be grouped into discrete blocks that subdivide the message 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 message 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 message.
• 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 message 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 position numbering scheme -- not both.