Technical Workshop Integration - EDI

What is EDI?
Electronic Data Interchange is the computer-to-computer exchange of routine business data between trading partners in standard data formats. This definition contains 3 key concepts about EDI: Computer-to-computer: EDI in its most efficient form flows directly out of a senders computer system directly into a receivers computer system without any human intervention; however, it is not always possible for EDI to flow in this most efficient manner. Routing business data: EDI is used for routine business documents like Purchase Orders and Invoices. It is not used for non-routine business documents like complicated contracts or information meant for humans to read and analyze. Standard data formats: A standard definition of the location and structure of the data is provided. Unstructured text is not EDI.

The diagram above illustrates how much slower the conventional paper process than the EDI process. Additionally, the conventional paper process includes substantially more human intervention to move business information from one company to another. The conventional process requires someone to handle a printed computer generated form and mail it. Then, the recipient re-keys the data back into another

Supportian Inc.

EDI - Introduction

Page 1 of 19

Technical Workshop Integration - EDI computer for their internal processing. (It is estimated that 80% of the data that is keyed into computers is output from other computers!) The EDI process is a computer transmitting the information directly to another computer, eliminating the paperwork and human intervention.

Benefits of EDI

Speed Data can move directly out of one computer system and into another with little to no delay. Accuracy Errors are reduced because data is not being re-keyed. Error rates from entering data are between .5 3%. On large volumes of transactions, the possibility for the introduction of errors is enormous. Simplicity EDI standards specify how data will be formatted and where it can be found. Security Much less likely to lose information transmitted through EDI than information sent via mail. EDI can be accessed only by authorized users, and then there are audit trails and archives of data. EDI data cannot be easily changed by unauthorized users. It is also not subject to viruses. These 4 benefits produce the following results: Faster buy-sell cycle time Faster cash flow Reduced order lead time Reduced inventories Ability to conduct just-in-time manufacturing Improved trading partner relationships

Supportian Inc.

EDI - Introduction

Page 2 of 19

Technical Workshop Integration - EDI

How does the EDI process work in the retail environment?

The retailer will initiate the process with an electronic transmission of an electronic Purchase Order (850). The supplier will receive the order, case it and print UCC-128 labels. Then, the order is packed and the UCC-128 labels are placed on the cartons. The cartons are then shipped to the retailer and the supplier electronically transmits an Advanced Ship Notice (856). After the shipment has been sent, the supplier transmits an electronic Invoice (810) for the goods. These electronic documents are sent in a standard Electronic Data Interchange (EDI) format.

What is X12, the Cross Industry Standard?

Supportian Inc.

EDI - Introduction

Page 3 of 19

Technical Workshop Integration - EDI X12 is the cross industry standard designed by the American National Standards Institute (ANSI) to support any business function in any industry. It provides a single standard with a single architecture, producing a common, uniform language for electronic communications; however, that creates a lot of extra baggage for any given business use. For example, the data that you need to buy an aircraft carrier is much different than the data that is needed to buy a shirt. X12 has to support this wide range of capabilities. X12 was designed primarily as the standard for EDI transactions in North America. In 1997, a global EDI standard emerged out of X12, called EDIFACT. Today, over 300 X12 transactions sets are used to handle most facets of business-to- business communications in many different industries including retail, government, transportation, and automotive. Common transactions include purchase orders, advanced ship notices, and invoices. X12 standards are developed, maintained and published by the Accredited Standards Committee (ASC).

What does an EDI message look like?

Supportian Inc.

EDI - Introduction

Page 4 of 19

Technical Workshop Integration - EDI

What is an Electronic Product Catalog and Bar Coding?

Electronic Product Catalogs

Electronic Product Catalogs are very similar to paper catalogs; however, they do not have to go through a slow, expensive printing process, which allows them to be updated frequently. These catalogs are used by buying organizations and are sometimes mandated for suppliers. Catalog service providers act as a central repository for multiple vendors catalogs. These repositories support customer-specific pricing and a broad range of product information. This enables buyers to access the catalog to request information from specific suppliers or search for specific product information. Usually, Electronic Product Catalogs can be populated several different ways including: EDI Transaction Set- 832 Spreadsheet Supportian Inc. EDI - Introduction Page 5 of 19

Technical Workshop Integration - EDI Proprietary web-based applications for direct entry and updating Bar Coding Many types of barcodes exist to identify products; however the following are the most commonly used: GTIN- A Global Trade Item Number (GTIN) is a 14-digit number that identifies your merchandise. The GTIN is quickly replacing the UPC. This number is an umbrella UCC identification number for other UCC numbers (UPC, EAN-13, and EAN-8) and can be achieved by padding the number with left justified zeros until reaching 14 total digits. In other words, if you have UPC numbers and need GTINs, add 2 zeros to the front of the UPC number. UPC- The Universal Product Code (UPC) is a standardized way for your Trading Partner to identify your products. The majority of Trading Partners require you, their suppliers, to have UPCs. The UPC is a 12 digit number, which is usually made up of a 6 digit block ID (UCC Manufacturers ID), 5-digits that identifies your product, and the last digit is a check digit. The check digit is a calculation based on the previous 11 digits. EAN- The European Article Number (EAN) is the European version of the consumer bar code. EPC- The Electronic Product Code (EPC) is the electronic bar code embedded into RFID chips.

Value Added Networks

What is a Value Added Network (VAN)?

Value Added Networks simplify the communication process by reducing the number of parties that you have to communicate with. VANs insert themselves between trading partners. They typically operate on a mailbox scenario where a company would send a transaction to a VAN and the VAN would then place the transaction in the mailbox of the receiver. The receiver would then contact the VAN and pick up any transactions it might have and then send anything it might need to send. It is very similar to email, but rather than being unstructured text, it

Supportian Inc.

EDI - Introduction

Page 6 of 19

Technical Workshop Integration - EDI is used for structured standardized data. ICC operates a Value Added Network that provides this mailboxing type of service and transmits the data using the Internet. EDI Management Software
What is EDI Management Software?

Also called EDI Translation Software Manages translation between Internal Application Data Formats and EDI Standard Formats Tracks and Controls the flow of EDI Transactions between Internal Applications and Trading Partners Automatically sends Acknowledgements FAs and reconciles the receipt of Functional

Allows users to input required information and it translates them into EDI standardized data Managed EDI (for suppliers)
What is Managed EDI for suppliers?

Manages all EDI Traffic for customers Equivalency of doing EDI to Fax or E-mail Little knowledge of EDI is needed Third Party acts as the face of the customer to their Trading Partner When done right, Trading Partners do not even know the Service Center is handling the transactions Helps Supplier Comply with EDI mandates

Supportian Inc.

EDI - Introduction

Page 7 of 19

Technical Workshop Integration - EDI

X12 Technical Tutorials - Overview

X12 is a U.S. standard and is primarily used in North America. The predominant international EDI standard is UN/EDIFACT. Accredited Standards Committee X12 of the American National Standards Institute (ANSI) is responsible for the X12 standard. For authoritative information on the standard, go to the source. Information on obtaining the standards may be obtained from the X12 Secretariat, the Data Interchange Standards Association.

Purpose of the Standards

The X12 standards provide structure for the electronic representation of business documents commonly exchanged between companies. Examples of such documents are Purchase Orders, Invoices, Shipment Notices, and Health Care Claims. Though some companies may use X12 formats internally between different applications or geographic locations, this usage is somewhat unusual. There are currently well over 300 documents defined in the standard. The original idea behind a national standard for EDI is that having just one format for exchanging data would make exchange simpler. EDI evolved from one-on-one proprietary formats to industry formats. When it started being used by companies operating in several different trading communities, it became apparent that a crossindustry national standard was needed. The dream of a single, common format did not quite come to fruition. See the Implementation Issues page of this tutorial.

What the Standards Provide

The X12 standards provide a means to encode business documents so that they may be interpreted by a computer application. The documents are organized as delimited data, meaning data is separated by "delimiter" characters rather than by fixed length fields and records. The standards provide means to organize this data into business documents called Transaction Sets, group these into groups of related documents called Functional Groups, and wrap these in an envelope called an Interchange. The X12 standard has many parts, but the essential portions are:

X12.5 - Defines the structure of the Interchange, i.e., the ISA and IEA segments in the outer envelope X12.6 - Defines the syntax for the standard. Defines data types, valid formats for a segment (a record), rules for organizing segments into Transaction Sets (documents), and grouping Transaction Sets into Functional Groups, or the GS/GE envelope. Data Element Dictionary - Provide definitions of individual fields, or data elements. Provides the lowest level of semantics, or meaning. Segment Dictionary - Provides definitions of records, or segments. Specifies the data elements which may occur in a segment. Provides the next level of semantics.

Supportian Inc.

EDI - Introduction

Page 8 of 19

Technical Workshop Integration - EDI

Transaction Set Tables - Provide the layouts of the individual business documents, specifying the particular segments which may occur in a Transaction Set. Provides the highest level of semantics.

The ASC X12 Committee and Versions of X12

The X12 committee meets three times a year to make further refinements to the standards. New documents, called Transaction Sets, may be developed. Minor enhancements to current Transaction Sets are also made to support the business needs of the members. This new development is incorporated into new releases of the standard. A major release is issued in December of each year, following the October X12 meeting. Subreleases are issued after the February and June meetings. New releases are intended to be backwardly compatible with old releases, i.e., software that can process an old version should be able to process a new version. However, this is not always the case. Due to the frequent changes in the standard, specialized software, called EDI Translators, have developed to perform conversion from X12 formats into the internal formats used by companies.

Transmission
The X12 standard in itself does not specify how the data should be transmitted between trading partners. Any computer-to-computer means will suffice, including magnetic tape. The most commonly used means is the use of a Value Added Network, or VAN. These VANs provide "mailbox" services, allowing a company to maintain only a single connection to the VAN with the VAN handling transmission to other companies (or their VANs), and collecting inbound transmissions. VANs may also provide services such as protocol conversion (I use Asynchronous Kermit and you use Bisynchronous 2780/3780), or character conversion (I use ASCII and you use EBCDIC).

X12 Technical Tutorial - Syntax and Control

1 Introduction and Overall Structure
The essence of X12 is defined in X12.5 and X12.6. These standards provide the syntax and control structures which allow data elements, segments, and transaction sets to be defined. For those with a background in computer science, the basic X12 grammar qualifies as a context free grammar. It is specified in X12.5 and X12.6 using BackusNaur Form (BNF) notation. The overall structure of X12 data is shown below.

Supportian Inc.

EDI - Introduction

Page 9 of 19

Technical Workshop Integration - EDI

2 Terminology and Basic Concepts

In this tutorial, only the basic concepts of the X12 syntax are addressed. The X12.58 security standards are relevant to X12.5 and X12.6 as discussed here, but are not included in the discussion.

2.1 Simple Data Element

Data elements are defined in the X12 Data Element Dictionary - X12.3. A data element is equivalent to a field in a data dictionary. Data elements have a name, a data element number, a brief description, a data type, and a minimum and maximum length. For elements which represent codes, either a list of valid codes is included or a reference is included to a source outside of the X12 standard.

Data Types
Data elements may have the following types:

N - Numeric with implied decimal point, signed. Example: N2 indicates a numeric with two decimal places. 12.34 becomes 1234. N0 indicates in integer. R - Decimal Number with explicit decimal point, signed. Example: 12.34 represented in R format is 12.34. Starting with 4010, exponential notation is also supported. ID - Identifier - A coded value, usually alphanumeric. EDI - Introduction Page 10 of 19

Supportian Inc.

Technical Workshop Integration - EDI

AN - String - alphanumeric. DT - Date - YYMMDD. As of 4010, CCYYMMDD is also supported. TM - Time - HHMM, with optional seconds and hundredths. B - Binary - Any sequence of 8 bit bytes.

2.2 Composite Data Structure

A composite data structure consists of two or more simple data elements separated by a delimiter character known as the component data element separator. The individual component data elements in the composite may be designated as either mandatory or optional.

2.3 Segment
Segments are defined in the X12 Segment Directory - X12.22. A segment is equivalent to a record type. A segment is composed of one or more data elements or composite data structures, which are equivalent to the fields in a record. Segments start with a two or three character segment tag which identifies the segment, equivalent to a record type field. Data elements are separated by a delimiter character known as an element separator, and end with a different delimiter character known as the segment terminator. Elements which are not assigned values in a particular instance of a segment are represented by consecutive delimiters, and such trailing delimiters are not transmitted. For example, if a segment XYX has five elements and in a particular transmission only the second has a value, it is represented as XYZ**123<CR>, where "*" is the element separator and <CR> is the segment terminator.

2.3.1 Elements
The elements in a segment may be assigned the following attributes:

Requirements - Mandatory, Optional, or Conditional If Conditional - Two or more elements together may have the following conditional attributes: o P - Paired or multiple. If any are used, all must be used o R - Required. At least one of those noted must be used o E - Exclusion. No more than one may be used o C - Conditional. If the first element is present, then the others must be present o L - List Conditional. If the first element is present, then at least one of the others must be present

Example: In the N1 Name segment, the first element, N1_01, data element number 98 (Entity Identifier Code), is mandatory. Elements three and four ( 66 Identification Code Qualifier and 67 Identification Code) have a Semantic Note indicating a Conditional Relationship of P0304. If one is present, then both must be present.

Supportian Inc.

EDI - Introduction

Page 11 of 19

Technical Workshop Integration - EDI

2.3.2 Semantic Notes

Segments may have Semantic Notes indicating the meaning to be applied to data elements, beyond just their name and description. For example: In the N9 Reference Number Segment, a Semantic Note indicates that the sixth element, 623 Time Code, indicates the time zone of the fifth element, 337 Time.

2.4 Transaction Set

A Transaction Set is a group of one or more data segments conveyed between trading partners. It usually represents a business document such as a Purchase Order, but any unit of information meaningful to both parties is sufficient. Transaction Sets are defined in the X12 standard with a number and name, a statement of purpose, a Functional Group ID, and a table listing the included segments, their position numbers, requirement designation, maximum usage, and loop repeat counts. Transaction Sets start with an ST Transaction Set Header segment and end with an SE Transaction Set Trailer segment. A specific segment may occur in several positions within a transaction set, representing different information in each different position. For example, an N3 segment in the previous example regarding the 837 Health Care Claim applies to the Subscriber's street address in the first NM1 loop, but would represent the provider's address in the 2310 NM1 loop. Transaction Sets are structured such that, in any given data stream containing a Transaction Set, a segment's position in the defined standard for the Transaction Set may be determined solely by the segment tag (except when LS/LE loops are used). In other words, the segments defined position in regard to the standard is determined by considering the segments that appeared before it in the data stream.

2.4.1 Segment Attributes

The Transaction Set definition includes attributes which apply to segments in a Transaction Set. These are:

Position Requirement - Mandatory or Optional (and in earlier version of X12, Floating) Maximum Occurrences - If more than 1, then the segment may be repeated at that position in the Transaction Set up through the maxim usage indicated.

2.4.2 Loops
A loop is a set of related segments in a Transaction Set. Segments are grouped together in this way to conveniently represent a block of related information. No formal Loops are defined, but several basic loop types, such as a Name/Address loop, appear with minor variations in many Transaction Sets. Different loops may be nested within each other, and loops may repeat up to the maximum loop occurrences specified within the Transaction Set. X12 defines two types of loop formats: Unbounded and Bounded.

2.4.2.1 Unbounded
An Unbounded loop starts with a specific segment, and all of the other segments in the loop may be considered children of that segment. The start segment may appear once and Supportian Inc. EDI - Introduction Page 12 of 19

Technical Workshop Integration - EDI only once in the loop, and each new occurrence of the starting segment starts a new loop. A loop has a requirement designation of optional or mandatory (corresponding to the requirement designator of the first segment in the loop), and a repeat count indicating the maximum number of times it may repeat. If any of the segments in the loop are used, the starting segment must be used even if the loop itself is optional. An example of an unbounded loop is the N1/N2/N3/N4 Name and Address loop. It starts with the N1 Name segment, and includes the N2 Additional Name, N3 Address, and N4 Geographic Location segments.

2.4.2.2 Bounded (LS/LE)

A bounded loop has the same characteristics as an unbounded loop, except it is bracketed by LS Start Loop and LE End Loop segments. Any of the segments in the loop may be the first in a specific instance of the loop, depending on requirement designation of the loop. Bounded loops are used to identify loops that otherwise would be indistinguishable from each other. If the loop does not appear in a particular transmission, the LS and LE segments should not appear. An example of a bounded loop appears in the 837 Health Care Claim ( Version 3040 in this example ). At Position 2110, we start an NM1 loop identifying the subscriber. Within this NM1 loop, we have several other NM1 loops identifying other entities related to this subscriber. Such as, at 2310 there is an NM1 loop describing the Health Care provider. This 2310 loop is bounded by an LS/LE structure. Without the LS/LE, it would appear that we are starting a new NM1 loop at 2110 for the Subscriber. This section of the 837 appears below:
NM1* subscriber info... ... LS*2310 NM1* Provider info ... ... LE*2310 ... NM1* Next subscriber loop

2.6 Functional Group

A Functional Group is a group of one or more related Transaction Sets sharing the same Functional Group ID. Functional Groups start with a GS Functional Group Header segment and end with a GE Functional Group Trailer segment. The details in the Functional Group GS/GE envelope are often used to route the group's transaction sets to the appropriate department or business application within a company.

2.7 Interchange
An Interchange is the lowest unit of data exchanged between trading partners. It consists of one or more Functional Groups enclosed in an envelope defined by an ISA Interchange Control Header segment and ending with an IEA Interchange Control Trailer segment. The details in the ISA segment are often used to route the Interchange between trading partners in an EDI Value Added Network, or VAN.

Supportian Inc.

EDI - Introduction

Page 13 of 19

Technical Workshop Integration - EDI

3 Envelope Details
Listed here are brief descriptions of the control segments for the interchange, group, and transaction set envelopes. For full explanation of these segments, their purposes, and their data elements, refer to X12.5 Interchange Control Structures, X12.6 Application Control Structure, X12.22 Segment Directory, and X12.3 Data Element Dictionary.

3.1 Interchange Envelope - ISA/IEA ISA - Interchange Control Header

The ISA is effectively fixed length, since all of the elements are fixed length. This results in the segment terminator always being in position 106. The element separator can be obtained from position 4, and the subelement separator from 105. These delimiters allow the remainder of the interchange to be parsed.

ISA01 - Authorization Information Qualifier ISA02 - Authorization Information ISA03 - Security Information Qualifier ISA04 - Security Information - This was originally used as a kind of a password. The receiver ID might be public information such as a DUNS number, but this field might contain a value which is not public information. It is however clear text, so the security provided is not at a very high level. ISA05 - Interchange ID Qualifier ISA06 - Interchange Sender ID - Identifies the sender. ISA07 - Interchange ID Qualifier ISA08 - Interchange Receiver ID - Identifies the receiver. ISA09 - Interchange Date - YYMMDD ISA10 - Interchange Time - HHMM ISA11 - Interchange Control Standards Identifier ISA12 - Interchange Control Version Number - Indicates the version of the ISA/IEA envelope ISA13 - Interchange Control Number - Uniquely identifies an interchange for tracking by trading partners and VANS, and can be used to detect duplicate, missing, or out of sequence transmissions. May take any numeric value, but is usually incremented by one for each interchange sent to the same trading partner. ISA14 - Acknowledgment Requested - Indicates a request for a TA3 Interchange Acknowledgment to be sent. ISA15 - Test Indicator - Test or Production ISA16 - Subelement Separator

IEA - Interchange Control Trailer

IEA01 - Number of Included Functional Groups - This is used for message integrity, developed before such things as check sums were widely implemented. IEA02 - Interchange Control Number - Must match the control number in the IEA.

Supportian Inc.

EDI - Introduction

Page 14 of 19

Technical Workshop Integration - EDI

3.2 Group Envelope - GS/GE

The Group Envelope, as noted above, may be used for internal routing. The X12 Version/Release is specified in the GS, so all of the Transaction Sets in the group must be of the same version/release.

GS - Functional Group Header

GS01 - Functional Group Header Code - Same as the Group Type of the included Transaction Sets. GS02 - Application Sender's Code GS03 - Application Receiver's Code GS04 - Date - YYMMDD, or CCYYMMDD as of 4010. GS05 - Time - HHMM GS06 - Group Control Number - Like the ISA control number, is used for audit and to detect duplicates, missing, or out of sequence groups. Most importantly, the 997 Functional Acknowledgment, which acts as a return receipt for the group, references the group control number. May take any numeric value so long as there are no duplicates in the interchange, but is usually incremented by one for each group of this type sent to the same trading partner. GS07 - Responsible Agency Code - X for X12 or T for TDCC GS08 - Version/Release/Industry Identifier Code - The first six characters specify the X12 version and release, while any of the last six may be used to indicate an Industry standard or Implementation Convention reference.

GE - Functional Group Trailer

GE01 - Number of included Transaction Sets - This is used for message integrity, developed before such things as check sums were widely implemented. GE02 - Group Control Number - Must match the group control number of the GS

3.3 Transaction Set Envelope - ST/SE

ST - Transaction Set Header

ST01 - Transaction Set Identifier Code - A three digit numeric code identifying the Transaction Set type, from the Transaction Set table. ST02 - Transaction Set Control Number - May take any alphanumeric value so long as there are no duplicates in the functional group. Usually starts with 0001 in each group, but there are several other numbering schemes in common usage. Is referenced in the 997 Functional Acknowledgment if individual transaction sets are positively acknowledged or if there are errors in the transaction set indicating a rejection.

Supportian Inc.

EDI - Introduction

Page 15 of 19

Technical Workshop Integration - EDI

SE - Transaction Set Trailer

SE01 - Number of included segments - This is used for message integrity, developed before such things as check sums were widely implemented. SE02 - Transaction Set Control Number - Must match the Transaction Set Control Number in the ST.

4 Example Interchange
This example has one transaction set, in one functional group, in one interchange. An asterisk "*" is used for the element separator. A carriage return "^M" is used for the segment terminator. Each segment is listed on a separate line for readability, but in reality the data appears as a single stream with the segments separated only by the <CR>. There are four N1 Name/Address loops. Please note that the ISA segment is wrapped over two lines to enable easier reading.
ISA*00* *00* *01*0011223456 *14*999999999* 950120*0147*U*00300*000000005*0*P*~<CR> GS*PO*0011223456*999999999*950120*0147*5*X*003040<CR> ST*850*000000001<CR> BEG*00*SA*95018017***950118<CR> N1*SE*UNIVERSAL WIDGETS<CR> N3*375 PLYMOUTH PARK*SUITE 205<CR> N4*IRVING*TX*75061<CR> N1*ST*JIT MANUFACTURING<CR> N3*BUILDING 3B*2001 ENTERPRISE PARK<CR> N4*JUAREZ*CH**MEX<CR> N1*AK*JIT MANUFACTURING<CR> N3*400 INDUSTRIAL PARKWAY<CR> N4*INDUSTRIAL AIRPORT*KS*66030<CR> N1*BT*JIT MANUFACTURING<CR> N2*ACCOUNTS PAYABLE DEPARTMENT<CR> N3*400 INDUSTRIAL PARKWAY<CR> N4*INDUSTRIAL AIRPORT*KS*66030<CR> PO1*001*4*EA*330*TE*IN*525*VN*X357-W2<CR> PID*F****HIGH PERFORMANCE WIDGET<CR> SCH*4*EA****002*950322<CR> CTT*1*1<CR> SE*20*000000001<CR> GE*1*5<CR> IEA*1*000000005<CR>

But What does it Mean? X12 Semantics The meaning of the data in an X12 Transaction Set is defined in several places in the X12 standard. The primary sources are the Data Element Dictionary (X12.3), the Segment Directory (X12.22), and the Transaction Set Tables (X12.1). A useful document that deals with semantics from a general perspective is the technical report on "Implementation of EDI Structures - Semantic Impact" (X12.59). Much of the content of this page is based on the work of X12C/TG3, which was performed in preparation for the

Supportian Inc.

EDI - Introduction

Page 16 of 19

Technical Workshop Integration - EDI technical report on how to express X12 semantics in XML syntax. For more information about that effort, please visit the X12C/TG3 page at ANSI ASC X12. EDI translation software may validate the syntax of an interchange by checking it against a segment directory, transaction set tables, and data element dictionary to validate data types and code values for ID elements. However, the determination of the exact semantic meaning of a particular data element, that is, the location in the users database or file to which it corresponds, must ultimately be determined by the user and the trading partner. Syntax can be (and commonly is) validated by EDI translation software. Proper usage of semantics can not.

Context is Everything - The Dispersed Nature of X12 Semantics

The semantic meaning of a particular data element can usually not be fully determined without considering the full context of the data element, such as the Transaction Set, loop, and segment in which it appears. In a few cases it is also necessary consider the values in other elements in the segment. This attribute has been referred to as dispersed semantics. For example, the sixth element of the N4 segment, N406 data element 310, is Location Identifier, and for example might have a value of "XYZ". However, we don't know this without considering GS08, which indicates the X12 version and release. By itself, Location Identifier does not mean much. It is qualified with N405 data element 309 Location Qualifier, which conveys the type of identifier. For example, "SN" in N405 indicates that the value in N406 is a Store Number. However, this still does not mean very much unless we consider that these elements appear in an N4 Geographic Location segment which appears in an N1 Name/Address loop. We don't know what kind of Name we are talking about unless we examine the code in N101, data element 98 Entity Identifier Code, which might indicate "ST" for a "Ship To" Name. So, we know are to ship to store number XYZ. However, if the N1 loop is in an 850 Purchase Order, we don't know if we ship the whole order to XYZ or just a line item unless we consider the segments that have come before the N4 and can determine that it is in the Header area of the transaction set or in a PO1 Line Item loop. The occurrence within an 850 Purchase Order transaction set sets an overall context for the exchange, and finally the group and interchange envelope segments complete the context by specifying the sender and receiver. Confusing, huh?

One more time, from the Bottom Up

At the lowest level, the meaning of a data element is defined by its name and description in the Data element dictionary. If a data element is a component element of a composite data element, the meaning is further qualifed. For example Unit or Basis for Unit Measure (DE 355) is given further context and meaning by appearing in the composite data element Composite Unit of Measure (C001).

Supportian Inc.

EDI - Introduction

Page 17 of 19

Technical Workshop Integration - EDI A data element (simple or composite) is further defined by the segment in which it is used. For example, the Amount data element (DE 610) has an entirely different meaning when used in the "Total Monetary Value Summary" (TDS) segment than when it is used in the "Adjustments to balances or services" (ADJ) segment. An element may be futher qualifed in a segment by:

Pairing it with another element as a qualifer. For example, the sixth element of the PO1 segment, Product/Service ID Qualifier (DE 235) contains a ID value that tells what kind of product or service appears in the seventh element, Product/Service ID (DE 234). The value "VP" in PO106 tells us that PO107 is a Vendor Part Number. A Segment Semantic Note - There are four Amount elements (DE 610) in the TDS segment. Semantic notes tell us that the first is the total amount of the invoice, the second is the amount on which a discount is based, the third is the amount due if paid by the terms discount date, and the fourth is the total amount of terms discount.

The meaning of a segment is qualified by:

Where it appears in the Transaction Set. The Administrative Communications Contact (PER) segment has a different meaning in the Invoice (810) in the header area just before the N1 loop than it does within the N1 loop. A value in a qualifier element, usually the first element in the segment. For example, "SY" in Reference Identification Qualifier (DE 128), REF01 of the Reference Identification segment, says that the whole REF segment describes a Social Security Number.

The meaning of a segment loop can often be qualified by a value in a qualifier element in the first segment. For example, "ST" in Entity Identifier Code (DE 98) in N101, says that the whole N1 loop is about the Ship To Name/Address.

Position vs. Occurrence, and other Fine Points

X12 experts will say that where a data element or segment occurs has no semantic meaning, but that position is all important. How do we resolve this seeming contradition? The answer is this: When designing a Transaction Set, the order of elements within a segment, and the order of segments (at the same level), within a Transaction Set, have no semantic significance. For example, it is not important that N1 Name comes before N3 Address Information. However, once the Transaction Set has been designed, it is essential that data streams coded to that transaction set definition observe the prescribed order. Translators are able to identify data elements and imply semantic meaning strictly by position in the data stream. So, during design position is not important, but when implemented position is everything. A complication of this concept is found in many Implemention Conventions, but is not supported in the standard. That is when someone dictates that specific semantic meaning is assigned to a particular occurrence of a segment or element. For example, where we Supportian Inc. EDI - Introduction Page 18 of 19

Technical Workshop Integration - EDI might have three occurences N1 Name/Address loop in the header area of an 810 Invoice (i.e. three occurences in the same position), we may be told to put the "Buyer" in the first loop and the "Bill To" in the second. We don't do this in the standards. The only qualification to all of this is found in X12.59, with the notion of "Functionally Equivalent Data Over-ride". This means that if the same information appears in the header and detail areas of a data stream, that the information in the detail area takes precedence. For example, we may have a primary "Ship To" address in an N1 Name/Address loop in the header area of an 850 Purchase Order, but a "Ship To" address in an N1 Name/Address loop in a Baseline Item Data (PO1) segment loop in the detail area says that that line item should be shipped to a different address.

A Simple Example
The following is an example of data that might be found in a paper Purchase Order and the corresponding X12 Interchange. It illustrates how we get meaning from context. For the highlighted data items:

PO Date is in BEG06 The Seller Name and Address are in the first N1 loop The Ship To Name and Address are in the Second N1 loop The Bill To Name and Address are in the Third N1 loop The unit price of the Widgets is in PO104

Please note that the ISA segment is wrapped over two lines for easier reading.
ISA*00* *00* *01*0011223456 *01*999999999* 950120*0147*U*00300*000000005*0*P**<CR> GS*PO*0011223456*999999999*950120*0147*5*X*003040<CR> ST*850*000000001<CR> BEG*00*SA*95018017***950118<CR> N1*SE*UNIVERSAL WIDGETS<CR> N3*375 PLYMOUTH PARK*SUITE 205<CR> N4*IRVING*TX*75061<CR> N1*ST*JIT MANUFACTURING<CR> N3*BUILDING 3B*2001 ENTERPRISE PARK<CR> N4*JUAREZ*CH**MEX<CR> N1*AK*JIT MANUFACTURING<CR> N3*400 INDUSTRIAL PARKWAY<CR> N4*INDUSTRIAL AIRPORT*KS*66030<CR> N1*BT*JIT MANUFACTURING<CR> N2*ACCOUNTS PAYABLE DEPARTMENT<CR> N3*400 INDUSTRIAL PARKWAY<CR> N4*INDUSTRIAL AIRPORT*KS*66030<CR> PO1*001*4.95*EA*14850*TE*IN*525*VN*X357-W2<CR> PID*F****HIGH PERFORMANCE WIDGET<CR> SCH*4*EA****002*950322<CR> CTT*1*1<CR> SE*20*000000001<CR> GE*1*5<CR> IEA*1*000000005<CR>

Supportian Inc.

EDI - Introduction

Page 19 of 19