EDI Integration in TIBCO BW

A Brief Overview of EDI

Electronic Data Interchange (EDI) has been around since the late sixties. It was not until the mid-eighties that EDI became widely accepted. Loosely defined, EDI is the computer-to-computer transmission of business data in a standard format, which replaces a traditional paper business document. Over the years, various standards organizations have developed the standards used today. While there are many specialized standards (e.g., FORD, GM, HIPAA), the ANSI X12, USC, and UN/EDIFACT standards are the most popular. ANSI X12 and USC are popular in North America and UN/EDIFACT is used primarily in the European and Asian communities. These standards specifications were developed well before the advent of self-describing data structures (e.g., XML) and are therefore very cryptic to read and understand to the human eye.

In general, an EDI transaction can be described as a variable length, delimited flat file with a very strict structure. That said, the structure does allow for dynamic forms through the use of loops and repeating segments (see below for details on loops and segments). Additionally, the standards also describe things such as character sets, formats, and code lists which further define and describe the business document. For instance, a data element for “Unit of Measure” (UOM) may only contain values from a code list which further defines the UOM codes (e.g., EAC=each, CRT=cartone, etc.) Because of the complexity of the EDI standards, early development of EDI solutions was limited to a narrow set of developers. However, over the years, many software solutions have evolved which simplify the implementation of EDI transactions. The EDIFEC SpecBuilder product TIBCO OEM’s as part of our EDI solution is a best-of-breed example of this type of solution.

The Parts of an EDI Transaction

Following is a description of the pieces and parts of an EDI transaction. The examples provided use an ANSI X12 Product Registration (140 – said “one forty”) as a reference.   All examples will be shown using SpecBuilder. The following screenshot, represents the high-level description of the Product Registration transaction set 140

Interchange Control Group

The interchange control group is comprised of the “ISA” and “IEA” segments. These segments provide a set of envelope information that describe critical information for a given business document transmission. The interchange control group guideline can be defined at a global level for a given trading partner and used across all transactions for that trading partner, or it can be defined differently for every EDI transaction.

The interchange control header, or ISA segment, provides critical information such as, interchange sender and receiver IDS, address information, date and time the data was generated for transmission, the interchange control number, the segment terminator, and the data element separator.

The interchange control trailer, or IEA segment, indicates the number of Function Groups enclosed and matches the interchange control number of the corresponding ISA segment.

Functional Group

A functional group is a collection of one or more transaction sets of the same type (in this case a V4010 140). A functional group begins with the GS and ends with the GE segment.

The functional group header, or GS segment, indicates which type of transaction sets is enclosed. All transactions within the functional group must be of the same time. In addition, the functional group header also identifies the specific version, release, sub-release, and industry identifier of the EDI standard being used.

The functional group trailer, or GE segment, indicates the number of transaction sets enclosed and matches the Group Control Number sent in the corresponding GS segment.

Like the interchange control group, the functional group can be defined at a global level for each trading partner for a given transaction, or it can be defined differently for each transaction.

Multiple function groups can be sent within the same transmission.

Transaction Sets

A transaction set is comprised of a collection of segments in a predefined sequence that conveys the business information of a specific transaction to the receiver. A transaction set is always enveloped by the ST and SE segments.

The transaction header, or ST segment, indicates which transaction set is being sent, via the Transaction Set Identifier Code (in this case, it would be “140”) and relays a control number for the transmission.

The SE segment provides the closure for each transaction and provides a check of the integrity of the transmission. It contains a count of the segments in the transmission (including the ST and SE segments) and is the match to the control number sent in the ST segment.

The remainder of the transaction set is comprised of the defined segments which convey the business information of the transaction.

Loops

The example above provides one example of the use of loops. Another common example of the use of loops is the specification of line items for a purchase order.

Segments

A data segment is a collection of related data elements. In the above example the N1 segment (Name segment) is used to contain the Entity Identifier Code, Name, Identification Code Qualifier, Identification Code, Entity Relationship Code, and Entity Identifier Code elements.

Each segment begins with a segment identifier and ends with a segment terminator (defined in the ISA control segment).

Data elements within a segment are separated by the element separator (also defined in the ISA Control segment). The last element in a segment ends with the segment terminator.

Data Elements

• Reference Number ID: the number which uniquely defines the data element within the ANSI ASC X12 context
• Name
• Standard Option: Mandatory, Optional, Conditional, Relational)
• User Option: (Used, Must Use, Not Used, Recommended, Not Recommended, Future, Dependednt)
• Minimum Length
• Maximum Length
• Description
• Type
• Identifier (ID): This is a data element that is defined in a code set. Only those values that have been approved by the administrator of the code set may be sent. Some of these code values are maintained by ASC X12, while others are maintained by other.
• Alpha/Numeric (AN): This is a data element for which any value may be sent. It is limited only by the minimum and maximum lengths given in the definition of the data element.
• Numeric (Nx): This is a data element that must be a numeric value. The total number of digits is defined in the minimum and maximum of the definition. The “x” indicates the number of digits to the right of the decimal in the numeric value. The decimal is implied and is never sent.
• Floating Decimal (R): This data element type is a special numeric type. The decimal must be included in the value which appears. If the decimal is not sent, it is assumed the decimal appears at the right of the value, i.e., a whole number.
• Date (DT): This data element type is specifically defined as a date. The format will be given in the definition.
• Time (TM): This data element type is specifically defined as time. The format will be given in the definition.