What is EDI: Understanding the Main Document Exchange Technology

Every decade has its own buzzwords. As we’re gradually leaving the 2010s behind, we’re saying goodbye to gluten-free, viral, and growth hacking screaming at us from headlines. The workforce of the 80s should remember one of the trendy phrases of that time - paperless office. When computers with video displays started popping up in the offices, people eagerly embraced digital documentation - to save time, money, and simply space. Lots of new ways of electronic communication sprung up.

Among them was EDI. Electronic Data Interchange passed the task of exchanging corporate documents from humans to machines. Strict, universal, and error-prone, EDI was introduced in the transportation sector to be later adopted in all industries dealing with hundreds of documents and receipts.

What is EDI and how it works

Electronic Data Interchange or EDI is a method of exchanging strictly formatted digital messages between computers. It’s often called “one step ahead of paper.” Yes, in the era of unlocking smartphones with our faces, we still use technology that was considered an innovation 30 years ago. However, it’s far from getting replaced. EDI is so convenient and universal that EDI systems are mandatory at most healthcare organizations, universities, retail brands, and construction organizations in the US.

Now, let’s break the definition down and examine what it actually means.

Exchanging - using a private, agreed-on communication channel.

Strictly formatted - translating in-house documents into standard formats.

Between computers - without human intervention.

For example, you’re a trucking business. You need to provide you clients - shipment companies - a status of their shipment. This document typically includes the address of where the cargo is coming from, its destination, estimated delivery date and time, and the proof of delivery with the info where it was dropped and who signed for delivery. Other information, like the package’s weight, dimensions, and quantity, may also apply.

Conventionally, you would send them a document via email (or even snail mail) that will likely look different than the same document from another trucking company. Someone would have to check their mail, open and confirm that the data is correct, and then transfer all data manually to the back office system.

EDI does all of this automatically and in the background. In this article, we explain how exactly and what you will need to embrace EDI communication.

A simplistic view of data traveling via EDI



EDI software

Unless you’re only using EDI because your partner requires it and would rather stay loyal to conventional spreadsheets, you most likely need an EDI software that will be responsible for smooth and automated data transition. You can use either cloud or on-premise solutions. The difference is in the IT effort you are ready to provide and scalability issues - cloud tools will automatically grow with you, while you’ll have to support bigger volumes with hardware and increased maintenance efforts.

Typical EDI software consists of:
  • Translation software
  • Mapping software
  • Integration with communication software
Here are two main things you want to know when looking for EDI software:

Integration with your in-house software. Make sure that EDI data can be accessed directly from your ERP or logistics management software. Some ERP systems like SAP or Infor already have EDI functionality out-of-the-box, some (like Epicor) have it available on demand. But in most cases, you will have to integrate a separate translation and EDI software on your own and the provider should have such possibility. If there’s no seamless integration and you still have to access EDI manually - you lose a bit of that desired automation.

Support for different communications. There are many protocols for transferring EDI data that your trading partner may require. You should be able to access most of them without extra integrations. This includes VAN, AS2, FTP, SFTP, FTPS, OFTS, etc. We will explain the difference further.

Understanding file formats

As EDI is used to help computers, not humans, communicate, you can’t prepare your data in an EDI format from the beginning. A document carrying information in an EDI format is called a Transaction Set (T-Set) or a message. For example, if we return to our trucking example, the T-Set you’d be looking for is 214 Transportation Carrier Shipment Status, as defined by ANSI X12 format. Use X12 Transaction Sets and UN/EDIFACT directories to define the rules and codes of all your documents.

There are two main file formats you will come around when working with EDI:

ANSI X12 - the main EDI format used in North America.

EDIFACT - the main EDI format outside of North America.

Your partner will let you know which format they accept, but for a transportation business operating in the US, you can be safe with assuming it’s ANSI.

paper-and-ANSI-and-EDIFACT-purchase-order-1024x801-min

As you can see, both translations are readable but not human-friendly

Source: EDIbasics



EDI mapping software

Documents need to have file formats and established transaction sets so another computer can easily validate it. It’s not enough to understand the data in it, the system also should know where this data belongs. This is managed by a process called EDI mapping.

EDI mapping is the process of configuring how each file will be translated and sent out. This means that you need to configure all details for each particular file once and the system will know how to perform the process in the future. For our Shipment Status message, you will want to locate the document in your ERP, link relationships between the data, and choose the destination. When you’re on the receiving end, the map should already have all the links back to your ERP. Data mapping is a complex process which requires a mapping expert to fulfill.

Example of a map in EDI translation software

Source: SelectHub



Communication methods: VAN vs AS2 vs FTP/SFTP/FTPS

Initially, EDI was designed to be transmitted independently of usual communication technologies. Let’s quickly compare what organizations prefer today.

Value Added Network (VAN)

This secure private network has existed before the Internet and remains a favored way for companies to exchange messages with multiple partners. It works similarly to email - you set up a virtual mailbox, VAN transmits messages through a direct dial-up, and they wait for you there until you check your mailbox. The VAN provider manages support and maintenance and sometimes provides additional services such as data backup or even data mapping. Today, many EDI methods can seem more convenient, but with partners supporting VAN, you may have no choice.

VAN is a middleman that manages connectivity with all partners on its side



Direct/Peer-to-Peer/Point-to-Point

This method follows an entirely different strategy. Here, you create an individual connection with each partner and have the freedom to choose a different protocol for them all. If you have many partners, establishing a direct connection with them may not be possible, so you’ll have to incorporate a different communication method.

For direct communication, you need to support all protocols you partners require

Now, what protocols are out there and what's the difference?

FTP was the first protocol to become accessible via VANs and remains the most well-known. The FTP server can be installed on any operating system, but it lacks security - you would need to incorporate your own encryption to transfer financial data. That’s why most organizations use a Virtual Private Network (VPN) on top of it.

FTPS was created to address FTP’s security problems, so it has SSL/TLS (Secure Sockets Layer or Transport Layer Security) encryption and digital certificates.

SFTP similarly uses an encryption method for FTP, this time - SSH (Secure Shell).

OFTP or Odette allows providing a digitally signed receipt on document delivery. It’s common in Europe, while AS2 - another protocol with similar functionality - is a standard for the US. It deserves a separate section.

AS2

Applicability Statement 2 or AS2 is the main alternative to VAN, although by its working principle it reminds direct communication. It runs on HTTPS, which ensures its security, and can be accessed online. Plus, it sends the receipts upon delivery which we mentioned above.

To use AS2, you need to constantly be connected to the Internet and ready to receive messages, so trading partners use software that keeps this channel open at all types. When choosing your EDI software, make sure it supports AS2 communication. When Walmart announced AS2 as its primal EDI protocol, the adoption of AS2 skyrocketed and it can now be found at almost any organization.

How to implement EDI step-by-step

1. Assemble an EDI team

Just as any structural change in an organization, introducing EDI requires control and shared responsibilities. Assign selected staff members the positions to manage EDI implementation from the IT side, start employee training, etc.

2. Analyze your current procedures

Take a look at how your partners are managing EDI, what protocols they use. Identify how people at your company currently manage documents to prepare a new workflow for them.

3. Create needs and requirements for your EDI solution

Decide the size of your future EDI infrastructure, the number of connections and their types, your readiness to allocate IT resources, and the amount of customization and integration your systems will require.

4. Choose your communication model

Are you planning to connect directly, use VAN, AS2, or a hybrid approach? Choose a communication provider accordingly.

5. Choose EDI software according to your needs

a. Check if your ERP system already has EDI integrated and whether the provider supports adding EDI functionality on demand. If so, study what protocols your software supports and check whether you're lacking any that your partners require.

b. If your provider doesn't have available integrations, search for the suitable solution on software rating websites like Capterra, G2 Crowd, and others. Pick a provider based on whether it can be integrated on your back office, cloud or on-premise, number of supported protocols, third-party integrations. If none seem fit, consider developing custom software or invite an IT consultant to help with integration into an ERP.

6. Start EDI mapping

Use EDI mapping software to configure the pathways for all files to travel through. Consider hiring a data mapping specialist to create correct links and avoid mistakes in the future.

7. Test your EDI system

Choose a small group of partners to test your first EDI experience. Confirm that data was transferred safely and mapped correctly. Did it handle the traffic? What was your employees' experience with the new workflow?

8. Introduce EDI to your trading partners

Monitor how the system is performing and gather feedback from employees and partners. Slowly integrate more functionality and communication types. Establish a team of experts to maintain and develop the program.

(9. Consider additional connectivity methods)

Look for other communication methods available for transportation businesses. Consider API and e-AWB connectivity as modern ways to exchange data with selected logistics vendors. Read the linked article for the overview of the opportunities and compare them with EDI.

Comments