test

Sun B2B Suite ASC X12 Protocol Manager User's Guide

About the X12 Protocol

This section provides the following information:

Introduction to X12

The X12 protocol is an electronic data interchange (EDI) standard, developed for the electronic exchange of machine-readable information between businesses.

Development of the X12 protocol was chartered by the American National Standards Institute (ANSI) in 1979 to develop uniform standards for the interindustry electronic interchange of business transactions, that is, electronic data interchange (EDI). The result was the X12 standard.

An organization called the X12 body develops, maintains, interprets, and promotes the proper use of the X12 standard. Data Interchange Standards Association (DISA) publishes the X12 standard.

The X12 body comes together three times a year to develop and maintain EDI standards. Its main objective is to develop standards to facilitate electronic messaging interchanges relating to business transactions, such as order placement and processing, shipping and receiving information, invoicing, and payment information.

X12 was originally intended to handle large batches of transactions. However, it has been extended to encompass real-time processing (transactions sent individually as they are ready to send instead of being held for batching).

X12 Message Structure

X12 messages have a message structure that indicates how data elements are organized and related to each other for a particular electronic EDI transaction.

Java CAPS Object Type Definitions

In Java CAPS, message structures are defined as Object Type Definitions (OTDs). Each OTD consists of the following elements:

X12 OTD Usage

The Transaction Set structure of an invoice sent from one trading partner (TP) to another defines the header, trailer, segments, and data elements required by invoice transactions. The X12 OTD for a specific version includes Transaction Set structures for each of the transactions available in that version. You can use these structures as provided, or customize them to suit your business needs.

eXchange uses OTDs based on X12 message structures to verify that the data in the messages coming in or going out is in the correct format. There is a message structure for each X12 transaction. The list of transactions provided is different for each version of X12.

Structure of X12 Envelopes

The rules for X12 envelope structure ensure the integrity of the data and the efficiency of the information exchange. The actual X12 message structure has primary levels that are hierarchical. From highest to the lowest, they are:

A schematic structure of X12 envelopes is shown in Figure 2–1. Each of these levels is explained in more detail in the remainder of this section.

Figure 2–1 X12 Envelope Schematic Diagram

Envelope Schematic Diagram

Figure 2–2 X12 997 (Functional Acknowledgment) Segment Table

X12 997 (Functional Acknowledgment) Segment Table

Figure 2–2 shows the standard segment table for an X12 997 (Functional Acknowledgment) as it appears in the X12 standard and in most industry-specific implementation guides.

Functional Groups (GS/GE)

Functional Groups, often referred to as the “inner envelope,” are made up of one or more Transaction Sets, all of the same type, which can be batched together into one transmission. The Functional Group is defined by the header and trailer segments.

The Functional Group Header (designated GS) segment appears at the beginning, and the Functional Group Trailer (designated GE) segment appears at the end. Many Transaction Sets can be included in the Functional Group, but all local transactions must be of the same type.

Within the Functional Group, each Transaction Set is assigned a functional identifier code, which is the first data element of the header segment. The Transaction Sets that constitute a specific Functional Group are identified by this functional ID code.

The GS segment contains:

The GE segment contains:

See Figure 2–3 and Figure 2–4.

Figure 2–3 Example of a Functional Group Header (GS)

Example of a Functional Group Header (GS)

Figure 2–4 Example of a Functional Group Trailer (GE)

Example of a Functional Group Trailer (GE)

Interchange Envelopes (ISA/IEA)

The Interchange Envelope, often referred to as the “outer envelope,” is the wrapper for all the data to be sent in one transmission. It can contain multiple Functional Groups. This characteristic means that transactions of different types can be included in the Interchange Envelope, with each type of transaction stored in a separate Functional Group.

The Interchange Envelope is defined by the header and trailer; the Interchange Control Header (designated ISA) appears at the beginning, and the Interchange Control Trailer (designated IEA) appears at the end.

As well as enveloping one or more Functional Groups, the ISA and IEA segments include:

The sequence of information transmitted is:

See Figure 2–5 and Figure 2–6.

Figure 2–5 Example of an Interchange Header (ISA)

Example of an Interchange Header (ISA)

The following list describes the ISA segments shown in Figure 2–5:

  1. Authorization Information Qualifier

  2. Security Information Qualifier

  3. Interchange ID Qualifier

  4. Interchange Sender ID

  5. Interchange ID Qualifier

  6. Interchange Receiver ID

  7. Date

  8. Time

  9. Repetition Separator

  10. Interchange Control Version Number

  11. Interchange Control Number

  12. Acknowledgment Requested

  13. Usage Indicator

Figure 2–6 Example of an Interchange Trailer (IEA)

Example of an Interchange Trailer (IEA

Transaction Sets (ST/SE)

Each Transaction Set also known as a transaction contains:

A Transaction Set has a three-digit code, a text title, and a two-letter code, for example, 997, Functional Acknowledgment (FA).

The Transaction Set is composed of logically related pieces of information grouped into units called segments. For example, one segment used in the Transaction Set might convey the address: city, state, postal code, and other geographical information. A Transaction Set may contain multiple segments. For example, the address segment might be used repeatedly to convey multiple sets of address information.

The X12 standard defines the sequence of segments in the Transaction Set and also the sequence of elements within each segment. The relationship between segments and elements can be compared to the relationship between records and fields in a database environment. See Figure 2–7 and Figure 2–8.

Figure 2–7 Example of a Transaction Set Header (ST)

Example of a Transaction Set Header (ST)

Figure 2–8 Example of a Transaction Set Trailer (SE)

Example of a Transaction Set Trailer (SE)

Elements of X12 Envelopes

The X12 messages are all in ASCII text, with the single exception that the BIN segment is binary. Each X12 message is made up of a combination of the following elements:

Elements are separated by delimiters. The remainder of this section explains these elements.

Data

The data element is the smallest named unit of information in the X12 standard. Data elements can be broken down into types. The distinction between the types is strictly a matter of how they are used. The types are:

Each data element has a unique reference number, and it also has a name, description, data type, and minimum and maximum length.

Segments

A segment is a logical grouping of data elements. In X12, the same segment can be used for different purposes. This means that a field’s meaning can change based on the segment. For example:

For more information on the X12 enveloping segments, refer to Structure of X12 Envelopes.

Loops

Loops are sets of repeating ordered segments. In X12 you can locate elements by specifying:

Delimiters

In an X12 message, the various delimiters are part of the syntax, dividing up the different elements of a message. The delimiters used in a message are defined in the interchange control header, the outermost layer enveloping the message.

For this reason, there is flexibility in the delimiters that are used. No suggested delimiters are recommended as part of the X12 standards, but the industry-specific implementation guides do have recommended delimiters.

The default delimiters used by the X12 OTD Library are the same as those recommended by the industry-specific implementation guides. The default delimiters in the X12 OTD Library are:

Segment terminator

~ (tilde)

Data element separator

* (asterisk)

Subelement (component) separator

: (colon)

Repetition separator (version 4020 and later)

+ (plus sign)

Within eXchange, delimiters are specified at the enveloping level. The delimiters defined for an envelope apply to all transactions in the same business service (a predefined dialog between the two parties).

Note –

It is important to note that errors could result if the transmitted data includes any of the characters that have been defined as delimiters. Specifically, the existence of asterisks within transmitted application data is a known issue in X12 and can cause problems with translation.

See Element Separator for information on the ePM delimiter parameter.

Control Numbers

The X12 standard includes a control number for each enveloping layer, as follows:

The control numbers act as identifiers. These numbers are used for message identification and tracking. eXchange includes a flag for each control number. This feature allows you to choose not to assign control numbers to outgoing messages and not to store control numbers on incoming messages.

The remainder of this section provides a brief explanation of each of these control numbers’ usage.

ISA13 (Interchange)

The ISA13 control number is assigned by the message sender. It must be unique for each interchange. This is the primary means used by eXchange Integrator to identify an individual interchange.

GS06 (Functional Group)

The GS06 control number is assigned by the sender. It must be unique within the Functional Group assigned by the originator for a Transaction Set.

eXchange ensures that the Functional Group control number GS06 in the header must be identical to the same data element in the associated Functional Group trailer, GE02.

ST02 (Transaction Set)

The ST02 control number is assigned by the sender and is stored in the Transaction Set header. It must be unique within the Functional Group.

eXchange ensures that the control number in ST02 is identical with the SE02 element in the Transaction Set trailer and is unique within a Functional Group (GS-GE). Once you have defined a value for ST02, eXchange always uses that same value for SE02.

Backward Compatibility

Each version of X12 is slightly different. Each new version has some new transactions. In addition, existing transactions can change from version to version.

New versions of X12 are usually backward-compatible. However, this compatibility is not a requirement of the X12 rules. You cannot assume that different versions of X12 are always completely backward-compatible.

You can expect that when you analyze the differences, only a few minor changes are required in the message structures. Therefore, it is recommended that, when you are using a new version or messaging between different versions, you make sure to be thoroughly familiar with any possible compatibility issues.

Note –

In this context, “backward compatibility” means that software that parses one version can, in some circumstances, be unable to parse the next version, even if the software ignores any unexpected new segments, data elements at the end of segments, and sub-elements at the end of composite data elements. No backward compatibility means that required segments can disappear entirely, data elements can change format and usage, and required data elements can become optional.

Example of EDI Usage

This section provides, as an example, an overview of the normal processes involved in EDI payment processing, that is, how electronic payments processing is used. Not everything in this example applies to the use of X12 in all possible payments processing scenarios.

Overview of EDI Payments Processing

EDI payments processing encompasses both collection and disbursement transactions. The exchange of funds is accomplished by means of credit and debit transfers. Transfers can also include a related bank balances, as well as transactions and account-analysis reporting mechanisms.

Most nonmonetary EDI TP communications are handled either directly between the parties or indirectly through their respective value-added networks (VANs). However, the exchange of funds requires a financial intermediary. This “third party” is normally the bank or banks that hold deposit accounts of the two parties.

The EDI operations involve the exchange of remittance information along with the order to pay. The remittance information, which acts as an electronic check stub, can be sent in any of the following ways:

The TPs and the capabilities of their respective banks determine:

Types of Information Exchanged Electronically

The following types of information can be exchanged electronically between bank and customer:

The electronic payment mechanism, which is a subset of EDI, involves the following separate activities:

Types of Electronic Payment

An electronic payment can be either:

Regardless of how a credit transfer was initiated, the payor sends a payment order to its bank in the form of an X12 Payment Order/Remittance Advice (Transaction Set 820).

The bank then adds data in a format required by the United States by the National Automated Clearing House Association (NACHA) and originates the payment through the Automated Clearing House (ACH) system. A corporate-to-corporate payment then performs the following functions:

When a credit transfer occurs, these two functions are sometimes treated as one, and sometimes treated separately. These functions can travel in either of the following ways:

X12 Transaction Set 820 is a data format for transporting a payment order from the originator to its bank. This payment order can be:

Once this decision has been made, Transaction Set 820 transports the remittance information to the beneficiary. The transfer can either be through the banking system or by a designated route separate from the transport of funds.

Note –

Whenever the Transaction Set 820 remittance information is not transferred with the funds, it can be transmitted directly from the originator to the beneficiary. It can also be transmitted through an intermediary, such as a VAN.

Transfer of Funds

Before funds can be applied against an open accounts-receivable account, the beneficiary must reconcile the following data streams:

These data streams were separated during the transfer operation.

If this reconciliation does not take place, and if the amount of funds received differs from the amount indicated in the remittance advice, the beneficiary might have problems balancing the accounts-receivable ledger.

The value transfer begins when the originator issues a payment order to the originator’s bank. If a credit transfer is specified, the originator’s bank charges the originator’s bank account and pays the amount to the beneficiary’s bank for credit to the beneficiary’s account.

If the payment order specifies a debit transfer, the originator is the beneficiary. In this case, the beneficiary’s bank originates the value transfer, and the payor’s account is debited (charged) for a set amount, which is credited to the originator’s (beneficiary’s) bank account.

The payor must issue approval to its bank to honor the debit transfer, either before the beneficiary presents the debit transfer or at the same time. This debit authorization or approval can take one or more of the following forms:

Payment-related EDI Transactions

X12 uses an end-to-end method to route the 820 Payment Order/Remittance Advice from the originator company through the banks to the beneficiary. Use of this method means there can be several relay points between the sender and the receiver.

The Transaction Set 820 is wrapped in an ACH banking transaction for the actual funds transfer between the banks.

Acknowledgment Types

X12 includes the following types of acknowledgments:

TA1, Interchange Acknowledgment

The TA1 Interchange Acknowledgment verifies the Interchange Envelopes only. The TA1 is a single segment and is unique in the sense that this single segment is transmitted without the GS/GE envelope structures. A TA1 acknowledgment can be included in an interchange with other Gs and transactions.

997, Functional Acknowledgment

The Transaction Set 997 Functional Acknowledgment includes much more information than the TA1 (see Figure 2–2). This Transaction Set was designed to allow TPs to establish a comprehensive control function as part of the business exchange process.

There is a one-to-one correspondence between Transaction Set 997 and a Functional Group. Segments within this Transaction Set identify whether the Functional Group was accepted or rejected. Data elements that are incorrect can also be identified.

Many EDI implementations have incorporated the acknowledgment process into all of their electronic communications. Typically, Transaction Set 997 is used as a functional acknowledgment to a Functional Group that was transmitted previously.

Note –

Transaction Set 997 is the acknowledgment transaction recommended by X12.

The acknowledgment of the receipt of a payment order is an important issue. Most corporate originators want to receive at least a Functional Acknowledgment (Transaction Set 997) from the beneficiary of the payment. Transaction Set 997 is created using the data about the identity and address of the originator found in the ISA and/or GS segments.

Application Acknowledgments

Application acknowledgments are responses sent from the destination system back to the originating system, acknowledging that the transaction has been successfully or unsuccessfully completed.

The application advice (Transaction Set 824) is a generic application acknowledgment that can be used in response to any X12 transaction. However, it has to be set up as a response transaction; only TA1 and Transaction Set 997 transactions are sent out automatically.

Other types of responses from the destination system to the originating system, which can also be considered application acknowledgments, are responses to query transactions, for example, the Eligibility Response (Transaction Set 271) is a response to the Eligibility Inquiry (Transaction Set 270).