Although the use of EDI, or Electronic Data Interchange, is growing rapidly, it remains a mystery to many who are suddenly told that they need it.
The following information gives the prospective user of EDI greater insight into this technology. This support information skips most of the higher-level technical aspects, focusing more on the basics and process flow of EDI.
What is Electronic Data Interchange?
EDI is simply the sending and receiving of information using computer technology
Its efficiency has made it a condition of doing business in dozens of industries, including retail, grocery, warehousing, transportation (rail, ship, and trucking), health care, education, real estate, and government. Any standard business document that one company would exchange with another (such as a purchase order, invoice, shipping schedule, inventory inquiry, and claim submission) can be exchanged via EDI between two parties, or trading partners, as long as both have made the preparations.
EDI cannot be activated with a flip of the switch or in a moments notice. Many procedures must be carried out in preparation for exchanging EDI data with a trading partner. This will be explained in a later section.
The use of EDI is not limited by differences in companies or communication methods. Instead, EDI bridges the information gap that exists between companies using different computer systems.
Although this information makes many references to the ANSI X12 standards, note that other standards exist. For instance, EDIFACT is commonly used in Europe and in the automotive industry. HIPAA (Health Insurance Portability and Accountability Act) is designed for the healthcare industry.
Can’t I just use e-mail?
Although electronic mail is faster than standard mail and eliminates paper, it differs greatly from EDI because the data is in an unstructured format. If you were to get a purchase order as an e-mail, you would likely print out the document and enter the data into another program, such as an accounting or inventory package.
EDI is transmitted in a structured format, based on the use of message standards, which ensures that all participants use a common language. For instance, if you were to receive a PO via EDI, the EDI software would take the data and put it into a “readable format” then import it in your existing software. The result? No manual data entry! In addition, the process can be programmed to take place without human intervention.
Setting up EDI – Determining the most appropriate solution
Once the need is established, you have to determine what type of solution best suits your business. If you are exchanging only a few documents per week or month, you may find it more economical to use a service-based solution. If you anticipate exchanging a lot of documents with several trading partners, an in-house translator is likely to be more efficient.
Before you can determine which is the better approach, you need to project:
With how many companies do you anticipate exchange EDI?
What type of transactions do those companies require?
How often do you expect to hear from these companies? Throughout the day? Weekly? Quarterly?
In dealing with your trading partner(s), are you sending your transactions to a specific location or individual facilities?
Are you being asked to supply SSCC labels?
Do you want to interface directly with courier companies
Do you need integrated inventory counts and warehous management
Answers to these questions will enable you to select the most effective solution.
Getting the implementation guide
Whether you use a service based solution or in-house software, you will need to format the data to your trading partner’s specifications. The formatting process, called mapping, is usually a part of the technical support service offered by your software provider, and the guidelines for mapping are in your trading partner’s implementation guide.
Often the implementation guide contains a trading partner questionnaire, which needs to be filled out and returned as soon as possible. This is the first step in establishing a trading partner relationship.
Please note that even though all of your trading partners may be using X12 standards, EDI guidelines are not universal. The map created for Company A’s invoice cannot be copied and used for Company B, as Company B likely has its own criteria. As a result, you will need an implementation guide for every trading partner.
Setting up communications
One of the most important aspects of EDI is selecting how the data is going to get from one place to the other, such as through a VAN or using a direct communication. In the majority of the cases the trading partner will designate the method.
VAN (Value Added Network)
Often referred to as the “electronic post office”, a VAN is a third party service that transmits and stores data in the “electronic mailbox” until it is picked up by the appropriate party. Since the EDI message contains addressing information, the van routes the message to the mailbox of the recipient. Until recently, it was considered the most secure method of transferring data.
Unlike the VAN, a direct connection allows you to pass the data straight to the receiving party. Types of direct connection include VPN (Virtual Private Network), FTP (File Transfer Protocol), and EDIINT (EDI over the Internet). Usually EDIINT is done in conjunction with AS2 software, which encrypts the data before sending it over the Internet.
Installing the software
There are three parts to EDI solutions: the translator, the mapper and the scan pack or warehouse application. Installing each part is simple; however, each piece of software must be customized to fit your specific needs.
The mailbox receives and sends EDI messages between your company and your trading partners. This is like an email system, but the messages are not text messages, they are business documents like Purchase Orders, Product Catalogues, Shipment messsages, invoices and many more different types.
The translator is the engine behind the EDI process . It has several components, including the engine itself, the EDI maps, the standards, master file verification and communications ability. Data is formatted using a mapping, that organizes the infomration inside each message, so that both the EDI and the trading partner’s messages match. Maps contain the rules of the transaction; these rules will be enacted by the translator itself. Mapping also includes integration with an existing application. The EDI translator can be programmed to go into an application, extract information, and send it out as an EDI file. It can also import incoming data, thus eliminating the need for data entry. As said earlier, the mapping is often done as part of the EDI supplier’s technical support service.
Scan pack or warehouse application
The scan pack or warehouse application provides the necessary functionality to view Orders, review and change details and send return Order acknowledgements or change enquiries. The application allows the fullfillment of orders by printing picking lists, providing packing screens, to capture weights, volumnes and items per cartons/pallets. Also provided are warehouse scanners to assist with the pick and pack process, providing Scan pack. Also the printing of necessary SSCC labels, product barcode labels and other labes, that may be necessary for conforming to the shipment standards outlined by trading partners.
Final steps in the set-up process
The trading partner will send sample data, which is then mapped following the guidelines. The completed map is tested by sending sample data (which is now formatted) back to the trading partner. If it fails, the mapping error must be found and corrected. Upon successful testing the EDI partnership is ready to go live.
How does EDI work?
Let’s presume that a buyer is sending a purchase order to the supplier.
Most likely the information contained in the purchase order resides in a computer application (for example, an inventory package) on the buyer’s PC. As long as it is possible to import and export files from the application, pertinent information can be extracted and mapped into a file for the EDI translation software.
The EDI translator will do compliance checking to ensure that the mapping complies with EDI standards and the trading partner’s implementation guide. Afterward, it will translate the message into an EDI format.
A communications connection is established in order to transmit the EDI purchase order. The EDI translation software controls the communications software.
The file is sent to either a mailbox, FTP site, or directly to AS2 recipients to be picked up.
The computer software receiving the EDI purchase order will reformat the incoming data so that it can be readily imported into an existing application’s data files. For instance, a PO received via EDI could be input into the Order Entry module.
When the order is received, the software generates a Functional Acknowledgement back to the buyer. The FA indicates that the message was received and was/was not compliant with the EDI standard. It does not address the actual data in the message.