1. Purpose and Scope

The purpose of this standard is to define the control structures for the electronic interchange of one or more encoded business transactions including the EDI (electronic data interchange) encoded transactions of Accredited Standards Committee (ASC) X12. This standard provides the interchange envelope of a header and trailer for the electronic interchange through a data transmission, a structure to acknowledge the receipt and processing of this envelope, and optional, interchange-level service request structures.

These service request segments are treated as a logical extension of the basic interchange control header. An interchange delivery notice segment provides a method to report on interchange services requested and indicates status of delivery and retrieval of an interchange.

2. Referenced and Related Standards

This standard is used with the ASC X12 series of standards on electronic data interchange.

The following material is from The Internet Engineering Task Force (IETF®). The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.

The following verbatim text is from the cited document as noted immediately below.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

Key words for use in RFCs to Indicate Requirement Levels

3. Description of Use

There are six areas of the interchange which appear in the following order.

• Interchange control header

• Interchange service requests

• Interchange delivery notice

• Interchange acknowledgment

• Functional groups

• Interchange control trailer

The interchange control header and the interchange control trailer form the basic interchange. An interchange may contain additional control segments (e.g., service requests, delivery notices, and acknowledgments) and one or more functional groups.

3.1 Definitions and Concepts

The following definitions apply to this description of the interchange control structure. Italicized words indicate these terms are defined elsewhere in this section.

DELIVER: The action whereby the original interchange is made available to the interchange receiver. An interchange is considered "delivered" when it has been successfully conveyed to the mailbox, or, if a mailbox is not in use, to the interchange receiver.

INTERCHANGE RECEIVER: The interchange receiver is the entity that is the intended recipient of the interchange as specified by the interchange sender in the interchange header segment. The interchange receiver performs syntactical analysis of the interchange header, trailer, and acknowledgment segments and generates interchange acknowledgments to be returned to the interchange sender, if requested.

INTERCHANGE SENDER: The interchange sender is the entity that constructs the interchange header, interchange trailer, and interchange service requests.

INTERCHANGE SERVICE REQUEST: Segment used to specify additional services within the interchange.

MAILBOX: A mailbox is an entity capable of providing protected storage under the control of an interchange receiver for an interchange in transit between the interchange sender and interchange receiver.

RECEIVING SERVICE REQUEST HANDLER: The receiving service request handler is the entity that receives an interchange transferred by other service request handlers and delivers the interchange as specified by the interchange sender. The receiving service request handler also generates interchange delivery notices to be returned to the sending service request handler.

REFUSE: The action taken on an interchange delivered to a mailbox that cannot, or will not, be retrieved.

REJECT: The action taken on an interchange that cannot be delivered or transferred successfully.

RETRIEVE: The successful conveyance of an interchange from a mailbox to the interchange receiver.

SENDING SERVICE REQUEST HANDLER: The sending service request handler is the entity that acts upon interchange service requests as specified by the interchange sender, transferring the interchange to the intended service request handler of the interchange receiver. The sending service request handler also processes interchange delivery notices returned by other service request handlers.

SERVICE REQUEST HANDLER: A service request handler is an entity, intermediate to the interchange sender and interchange receiver, capable of acting upon one or more optional service requests or delivery notifications.

TRANSFER: The action whereby a sending service request handler sends an interchange to a receiving service request handler.

3.2 Basic Interchange Service

The basic interchange control structure is designed to satisfy the basic requirements for enveloping and routing electronic business data.

3.2.1 Basic Interchange Service Request

The Interchange Control Header (ISA) and Interchange Control Trailer (IEA) segments form the basic interchange service request. This is a basic delivery service request for one or more functional groups or interchange-related control segments, or a combination of functional groups and interchange-related control segments. The basic interchange service request performs the following functions.

• Defines the data element separator, component element separator, and segment terminator

• Identifies the sender and receiver

• Provides control information for the interchange

• Allows for authorization and security information

The basic interchange service is required for delivery of the interchange. The addressing information is located within the interchange header.

3.2.2 Basic Interchange Acknowledgment

An Interchange Acknowledgment segment (TA1) is used to report the receipt of the contents of one interchange control header and trailer envelope where that envelope surrounds one or more functional groups. This acknowledgment is transferred between the interchange receiver and sender as addressed in the interchange header. The TA1 reports the results of the syntactical analysis of the interchange control header and trailer. There is no acknowledgment for the TA1, thereby preventing an endless loop of acknowledgments. The flow of the original interchange and the corresponding acknowledgment are diagrammed in Figure 3.1 - Flow of Original Interchange and Corresponding Acknowledgment.

Figure 3.1 - Flow of Original Interchange and Corresponding Acknowledgment

The interchange control number value in TA1 is the same as for the ISA for which the acknowledgment was prepared. This control number serves as a link between the interchange header and the acknowledgment of that header.

The TA1 reports the status of the interchange envelope only. It is not used to report the status of the functional groups and transaction sets in the interchange.

The preparer of the interchange header and trailer indicates the level of acknowledgment requested in the acknowledgment requested data element. If the value in this data element position indicates no acknowledgment, the interchange receiver shall not return that acknowledgment. A TA1 control segment shall not be generated for an interchange that does not contain any transaction sets, thus preventing an endless loop of TA1 or TA3 acknowledgments.

3.3 Optional Interchange Service Requests

The basic interchange service capability provided by the ISA can be expanded by optional interchange service requests and responses.

The optional interchange service requests accompanying a basic interchange request (ISA) provide the interchange sender with a means to request ancillary services that may be provided by service requests handlers.

The optional interchange service request segment and the service functions they are designed to support are:

ISB - Grade of Service Request and

ISE - Deferred Delivery Request.

It is the responsibility of the interchange sender to know whether or not their service request handler (SRH) supports the service request.

When the SRH receives a service request from the interchange sender or sending SRH, the SRH will, by default, remove the service request. To override the default, the SRH must establish an agreement with the interchange receiver or receiving SRH to retain the service request.

Although the segments for these services are separate segments, they immediately follow the basic interchange header and must be treated as a logical extension to the ISA. This means that the service request handlers must examine the fully extended header to decide if there are any optional services to perform.

3.4 Interchange Syntax Extension (ISX)

An Interchange Syntax Extension segment is used by the interchange sender to indicate to the interchange receiver additional information required for the correct syntactic processing of the interchange. An Interchange Service Extension is optional and only used by mutual agreement between the interchange sender and interchange receiver.

3.5 Interchange Delivery Notice (TA3)

The Interchange Delivery Notice segment (TA3) is exchanged between service request handlers to inform the sending service request handlers of actions taken on the interchange by the receiving service request handler. The TA3 reports the delivery and the retrieval of the interchange. The TA3 also reports the unsuccessful delivery or retrieval of the interchange and identifies the error condition. Data extracted from the reported interchange for identification purposes and timestamps that identify the time an action has occurred are included. Other optional service request handler actions are also reported.

The flow of the original interchange and the corresponding TA3 segments are diagrammed in Figure 3.2 - Flow of Original Interchange and Corresponding Interchange Delivery Notice (event sequence illustrated as numbered).

Figure 3.2 - Flow of Original Interchange and Corresponding Interchange Delivery Notice (event sequence illustrated as numbered)

The use of TA3 is optional. Its usage should be based on mutual agreement. A TA3 control segment shall not be generated for an interchange that does not contain any transaction sets, thus preventing an endless loop of TA1 or TA3 acknowledgments.

TA3 segments are conveyed in an interchange addressed from the receiving service request handler to the sending service request handler.

3.6 Order of Control Segments

The interchange prepared by the interchange sender shall occur in the order as listed in Table 3.1 - Order of the Interchange Segments for Interchange Sender. (See explanations of field heading that follow figure 3.4.)

NOTE: In the diagram above, the functional group is not an interchange component of this standard but appears in this figure to establish positioning for the functional groups. Zero, one, or more than one interchange acknowledgments may appear in one interchange. Zero, one, or more than one functional groups may appear in one interchange. However, at least one interchange acknowledgment or functional group must appear in an interchange for an interchange sender.

The interchange prepared by the service request handler shall occur in the order as listed in Table 3.2 - Order of the Interchange Segments for Service Request Handler.

3.7 Date and Time in the Interchange Segments

3.7.1 Basic Interchange Service - Dates and Times

The dates and times used in the ISA and TA1 segments represent local date and time of the interchange sender.

3.7.2 Optional Interchange Service Requests - Dates and Times

For optional interchange service request segments, a relationship to universal time coordinate (UTC) is provided to allow calculation of the time and date independent of the location of the interchange sender and the service request handler. This is particularly important if the interchange sender and the service request handler do not have the same local time.

3.7.3 Interchange Delivery Notice - Dates and Times

For the TA3, the date and time used to identify an interchange is copied from the interchange header and therefore represent local date and time of the interchange sender. The dates and times used as action dates and times shall be UTC.

4. Syntax

4.1 Basic Structure

A data element corresponds to a data field in data processing terminology. It is the smallest named item in the standard.

A control segment has the same structure as a data segment; the distinction is in the usage. The data segment is used primarily to convey user information, while the control segment is used primarily to convey control information and to group data segments. A data segment corresponds to a record in data processing terminology. The data segment begins with a segment ID and contains related data elements.

Other definitions, such as data element types, may be found in X12.6 Application Control Structure.

4.2 Syntax Notation

The syntax is defined in Backus Naur Form (BNF), which is described below. Other syntax elements may be found in X12.6 Application Control Structure.

• Lower case words denote syntactic constructs which are enclosed in angle brackets. The underscore is included as a valid character, e.g.,

  <transaction_set>

• The defined construct is on the left side of a statement and is separated from the defining right side by the symbol "::=", e.g.,

  <one_construct>

  ::=

  <another_construct>

• Uppercase words are predefined labels, e.g.,

  TRM

• Lowercase words not enclosed in angle brackets denote a general class of items which are not further defined in this section of the standard, e.g.,

  data

• Brackets denote optional items, e.g.,

  [<one_construct>]

• When alternative definitions exist, they may be shown separated by a vertical bar "|", e.g.,

  <letter_or_digit>

  ::=

  <uppercase_letter> | lt;digit>

• Braces enclose an item which may appear zero or more times, e.g.,

  <unsigned_integer>

  ::=

  <digit> {<digit>}

4.3 Delimiter Specifications

The delimiters consist of three separators and a terminator. The delimiters are devised for inclusion within the data stream of the transfer. The delimiters are:

• <tr> segment terminator

• <gs> data element separator

• <us> component element separator

• <rs> repetition separator

The delimiters are assigned by the interchange sender. These characters are disjoint from those of the data elements; if a character is selected for the data element separator, the component element separator, the repetition separator or the segment terminator from those available for the data elements, that character is no longer available during this interchange for use in a data element. The instance of the terminator <tr> must be different from the instance of the data element separator <gs>, the component element separator <us> and the repetition separator <rs>. The data element separator, component element separator and repetition separator must not have the same character assignment.

4.4 Interchange Structure Syntax

The BNF for the syntax of this standard is listed below. Other syntax elements not defined here may be found in X12.6 Application Control Structure.

4.4.1 Basic Interchange Segments

The basic interchange segments consist of the ISA, the IEA, and the TA1 segments.

4.4.1.1 Interchange Control Header Segment (ISA)

4.4.1.2 Interchange Trailer Segment (IEA)

4.4.1.3 Interchange Acknowledgment Segment (TA1)

4.4.2 Interchange Service Request Segments

The interchange service request segments are the Grade of Service segment (ISB) and the Deferred Delivery Request (ISE) segments.

4.4.2.1 Grade of Service Request Segment (ISB)

4.4.2.2 Deferred Delivery Request Segment (ISE)

4.4.3 Interchange Delivery Notice

4.4.3.1 Interchange Delivery Notice Segment (TA3)

4.4.4 Interchange Syntax Extension (ISX)

5. Interchange Segment Specifications

5.1 Basic Interchange Segments

5.1.1 Segment Specifications

Specifications for the interchange segments are provided in the segment directory.

5.1.2 Interchange Control Header Segment (ISA)

Purpose:
To start and identify an interchange of zero or more functional groups and interchange-related control segments.

The actual values of the data element separator, component element separator, repetition separator, and segment terminator for this interchange are set by the interchange control header. For a particular interchange, the value at the fourth character position of the interchange control header is the data element separator, and the value of the last character position is the segment terminator. The extent of this particular usage of the data element separator, component element separator, and the segment terminator is from this header to, and including, the next interchange trailer. The interchange control number value in this header must match the value in the same data element in the IEA segment.

In order to provide sufficient discrimination for the acknowledgment process to operate reliably and to ensure that audit trails are unambiguous, the combination of interchange sender's qualifier and ID (ISA05, ISA06), interchange receiver's qualifier and ID (ISA07, ISA08) and the interchange control number value (ISA13) shall by themselves be unique within a reasonably extended time frame whose boundaries shall be defined by trading partner agreement. Because at some point it may be necessary to reuse a sequence of control numbers, the Interchange Date and Time may serve as an additional discriminant only to differentiate interchange identity over the longest possible time frame.

5.1.3 Interchange Control Trailer Segment (IEA)

Purpose:
To define the end of an interchange of zero or more functional groups and interchange-related control segments.

The interchange control number in this trailer must match the value in the same data element in the corresponding ISA segment.

5.1.4 Interchange Acknowledgment Segment (TA1)

Purpose:
To report the status of the processing of an interchange header and trailer by the addressed receiver or the non-delivery by a network provider.

5.2 Optional Interchange Segments

5.2.1 Grade of Service Request Segment (ISB)

Purpose:
To request a delivery priority for this interchange higher or lower than normally provided. The priority request is performed by each service request handler, using each handler's criteria for providing priority delivery service.

5.2.2 Deferred Delivery Request Segment (ISE)

Purpose:
To specify the earliest time when the interchange can be delivered.

The time and date in the ISE segment indicates the earliest time the interchange can be delivered to the interchange receiver.

5.2.3 Interchange Syntax Extension (ISX)

Purpose:
To allow the interchange sender to specify additional information required for the interchange receiver to perform syntax interpretation of the interchange. This segment allows specification of a release character, character encoding, and similar capabilities.

5.3 Interchange Delivery Notice Segment (TA3)

Purpose:
To provide a notice from the receiving service request handler to the sending service request handler that an interchange was delivered or not delivered to the interchange receiver's mailbox, or some other ancillary service was performed, and that the interchange receiver retrieved, refused, or purged the interchange; TA3 is exchanged only between service request handlers; use of the TA3 segment is optional.

6. Data Element Specifications

6.1 Data Element Definitions

Specifications for the data elements of this standard are provided in the Data Element Dictionary. Code Sources for code lists not maintained by ASC X12 appear in the Index to Code Sources at the end of the Data Element Dictionary. Reference to Code Source Identifiers follow Data Element descriptions or Data Element definitions.

Appendix A. Implementation Considerations

This Appendix covers implementation considerations regarding the character sets used in the interchange of the transaction sets with particular emphasis on the delimiters. The basic and extended character sets are defined in X12.6; reference should be made to that standard for a definition of those character sets. Portions of those definitions are repeated here as required for understanding. The BNF used below is defined in X12.6.

A.1 Basic Character Set

The selection that follows is designed to have representation in the common character code schemes of EBCDIC, ASCII, and CCITT International Alphabet 5. The ASC X12 standards are graphic-character-oriented; therefore, common character encoding schemes other than those specified herein may be used as long as a common mapping is available. Since the graphic characters have an implied mapping across character code schemes, those bit patterns are not provided here.

The basic character set of this standard includes those selected from the uppercase letters, digits, space, and special characters as specified below.

A.2 Extended Character Set

An extended character set may be used by negotiation between the two parties and includes the lowercase letters and other special characters as specified below.

It should be noted that

and

include several character codes which have multiple graphical representations for a specific bit pattern. The complete list appears in other standards such as CCITT S.5. Use of the USA graphics for these codes presents no problem unless data is exchanged with an international partner. Other problems, such as the translation of item descriptions from English to French, arise when exchanging data with an international partner, but minimizing the use of codes with multiple graphics eliminates one of the more obvious problems.

A.3 Control Characters

Two control character groups are specified which have only restricted usage. The common notation for these is also provided, together with the character coding in three common alphabets represented by their hexadecimal values. In the following table IA5 represents CCITT V.3 International Alphabet 5.

A.3.1 Terminal Control Set

The terminal control set includes characters used to control terminal display characteristics. These characters usually will not have an effect on a transmission system. These are presented by the syntactic entity of <term_control_char>.

Note: The equivalent representation for the EBCDIC “new line” character is the character pair "carriage return" "line feed" in ASCII or IA5. If mapped in this manner, the superfluous "line feed" is ignored, and the "carriage return" is treated as the delimiter. For historical reasons, many systems support this mapping for use as the <segment_terminator>.

A.3.2 Communication Control Set

The communication control set includes those that may have an effect on a transmission system. These are represented by the syntactic entity of <comm_control_char>.

A.4 Specification of Delimiters

The delimiters are defined within this standard. This section of this Appendix covers the recommended maximum range of the characters for the delimiters. A series of specific recommendations are provided in Section 5.

A.4.1 Terminator

A.4.2 Data Element Separator

A.4.3 Subelement Separator

A.4.4 Repetition Separator

A.4.5 Release Character

A.5 Recommendations for the Delimiters

Because of the potential conflicts with either the data elements or with special uses in transmission and device control, the following recommendations are provided for the delimiter character selection.

The following characters usually occur in data. They should not be used as delimiters:

The following characters often appear in data. Use as delimiter characters with caution.

The following characters sometimes appear in data. Use as delimiter characters with caution.

The following characters are used for terminal control. Use as delimiter characters with caution.

The following characters may disrupt communications. Use as delimiter characters with caution.

Delimiter characters must be chosen with care, after consideration of data content, limitations of the transmission protocol(s) used, and applicable industry conventions. In the absence of other guidelines, the following recommendations are offered:

A.6 Encoding Specification

X12 has always used a graphical character set and has been neutral toward the particular encoding used in the data stream of a transfer. However, the ability to specify the specific encoding early in the data stream raises some implementation considerations around being able to properly read the encoding. In the absence of mutual agreement between sender and receiver, if it is desired that the encoding be determined from reading the data stream it is recommended that the interchange up through and including the ISX segment be encoded in a character set compatible with US-ASCII.

Encoding schemes are used to preserve data in digital format for storage and transmission. Each encoding has an association with a defined set of characters and is the method of representing a string of characters with a string of bytes. X12 Encoding applies to the data stream beginning with the Functional Group to the end of the interchange.

Language specific encoding provides the ability to identify the set of characters contained in elements defined as text beyond the ISX. Element level encoding should be used with the language specific character sets and only applies to text elements. Segment identifiers, delimiters, and elements defined with code list values should remain in a character set compatible with US-ASCII.

Universal character sets defined with the Unicode Standard have the capability to represent the characters defined in most all encoding schemes and introduce a difference in how the encoding should be applied to the X12 data stream. Package level encoding should be used with Unicode encoding schemes such as UTF-8, UTF-16, and UTF-32. Encoding schemes defined in the Unicode Standard represent each character as a binary number in 8, 16, or 32 bits. A Unicode encoding would be applied to all characters following the ISX segment.