This introduction aims at addressing the basic questions of convention and implementation of the EDI technology.  I have a list of topics, and hope that over time I can cover all of them.  I also hope that people reading here may have questions that I haven’t thought to write about.  Please let  me know what your questions are and I will see what I can do about providing answers.

• What is EDI?
• Parts of EDI
• Segments
• Delimiters
• Conventions of EDI
• Why are there more than one version of EDI?
• Standards and Usage
• Encoded Values
• EDI in Good Form
• Element Notation
• Wrapped and Unwrapped EDI
• Enveloping Part One
• Enveloping Part Two – ISA
  
• Enveloping Part Three – GS
• Enveloping Part Four – ST
• Loops in EDI
• Hierarchical Levels

Of course understanding how EDI presents and represents data is the first step.  From here we may want to go to our Data Mapping Guide, or if we are familiar with mapping there are some examples in our mapping case studies of EDI to and from other formats.  Again, if you have an interesting problem or solution, I would love to here about it.  Please send it to
roy@TheIntegrationEngineer.com and I will see what I can do.

Document Identifier

The document Identifier is not encoded.  That is to say, for an 850 the ST document ID is “850″.  For an 810, the Document Identifier is “810″ and so on.  Thus if you open an EDI file, and don’t recognize the GS_01, skip to the ST_01 and it will tell you what standard you will need to find to read this document.

Good form would dictate that the GS_01 and the ST_01 would specify the same type of document.  The GS would specify it on a functional level, and the ST on the standard level.  Thus they would not be identical strings but would indeed convey the same message about what the document(s) would be.  Some EDI translator or processing software will validate this relationship and some may not.  But in the end consistency is the best policy.

Control Number

The control number is different for the ST than we saw in both the ISA and GS.  The ST_02 is a 3 to 9 digit number.  This means that it will start with 001 not 000000001.  Of course you can still use a 000000001 but don’t be surprised when you see less than 9 digits in the ST-SE control number.  Whichever you chose, you must do the same for both the ST and SE.

(Using 000 or 000000000 may be allowed, but is not recommended as any application that trims the zeroes will get an empty string and produce an error.  Be nice and only use values greater than zero.)

Segment Counter

The SE segment counter is the part of the ST-SE that gives people hand editing an EDI document the most trouble.  If the counter is inaccurate it indicates that the document is corrupted.  This should fail in all good translators as processing a corrupt EDI file is saying, “Its okay if we get bad data.”  This counter represents the number of segment between the ST and before the SE.

And it is just that simple.  Remember that you can have more than one GS-GE envelope inside an ISA-IEA, and you can have more than one ST-SE inside a GS-GE, but you can only have one document of one type in side a ST-SE envelope.

–

For an overview of Enveloping go here.

Looking for the ISA enveloping page?

Looking for the  GS enveloping page?

Looking for something else relating to EDI?  Check out the EDI Primer post

The GS segment is the second mandatory enveloping segment.  It shares some properties with the ISA segment.  There is a sender and receiver, version Identifier, time stamp and control number.  But one thing that the GS has that the ISA does not is a Functional Identifier.

That’s right, Functional.  This means that within the GS envelope are only EDI messages or documents that have the same function.

Here is a GS segment:

GS*PO*901234572000*908887732000*081031*0835*1*T*004010!

Like all segments, the first element is 0 and identifies the segment type.  This segment has a GS in this element, making it a GS segment.

Unlike the ISA segment, that does not change in any way from standard to standard, the GS may change a bit.

Here are the definitions of the GS segment for the 3020 X12 standard:

There are 8 elements.

And here is the definitions of the GS segment for the 4010 X12 standard:

Again there are 8 elements.

Now look at the size of the Date and Time elements in GS_04 and GS_05.  In the 3020 version, the Date is 6 char, and in 4010 it is 8 char.  The time also grows from a 6 to a possible 8 char size.

Version 4010 was considered the Y2K standard where the dates moved from a 6 char date, to and 8 char date to accommodate the century change.

Other than this change, the GS segments and usage are the same.

Element by Element

GS_01 is the Functional Identifier.  This designates the type of messages this envelope contains.  If it contains Purchase Orders, the GS_01 is “PO”  if it contains Invoices, it is “IN” as so forth.

GS_02 is the Sender Identifier.  This does not have to be the same as the ISA Sender, but it can be.  This element has the same restrictions on content, a 15 character alpha-numeric.  But unlike the ISA sender, this one is not fixed in size.  This means that the delimiters fit around the value without including any white space.  In many basic implementations, the value in the ISA sender, and the GS sender are the same value.

GS_03 is the Receiver Identifier.  This does not have to be the same as the ISA receiver, but it can be.  This element has the saem restrictions on content, a 15 character alpha-numeric.  But unlike the ISA sender, this one is not fixed in size.  This means that the delimiters fit around the values without including any white space.  In many basic implementations, the values in the ISA receiver and the GS receiver are the same value.

GS_04 is the Date.  It should be the date of the creation of the GS envelope.  Many times it is the same date as the ISA date.

GS_05 is the Time.  It should be the time of the creation of the GS envelope.  Many times it is the same as the ISA time.

GS_06 is the Control Number.  This is a 1 to 9 numeric value.  This is a number that needs to be unique inside the ISA envelope only.  Some implementations use an incrementing number that increments with the usage like the ISA control number.  Others just have a count of the number of GS envelopes inside an ISA.  Both are acceptable.  All that is required is that the GS control number be unique among other GS control numbers within the ISA envelope that it is contained in.

GS_07 is the Agency Code.  Basically for any X12 document that will be “T” or “X”.  I have only seen “X” indicating that it is really using X12.  Even when it is not.  Most of the time I ignore this value.

GS_08 is a Version identification value.  Just like the ISA_12, this identifies the standard, but identifies it to the next level.  Thus if you are 4010, this will be 004010 and so on.

Too Much?

No problem, there are really a few things to pay attention to as you begin to work with GS envelopes.  And if you are just needing to do a quick edit and resubmit you may not need to do much.

• Pay attention to the GS_02 and GS_03, these are the sender and receiver and need to be conrect to route documents and match with the profile for most systems.
• Make sure the GS_01 is the type of document that you are really sending.  Some systems get cranky when they get an Invoice in a Purchase Order envelope.
• And as always, make sure your GS and GE control numbers match and are unique inside the ISA-IEA envelope.

–

For an overview of Enveloping go here.

Looking for the ISA enveloping page?

Looking for the ST enveloping page?

Looking for something else relating to EDI?  Check out the EDI Primer post

The ISA Segment is the first segment in any EDI document.  Once you understand what it is saying, This long random seeming string will make sense, and be very helpful in helping you relate EDI documents to the real world task that you need to do.

Here is an ISA segment.

ISA^00^          ^00^          ^01^9012345720000  ^01^9088877320000  ^080902^1523^U^00401^000000001^0^T^|~

This is one long string, there is no linefeed or line break.

Like all segments, the first element is 0 and identifies the segment type.  This is an ISA segment.

There are 16 ISA elements, here are the definition for the ISA

A note on Qualifiers

A qualifier is an element that precedes an element and defines the type of data will be found in the element that it precedes.  The Qualifier element is also an encoded element.  Encoded elements are elements that have a defined set of possible values.

The Unit Of Measure is my favorite example of a qualifier.  The UOM precedes the quantity.  Thus when you have a quantity of 5, your will know that it is 5 boxes not five containers or eaches by knowing what the UOM qualifier is for that quantity.  For the Unit Of Measure, there is a specific set of them and what they mean.

Element by Element

ISA_01 is a qualifier.  The Authorization Information Qualifier can be one of 7 values from 00 to 06.  Most of the time it is 00 which means that ISA_02 will not contain meaningful data.  This field must be populated with one of these values.

ISA_02 is for Authorization Information.  If the ISA_01 is 00, this will normally be left blank.  If ISA_01 is one of the other 6 valid values, this field must be populated.  The value here will be used to determine the authorization of the document.  I have only seen this used with one trading partner.  You might not see this at all.

ISA_03 is also a Qualifier.  It is the Security Information Qualifier and can be one of two values, 00 or 01.  Most of the time it is 00 which means that ISA_04 contains no password.  This field must be populated with one of these values.

ISA_04 is for Security Information.  This is also called the password.  If the ISA_03 is 01, this must contain a value.  Most of the time this will be blank.

ISA_05 is an Interchange ID Qualifier.  There are two of these.  They qualify or define the Interchange ID field that they precede.  These are required to be present.  There are 41 valid options, and I won’t define them all here.  Some common usages are:

01 = DUNS number

12 = Phone number

14 = Duns Number with Suffix

16 = DUNS with 4 character suffix

ZZ = mutually defined.

ISA_06 is the Sender’s Interchange Identifier.  This value will identify the sender to the receiver.  The receiver should have this as a unique value.  Thus some times it is necessary to have more than one option in case the value you have chosen is already in used by some other Trading Partner that the receiver exchanges documents with.

ISA_07 is an Interchange ID Qualifier.  It follows the same rule as ISA_05 but qualifies the receiver instead of the sender.

ISA_08 is the Receiver’s Interchange Identifier.  This values tells the sender’s system where the message is going, and tells the receiver’s system that this message is for them.  The sender will need to have a unique value for each trading partner.

ISA_09 is the Interchange date.  This is the date that the ISA envelope is created.  Sometimes this value is derived from the contents of the document, but ideally this should be the date of the interchange envelope.

ISA_10 is the interchange time.  This is the time that the ISA envelope is created. Sometimes this values is derived from the document, or is defaulted to midnight.  Ideally this should be the time of the interchange envelope.

ISA_11 is the Standard Identifier.  This will always be ‘U’ identifying this as the US EDI standard.

ISA_12 is the Standard Version Number.  This relates to the major version of the EDI standard that is used.  This value needs to be accurate so that the receiver’s EDI system can expect the right size of fields in the GS segments.  This may not look like what it is, as you see this ‘00401′ for a version of ‘4010′.  This only identifies the major version, not distinguishing between 4010, 4011 and 4012.

ISA_13 is the Interchange control number.  This is the way that an EDI system identifies the envelope.  This control number should not be random, but an incrementing number.  It is 9 digits padded with zeroes.  The combination of ISA Sender and Receiver Identifiers and the Control number should identify a distinct interchange transmission.  When 9 ‘9’s are reached, the control number should roll back to 1. Nine zeros should be avoided as some systems that may internally trim the zeros will them be presented with a null value.

ISA_14 is the Acknowledgment Request.  This lets the EDI file make a request for a functional acknowledgment or 997 to be transmitted. This is a binary option of 0 meaning “don’t send a 997.”  and 1 meaning “send a 997.”  In a perfect world any ISA with a 1 in this would get a 997 returned.  In the real world, most EDI systems require some setup to enable the 997, thus it is good to discuss this before sending the request.

ISA_15 is the usage indicator.  This can be one of three values.  P is for Production Data, T is for Test Data, and I is for Information Definition.  This is important as a EDI system should only process interchanges with the P as production data.

ISA_16 are the delimiters.  You may remember from the delimiter discussion that these are in a fixed position.

Too Much?

Really there are only a few things that you need to worry about as you start working with EDI and the ISA.  If you are just needing to do a quick edit for a test or to resubmit a document, here is what is important.

• Pay attention to the ISA_05, 06, 07 and 08.  These are the sender and receiver fields.
• Increment you control numbers to make sure that you EDI files don’t get booted as dupes.
• Make sure the ISA and IEA have matching control numbers.

–

There’s more!  Now we explain the GS envelope.

For an overview of Enveloping go here.

Looking for the ST enveloping page?

Looking for something else relating to EDI?  Check out the EDI Primer post

The first segment in and EDI file is the ISA segment.  The very last segment in and EDI file is the IEA.  For those of you familiar with XML, you may be thinking of this as <File> and </File>.

This approach may make EDI seem familiar, but XML was not around when EDI was being created.  It is more like a Beginning Of File (BOF) and End Of File (EOF) marker.  However, there is no reason in EDI not to place multiple EDI envelopes in the same file.

Structure of Enveloping

The first part of and EDI envelope is the ISA-IEA.  As explained above, the ISA is the first segment, and the IEA is the last.

Directly below the ISA-IEA is the GS-GE envelope.  The second segment is the GS segment, and the segment before last is the GE segment.

Inside the GS-GE is the ST-SE.  The third segment is always the ST, and the third from last is always the SE.

If we were to explode the envelope, it would look something like this:

ISA

GS

ST

(data contents here)

SE

GE

IEA

Three envelopes with three purposes.

If the illustration above were all there was to enveloping.  This would be over.  And it would also be pretty useless.

The ISA segment is the interchange envelope.  It contains information for the envelope and its contents.  The IEA completes the envelope, and contains a matching control number with the ISA and a counter indicating the number of GS-GE envelopes it contains.

The GE segment is the functional level.  It contains an encoded value indicating what the functional purpose is the contents of the GS envelope is.  It also has come functional delivery identifiers.  The GE, like the IEA, has a corresponding control number with the GS, and has a counter of the number of ST envelopes it contains.

The ST is the document level.  It does not contains any sender of receiver identifiers.  It does contains the document number that indicates the document type.  The SE like the IEA and the GE, contains a  corresponding control number with its partner the ST segment.  It also  contains a counter of the number of segments contained in the ST-SE document envelope.

These counter and control numbers serve important functions.  The indicate where the transitions are between logical sets of data, and they ensure that data is not lost in transmission or garbled with the end of one file being paired with the beginning of another.

Based on this, here are some other illustration of the EDI enveloping structures.

Example 1:

ISA

GS

ST

(data contents here)

SE

ST

(data contents here)

SE

GE

IEA

Example 2:

ISA

GS

ST

(data contents here)

SE

GE

GS

ST

(data contents here)

SE

GE

IEA

Example 3:

ISA

GS

ST

(data contents here)

SE

GE

IEA

ISA

GS

ST

(data contents here)

SE

GE

IEA

Each of these represents a valid way to send two EDI documents in the same physical file.

In Example 1, both documents are in the same ISA, therefore they are both going to the same interchagne receiver.  Both are also in the same GS, therefore they are of the same type and going to the same Functional receiver.

In Example 2, both documents are in the same ISA, therefore they are both going to the same interchange receiver.  They are not in the same GS, so they may be of different functional types and or destined for different functional receivers.  Say we receive an shipping notice and an invoice, we could get them together, and route the shipping notice at the GS or functional level to the receiving system.  And then route the invoice at the functional level to the accounting system.

In Example 3, both documents are in their own ISA envelope.  They may be destined for separate interchange entities or the same one.  They may be of different types or the same time.  They may be as different as any two files, but we are illustrating is that documents can be in the same file, and still be separate documents.

Summary

What is important to understand is what enveloping is.  Enveloping is the way EDI ensures file integrity and lets the message determine its destination and type. EDI enveloping segments are required, and follow a pattern that allows for a wide diversity in grouping of data for logical consumption.

Next we will dissect the elements of the enveloping segments, ISA-IEA, GS-GE, ST-SE.  And we will talk about the control numbers an how those relate to functional acknowledgements.

–

For more specifics on enveloping:

• Enveloping – ISA
• Enveloping – GS
• Enveloping – ST

Looking for something else relating to EDI?  Check out the EDI Primer post

–