test

Sun B2B Suite ASC X12 Protocol Manager User's Guide

Chapter 2 Overview of ASC X12 PM

This chapter provides a general overview of X12 data structuring, as well as ASC X12 PM and its place in Java CAPS, including system descriptions, general operations, and basic features.

This chapter contains the following topics:

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).

ASC X12 Protocol Manager Overview

Because ASC X12 PM integrates with eGate, eInsight, eXchange, and the X12 OTD Library, the product enables you to design Java CAPS Projects that process and validate X12 messages.

Note –

As you use this document, refer to the eXchange Integrator User’s Guide for information relating directly to eXchange operation.

Basic Operation

ASC X12 PM handles the basic operations necessary for X12 messaging, such as:

ASC X12 PM and eXchange

eGate and eXchange enable you to build Java CAPS Projects that process standard B2B business communication and enveloping protocols, such as X12. ASC X12 PM works during message processing with eXchange to provide the following features:

ASC X12 PM and the X12 OTD Library

ASC X12 PM provides packaged Business Protocols with rules that process and validate X12 messages, which are called OTDs in Java CAPS. Java CAPS provides packaged X12 OTDs as part of the X12 OTD Library. You can also build your own OTDs using the SEF OTD wizard, which is supplied with eGate.

How ASC X12 PM Messaging Works

Total operation of ASC X12 PM happens in the following functional layers:

Key Parts of EDI Processing Logic

The key parts of EDI processing logic are listed in Table 2–1.

Table 2–1 Key Parts of EDI Processing

Term 

Description 

Language Analogy 

eGate Component 

Structure 

Format, segments, loops 

Syntax rules 

OTD elements and fields 

Validation 

Data contents “edit” rules 

Semantic rules 

Validation methods 

Translation (also called mapping) 

Reformatting or conversion 

Translation 

Collaborations, Java Collaboration Definitions (JCDs) 

Enveloping 

Header and trailer segments 

Envelope for a written letter 

Special “envelope” OTDs: FunctionalGroupEnv and InterchangeEnv 

Ack 

Acknowledgments 

Return receipt 

Specific acknowledgment elements in the OTD 

eGate uses the structures, validations, translations, enveloping, and acknowledgments, as explained in the remainder of this section, to support the X12 standard.

OTD Message Structures

The X12 OTD Library includes pre-built OTDs for all supported X12 versions. These OTDs can be viewed in the OTD Editor, but cannot be modified.

To customize the OTD structure , for example, to add a segment or loop , you must first generate a .sef file (typically using a third-party application). You then use the SEF OTD Wizard to generate the OTD.

Validations, Translations, Enveloping, and Acknowledgments

Within each X12 OTD are Java methods and Java bean nodes for handling validation. The marshal and unmarshal methods of the two envelope OTDs handle enveloping and de-enveloping.

Note –

For more information on these OTDs, see the X12 OTD Library User’s Guide.

No prebuilt translations are supplied with the X12 OTD Library. You build data translations with an eGate Enterprise Designer user interface called the Java Collaboration Editor (JCE).

Note –

In eGate, X12 translations are called Java Collaboration Definitions (JCDs).

Message Information Levels

The following levels of information guide the final format of a specific X12 transaction:

X12 Version Support

ASC X12 PM provides support for the X12 versions shown in .

Table 2–2 Supported X12 Versions

  • 4010

  • 4011

  • 4012

  • 4020

  • 4021

  • 4022

  • 4030

  • 4031

  • 4032

  • 4040

  • 4041

  • 4042

  • 4050

  • 4051

  • 4052

  • 4060

  • 4061

  • 5010

  • 5020

Using the SEF Wizard

You can use this product with custom SEF OTDs built with the SEF OTD wizard. The wizard supports the most current SEF versions.

The SEF OTD wizard does not handle the following information and sections:

About eXchange Integrator

eXchange Integrator provides an open Business Protocol framework to support standard EDI and B2B protocols, as well as packaging protocols. The eXchange product supports existing standard protocols, using an extensive set of prebuilt eInsight Business Processes (BPs). It also provides the tools and framework to create and adopt new protocols and to build custom BPs.

B2B modeling semantics are exposed so that eInsight Business Rules can be added and tailored to address the particular needs of providing eBusiness solutions. The tight integration with the rest of Java CAPS provides validation, logging, and reporting capabilities. Because each logical step within any Business Rule is accessible anywhere along the entire eInsight BP, the design tools provide complete end-to-end visibility.

Note –

For a complete explanation of eXchange and eInsight, as well as their operation, see the eXchange Integrator User’s Guide and eInsight Business Process Manager User’s Guide.

Understanding BPs

An eInsight BP is a collection of actions or operations that take place in your company, revolving around a specific business practice. These processes can involve a variety of participants and may include internal and external computer systems or employees.

In eXchange, you create a graphical representation of a business process called a BP model. When you are using the sample for a PM’s implementation scenario, the system uses the BPs necessary for scenario’s operation. The BPs specific to the sample scenario provided with the product have already been created for this scenario.

Trading Partner Overview

The architecture of eXchange centers around the concept of sending and receiving messages relative to one or more TPs. Each TP that you import or create and then configure corresponds to one of your business trading partners.

These TPs contain configurable transaction profiles for each individual TP relationship. You can configure TPs with Transaction Profiles and Schedules, within ePM, for use by run-time components.

Each Transaction Profile specifies which one or more BPs to use for the current transaction, where and how to receive inbound messages, how to configure and secure messages in their channels, and how and where to deliver outbound messages.

Process Overview

Using eXchange to create a business solution consists of the following phases:

eXchange Partner Manager

ePM is a feature of eXchange you can use as a tool that allows you to configure eXchange for use with any of your PMs. You must set specific parameter values within ePM to ensure the correct operation of your Projects, for each protocol. This guide explains how to use and configure ePM, to set parameters relevant to this guide’s PM.

For more information on how to use ePM, see the eXchange Integrator User’s Guide.

B2B Suite, eXchange, and Java CAPS

eXchange is one of the products that make up the B2B Suite within Java CAPS. The B2B Suite products, including eXchange, provide a Web-based TP configuration and management solution for automating and securely managing business partner relationships. The products also facilitate real-time interaction between the enterprise and its TPs, suppliers, and customers.

As a part of Java CAPS, the B2B Suite provides the following benefits and features:

The B2B Suite is tightly integrated with Java CAPS and runs as a group of components within the Java CAPS environment. Figure 2–9 illustrates how the B2B Suite, eXchange, and other Java CAPS components work together, including eInsight.

Figure 2–9 Relationship of the B2B Suite, eXchange, and Java CAPS

Relationship of the B2B Suite, eXchange, and Java CAPS