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.

Parts of the PO1

Here is a diagram of a sample PO1 segment:

Like any other segment in EDI, the PO1 segment is composed of elements.  Here is a list, element by element and what it contains.

Good Form on PO1 line

EDI in Good Form is both style and best practice tips to avoid common exceptions.  Paying attention to good form tips and best practices helps you create an integration solution that is not only complies to the standard, but functions to help you and your trading partner have an unnecessary support burden due to the avoidable unexpected.

1.  It is bad from to have PO1 Product and Service pairs that are empty.  This relates to not having any trailing element delimiters.  It also goes along with not having empty pairs in the line with populated Product and Service element pairs following.  Thus it is best to build your mapping so that optional data doesn’t create empty elements when it opts out.

2.  When reading a PO1 line, it is best to assume that an expected Product and Service value could be in any pair.  So the map needs to walk down the pairs of elements until it finds the qualifier that indicates the value you are looking for.  This allows you to use the same input map with multiple EDI producing trading partners that may have interpreted the priority of data in different ways, and avoid exceptions.

3.  When producing EDI with a PO1 line, it is best to be as consistent as possible with your placement of the Product and Service data.  Create your logic and mapping so that mandatory data occurs early in the PO1 line, and optional data is moved to the end.  This will keep your required data from hopping around positionally.  This will help your trading partners that may not have had the foresight to follow Good Form Tip number 2 from having exceptions that slow down you process.

PO1 Loop Segments

As we said in the beginning, the PO1 is a segment, and a loop/group. And as you may have noticed, there is data that you may need that is not covered in the elements available in the PO1 Segment that belong to the line item.  Values like Item Description, found in the PID segment. Or Tax information, found in the TAX and TXI segments.  These and other values are found on the line item, but are not on the PO1 segment.  We will have talk about some of these other segments and where to find other common data on another day.

In the context of delimited data files, an element is the contents between two delimiters.  Like in a spreadsheet, the element is the contents of a cell.  In EDI, we have delimited segments, and just like a delimited file, the contents between the delimiters is the element.

So in this segment “PO1*1*8*EA*10**SW*H11510.REF*CT*089480-00-B-0336~”, the 5th element or PO1_04 is “10″, while the 6th element or PO1_05 is empty.

Empty elements are not necessarily null.  Calling something null when the data type is know like an empty element can cause some data theory debates.  I don’t want to start one here, but may write about that philosophical discussion at a later time.

What types of elements are there?

What we are really talking about is the data type.  Each element in an EDI file has a specific data type defined.  Part Numbers are Alpha-Numeric which means that they may contain letters in the alphabet, and number in any mixture.  Where a price is not just a number, but is a currency.  Letters are not acceptable in the price field, so one can’t populate it with “N/A” in any case.

I won’t describe all of the data types here.  That is a discussion for some other time.  Most of the time these are fairly easy to work with, especially when you have samples to work from.  But there is another type of element.  This is the encoded value element.  This element does still contain a value, but it is in a code.

UOM or Unit Of Measure is the easiest to relate to, as it deals with something physical.  In the PO1 segment above, we find the UOM in the PO1_03 element.  In this case it means “each”  and by putting “EA” in this position we don’t have to type out “each” every time we just us EA as the abbreviation for this.

Why do we do this?  Well as I said the UOM is the easiest encoded element.  Some of the other encoded elements that are available define larger concepts.  Also, by having an encoded element, the EDI standard constrains the data to a rational type of data.

For instance, if you have an order response, we don’t want to have to process a free form response, we want to know if the product is accepted, back ordered or canceled.  And I want to know this in the same way for everyone.

What is Element Notation?

Elements are contained in segments.  The segment is referred to by the characters that preceded the first delimiter.  Each element in the segment has the name of the segment followed by its position in the segment.  Sometimes these are not separated, or they are separated by a space or underscore.  The position of the element is 0 based counting.  This means that the first position, the position preceding the first delimiter where the name of the segment is found, is position 0.

Thus in this segment, “N1^ST^Bill’s Grill^01^123456789~”, the N1 is N1_00.  I prefer the underscore to the space or no delimiter format for clarity.  But they are all used, so this would be the same as N101 and N1 01.  We use a two digit position designator even for positions less than 10 for clarity as well.  If there are any segments that develop more than 99 positions, there won’t be many.  And even fewer will ever be used.  And we don’t reduce it to just one digit, as N11 might actually exist, and that could cause confusion.

Now back to our example;  N1_01 is “ST”.  N1_02 is “Bill’s Grill” as so forth.

An example of how this is used is first found in our mapping rules that we need to write down.  And then in our notes and documentation.  If you wanted to say, “Whenever we have a ship to address for ‘Bill’s Grill’ we need to used the Duns number of ‘123456789′.”  We could say , “When N1_01 = ‘ST’ and N1_02 = ‘Bill’s Grill’ then N1_03 = ‘01′ and N1_04 = ‘123456789′.”  This way we are not leaving anything open to interpretation and clarity is our friend when writing rules for mapping and forming data.

You will see this used extensively in the mapping exercises here, and once you get the hang of using Element Notation, you will never write it any other way.

–

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

–