Why are there more than one version of EDI?
When EDI was born, (in the 1970s), the committee did its best adopt a forward thinking plan and architecture. But there was really no way for people living before the birth of e-mail to make place for what we use today to do business. So the early versions of EDI had no place for e-mail addresses, and other things that we use in e-commerce today.
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
–
Subscribe to "The Integration Engineer" by Email
Find out about the tools and services available at The Integration Engineer's Consulting site.
