Electronic Data Interchange Details

EDI Standard

Necessary tool for sending an EDI message is to use an EDI standard. EDI standard is the common language between trading partners
After reading this chapter you will be able to answer: What is an EDI standard?Who can make an EDI standard?Can you name a widely used EDI standard?What are the parts of an EDI standard?

2. What is an EDI standard?
Why do we have to use common format? An invoice is a typical example of a document transmitted by EDI. An invoice always includes name, address, date, amount to be paid etc. However each company has its own format for invoices. With the use of EDI there is a need for a common format for messages like a common language between sender and recipient.
What is a message standard?
Message standard is an agreed standard with certain format and certain syntax rules. That means that sender and recipient have to agree upon a fixed method of specifying and presenting data, so as to eliminate communication problems.
Can we make our own standards? Sender and recipient can agree to use a certain format for messages, thus they both will recognize these messages. In order to recognize the messages they only need a ‘translation software’, which they can develop.But what if there are more than two partners who want to use EDI? They have to use all of them the same standard and one translation software otherwise they will have to develop a translation software for each message standard.
For example if there are four different partners in a transaction and each of them uses its own standard there is a need for 12 different translation software's
There is a need for a common message standard In order to avoid translation and communication problems different actors have to use common language namely a common message format.
Categorization of EDI standards
· Proprietary Used by two or more companies which belong to a close group
· Sectorial Used by different economical sectors
· National Used within one country
· Global There is a tendency of congruity between all standards to a global standard, the UN/EDIFACT.

3. The UN/EDIFACT standard
History The UN/EDIFACT is the result of United Nations effort for the development of a global standard for EDI.
EDIFACT stands for Electronic Data interchange for Administration, Commerce and Transport.EDIFACT is currently used internationally in different sectors of economy.
Parts of EDIFACT standard

Analysis of an EDI standard and especially of an EDIFACT standard includes:
· Data elements
· Syntax rules
· Hierarchical structuring
Data elements
Data elements are the most important part of an EDI message. Data elements are data that have to be transmitted with an EDI message.Data elements can include codes, abbreviations etc.
Syntax rules
Syntax rules gives the framework in which data elements will be combined and used in order to develop an EDI message that fulfils the requirements of an EDIFACT standard.
Syntax rules include
· Hierarchical structuring
· Implicit identification of data elements
· Character sets and separators
· Variable length fields
· Mandatory or conditional data elements and segments
· Repetition of data elements and segments
Hierarchical structuring
The first characteristic of the syntax rule of an EDIFACT message is the hierarchical structuring.Hierarchical structuring gives the structure of data to be presented.Data elements are grouped to data segments that can give complete information.Each EDI message consists of data segments that present the main data. The data segments are enveloped between other segments containing general information such as message header, references, etc.


Electronic Data Interchange


Ø EDI is the computer-to-computer exchange of business information using public standards.

Ø A trading partner is a business that has agreed to exchange business information electronically.

Ø In EDI, electronic documents (purchase orders, bills, etc.) are given standardized electronic formats and numbers, so everyone involved can correctly interpret the information being transferred. VANs, maintained by companies similar to long distance phone companies, provide telecommunications connectivity between trading partners. Translation software used by each trading partner to translate the business data.

Details:

Electronic Data Interchange (EDI) is the computer-to-computer exchange of structured information, by agreed message standards, from one computer application to another by electronic means and with a minimum of human intervention. In common usage, EDI is understood to mean specific interchange methods agreed upon by national or international standards bodies for the transfer of business transaction data, with one typical application being the automated purchase of goods and services.
Despite being relatively unheralded, in this era of technologies such as XML services, the Internet and the World Wide Web, EDI is still the data format used by the vast majority of electronic commerce transactions in the world.

Contents

1 Standards
2 Interpreting Data
3 Standards organization
4 ANSI ASC X12
4.1 ANSI X12 Format Overview


Standards

The EDI standards were designed from the beginning to be independent of lower level technologies and can be transmitted using Internet protocols as well as private networks. It is important to differentiate between the EDI documents and the methods for transmitting them.

While comparing the bisynchronous 2400 bit/s modems and value-added network to the Internet some people predicted erroneously that EDI would be replaced. These older transmission methods are being replaced by Internet Protocols such as FTP, telnet and email, although standards for these media are still emerging. In 2002, the IETF published RFC 3335, offering a standardized, secure method of transferring EDI data via e-mail. As of 2005, an IETF working group, EDIINT, is preparing similar documents for HTTP and FTP transfers. The EDI documents themselves, as well as the traditional EDI service providers (value-added networks), remain.
EDI documents contain the same data that would normally be found in a paper document used for the same organizational function. For example an EDI 940 ship-from-warehouse order is used by a manufacturer to tell a warehouse to ship product to a retailer. It typically has a ship to address, bill to address, a list of product numbers (usually a UPC code) and quantities. It may have other information if the parties agree to include it. However, EDI is not confined to just business data related to trade but encompasses all fields such as medicine (patient records, laboratory results..), transport (container and modal information...), engineering and construction, etc.

There are three major sets of EDI standards. UN/EDIFACT is the only international standard (in fact, a United Nations recommendation) and is predominant in all areas outside of North America. ANSI ASC X12 (X12) and the Uniform Communication Standard (UCS) are popular in North America and are very similar to each other.

These standards prescribe the formats, character sets, and data elements used in the exchange of documents and forms, such as purchase orders (called "ORDERS" in UN/EDIFACT and an "850" in X12) and invoices.
The standard says which pieces of information are mandatory for a particular document, which pieces are optional and give the rules for the structure of the document. The standards are like building codes. Just as two kitchens can be built "to code" but look completely different, two EDI documents can follow the same standard and contain different sets of information. For example a food company may indicate a particular product expiration date while a clothing manufacturer would choose to send color and size information.
Organizations that send or receive documents from each other are referred to as "trading partners" in EDI terminology. The trading partners agree on the specific information to be transmitted and how it should be used. This is done in human readable specifications (also called specs or spec sheets). While the standards are analogous to building codes the specifications are analogous to blue prints. (The specification may also be called a mapping but the term mapping is typically reserved for specific machine readable instructions given to the translation software.) Larger companies have existing specification sheets and are usually unwilling to negotiate. Often in a large company these sheets will be written to be used by different branches or divisions and therefore will contain information not needed for a particular exchange. (Deviations from and clarification to the specification sheets should always be obtained in writing.)


Interpreting Data
Often missing from the specifications are real world descriptions of how the data should be interpreted. This is particularly important when specifying quantity. For example, suppose candy is packaged in a large box that contains 5 display boxes and each display box contains 24 boxes of candy packaged for the consumer. If an EDI document says to ship 10 boxes of candy it may not be clear whether to ship 10 consumer packaged boxes, 240 consumer packaged boxes or 1200 consumer packaged boxes. It is not enough for two parties to agree to use a particular qualifiers indicating case, pack, box or each; they must also agree on what that particular qualifier means.
EDI translation software provides the interface between the internal system and the common standards. For an "inbound" document it typically takes the variable length fields of the EDI document, translates the individual pieces of data and then creates a file of fixed length fields. For an "outbound" document the translation software queries the internal system, as in the case of an SQL database, or it translates a fixed width file exported by the internal software. Translation software may also utilize other methods or file formats. The mechanism of translation is not part of the standard.

(In EDI terminology "inbound" and "outbound" refer to the direction of transmission of an EDI document in relation to a particular system, not the direction of merchandise, money or other things represented by the document. For example, an EDI document that tells a warehouse to perform an outbound shipment is an inbound document in relation to the warehouse computer system. It is an outbound document in relation to the manufacturer or dealer that transmitted the document.)


Standards organization
Standards Organizations are bodies, organizations and institutions that produce, and in some cases measure, standards.


ANSI ASC X12
ANSI ASC X12 is the official designation of the US National standards body for the development and maintenance of EDI standards for the United States. The group was founded in 1979, and is an accredited standards committee under the American National Standards Institute. The acronym stands for "American National Standards Institute Accredited Standards Committee X12," with the designation of X12 being a sequential designator assigned by ANSI at the time of accreditation with no other significance.


An EDI X12 Formatting Example:

Following is an example of an EDI document. They are typically sent in a format similar to the following code, except that the code shown has been broken into multiple lines for display, while the real document is a single long line of text.
ISA* * * * *ZZ*SENDER *ZZ*
RECEIVER *041201*1200*U*00305*000000101*1*P*^!GS
*PO*SENDER*RECEIVER*041201*1200*101*X*003050!ST*850
*000000101!BEG*22*NE*101**041201*123456!FOB*DF*ZZ*JM
J!DTM*037*041205!DTM*038*041215!DTM*002*041218!TD1*
CNT90*1!TD5****JJ*X!TD3*40!N1*OB**92*7759!N3*111 Buyer
St!N4*Conyers*GA*30094*US!N1*SE*Foo Bar Sellers!N4****US
!REF*DP*101!PO1*100*1*EA***ZZ*BL47*HD*100!PID*F****
Widget!PO4**1*EA!N1*CT**38*CN!N4****CN!CTT*1*100!SE*22
*000000101!GE*1*101!IEA*1*000000101!

Here is the same document "unwrapped" at the segment level and indented to show the looping structure:
ISA* * * * *ZZ*SENDER *ZZ*RECEIVER *041201*1200*U*00305*000000101*1*P*^!
GS*PO*SENDER*RECEIVER*041201*1200*101*X*003050!
ST*850*000000101!
BEG*22*NE*101**041201*123456!
FOB*DF*ZZ*JMJ!
DTM*037*041205!
DTM*038*041215!
DTM*002*041218!
TD1*CNT90*1!
TD5****JJ*X!
TD3*40!
N1*OB**92*7759!
N3*111 Buyer St!
N4*Conyers*GA*30094*US!
N1*SE*Foo Bar Sellers!
N4****US!
REF*DP*101!
PO1*100*1*EA***ZZ*BL47*HD*100!
PID*F****Widget!
PO4**1*EA!
N1*CT**38*CN!
N4****CN!
CTT*1*100!
SE*22*000000101!
GE*1*101!
IEA*1*000000101!



Format Overview
Segment Types
ISA Interchange Control Header
GS Function Group Header
ST Transaction Set Header
SE Transaction Set Trailer
GE Function Group Trailer
IEA Interchange Control Trailer
Segment Formats
ISA*fields^
GS*fields^
ST*fields^
SE*fields^
GE*fields^
IEA*fields^
Note: * = Field Separator; ^ = Segment Separator
Segment Fields
ISA Segment
ISA01 Authorization Information Qualifier
ISA02 Authorization Information
ISA03 Security Information Qualifier
ISA04 Security Information
ISA05 Interchange ID Qualifier
ISA06 Interchange Sender ID
ISA07 Interchange ID Qualifier
ISA08 Interchange Receiver ID
ISA09 Interchange Date
ISA10 Interchange Time
ISA11 Interchange Control Standards ID
ISA12 Interchange Control Version Number
ISA13 Interchange Control Number
ISA14 Acknowledgement Requested
ISA15 Test Indicator
ISA16 Subelement Separator
GS Segment
GS01 Functional ID code
GS02 Application Sender's Code
GS03 Application Receiver's Code
GS04 Date
GS05 Time
GS06 Group Control Number
GS07 Responsible Agency Code
GS08 Version/Rel. Ind. ID Code
ST Segment
ST01 Transaction set ID code
ST02 Transaction set control number
SE Segment
SE01 Number of included segments
SE02 Transaction set control number (same as ST02)
GE Segment
GE01 Number of Transaction Sets Included in this Function Group
GE02 Group Control Number (same as GS06)
IEA Segment
IEA01 Number of Included Functional Groups
IEA02 Interchange Control Number (same as ISA13)
This output file uses the X12 EDI standard.
The segment delimiter is a backslash ("\").
The element delimiter is an asterisk ("*").
Sample File
Note: Linefeeds and "(Continued)" notes inserted for clarity
ISA*00* *00* *01*123454321 *01(Continued)
*012341234 *031016*2359*U*00401*987600111*0*P*:
\GS*RA*123454321*012341234*031016*2359*987600111*X*004010
\ST*820*987600111
\BPR*C*77.77*C*ACH*CTX*01*234056789*DA*0099109999*(Continued)
*123454321*01*045678099*DA*1008973899*031016
\TRN*1*0310162359
\REF*AA*EDI6
\N1*PR*WHIZCO OF AMERICA INC
\N3*55 MEGAPLEASANT ROAD*SUITE 999
\N4*SUPERVILLE*NY*10954
\N1*PE*YOWZACO
\ENT*1
\RMR*AP*1111111111111111*PO*11.11
\RMR*AP*2222222222222222*PO*22.22
\RMR*AP*4444444444444444*PO*44.44
\DTM*055*031016
\SE*000000014*987600111
\GE*1*987600111
\IEA*1*987600111\

EDI comes in a variety of standard definitions such as ANSI X12, EDIFACT, and TRADACOM. The example documents shown above are of the X12 variety.
EDI documents are text files which are delimited into segments (in this example by the "!" character), and each segment is further delimited into elements (by the "*" character). Elements may also (rarely if ever) be subdivided into sub-elements (by the "^" character). In the "unwrapped" example above, each segment is on a line by itself. The first position in a segment is the segment identifier. For example, the first segment is an "ISA" segment and the last is an "IEA" segment. Each segment is made up of a number of elements. The first element in the "GS" segment is "PO". (Note that segment identifiers are not considered elements.)
The order and content of the segments create various levels of enveloping. The outermost level (from "ISA" to "IEA") makes up the interchange. The next level (from "GS to "GE") makes up the functional group. The last level (from "ST" to "SE") contain the transaction set. Each interchange may contain multiple functional groups and each functional group may contain multiple transaction sets. The ISA, IEA, GS, GE, ST, and SE segments are all enveloping headers. Transaction sets are the data payloads in an EDI message. The example above is a purchase order. It is distinguished as a purchase order by the "PO" in the first element of the GS segment and the "850" in the first element in the ST segment.
Looping occurs when a looping segment is encountered. Looping segments are not obvious by looking at the document itself. If the second example above were not provided, it would be impossible to determine correctly which segments were looping segments and which were not. A looping structure ends when no more segments that belong in the loop are encountered. There is no explicit end to the looping mechanism.


Setting up EDI

Ø Whether you use a service based solution or in-house software, you’ll need to format the data to your trading partner’s specifications. The process of formatting is called mapping.

Ø EDI guidelines are not universal. The map created for Company A’s invoice cannot be copied and used for Company B’s invoice as Company B has its own criteria. You’ll need an implementation guide for every trading partner.

Ø Setting up communication: One of the most important aspects of EDI is selecting how the data is going to get from one place to the other, such as through a VAN or using a direct connection.
VAN: A VAN is a third party service that transmits and stores data in the “electronic mail-box” until it is picked up by the appropriate party. Since the EDI message contains addressing information, the VAN routes message to the mail-box of the recipient.
Direct Connection: Unlike the VAN, a direct connection allows you to pass the data straight to the receiving party, e.g. VPN, FTP, EDIINT (in conjunction with AS2).

Ø There are two parts to EDI: the translator and the mapper.
Ø The translator is the engine behind the EDI process and governs the day-to-day activity. It has several components, including the engine itself, the EDI maps, the standards and communications ability.
Ø Data is formatted using the mapper, a software tool that enables one to properly organize the data so that it follows both the EDI and the trading partner’s standards.
Ø The trading partner will send sample data, which is then mapped following the guidelines. The completed map is tested by sending sample data (which is now formatted) back to the trading partner. If it fails, the mapping error must be found and corrected.



How EDI Works

Let us presume that a buyer is sending a purchase order to the supplier.
1. Most likely the information contained in the purchase order resides in a computer application (for example, an inventory package) on the buyer’s PC. As long as it is possible to import and export files form the application, pertinent information can be extracted and mapped in to a file for the EDI translation software.
2. The EDI translator will do compliance checking to ensure that the mapping complies with EDI standards and the trading partner’s implementation guide. Afterward, it will translate the message into an EDI format.
3. A Communications Connection is established in order to transmit the EDI purchase order. The EDI translation software controls the communications software.
4. The file is sent to either a mailbox, FTP site, or Directly to AS2 recipients to be picked up
5. When the order is received, the software generates an FA back to the buyer. The FA indicates that the message was received and was/was not compliant with the EDI standard. It does not address the actual data in the message.
5. The computer software receiving the EDI purchase order will reformat the incoming data so that it can be readily imported into an existing application’s data files.


There are several benefits of using EDI:
o Reduced postage costs
o Reduced expenses
o Greater speed
o Greater accuracy of information
o Elimination of paper document
o Elimination of labor intensive tasks such as data-entry