Print this page

Estimated reading time: 3 minutes, 5 seconds

Am I doing EDI correctly?

correct processHaving worked in the EDI field for more than 20 years, and specifically as a consultant for nearly 10 years, this is an unasked question at many of the places I've contracted and, as so many other questions in business, the answer is a resounding “maybe”.  Many executives believe that they're doing EDI simply because they have an EDI tool in their IT department and they're exchanging data with some of their customers/suppliers.  Ofttimes their customers/suppliers do not agree... this is often, but not always, because the data being exchanged is not in the "standard" format.

The commonly accepted definition of EDI normally goes something like this: EDI is "the electronic exchange of business-to-business documents in a standardized, machine processable format."  There are “generally accepted” national/international standards such as X12 and EDIFACT and there are subsets of these standards that are (usually) industry-specific, such as VICS (Voluntary Interindustry Commerce Solutions – retail) and HIPAA (government mandated Health Care standards).  These types of document exchange standards are what is normally called EDI.

EDI is also frequently distinguished from XML (eXtended Markup Language) and pundits have been declaring the demise of EDI for years claiming that XML will replace EDI, however does XML not also meet the definition of machine processable?  Is it not also exchanged electronically?  The only “unmet” qualification is that the data is not in a recognized standard.  XML structures can be defined differently from one customer/supplier to another… even when both are starting with the same type of document (invoice, purchase order, ship notice, etc.) But then, is that not also possibly within the “generally accepted” standards?  This is the very reason that many large EDI “hubs” produce their own implementation guides… “This is how we implement this transaction set.”

Next up is the issue of “proprietary data formats.”  (Flat files, XML files, EXCEL™ files, etc.)  As long as you and your trading partner can agree on the format and the use of the data, and the data can be processed automatically on both ends of the exchange, does that not also mean the data is “standard” , albeit for a small group of implementers?  Again, is this data not also being exchanged electronically?

As far as communications are concerned, whether you’re using a VAN (Value Added Network), FTP, AS2, HTTP, email or something else, as long as you can automate the system and reliably get the data to/from your trading partner, you meet the qualification for electronic data interchange.

In short, if you are exchanging documents with your trading partner electronically, you are “doing EDI”… even if you’re not doing “standard EDI”. 

Are you using your EDI tool efficiently is another question… one that is best answered by someone who’s been working with EDI for a while.  If you do not have such a person on-site, or you are unsure of the qualifications of your EDI personnel, it could behoove you to check with a qualified consultant to find out… you might find that there are ways to improve your business processing flow that can result in substantial savings to your company… if not, you may find that your EDI personnel are more of a value to your company than you realized.  At the very least, ask your EDI personnel if they can think of any ways to improve processing or cross functional boundaries to be able to expand your EDI processing.  If you’re only using EDI to process outgoing purchase orders, consider expanding into receiving invoices, sending payment notices, sending shipping notices, etc.  The value of EDI is best appreciated when implemented across-the-board.
Read 8407 times
Rate this item
(0 votes)