What is EDI?
EDI stands for “Electronic Data Interchange” It is a file based format that goes back before the modern Internet and our current concept of e-commerce. The problem that EDI was trying to solve was, “How do we get data from one system to another reliably, cheaply and in a common format?” These problems are still with us today, not because EDI didn’t provide a workable solution, but because it was not implemented on a wide scale. And because competing solutions also exist so that no one has a corner on the market of data formatting.
EDI is a file format
EDI is a file format that provides a standard of data format with the goal that an EDI file generated by one system will be deliverable to a second system, and that system will be able to read the data it needs from the file.
That may sound pretty basic. But in my experience if you put three developers in a room, you get 5 file formats. And the formats are workable, but none are the same. And some, not even close. The trouble this causes is two fold.
First, each new format brings with it the preconceptions and experience (or lack of) that the creator of the format has. This can cause problems as expected data may be missing or extraneous data included when the communication from this system with another is attempted. Also some transactional logic is implied in within the dataset.
Secondly, having a great diversity in the way data is presented means that the room for error is greatly increased. As form and content are dissimilar, converting something small like a date to a date time stamp introduces a bogus time stamp to make the format compliant. This small error in the data is generally acceptable, but as more are introduced, the potential for them impacting significant data increases.
This is where standardization enters the discussion. In the same way that proponents of cXML, ebXML, and other XML that pruports itself as a standard, EDI is a standard for handling data. As with reading left to right, top to bottom is our standard for writing(along with all of the grammes and punctuation rules) help us integrate this document, so do the electronic data standards help us interpret what those electronic documents mean.
EDI is a Data Structure
Where an EDI file contains data, the EDI standard contains Data Structures. Each EDI document type contains a structure for presenting a type of data in a logical fashion. This is part and parcel of the solution that EDI is providing. Structured data allows the receiver to scrape out the data that is important quickly. And this is not unique to the EDI standard, but it is a basic part of what EDI is.
When you unwrap an EDI file you can see that the data structure is roughly modelled after the paper that EDI is replacing. This is a plus in that systems that started out based on paper orders and invoices are easy to map to EDI. We also see systems that are not based on paper, and some times they have unique requirements that are not so easy to map. In any case, EDI has a stable and predictable strucuture that was designed around the flexibility needs of commercial transactions.
EDI is Business Conversation
There is an “I” in EDI, and it stands for Interchange. Without someone to send EDI files to, EDI has no purpose. When we discuss the ISA envelope there is a Sender and a Receiver. And just sending files to the partner is less useful of an EDI implementation than when the trading partner send files back in response. Here is an example:
- We get a conversation that starts with a Catalog (832) sent from the Vendor/Supplier.
- Then a Request for Quotation (840) from the Retailer.
- This is responded to with a Response to a Request for Quotation (843).
- Next a Purchase Order (850) is sent to the Supplier
- The Supplier Responds with a Purchase Order Acknowledgement (855)
- Later the Supplier sends an Advance Ship Notice (856)
- Finally the supplier sends an Invoice (810)
- And the Retailer sends an Remittance Advice (820) concluding the transaction.
- (unless there is a return …..)
All of these are not required, and there are others that could be included. But EDI with its set of document types, allows for a complex and information rich exchange of information so that the parties to a e-commerce transaction have the information to respond to each other appropriately.
EDI is a Solution
I have encountered many people who have a preferred data presentation format. They are evangelical about the superiority of cXML, or CSV, or even EDI. But in the long run an Integration Engineer should avoid having favourites. It is our job to be the interpretors for these formats. From time to time we will need to recommend one or the other for a specific task of implementation, but always rolling our eyes and cursing one format as the root of all our problems is never productive.
EDI provides solution to e-commerce problems. Getting business information to your partner in the transaction; cheaply, quickly and reliably, are key to the solution. By following the best practices of EDI or whatever solution that you have chosen will help you create this solution.
–
Looking for something else relating to EDI? Check out the EDI Primer post
–
