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.

What is a line item?

A line item is a group of data and its structure that is or can be repeated multiple times in its document.  It holds the data that is the focus of the document, and a part of a document or transaction that contains distinct part that can stand alone.  For instance, an order that has two line items could be split into two orders that would be able to be filled separately.  It does not necessarily contain information that can be applied to a group of items, although sometimes this information is included.  This feeds into what type of data that a line item contains.

What type of data does a line item contain contain?

In a purchase order, or other commerce related document these pieces of data will be found in the line item:

1. Purpose of line
2. Product or Service ID
3. Quantity
4. Unit of Measure
5. Price or Fee
6. Taxes
7. Special Handling
8. Descriptions

Some additional data can be aggregated to the document level or published at the line item level;

1. Ship to or Deliver to data.
2. Discounts
3. Shipping methods or tracking information

Where in EDI does this data go?

For the most part, the PO1 segment and group contain the line item data.  There are a few transactions that use another segment.  The invoice for instance uses the IT1 segment.  Depending on the scope of our definition, an HL group could be a line item in some documents.

Line items are at the center of our transactions.  Purchase Orders, Invoices, and Catalogs would not be worth creating without the line items they contain.

Parts of ACK

Here is a diagram of a sample ACK segment:

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

Best Practices

With the ACK the best practices are more in how to implement and what to expect.  So here are some things to remember when implementing this segment.

1. An ACK is part of a PO1 line for a response to another PO1 line transaction.  This segment supplies a status, and can modify the line item contents.
2. There can be more than one ACK segment for a line item.  (4010 855s allow 104 repetitions of the ACK)
3. When an ACK explicitly changes the line item it can only change that one type.
4. There is a status called Accepted With Changes.  “AC”  For this, you will need to parse the ACK and see if any of the values have changed.

Parts of IT1

Here is a diagram of a sample IT1 segment.

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

I wrote a section on Line Item Good Form and Best Practices in the article about PO1 Line Items.  Instead of repeating that I will just let you hop over there are read it.

IT1 Loop Segments

As we said in the beginning, the IT1 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 IT1 Segment that belong to the line item.  Values like Tax information, found in the TAX and TXI segments.  These and other values are found on the line item, but are not on the IT1 segment.

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.

EDI is not a flat file, but it does have repeated lines or segments.  Some times this repetition comes in groups and sometimes its just a line that get repeated in part of the document.  Repeating structured data is fundamental to EDI, but can become difficult to interpret at times.  Understanding the types of repeating structures and when and where they may occur can save a lot of time.

Repetition

There are three kinds of loops/repeated segments; First there is a simple segment that can appear more than once.  Lets call this a Repeating Segment.  Second there is a group of segments that appear together, and may repeat.  Lets call this a Repeating Group.  And finally there is a segment or group that repeats within a beginning and ending loop envelope.  Lets call this a Repeating Envelop.

Repeating Segments

A repeating segment is pretty much just what it sounds like, a segment that may occur more than one time.  A good example of this would be the AMT segment.  The AMT is a segment that contains a monetary value.  The AMT_01 declares what type of value it is, and the AMT_02 has the amount of money.  In an EDI document like an invoice, we may need to have many values, subtotals, taxes, base price, and so on.  Having a repeating segment lets us put all of these values on their own independent segment to be interpreted and included as best fits the Trading Partners and the nature of the transaction.

Here is an example of an unwrapped N1 group where the N3 is repeated:

N1*AC*ARTHUR JONES*1*9012345918341*11*SE~
N2*GEORGE WASHINGTON~
N3*157 WEST 57TH STREET~
N3*Suite 2001*5th Floor~
N4*CINCINNATI*OH*43017~

When segments are repeatable, they are indicated with a “Max Use” value of greater than one in the standards and usage specification.  In the N1 Group, the N2 and N3 segments may have a max use of 2.

Repeating Groups

A repeating group is also what it sounds like.  It is a group of segments that work together and get repeated.  This loop is generally referred to by the primary segment.  This segment is required in this group.  This means that if this group occurs, this segment must also occur.

Most Repeating Groups are contextual.  This means that they are defined by the segments that surround them, and are terminated by the first segment that is not in the group, or starting the group again.  So a Repeating Group may repeat, but as soon as we move out of the segments in this group, we are done repeating it and move on to the next segments or groups defined in the standard.

The N1 is a good example.  The N1 group contains name, address and contact related information.  The only required segment is the N1.  Subordinate to the N1 (that contains name and such) is the N2 (that contains secondary name or attention type data.) Then comes the N3 (with the street address) and then the N4 (with the city, state, country, zip).

Not all groups have the same letters, like ‘N’ and the N1 group is no different.  It also contains the PER segment that contains a persons name, and contact info like phone number or email.  Any PER that happens under an N1 is for that location.

In a document like an order you may want to have the address and contact for the shipper, the receiver, a biller, and a payer.  There are many possibilities, and these are all repeated in this group. Here is an example of an unwrapped N1 group where the that is repeated:

N1*ST*MRS JONES*1*123456789*11*SE~
N2*BEVERLY SIMPSON~
N3*157 WEST 57TH STREET~
N4*CINCINNATI*OH*43017~
N1*SF*MR JONES*1*9012345918341*11*SE~
N2*MAGGIE MCGILLICUTTY~
N3*1001 MAPLE STREET~
N4*PITTSBURGH*PA*86753~

Segments that are in a repeating group are listed as being in a Loop.  They may be repeated whenever the loop is repeated as specified in the standards and usage specification.  Thus you may have a max use of the N3 as 2, and an N1 Loop that has a max use of 1000.  So really you could see 2000 N3 segments, (2 for each of the 1000 possible N1 loops).

Repeating Envelope

A repeating envelope makes reference to EDI Enveloping.  Basically, the ISA-IEA envelope can contain one or more GS-GE envelopes.  And each GS-GE can contain more than one ST-SE envelope.  These levels of enveloping are covered in greater detail on the EDI Enveloping page.  But it doesn’t have to stop there.  In the 3050 850 document there is a loop called LS-LE that contains terms.  This section happens inside the ST-SE.  And there is nothing to prevent other sub envelops from happening where there is a need.

What is fundamental to these types of loops is that they have a designated beginning, and ending.  They must have both.  Repeating Groups end when a beginning of a new iteration of the loop is found, or a segment that is not in the group is found.  This can leave some ambiguity if the standard is not followed closely.  The Repeating Envelope leaves nothing to chance and declares that it is done.

A note about Required segments

You may have noticed in the examples above or in the specification that we referenced that there are required segments in loops that are optional.  This is not a contradiction and I will explain this here.  A loop may be optional.  If it is, then it may be ommitted entirely from a document while still compliant with the standard.  If the loop is included, then the required and optional segments within that loop apply.  And they apply in each instance of the loop.  (We can’t have an second N1 loop unless we include the required N1 segment.)

Basically this is like scope in XML.  The requirements of mandatory or optional only apply within the scope of the loop where they are defines. in the same fashion as sub nodes in and XML hierarchy.

Basic Fundamentals to Remember

1. Some segments can occur more than once, or can be repeated.
2. Some groups of segments can and often do occur more than once.  These are contextual and are terminated by segments after the group in the standard.
3. Some segments are encapsulated in beginning and ending segments like enveloping.  These segments can repeat, but only in another encapsulation or envelope.
4. The standard will indicate when repetition is allowed.

–

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

–

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

Wrapped

As I said wrapped EDI has nothing between the segment terminator and the next segment, in this format;

SEG|||~SEG||||||~

and so on.  Wrapped EDI looks like this:

ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *090508*1459*U*00200*000000001*0*T*:~GS*PO*901234572000*908887732000*090508*1459*1*T*004010~ST*850*0001~BEG*01*BK*99AKDF9DAL393*39483920193843*20090508*AN3920943*AC*IBM*02*AE*02*BA~DTM*002*20090508*1615*CT*CM*DATE TIME PERIOD~N1*AC*ARTHUR JONES*1*9012345918341*11*SE~N2*MAGGIE MCGILLICUTTY*BEVERLY SIMPSON~N3*PO BOX 123*157 WEST 57TH STREET~N4*CINCINNATI*OH*43017*US*IP*02535~PER*AC*ARTHUR JONES*TE*(614)555-1212*TE*(614)555-1212*TE*(614)555-1212*ADDL CONTACT DESC~PO1*AAA849*100*DP*100.00*PD*AB*ASSEMBLY*BL*BRAND OR LABEL*ON*CUST12345*AB*ASSEMBLY*BL*BRAND OR LABEL*ON*CUST12345*AB*ASSEMBLY*BL*BRAND OR LABEL*ON*CUST12345*AB*ASSEMBLY~PID*F*BC*AX*UNSCENTED*GENERAL PURPOSE*BS*SUBQUALIFIER*N*ENG~CTT*10*855*12345678*HB*40*QD*GENERAL PURPOSE~SE*12*0001~GE*1*1~IEA*1*000000001~

Unwrapped

When we unwrap the EDI, we don’t just place any character between the segment terminator and the next segment, we place a carriage return and line feed.  This makes all of the segments appear to be justified like separate lines of a text file.  Thus the format is changed in this manner;

SEG|||~

SEG||||||~

and so on.  Unwrapped EDI looks like this:

ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *090508*1459*U*00200*000000001*0*T*:~
GS*PO*901234572000*908887732000*090508*1459*1*T*004010~
ST*850*0001~
BEG*01*BK*99AKDF9DAL393*39483920193843*20090508*AN3920943*AC*IBM*02*AE*02*BA~
DTM*002*20090508*1615*CT*CM*DATE TIME PERIOD~
N1*AC*ARTHUR JONES*1*9012345918341*11*SE~
N2*MAGGIE MCGILLICUTTY*BEVERLY SIMPSON~
N3*PO BOX 123*157 WEST 57TH STREET~
N4*CINCINNATI*OH*43017*US*IP*02535~
PER*AC*ARTHUR JONES*TE*(614)555-1212*TE*(614)555-1212*TE*(614)555-1212*ADDL CONTACT DESC~
PO1*AAA849*100*DP*100.00*PD*AB*ASSEMBLY*BL*BRAND OR LABEL*ON*CUST12345*AB*ASSEMBLY*BL*BRAND OR LABEL*ON*CUST12345*AB*ASSEMBLY*BL*BRAND OR LABEL*ON*CUST12345*AB*ASSEMBLY~
PID*F*BC*AX*UNSCENTED*GENERAL PURPOSE*BS*SUBQUALIFIER*N*ENG~
CTT*10*855*12345678*HB*40*QD*GENERAL PURPOSE~
SE*12*0001~
GE*1*1~
IEA*1*000000001~

Converting from Wrapped to Unwrapped and back

When you need to do this, you need to do this fast, not manually.  Sure the manual way works with small files, but if you are trying to edit a big invoice or order, you will want to do something snappier than walking through the file segment at a time.  Here are two ways to do it with common tools.

VI

To unwrap:

1. open the file.  Type “vi [file name]“
2. Hit “:” to get the command prompt
3. Type “%” to do a every line replace. (may not be needed as this is wrapped, but it doesn’t hurt.)
4. Type “s” for a substitution.
5. Type “/” to begin the string to find.  (you may need to escape characters like ~ and | with a \.  I will show this in the example)
6. Type the delimiter to be replaced.
7. Type “/” to begin the replaced string (again with the possible need to escape characters.)
8. Type the delimiter again, as we don’t want to lose it, then follow it will a [crtl]+v and [crtl]+m
9. Type “/” to end the substitution
10. Type “g” to make it global or indicating all of the instances not just the first one.

It looks like this:  “%s/[delimiter]/[delimiter]^M/g”

Put another way, here is what I typed for our example:  “%s/\~/\~^M/g”  (notice that I am escaping the ~ with a \)

To re-wrap:

1. open the file.  Type “vi [file name]“
2. Hit “:” to get the command prompt
3. Type “%” to do a every line replace. (may not be needed as this is wrapped, but it doesn’t hurt.)
4. Type “s” for a substitution.
5. Type “/” to begin the string to find.  (you may need to escape characters like ~ and | with a \.  I will show this in the example)
6. Type “\n” to designate the newlines.
7. Type “/” to begin the replaced string (again with the possible need to escape characters.)
8. Type “//” to begin and end the substitution.
9. Type “g” so that it will get any multiples of the newline.

It looks like this: “%s/\n//g”

MS Word

To Unwrap:

1. Open file.
2. Select Edit>Replace or press [ctrl]+h
3. In the “Find what” field insert the delimiter.
4. In the “Replace with” field insert the delimiter, and then click on the “More” button on the bottom of the control.
5. In more, there is another button called “Special”  Click on this button and select “Manual Line Break”
6. Click replace all and the EDI will unwrap.

To re-wrap:

1. Open file.
2. Select Edit>Replace or press [ctrl]+h
3. In the “Find what” field click on the “More” button on the bottom of the control.
4. In more, there is another button called “Special”  Click on this button and select “Manual Line Break”
5. Don’t put anything in the  “Replace with” field.
6. Click replace all and the EDI will re-wrap.

Other Tools:

There are lots of other tools that can do the search and replace with newlines, these are only two ways.  If you have one that you would like to share, please let me know.

—

Looking for something else relating to EDI?  Try here.

]]> http://www.theintegrationengineer.com/edi-wrapped-and-unwrapped/feed/ 0 http://www.theintegrationengineer.com/edi-elements/ http://www.theintegrationengineer.com/edi-elements/#comments Tue, 13 Jan 2009 16:44:18 +0000 Roy http://www.theintegrationengineer.com/?p=59 What is an Element?

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

–

Eliminate trailing delimiters.

When EDI was first created, modems were much slower, and high speed internet and Wi-Fi didn’t exist.  Moving large, verbose files over a network took time, and e-commerce solutions charged by the kilo-character.  This means that having unneeded characters cost money.

EDI, in good form tries to eliminate extra characters.

The rule is to keep your segments as compact as possible by eliminating optional trailing data elements.

Choosing Effective Delimiters

It is illegal to have a delimiter as part of the data in any data field.  There is no escape character that will allow it.  That being said, many systems will allow EDI that breaks this rule to be formed, as it does not harm the system sending the message.

However, it becomes impossible for the receiver to read the message properly.  (I know that some of you have encountered and scripted solutions for this type of thing, but this is about good form, not work-a-rounds for bad form.)  If you are lucky, this violation only errors out of translation.  If you are not so lucky, the translation succeeds and you have corrupt  data in your system.

The rule is to select delimiters that will never appear in your output data.

Avoid Unnecessary Repetition

Some segments can be found in multiple locations in an EDI document.  This allows for a flexible and context sensitive usage of segments and data.

Lets take the N1 segment and group for example.  In a shipping notice you can use the N1 in the header section before any of the line items, but you can also use it in the line level.  This gives you power to specify specific shipping locations for the line.

This is great if each line is going to a different locations, but if most of the time this means that the N1 group repeats the same information over and over, then we are wasting space and are not in good form.  It would be best if we place as much information where it will only be displayed once if it is the same.  And in our shipping example, we can specify that N1 only appears in the line if and when there is an overriding shipping locations.  (this is where having effective usage specs comes in handy.)

The rule is to avoid repetition of any data that can be represented in a non-repeating structure.

Remove Excess White Space

Just like any other character spaces take up room in the file.  Outside of the ISA segment, no EDI fields should contain leading or trailing white space.

The rule is to trim or remove any whites space in an EDI field.

Send EDI in Wrapped form

When EDI is wrapped it looks like one continuous line of text characters.  When EDI is unwrapped each line appears on its own line.  Normally people do this by inserting carriage returns and line feeds after each segment delimiter.  Humans have an easier time reading an unwrapped EDI files.  So in most of the examples of EDI that I use here are unwrapped EDI.

Wrapped and unwrapped EDI are both EDI and most parsers don’t have a problem with either one.  But line feeds and carriage returns are characters and take up space.  And because in good form EDI eliminates excess characters, these should be eliminated as well.

The rule is, always transmit wrapped EDI.

Some people try to have the best of both worlds and try to use a line feed as a segment delimiters.  This is a bad idea.  First, delimiters are supposed to be a single character, second, different operation systems treat these characters differently.  And some systems pre process files and remove carriage returns and line feeds.  Basically, its not a nice way to do it and will eventually cause someone trouble.

What all these rules have in common?

What all of these rules have in common is saving space.  Creating EDI that uses extra or unnecessary characters is bad form.

–

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

–

The segment is what makes an EDI file an EDI file.  They are at the very heart of EDI.  There are hundreds of different types of segments and each holds a different type of data.

N1^BT^Bill Gates^01^123456789~

For instance the ‘N1′ segments holds some common data that is used in many EDI documents.  First, the ‘N1′ type.  This is the name type.  The first elements following is the qualifier for the second field.  If this is were an invoice it might be the code ‘BT’ indicating that the value in the second field is the name of the “Bill To’ party, in this case ‘Bill Gates’.  Following the name is another qualifier that determines the type of the account number in the fourth filed.  In this case we will use the DUNS Number, and so on.  We stop now with the segment terminator to indicate to the parser that the next character will start a new segment.

What are Segments?

In EDI a segment occupies the space from the character directly following a segment delimiter, to and including the next segment delimiter.

How are segments used?

By using segments, EDI files are able to represent data in a compact, logical arraignment.  Parsing out the data is just a function of recognizing the pertinent segments and reading the data.  As a rule of thumb, segments should only be as long as the data they contain.  So even if there are 10 possible elements in the segment, if we only have data in 4, we terminate the segment there.  We discuss that further in the Good Form section.  This PO1 segment illustrates the salient points.

PO1^1^100^EA^100.00^^VN^A-1234~

The PO1 line in the specification for 4010 can have 25 elements, but we only have the basic required elements and one set of the identifiers.  This only takes us to the 7th element.  The remaining 18 elements are not needed, and so are not included.

Also of note is the PO1_5.  This element is optional, so there is no data there.  But because we are using elements after it, it must be present, even if empty, to keep the position of the elements that come after it.

Summary

Segments in EDI don’t just occur randomly.  There are some segments, those involved in enveloping, that have a mandated location across all EDI files.  Each type of EDI document has a logical order that segments are to follow.  A shipping notice will have an defined set of segments and order of segments.  Some will be required, and some will be optional, and some will be conditional on other segments.  An invoice on the other hand will have a different defined set of segments, some will be in common, and some will be unique to those of the shipping notice.  We will see this illustrated in the mapping exercised that use EDI formats.

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

]]> http://www.theintegrationengineer.com/edi-segments/feed/ 0