EDI Enveloping Part Two (The ISA)

question key EDI Enveloping Part Two (The ISA)What is in the ISA?

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

isa elementdef1 EDI Enveloping Part Two (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.
tick tock EDI Enveloping Part Two (The ISA)
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

Subscribe to "The Integration Engineer" by Email

Related Articles:

7 Responses to “EDI Enveloping Part Two (The ISA)”

  1. GarykPatton Says:

    Hi! I like your srticle and I would like very much to read some more information on this issue. Will you post some more?

  2. Gerary White Says:

    The meaning of ISA is well stated in this post. The other content will be very helpful as long as the reader will be able to understand it.

  3. Samuel Akiona Says:

    Considerably, the article is in reality the best on this important matter. I concur with your results and will thirstily look forward to your approaching updates. Just saying thanks won’t just be sufficient, for the fantastic lucidity within your writing. I’ll instantly grab your rss feeds to keep abreast of any updates. Solid work and a lot of success in your online business venture!

  4. Kevin Greg Says:

    Hi, this article is really awesome and it help me to understand this EDI part perfectly.Really thanks a lot

  5. Don Vincent Says:

    I just happened to see this while searching for EDI standards and noticed the explanation of ISA_14.

    Please note that ISA_14 is for TA1 (interchange acknowledgement) and not really meant for 997.

  6. Cevin Says:

    I have worked with importing 850 orders and 862 shipping schedules into our system, as well as producing 856 advance shipping notices, and 810 invoices. I am working on importing 830 planning schedules, but I noticed that the major revision listed in ISA_12 is “00401″, but the version listed in GS_08 is “002000″. Shouldn’t the GS_08 be a more specific version of ISA_12? How big of an issue is this?

  7. Roy Says:

    Cevin,

    You are right on the money. In the ideal or perfect world, the GS_08 would have a more specific reference to the standard that is being used in the EDI document. So where the ISA_12 is 00401 indicating that the content of the document is between 4010 and 4019, the GS_08 ‘should’ specify which of these standards is used specifically. That is how the perfect world should be.

    But we don’t live there. In my experience some vendors don’t update and change the ISA_12 when the instigate a new standard. And so you can do a couple of things. If the software that you are using to transform the data and parse the EDI will allow you to use a 401x reference in the ISA and a 2000 reference in the GS, you can move on and do the transformation/parsing. Some EDI apps don’t like this. I have used one in the past where when this happened I had to request the Trading Partner to fix the problem.

    If your parser will put up with this, then you can move on to the parsing. I would start by checking to see if the contents of the document is really 2000. That would be my bet, but you will want to verify that by referring to the EDI usage spec provided, or by looking at key indicators like dates and such.

    So is this a BIG issue? Only if your parser won’t let you parse the document like this. Or if you want to push the issue.

    In any case, this is something that we see with EDI trading partners from time to time.

Leave a Reply