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:
An overview of the X12 protocol, including the structure of an X12 envelope, data elements, and syntax.
An explanation of how to use the generic message structures provided as an add-on to eGate and eXchange, to help you quickly create the structures you need for X12 message transactions.
An example of how X12 is used in payment processing.
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.
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).
In Java CAPS, message structures are defined as Object Type Definitions (OTDs). Each OTD consists of the following elements:
Physical Hierarchy – The predefined way in which envelopes, segments, and data elements are organized to describe a particular X12 EDI transaction.
Properties – The characteristics of a data element, such as the length of each element, default values, and indicators that specify attributes of a data part, for example, whether it is required, optional, or repeating.
Included with the ASC X12 PM product is the X12 OTD Library. See the X12 OTD Library User’s Guide for details.
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.
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–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, 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:
Functional ID code (the two-letter transaction code; for example, PO for an 850 Purchase Order, HS for a 270 Eligibility, Coverage, or Benefit Inquiry) to indicate the type of transaction in the Functional Group
Identification of sender and receiver
Control information (the Functional Group control numbers in the header and trailer segments must be identical)
Date and time
The GE segment contains:
Number of Transaction Sets included
Group control number (originated and maintained by the sender)
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:
Data element separators and data segment terminator
Identification of sender and receiver
Control information (used to verify message was correctly received)
Authorization and security information, if applicable
The sequence of information transmitted is:
Optional interchange-related control segments
Actual message information, grouped by transaction type into Functional Groups
The following list describes the ISA segments shown in Figure 2–5:
Authorization Information Qualifier
Security Information Qualifier
Interchange ID Qualifier
Interchange Sender ID
Interchange ID Qualifier
Interchange Receiver ID
Interchange Control Version Number
Interchange Control Number
Transaction Set header (designated ST)
Transaction Set trailer (designated SE)
Single message, enveloped within the header and footer
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.
Elements are separated by delimiters. The remainder of this section explains these elements.
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:
Simple – If a data element occurs in a segment outside the defined boundaries of a composite data structure, it is called a simple data element.
Composite – If a data element occurs as an ordinally positioned member of a composite data structure, it is called a composite data element. A telephone number is a simple example of a composite. It has a three-digit area code, which must precede the three-digit central office code, which must precede the final four digits.
Each data element has a unique reference number, and it also has a name, description, data type, and minimum and maximum length.
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:
The NM1 segment is for any name (patient, provider, organization, doctor)
The DTP segment is for any date (date of birth, discharge date, coverage period)
For more information on the X12 enveloping segments, refer to Structure of X12 Envelopes.
Transaction Set, for example 270 or 271
Loop, for example “info. receiver loop”
Occurrence of the loop
Segment, for example BGN
Field number, for example 01
Occurrence of the segment (if it is a repeating segment)
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:
+ (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).
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.
GS06: Functional Group
ST02: Transaction Set
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.
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.
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.
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.
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.
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.
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.
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:
Directly between TPs or through their respective EDI VAN mailboxes
Through the banking system, with the beneficiary’s bank sending notice of payment to the beneficiary
By the originator to the originator’s bank as an order to pay, with the originator’s bank notifying the beneficiary
The TPs and the capabilities of their respective banks determine:
Routing of the electronic check stub
Whether payment is of the type:
Debit authorized by the payor and originated by the beneficiary
Credit transfer originated by the payor
The following types of information can be exchanged electronically between bank and customer:
Daily reports of balances and transactions
Reports of lock-box and electronic funds transfer (EFT) remittances received by the bank
Authorizations issued to the bank to honor debit transfers
Monthly customer account analysis statements
Account reconcilement statements
Statements of the demand-deposit account
The electronic payment mechanism, which is a subset of EDI, involves the following separate activities:
Exchange of payment orders, causing value to transfer from one account to another
Exchange of related remittance information in standardized machine-processable formats
Credit transfer, initiated by the payor
Debit transfer, initiated by the payee as authorized by the payor
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:
Transfers actual monetary value
Transfers notification of payment from payor to payee
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:
Together through the banking system
Separately and by different routes
X12 Transaction Set 820 is a data format for transporting a payment order from the originator to its bank. This payment order can be:
Instructions to the originator’s bank to originate a credit transfer
Instructions to the TP to originate a debit transfer against the payor’s bank account
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.
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.
Payment advice from the receiving bank
Remittance information received through a separate channel
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:
Individual item approval
Blanket approval of all incoming debits with an upper dollar limit
Blanket approval for a particular TP to originate any debit
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.
X12 includes the following types of acknowledgments:
TA1 Interchange Acknowledgment
997 Functional 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.
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.
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.
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).
As you use this document, refer to the eXchange Integrator User’s Guide for information relating directly to eXchange operation.
Interchange and acknowledgment processing
Business message correlation
Enveloping and de-enveloping
Document batching and splitting
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:
Structural message validation
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.
View: The Enterprise Designer provides the ability to create X12 Projects, and the eXchange Message Tracking feature allows the searching and viewing of X12 messages.
Services Orchestration: You use the eXchange Partner Manager to design a Transaction Set. Then, the X12 Project prepares and returns the interchange and functional acknowledgments (TA1 and 997) to the TP, as well as performing message correlation to associate the business response with the appropriate request.
Integration Services: X12 Projects validate ISA and GS envelopes from incoming messages, prepare ISA and GS envelopes for outgoing messages, batch together documents to be delivered as a single transaction (ISA), and record the activities in Message Tracking.
The key parts of EDI processing logic are listed in Table 2–1.Table 2–1 Key Parts of EDI Processing
Format, segments, loops
OTD elements and fields
Data contents “edit” rules
Translation (also called mapping)
Reformatting or conversion
Collaborations, Java Collaboration Definitions (JCDs)
Header and trailer segments
Envelope for a written letter
Special “envelope” OTDs: FunctionalGroupEnv and InterchangeEnv
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.
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.
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).
In eGate, X12 translations are called Java Collaboration Definitions (JCDs).
X12 Standard: The Accredited Standards Committee publishes a standard structure for each X12 transaction.
Industry-specific Implementation Guides: Specific industries publish Implementation Guides customized for that industry. Normally, these guidelines are provided as recommendations only. However, for the sake of uniformity and compatibility, it is extremely important to follow these guidelines.
TP Agreements: It is normal for TPs to have individual agreements that supplement the standard guides. The specific processing of the transactions in each TP’s individual system can vary from one site to another. Because of this, additional documentation providing information about the differences is helpful to the site’s TPs and simplifies implementation. For example, although a certain code might be valid in an implementation guide, a specific TP might not use that code in transactions. In such a case, it could be important to include that information in a TP agreement.
The SEF OTD wizard does not handle the following information and sections:
In the .SEMREFS section, semantic rules with its type of the exit routine are ignored as per SEF specification. An exit routine specifies an external routine, such as a COM-enabled server program supporting OLE automation to run for translators or EDI data analyzers.
The .TEXT sections, for example, .TEXT,SETS, .TEXT,SEGS, .TEXT,COMS, and .TEXT,ELMS, are ignored, because these sections store information about changes in a standard’s text, such as notes, comments, names, purposes, descriptions, titles, semantic notes, explanations, and definitions.
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.
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.
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.
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.
Using eXchange to create a business solution consists of the following phases:
Design phase within Enterprise Designer
Configuration/design phase within ePM
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.
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:
B2B services via eXchange
Protocol managing, specifically by the PMs
Protocol formats contained in the OTD Libraries
Trading partner management facility, that is, the ePM interface
Archiving tool, the Message Tracking feature
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.