Abstract

This reference model describes the relationships and use of various X12 control structures and transaction sets used to acknowledge and track X12 interchanges. These include X12.5, Interchange Control Structures, X12.6, Application Control Structure, X12.56, Interconnect Mailbag Structures, X12.274, Data Status Tracking Transaction Set 242, X12.44, Application Advice Transaction Set 824, X12.20, Functional Acknowledgment Transaction Set 997, and X12.9 Purchase Order Acknowledgment Transaction Set 855.

1. Preface

1.1 General

This document is a Type II Technical Report, commonly referred to as a reference model. It was developed by X12C!TG1, the Communications Task Group of ASC X12 Communications & Controls Subcommittee.

1.2 Purpose and Scope

ASC X12 has defined and approved several control structures and transaction set standards intended to augment EDI auditing and control systems. It is the intent of these standards to provide a tracking mechanism for EDI data as it moves through the transmission cycle.

Through the implementation of these tracking tools, and analysis of the resulting information, delays or failures in delivery can be identified and corrected. This is especially true in a multi-VAN (value-added network) environment.

The purpose of this document is to summarize the use of the ASC X12 control structures and standards for the acknowledgment and tracking of EDI interchanges. This document reviews long-standing control structures and practices, such as the interchange header standards and the Functional Acknowledgment Transaction Set (997), and more recent standards, such as X12.56, Interconnect Mailbag Structures, and the TA3 Segment.

Implementation of these control structures and transaction sets is optional. Some of these standards are heavily used in EDI environments today, while use of other standards is less common. This document reviews the intended integration of these standards that results in a detailed audit trail of the data migration from the interchange sender to the interchange receiver.

1.3 Version and Release

This reference model is not based on or dependent on any particular version of the ASC X12 Standards referenced; information is useful for applications regardless of which version/release of the standards is being used.

1.4 Referenced and Related Standards

ASC X12 transaction sets and other standards referenced in this document include:

These standards are available from the X12 Store: http://store.x12.org.

Suggestions for improvement of this guideline are welcome. They should be sent to: support@x12.org.

2. Introduction

2.1 Definition of Terms

New terms have been defined in ASC X12 to describe the EDI standards and models. As these terms are utilized by other organizations, they tend to take on multiple meanings. The following definitions, based on the X12 Standards documents listed here, are footnoted where a more detailed discussion of the definition exists in a standards document; refer to the appendix for each source.

Application Advice Transaction Set 824: Provides the ability to report the results of an applications system's data content edits of transaction sets.³

Application-specific Acknowledgment: A family of transaction sets that provides for the application level acknowledgment and reconciliation of business data. These transaction sets are generated by the interchange receiver in response to a sender's interchange.

Basic Interchange Acknowledgment Segment (TA1): This segment 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.¹

Cross-functional Transaction Set: A transaction set used to relate information about a preceding transaction set; designed to support transaction sets independent of functional grouping. An example is Application Advice Transaction Set 824.

Data Status Tracking (DST) Transaction Set 242: A management transaction set used to provide status information regarding interchange flow from an interchange sender to the interchange receiver. It is the vehicle by which the status information is conveyed by a service request handler to the interchange sender, interchange receiver, or both.³

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.¹ Note: It is important to recognize that, for the context of this document, deliver does NOT mean retrieved by the receiver, nor does it mean that an agent (such as a VAN) has acknowledged receipt of the data.

Functional Acknowledgment Transaction Set 997: Provides the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents.³

Interchange: The basic control structure designed to satisfy the basic requirements of enveloping and routing the included electronic business document.¹

Interchange Delivery Notice Segment (TA3): A service segment exchanged between service request handlers to inform the sending service request handler of actions taken on the interchange. The TA3 reports the delivery and retrieval of the interchange and also reports the unsuccessful delivery or retrieval of the interchange and identifies the error condition.¹

Interchange Receiver: The intended recipient of the interchange as specified by the interchange sender in the interchange header segment.¹

Interchange Sender: The entity that constructs the interchange header, interchange trailer, and interchange service requests.¹

Interconnect Entity: Any organization that communicates EDI data with another organization where neither communicating party is responsible for processing and acting upon the semantic data (business transactions which may be contained in the mailbag).²

Interconnect Mailbag Control Structure, X12.56 (Mailbag): Provides control structure and an audit mechanism to facilitate the exchange and receipt acknowledgment of EDI data between interconnecting entities. The original sender and the ultimate receiver of the data contained in the mailbag have no responsibility for creating, managing, or removing the interconnect mailbag segments. This standard is solely for use between sites acting as interconnect entities.²

Mailbox: 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. (1) A protected receiving location with a unique address such that, once an interchange is placed in the mailbox of the receiver, it may only be retrieved by the receiver.²

Receipt and Safe Storage: An interconnect mailbag is received and safely stored when: (a) the control numbers in the interconnect mailbag header and trailer match; (b) the control totals listed in the interconnect mailbag trailer are consistent with the number of interconnect mailbag acknowledgments and interchanges in the interconnect mailbag; and (c) the entire interconnect mailbag has been successfully stored such that its contents can be obtained, for processing, delivery, or both, in their entirety at some later time.²

Refuse: The action taken on an interchange that has been delivered to a mailbox and can not, or will not, be retrieved.

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

Service Provider: Any process or set of processes that accept an interchange from a sender and convey it to a mailbox that represents the addressed receiver. Direct connections between senders and receivers involve no service providers.²

Service Request Handler: An entity, intermediate to the interchange sender and interchange receiver, capable of acting upon one or more optional service requests or delivery notifications.¹

Syntactical Validity: The determination of an interchange's compliance with EDI standards.

Transmission Life Cycle of an EDI Document: The processes through which an EDI document passes as it is transferred from the interchange sender, through interconnect entities, to the interchange receiver. Note: For the purpose of this paper, the reader may consider a value-added network (VAN), a service provider, an interconnect entity, and a service request handler (SRH) as synonymous. There are two basic categories of SRHs:

• The interchange sender's SRH provides services at the request of the interchange sender.
• The interchange receiver's SRH provides services at the request of the interchange receiver.

3. Data Flow Model

This document describes three data flow models to illustrate the uses of control structures in various EDI transmission life cycles. The first model depicts the exchange of EDI data in a point-to-point environment where the interchange sender and interchange receiver communicate directly. The second model depicts the exchange of EDI data through a common value-added network (VAN). The third model depicts the exchange of EDI data through multiple VANs.

These models depict specific examples of the EDI transmission life cycle. Many other combinations are possible, some requiring fewer exchanges of data, some requiring more exchanges of data. These models are pictorial representations of the X12 control mechanisms and, as such, ignore the concepts of interchange bundling and data accumulation for processing effectiveness. While important, they are outside the scope of this document.

3.1 Data Flow Model: Point-to-point

Figure 1 outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a point-to-point configuration where the interchange is created and transmitted by the interchange sender directly to the interchange receiver.

It should be noted that the use of the control audit structures described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the X12 Standards and have agreed upon the operational environment.

Figure 1.

Action 1: The interchange is created and transmitted by the interchange sender to the interchange receiver.

Action 2: The interchange receiver reports the receipt and syntactical validity of the sender's interchange envelope by generating a TA1 Segment enveloped in an ISA/IEA enveloping structure addressed to the sender. This interchange is then transmitted by the interchange receiver to the interchange sender. The TA1 is the first end-to-end acknowledgment of receipt of the sender's interchange. The interchange sender processes and reconciles the TA1 with the sender's internal auditing systems.

Action 3: The interchange receiver reports the syntactical validity and translatability of the sender's interchange by generating one or more Functional Acknowledgment Transaction Sets 997 enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted by the interchange receiver to the interchange sender.

The interchange sender processes and reconciles the Functional Acknowledgment Transaction Set 997 with the sender's internal auditing systems. Through the processing of the functional acknowledgments, the interchange sender ascertains the status of the data within the receiver's EDI system.

Action 4: The receiver delivers the translated business data to the appropriate processing application. Depending on applications and available standards, the receiver returns a cross-functional transaction set (such as the Application Advice Transaction Set 824), or an application-specific acknowledgment (such as the Purchase Order Acknowledgment Transaction Set 855). This transaction set is then enveloped in an interchange and transmitted by the interchange receiver to the interchange sender.

The interchange sender processes and reconciles the Application Advice Transaction Set 824 or an application-specific acknowledgment with the sender's internal auditing systems. Through the processing of these transaction sets, the interchange sender ascertains the status of the business data in the receiver's application system.

3.2 Data Flow Model: Single Value-added Network (VAN)

Figure 2 outlines the control and audit structures utilized throughout the transmission life cycle of an interchange. This figure represents a single VAN configuration where the interchange is created by the interchange sender, flows through a service request handler (SRH), and ultimately is retrieved and processed by the interchange receiver.

It should be noted that the use of the control audit structures described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the X12 Standards and have agreed upon the operational environment.

*Interchange Acknowledgement, Functional Acknowledgement, and Application Acknowledgement
are transmitted by the Interchange Receiver through the SRH and ultimately to the Interchange
Sender. Representation outside of SRH in this model is for clarity only.

Figure 2.

Action 1: The interchange is created and transmitted by the interchange sender to the SRH.

Action 2: A Data Status Tracking (DST) Transaction Set 242 may be returned to indicate the success or failure of the receipt and safe storage of the sender's interchange or transmission by the SRH. This is the initial opportunity for the SRH to provide feedback on a specific interchange or document. The interchange sender processes and reconciles the DST Transaction Set with the sender's internal auditing systems.

The SRH may provide subsequent DST Transaction Sets based on a prior agreement with the sender. Some examples of potential trigger mechanisms include; timing triggers, status updates, and the expiration of anticipated reporting data.

Some of the potential reporting statuses include; delivered, retrieved, purged, and refused.

Action 3: The SRH processes the sender's data and safe stores the documents in the receiver's mailbox for retrieval.

Action 4: The interchange receiver retrieves the sender's interchange from the receiver's mailbox on the SRH.

Action 5: With no additional tracking information expected to be provided by the service request handler, the final DST Transaction Set can be provided to the interchange sender. The sender processes and reconciles the DST Transaction Set with the sender's internal auditing systems.

Action 6: The interchange receiver may also receive a DST Transaction Set from the SRH, providing tracking information from the SRH's initial receipt of the interchange through the retrieval by the receiver. The receiver processes and reconciles the DST with the receiver's internal auditing systems.

Action 7: The interchange receiver reports the receipt and syntactical validity of the sender's interchange envelope by generating a TA1 Segment enveloped in an ISA/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the SRH to the interchange sender. The TA1 is the first end-to-end acknowledgment of receipt of the sender's interchange. The interchange sender processes and reconciles the TA1 with the sender's internal auditing systems.

Action 8: The interchange receiver reports the syntactical validity and translatability of the sender's interchange by generating one or more functional acknowledgments enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the SRH to the interchange sender.

The interchange sender processes and reconciles the Functional Acknowledgment Transaction Set 997 with the sender's internal auditing systems. Through the processing of the Functional Acknowledgments, the interchange sender ascertains the status of the data within the receiver's EDI system.

Action 9: The receiver delivers the translated business data to the appropriate processing application. Depending on applications and available standards, the receiver returns a cross-functional transaction set (the Application Advice Transaction Set 824), or an application-specific acknowledgment (such as the Purchase Order Acknowledgment Transaction Set 855). This transaction set is then enveloped in an interchange and transmitted through the SRH to the interchange sender.

The interchange sender processes and reconciles the Application Advice Transaction Set 824 or the application-specific acknowledgment with the sender's internal auditing systems. Through the processing of these transaction sets, the interchange sender ascertains the status of the business data in the receiver's application system.

3.3 Data Flow Model: Multi-VAN

Figure 3 outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a multi-VAN configuration where the interchange is created by the interchange sender, flows through the sender's SRH to the receiver's SRH, and ultimately is retrieved and processed by the interchange receiver.

It should be noted that the use of the control audit structures described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the X12 Standards and have agreed upon the operational environment.

*Interchange Acknowledgement, Functional Acknowledgement, and Application Acknowledgement are
transmitted by the Interchange Receiver through the Receiver's SRH, the Sender's SRH, and ultimately
to the Interchange Sender. Representation outside of SRH in this model is for clarity only.

Figure 3.

Action 1: The interchange is created and transmitted by the interchange sender to the sender's service request handler (SRH).

Action 2: A Data Status Tracking (DST) Transaction Set 242 may be returned to indicate the success or failure of the receipt and safe storage of the sender's interchange or transmission by the sender's SRH. This is the initial opportunity for the SRH to provide feedback on a specific interchange or document. The interchange sender processes and reconciles the DST with the sender's internal auditing systems.

The sender and the sender's SRH may agree to use additional status reports. The X12 Standards are mute on the requesting mechanism. Some examples of potential trigger mechanisms include; timing triggers, status updates, and the expiration of anticipated reporting data. Some of the potential reporting statuses include; delivered, retrieved, purged, and refused.

Action 3: The sender's SRH processes the sender's data and safe stores the documents in a mailbox for forwarding.

Action 4: The sender's interchange is mailbagged by the sender's SRH in preparation for transmission to the receiver's SRH. The mailbag, with its contents of one or more interchanges and/or mailbag acknowledgments, is then transmitted to the receiver's SRH.

Action 5: The receiver's SRH provides for the receipt and safe storage of the mailbag and generates a mailbag acknowledgment. Within a mutually agreed-upon time frame, the receiver's SRH transmits the mailbag acknowledgment to the sender's SRH, which processes and reconciles the audit trails.

Action 6: The receiver's SRH processes the sender's data and safe stores the documents in the receiver's mailbox for retrieval. One or more TA3 Segments are generated, reporting the processing and delivery results. These results may be positive or negative with reason codes.

Action 7: Within a mutually agreed-upon time frame, the receiver's SRH transmits the TA3 Segments in an ISA/IEA enveloping structure to the sender's SRH. The sender's SRH will process and reconcile the audit trails with the new information.

Action 8: The interchange receiver retrieves the sender's interchange from the receiver's mailbox or the receiver's SRH. Once retrieved, the receiver's SRH generates a TA3 Segment, reporting the receipt results. If the receiver is unable to retrieve the sender's interchange, the receiver's SRH will generate a negative TA3 Segment with reason codes.

Action 9: Within a mutually agreed-upon time frame, the receiver's SRH transmits the TA3 Segment enveloped in an ISA/IEA enveloping structure to the sender's SRH. The sender's SRH will process and reconcile the audit trails with the new information.

Action 10: With the TA3 Segment acknowledging receipt or failure of receipt of the interchange by the receiver, no additional tracking information is expected to be exchanged between the service request handlers. Therefore, the final DST Transaction Set can be prepared by the sender's SRH and provided to the interchange sender. The sender processes and reconciles the DST Transaction Set with internal auditing systems.

Action 11: The interchange receiver may also receive a DST Transaction Set from the receiver's SRH, providing tracking information from the receiver's SRH's initial receipt of the interchange through the retrieval by the receiver. The receiver processes and reconciles the DST Transaction Set with the receiver's internal auditing systems.

Action 12: The interchange receiver reports the receipt and syntactical validity of the sender's interchange envelope by generating a TA1 Segment enveloped in an ISA/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the receiver's SRH to the sender's SRH and, finally, to the interchange sender. The TA1 Segment is the first end-to-end acknowledgment of receipt of the sender's interchange. The interchange sender processes and reconciles the TA1 Segment with the sender's internal auditing systems.

Action 13: The interchange receiver reports the syntactical validity and translatability of the sender's interchange by generating one or more Functional Acknowledgment Transaction Sets 997 enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the receiver's SRH to the sender's SRH and finally to the interchange sender.

The interchange sender processes and reconciles the Functional Acknowledgment Transaction Sets 997 with the sender's internal auditing systems. Through the processing of the Functional Acknowledgment Transaction Sets, the interchange sender ascertains the status of the data within the receiver's EDI system.

Action 14: The receiver delivers the translated business data to the appropriate processing application. Depending on applications and available standards, the receiver returns a cross-functional transaction set (such as the Application Advice Transaction Set 824), or an application-specific acknowledgment (such as the Purchase Order Acknowledgment Transaction Set 855). This transaction set is then enveloped in an interchange and transmitted through the receiver's SRH to the sender's SRH and finally to the interchange sender.

The interchange sender processes and reconciles the Application Advice Transaction Set 824 or the application-specific acknowledgment with the sender's internal auditing systems. Through the processing of these transaction sets, the interchange sender ascertains the status of the business data in the receiver's application system.

4. Entity/Process Interfaces

In order to accurately report the transition of data through multiple parties, a control and auditing system should include a control point at each entity or processing interface. This approach applies equally well for EDI data as it moves through its transmission life cycle.

The following table (Figure 4) provides a summary of the various entities and processes involved in the interchange's transmission life cycle, and the corresponding X12 control structures.

The first column in Figure 4 represents the different functions that occur during an interchange's transmission life cycle. For clarification, the action number associated with the multi-VAN model (Figure 3) has also been provided.

Each function may have one or more associated control structures. If a control structure exists for a given function, the corresponding action number associated with the multi-VAN model (Figure 3) is provided.

For example, the "Receipt and safe store of interchange from sender to sender's SRH" is depicted as action 1 in the multi-VAN model. The Data Status Tracking (DST) Transaction Set 242 reports this activity and is depicted as action 2 in the multi-VAN model. The remaining control structures are not generated as a result of this function.

Figure 4.

5. Necessary and Sufficient Utilization

As exemplified in the preceding models, full control implementation requires significant investment by all of the parties involved in the transmission life cycle of an EDI document. Application systems and business processes must be re-engineered, trading partner and value-added network (VAN) interfaces and expectations must be re-evaluated and adjusted. There is a significant ongoing cost associated with the maintenance of the control information—data transmissions, data storage and retention, larger and more complex reporting mechanisms.

In some implementations, EDI control structures are replaced with non-EDI control processes that are outside of the scope of this document (e.g., personal contact, e-mail, letters). These additional control processes may be adequate for specific EDI implementations.

However, there are also significant advantages to be realized by the implementation of the X12 control structures. With the ability to identify faulty systems, the reliability of data transmissions can be improved. With the new information, interchange senders, receivers, and VANs will be capable of better managing the EDI data, and therefore, their businesses.

5.1 A Necessary Implementation

A necessary implementation of these control and auditing standards using only EDI control structures would include the sender's interchange (containing the business data) and the receiver's application response (Application Advice Transaction Set 824 or an application-specific acknowledgment transaction set). By implementing these two structures, the sender can then ascertain if the EDI transaction cycle is complete.

When the sender has received the application response, the sender can interrogate the response to determine the precise status of the data. The receiver may have processed and accepted the data, rejected part or all of the data, or modified the data. Under all of these conditions, the transaction cycle is complete.

If the sender has not received the application response, the EDI transaction cycle has not been completed. The receiver has not received, processed, and provided a response to the business data. There may be many reasons for this situation, which is indicative of a failure or a delayed response.

5.2 A Sufficient Implementation

As shown in the example above, if there are no failures or delays in the transmission of and response for a sender's interchange, the necessary implementation is sufficient. However, if problems are encountered during the processing cycle, there is insufficient information to identify and rectify the failing system. Therefore, the necessary implementation outlined above does not provide for a sufficient implementation.

As demonstrated in the data flow model, each of the control elements provide a unique and necessary function in the auditing of the data life cycle. The Data Status Tracking Transaction Set 242, X12.56 Interconnect Mailbag Structures Standard, the TA3 and TA1 Segments, the Functional Acknowledgment Transaction Set 997 and the application-specific acknowledgment standards such as the Purchase Order Acknowledgment Transaction Set 855 have unique properties and structures that provide for the transmission, security, and auditability of an EDI interchange as it travels through the various communication entities. Failure to implement any one of the available standards will result in an insufficiency in the control and audibility of an EDI document's transmission cycle, especially in a multi-VAN environment.

5.3 Implementation in the Marketplace

The EDI marketplace will ultimately define the implementation balance for these control and auditing mechanisms. A full implementation may be the only adequate solution, or a hybrid of solutions providing contained cost and improved reliability may be sufficient. Over time, only the EDI marketplace will be able to define the appropriate utilization of the elements in the data flow models.

A. Appendix

A.1 Reference Sources Footnoted

Please see Section 2 Introduction for notations to the following X12 Standards:

¹X12.5 Interchange Control Structures

²X12.56 Interconnect Mailbag Control Structures

³Extracted from the Transaction Set Tables in the X12 Draft Standards for Trial Use; no specific version/release used.