This post was updated to reflect current trends and information.
A technical introduction to EDI
Before I start explaining anything about EDI2XML, I would like to start by giving a more technical introduction to EDI, its usage and its history. EDI is an acronym for Electronic data Interchange. It has been around for a long time and has been used by retailers and private corporations in several verticals (health, retail, insurance…). When people in the business community talk about exchanging “EDI transactions“, they refer to a combination of the following:
- Structured EDI file format including version, revision, standard…
- Protocol of communication, medium and security (FTP, sFTP, AS2, VAN…)
- Business partners (vendors, retailers…)
Simply speaking, EDI is the process of “electronically” exchanging documents between business partners in a pre-defined format. The information is transmitted in a secured manner. Normally, files with EDI format are structured and follow “EDI standards”.
Following is the list of EDI standards widely used in the business community worldwide:
- UN-recommended UN/EDIFACT is the only international standard and is predominant outside of North America.
- US standard ANSI ASC X12 (X12) is predominant in North America.
- TRADACOMS standard predominant in the UK retail industry.
- ODETTE standard used within the European automotive industry
Read: What is a VAN ?
EDI has been evolving with different versions, revisions and sub-revisions. For example, in the X12 standard EDI format, I started my EDI career with the EDI version 3010. Today, we are working with much higher EDI versions such as 4010, 5010, 5020… It is important to note that within each one of the above versions, different revisions might exist.
EDI transactions and documents
Read: How does EDI2XML work ?
EDI documents are “number coded”; for example, a Purchase Order sent by a retailer to a vendor using EDI format is coded under the number “850”. The same applies for other documents such as 810 (for invoice), 856 (for Advance shipping notice), 820 (for Payment Advice), and 860 (for Retailer triggered Purchase Order Change). The list goes on and it is not limited to the above. For a more extensive list of EDI documents that EDI2XML supports, visit our EDI Document Library.
Each EDI document sent to a party has to be responded to by the other party by sending back a Functional Acknowledgment (FA 997). The 997 designates that the “structure” of the EDI file was certainly received, without looking at the “content” of the EDI formatted file. Both business partners understand the “content” of the information and they are able to translate into business terms. This is where EDI2XML comes into play to convert and translate the content and make it ready for integration.
To learn more about EDI, read our new blog “What is EDI (Electronic Data Interchange)?”