So it goes like this:

850 is a Purchase order, and is sent to the Vendor

855 is an Order Response, and is sent from the Vendor.  It confirms, updates or rejects each line, or the PO as a whole.

856 is the Ship Notice. and is sent from the Vendor.  It may contain one or more lines from one or more orders and can indicate shipment of partial lines from a PO.

810 is the Invoice, and is sent from the Vendor.  It contains one or more lines from one or more POs, but generally people keep these to only one PO.

820 is Remittance, and is sent to the Vendor.  It contains information relating to payment.

First you will need to have a Google Analytics account.  If you don’t have one, you might want to check it out.  Its free and you can sign up at http://www.google.com/analytics

As soon as you are ready with you Google Analytics account.  And you have told it that you want to monitor your site.  It will generate some code for you to place on every page that you want to monitor.  But don’t worry, Magento doesn’t need you to do much to accomplish this.  If you look at your accounts page, you will see something like this:

I have blurred out my domain and account, but what you will see in the red box, is the number that you will need to put into Magento.

So copy it to a text file or just leave the page up and go back to it when you need this number.

Now, go to your Admin page on your Magento installation.  You will need to go to System>configuration as shown below.

Once in configuration, you should find a set of navigation links on the left hand of the page.  In the “Sales” section you will find a “GoogleAPI” selection.

This will take you to the section with a Google Analytics control.

Expand the Google Analytics control and set Enabled to Yes.

Now here is where you type or past in your account number from the Google Analytics report page we saw at the top of this article.

Once you have typed it in, click on the “Save Config” button.

When you see this message, you are ready to go.

You might have to wait a few hours before the green check mark appears on the Google Analytics site.

If you have used a standards editor, you probably know what an SEF file is, or have used it.  Some applications and EAI even use SEF files as part of their document creation and validation processes.  It becomes useful to describe briefly what SEF files look like, and what type of information they contain.

What is in there?

If you are familiar with EDI, and have cracked open an SEF file with your standard text editor of choice, you will already know what I am about to say.  The contents of the SEF file don’t look that complex to someone who is used to and familiar with how various EDI files look.  For those that are not so brave, I will explain this painlessly.

First, the SEF file is really just a text file.  It can be edited by hand, but I don’t really recommend it.  (not because you can’t, but because it is tedious.)

Second, it contains its data in sections.  There is a section for doc types, segments, elements, and encoded data.  There is also a few housekeeping sections like version and name etc.

What is an SEF file for?

SEF stands for Standards Exchange Format.  This is literally a file format that was designed to contain information about EDI standards.  It was created so that a computer application could understand an EDI file.  It is used by some application like Standard Repositories and Standards Editors to allow us humans to deal with a standard like it was a text document.  While at the same time keeping a repository that can be used by an integration application to form and validate an EDI file.

If you are familiar with the concept of metadata then an SEF file is the EDI standard’s metadata.  If you are not familiar with metadata, then skip this part.

Do I need to know about SEF files and EDI?

Nope.  SEF is only useful if you are exchanging standards using the format.  If your standard and usage is in the form of a PDF or a spreadsheet, that is fine.  Many people do just that.

For me, I need to know this because I am trying to build some Standard Repository tools, and want to use the SEF format to manage them.

And for those that want a deeper look, I will be following this article with some deeper and more detailed articles dealing with the internals of the SEF file.

EDI Specifications

In the larger sense, the EDI specification is the set of rules that define each document type, the segments they contain, and the size and type of data in the elements.  When we talk about the EDI Standard Specification, we are talking about the whole set of valid EDI document types.  If something is valid EDI, then it complies with the EDI Standard Specification.  However, this large, all encompassing specification is not useful in coordinating the exchange of documents between two trading partners.

What goes in an EDI Usage Specification?

So we take EDI Standard Specification and we reduce it.  We remove the unused document types and the unused segments within the documents we will use.  And we even remove the unused elements and encoded values within the segments we will use.  At this point, we have created an EDI Usage Specification.  We can also add to the specification by including values that we need, like designating the an optional value or ID as required and specifying what type is should be.

How is an EDI specification Used?

Now that we have a usage specification we can use it to do to basic things.  First, it is the source of information for us to set-up our integration for our EDI document exchange.  And Second it is the format that we validate our EDI documents with to determine a valid transaction.

EDI Usage Specifications can be a source of data and integration documentation.  This can become extremely valuable when the choices and information about how your EDI interface works is recorded into the notes of the Usage Specification.

Beyond a visual validation of looking at the EDI file and comparing it with the specification, many times a specification can be found in the form of an SEF file.  The SEF file can be used in an EDI validation application.  This allows a potentially large and unwieldy EDI file to be scanned for compliance and accuracy.

There may be other uses, but these are the main two, integration data repository, tool for EDI validation.

EDI Specification Examples:

To walk through how a usage specification works, and is used, check out this review of BookNet Canada’s specification.

Then you can take a look at the EDI specifications published by Macy’sNet that they keep online to assist their trading partners in making and keeping effective integrations.

Sometimes we only use the EDI specification, they way we have always used them.  It can be instructive to browse the usage specifications of other companies.  We see what they remove, what they include, what comments they make, and what rules they document.  And seeing how others do things can help us to be more effective in how we use EDI specification documents.

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.

When businesses realize that the catalog data that they have may be worth as much as the products or services that they sell, they may be tempted to sell that instead.  Before they do, they need to think about who owns the data.

Lets say hypothetically that there is an integration tool that helps people that sell widgets, get widget pricing and data from people that make widgets. And this integration tool also helps people that sell widgets, place orders, and people who make widgets, invoice and collect payment from those that sell. The data that passes accross this integration tool is, in itself valuable to both the people that sell the widgets, and the people that buy widgets.

Other companies making widgets would be interested to know that there are people selling widgets that are getting shipping delays when they order from other widget makers. And people who sell widgets would like to know if there are people that make widgets cheaper than from those they are buying from.

But if I make widgets, I don’t want other widget makers to see what my prices are.   If I sell widgets, I don’t want other widget sellers to know what I am paying for my widgets. This information is something that makes me able to compete.  It is the type of information that the widget maker and seller want to own, and control when and if it is released.

But there is one person that knows all of this information about all of the widget makers and sellers.   That is the person that has access to the data of the integration tool.  It is also likely that the manufacturer and retailer have signed contracts about the disclosure of the information.  This information is confidential and can not be disclosed to other parties.

I was involved with one company that sold the information or information about it back to the manufacturers and retailers.  Since we had all of the data, we could easily report when there were discrepancies between orders, and shipments.  So we reported to the retailer patterns of  order anomalies they were having with all of their vendors.  We also reported catalog errors to the vendors so they could see what retailers continued to use bad or old part numbers.

And then the tricky part.  We convinced the vendors and retailers to let us have access to their data for “Industry Analytic”  products.  For this the information became abstracted so that no one could see information about a specific retailer or vendor.  But they could see industry trends or get a score card reports of a variety of metrics relating to their supply chain health.

This was a fun project to be a part of.  And the company I was with created whole new products and revenue streams.  But you don’t have to be a supply chain integration company to make use of data that you own.  If you have vendors here are a three questions that you can ask your database people to provide you with.

1. Order time to Fulfillment time.
2. Back Order or Out of Stock frequency.
3. Order Price to Invoice price accuracy.

And there are more questions to ask.  Asking them can help you to see places where your supply chain is leaky, and can help you start to leverage data that you own to improve your own bottom line.

There is a temptation to use this same validation in the production integration. But this would be a mistake. I’m not saying, “Don’t validate.” I highly encourage validation on both standard compliance and required data validation in mapping and integration. But to use the usage specification has a side effect that I witnessed once. (Only once.)

Validating Transactional EDI to Usage Specification

We had an integration requirement once that required that we only allow EDI elements that were in our usage specification. This was outside of our normal process and we all soon learned why.

When we validated EDI files based on the standard, we would error out documents that were corrupted, or in violation of the full EDi specification. (having mangled segments, or invalid UOMs and such.) But this one time, we thought it would be a good idea to also fail documents that had any extra data that we weren’t going to use. So we pulled all of the segments and elements out so that we were just down to what was in our usage specification.

This worked just like we told it to. As when the next file came in that was in bad form with extra trailing delimiters on the line item, it failed. And then the next with an extra segment that we didn’t care about? Well it failed too. As so on.

We soon were buried under failed EDI files that were valid EDI, and did contain the data we needed, but simply had something extra. And we were calling them all exceptions.

At first we added in a few of the common segments that were being sent. This relieved the lion’s share of the errors. But it still cropped up from time to time. Each time we would have failures for this reason we had to explain why. This grew tedious and embarrassing.

Eventually we re-mapped the doc-type using the complete standard in our validation. Magically all of these errors went away, and so did the embarrassing explanations.

Here is the way the process should work, generalized.

1. EDI envelop is validated against EDI standard.
2. EDI document is validated against EDI standard
3. Mission critical values are validated against Usage Specification.
4. File is processed.

What this does is to establish an inherent hierarchy of exceptions.  Transactions that fail on step 1 are all falling because the envelope is corrupt or  in error.  Also, Transactions that fail on step 2 are failing for a general EDI reason.  Both of these steps will have exceptions that can be handled by anyone with EDI knowledge.  Operational and Application rules don’t necessarily need to be known to understand how to handle errors at these levels.

Step 3 and 4 are exactly the opposite.  Errors that happen because of mission critical data that is missing or in error must be handled by someone that knows what the mission critical form is supposed to look like.  And files that pass validation but fail later in processing may need to be corrected and the validation process updated.  Or they may point to an error in the application itself.  In any case, much more knowledge of the whole process is required at these stages.

Take Away

First, by sharing this experience I hope that everyone can appreciate that sometimes requirements make us to funny things.  But I also wanted to share the approach to validation that I have found most helpful.  I have seen implementation that don’t do any EDI or Enveloping validation.  These are just as dangerous and frustrating as my experience.  But now all of the errors are pushed down to step 3 and 4.

I’d also like to invite you to subscribe to my newsletter.  It comes out once a month, starting at the end of this month.  I’ve got some great ideas for it, and think it will be terrific.

One of the things that in invaluable is the ability to share your standard documentation both internally and externally.  EDISIM is a tool that has allowed me to do that.  They produce a very professional looking document for external consumption and the standard is exportable so that everyone using EDISIM can share the same standards file in a format called SEF.

Features of a Good Standards Reference

Navigate Standards (multiple versions, doctypes, segments, etc)

A Standards Reference needs to offer a navigation interface of some kind.  You need to be able to see the versions,  standards and document types.  You will also want to drill in and view the reference outside of the document types, and  browse the segments or data element definitions.  But at the core, you need to be able to see a graphical representation of the standard, view the format and see the structure of how data will be represented in the EDI format and document.

Edit Standards

Just browsing the standard is not going to get the job done.  You need to be able to make alteration so that you don’t just have the high level X12 standard, like the book on my desk, but can make a standard that is your usage specification.  This means you will need to be able to do two operations on the standard.

First you will need to make changes to what elements and segments are displayed, and make changes to the encoded values that these elements support.  Editing these structures will aid you when you use the standard to validate and check for compliance based on your usage specification, and when creating documents to share and publish.

Second you will be able to add some of your business rules documentation to clarify the default definition of the standard.  This is especially useful if you need to pass some data that uses a mutually defined qualifier.  This lets you define what the “mutually defined” value should be.  This again helps when you publish and share your standard.

Export and Import (Read SEF)

All of the standards references that I have used had the ability to import and export a standard in an SEF file format.  SEF or “Standard Exchange Format” is a file that holds the standard dictionary and format for EDI files.  This is a nice way to  not only transfer and store the standard your company uses so that everyone has a copy of the same usage implementation.  But if no proprietary information is stored in the notes, it can be sent to trading partners out side of the company to aid in their integration efforts.  Any other export and import is a bonus, but SEF is a requirement..

Print (export to doc or pdf, or printer)

In spite of all this paperlessness, some times we still need to print things out.  Printing to a pdf or printing to paper is useful when sharing the standard and usage specification in a non-editable format so that others can view it, and make use of the information.  So for managers, or clients, or other parties that only need a viewable format to follow, this feature is a must have.

Save as editable file (RTF or other.)

Ok, just like printing, sometimes companies want all of their documentation to look the same.  To facilitate this, it is nice to be able to save the specification out to a rtf, or doc, and then add the company header, logo, watermark, etc.  This allows you to take the standards reference and really own the edits and notes that you have added.  For companies that have extensive documentation processes, this feature is a must have.

Other Good Reference Features

Validation

Validation is not a feature of an EDI standards reference, but it is a good tool that sometimes comes with them.  Validation tools read and EDI file, and compare the contents with the standard.  They should then identify all of the errors they can see and report on them.

In my experience validations may need to be run repeatedly as some errors in an EDI file will mask following errors.  For instance, if  the N1 segment is wrong, the validator may not be able to tell if all of the other lines in the N1 loop are valid.  So when I validate an EDI file, I correct the errors seen on the first pass and re-validate.  This has saved me from telling a trading partner to fix an issue, only to have to tell them about another issue later.  After all, we do want our integrations to go quickly.

Test Data

Sometimes looking at the standard is just not enough to show us how things will look when formed into the document.  Seeing sample data is essential, and one of the first things I request at the beginning of any integration project.  A Standards Reference will sometimes have tools that will create a test data EDI file based on the standard.  This can be useful if you are working with a new document type that you haven’t encountered before and need to see how the standard looks in the formed document.

Evaluation of Standards Reference Technologies

Is there a feature that I have missed?  Please let me know.  Also,what EDI standards reference tools have you used?  What do you like or dislike about them?  How about any non-EDI specific tools?  Please let me know what you have used.  I would like to compile a list of tools and run some comparisons of what is out there.

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

Amazon.com Widgets

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*AN* 3920943*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 a backslach (\) followed by “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/ 2 http://www.theintegrationengineer.com/edi-elements/?utm_source=rss&utm_medium=rss&utm_campaign=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

–

The goal of EDI was to provide a way to support communications between dissimilar computer systems.  EDI was intended as a light weight, reliable means to transmit data. By today’s standards, EDI may not seem that easy, open and light weight.  But if you realize that at the time it was being developed some of the things we take for granted, like IP addresses, and Domain Name Systems were on the drawing board, or not really understood or used.

Data Dictionary

One of the ways that EDI saved space and enforced consistency was to use encoded values.  Using the UOM list is easy to understand.  And it really hasn’t changed that much.  But there were also encoded values for things like the type of address or the type of financial transaction.  Basically there are more variations of these today, than there were at the time of EDI’s birth.

Now this is not to say you can’t used something that the standard builders didn’t think of.  There is a common wild card value for almost all of the encoded value fields.  That is ZZ (note that if the length is 1 or 4 or any length, then it is the number of ‘Z’ characters to fill the required space).  ZZ is a value for ‘Mutually Defined’.  Meaning, “the standard doesn’t have this, but I expect the receiver to understand what this is.”

But just using that all of the time would reduce the value of the standard.  So you may have used ZZ to list an address type that the 3030 standard doesn’t support, but the 4010 standard has it now, and we should used that when we build a 4010 document.  The creation of a Data Dictionary not only reduced the size of the EDI file, but also helped enforce the usage of common concepts.

Syntax

Both the size and order of the segments has changed from the earliest versions of EDI.  Segments were only created as long as was thought needed to contain the pertinent data.  Segments that related to contact information defined in the era where you might have a fax number in addition to your office number, just doesn’t have the space for your cell phone.  And the line item definition may not have enough space now that you might want to include the UNSPC number that didn’t exist then.  So the segments have grown, and some orders have changed to allow for better representation of the data.

Objects Being Represented.

Back in the beginning, EDI was representing paper objects.  So when people mapped from EDI, or talked about EDI, their brains didn’t go far from the idea of what the paper order or invoice, or status would look like.  But very quickly, younger minds started to represent data as just data.  No longer tied to the paper order form, or other physical media, data began to take on characteristics of the real data, and real objects that the paper was describing.

EDI has been slow follow this completely.  Backward computability is a good excuse, but mostly it seems that the established syntax was flexible enough that new things can be represented.  This is a double edged discussion, and we will leave it with this.  As the nature of e-commerce evolved, EDI formats changed to follow the evolution.

Summary

EDI is a collection of standards and versions.  As time has moved forward, the nature of our e-commerce needs have changed.  EDI has changed too, but instead of letting working standards become obsolete, a new version of the standard is published.  These standards implemented incremental changes in the Data Dictionary, Syntax and Objective Representation of the E-Commerce transactions.

–

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

–

EDI is a standard, and having standards in e-commerce or any type of integration, is important in achieving success in your integration efforts.  I found this old video of Bill Gates talking about this very topic, and I decided to share it here.

Bill Gates is speaking in 1998, and mentions the need for standards like EDI in conduction e-commerce.  “Creating those standards…make information move easily…”  “So standards are becoming more important.

Bill and I don’t pal around or anything, and I am not a big fan of Biz Talk, but what he says in this clip supports some of the things that I support here.  Standards make e-commerce communication better.  EDI is a foundation level standard that we should draw from, so understanding what EDI is, becomes important as well.

–

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

Files are called “Flat Files” when they contain a single data structure.  Generally this structure is the column and row structure like a spreadsheet or table, but a file in binary or encrypted with a single encryption key could also be called a flat file.  Files that are not flat; marked up files like XML or HTML, EDI files, other formats like HL7 or SEF files and others.  Here I am going to briefly discuss two flat file types; Delimited Files, and Fixed Width Files.

What is a Delimited File?

Ok, to describe it briefly, a delimited file is a file where the data is organized in rows and columns.  Each row has a set of data, and each column has a type of data.  If it sounds like I am describing a spreadsheet, you are right on the money.  To make the column, each row has the columns separated with a character called a delimiter.  See the example below.

Tables of data and spreadsheets are both similar to a delimited file in the way they organize data.  In the delimited file all of the empty space, or white space is removed.  What we see here is a classic example of exporting a spreadsheet table as a comma delimited file.  In theory, this data can be imported by any other application that can read a delimited file.

Believe it of not, a space is a character, and takes up space in a file.  Back in the day people went out of their way to save space so that files could be send over slow modem connections.

What is a Fixed Width File?

There is another type of file, is is called a Fixed Width or Fixed Position file.  It is different from a delimited file in that the data fields are defined by the character position.  See the example below.

In a fixed width file, the delimiter characters are eliminated.  If the data is formulated such that the data fields are the same size, this format can be more compact than a delimited file. You can see here that we know the size of the Birthdate data, so we eliminate all the spaces between the Bdate and Department fields.  If all of the data was formatted for size like this, we could really make this file small, so that it only contains the data.

We also eliminate the pesky problem of delimiters found in data.  The issue of a comma delimited file containing a field that has a comma in the data.  How does the parser know that this comma is not really a delimiter, but is part of the data?  Anyway, that problem is eliminated in a fixed width file.

Comparison

This is not a contest of which format is superior.  Both file architectures are useful and both are used commonly enough that you need to be at ease working with both.  Delimited files are really easy to work with as long as your data is clean of the delimiter character.  Doing quick integration of data common in ETL tasks, delimited files are far more common that Fixed Width.  Continuous operations of data integration and importation many times find that Fixed Width or Position files are more reliable for the unattended operation, even ETL if it is unattended.

As with many things in integration work, we want to pick the best option.  Knowing and working with both fixed and delimited files will help you determine which is the right choice for the task you have before you.

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

–