How to implement EDI?

Simple illustration of a road turning through a green field

How to Implement EDI - Practical Guide

In prior articles, I wrote about what is EDI from the business perspective and I debated on the benefits of using electronic document exchange. This time I aim to provide a straightforward explanation of how EDI functions and outline the essential requirements for implementation, particularly from a technical standpoint.

This article is tailored for those without prior EDI experience who find themselves tasked with overseeing an EDI implementation project.

 

Information Flow Between IT Systems

While it is possible to exchange the data with partners in any agreed format, it becomes unpractical at larger scale. This is where standards, such as EDIFACT, X12 or UBL comes to help. Below, I assume such an organization.

First, let’s revisit the diagram below to understand how data flows between the systems of two companies.

 

Schema of business documents exchange between partners connected by EDI

 

For outbound data, we must:

  • Extract data from your ERP system.
  • Convert the file to an universal EDIFACT format (or X12 in the USA).
  • Safely and securely transmit the data to your commercial partner.

For inbound data, the process is reversed:

  • Receive the data in EDIFACT format.
  • Convert them to the format expected by your ERP system.
  • Import the data into the ERP system.
  • Process the received documents in an internal workflow, allowing for data acceptance/rejection and subsequent actions. For example, upon receiving a purchase order: checking quantities and prices, reserving goods in the warehouse, or placing back-orders and finally sending a PO confirmation.

The data being exchanged are always linked to a business events: e.g. ordering goods, shipping goods or issuing an invoice. Ideally, all of the above actions should take place fully automatically, based on a set of predefined business rules.

 

What is needed for EDI implementation?

Based on the above description, we can identify three key stages in an EDI implementation project: changes to the ERP system, deployment of tools for EDI data translation and transfer, and organisation of system maintenance.

Since we are discussing a change, which requires the involvement of key personnel from several departments (IT and various business departments), it is crucial to coordinate the project and to involve the company’s management in it.

 

1. Customization of the ERP System

This task falls under the responsibility of your internal IT team or the subcontractor in charge of maintaining your ERP system.

One remark before you start to worry: there’s a chance that your ERP system already have built-in imports/exports encompassing all the necessary data. Even if that’s not the case, customization or creation of these interfaces is usually a straightforward process.

Data export:
  • As a general rule, it’s advisable to export all available data for a given business event. This approach allows one export to serve electronic documents for all partners, eliminating the need for additional modifications later.
  • A reasonable minimum is to export all the data present on a traditional version of the document, such as a paper order or invoice.
  • During the stage of comparing your data with the partner’s specifications, you might discover that certain business processes need adjustments. For instance, a partner may expect to receive one invoice per delivery note.
Data import:
  • My advice is to begin from the end: analyze how to use the received data to maximize the automation of related business processes (e.g., completely automated approval of goods invoices).
  • Unlike data export, for the import, you can selectively choose from all received data only those that will be useful for your automation.
  • Incoming EDI documents should undergo strict verification, and in case of errors, they should be blocked, generating an alert for the staff responsible for system supervision. This helps prevent the mass introduction of errors in the system.

 

2. Change Data Format and Send EDI Documents

Internal or External

This part of the project involves making a choice:

  • Internal Implementation: use specialized software installed by the internal IT department.
  • EDI Service Provider: Subscribe to a cloud-based tools or services. This topic will be further explored in another article: “EDI Provider: How to Compare Offers and Make a Choice”.
Documents translation

Translating electronic documents, or - in other words - changing the data format, requires:

  • Field Mapping: Specify where the data from the input file should be placed in the output file.
  • Conversion of Data: This includes adjusting dates format, decimal separators, length limits, and changing the encoding of national characters.
  • Internal Codes Conversion: Examples include converting types of promotions, discounts, charges, and taxes.
  • Setting Data Control Rules: Define conditions under which the translation of the document should result in an error (e.g. missing mandatory data, incorrect dates, data types, etc.).

At times, it may be necessary to include additional information in outbound documents which was present in the inbound document, such as internal supplier code. If this information cannot be stored in the ERP system, it can be stored and later added by the translation software, using so-called translation tables.

Data transfer

In current large-scale EDI implementations, the prevalent choice for secure transfer of business documents over the Internet is the specialized AS2 protocol. This protocol offers a crucial feature: automatic acknowledgment of document receipt via MDN (Message Disposition Notification). This feature establishes a clear division of responsibilities between partners. For a deeper understanding of how the AS2 protocol operates, refer to the article: How to implement communication via AS2 - best practices.

Occasionally, the X.400 protocol is still encountered; however, its diminishing popularity and associated costs make it advisable to avoid. Other forms of data transfer, such as (S)FTP, are generally not preferred for sending business documents due to the absence of a proper acknowledgment mechanism.

 

3. Plan the Maintenance of the System

While it may seem obvious, the importance of planning system maintenance cannot be overstated. Every IT system requires supervision, and EDI is no exception. It’s crucial to pay special attention to overseeing the process of translation and data transfer. This is the stage where problems may arise frequently, such as changes in partners’ systems, missing or incorrect data, or network issues. The team in charge of EDI system supervision should monitor the flow of documents and address all issues, in coordination with all involved parties. Our company Solvedi provides such service.

 

Degree of Automation

The whole data exchange process should ideally be fully automatic, aligning with the primary goal of EDI: automating business processes and eliminating delays. Typically, the data are exported in batches, such as sending new purchase orders once or a few times a day.

Occasionally, you may come across EDI systems that - at some stage - require human involvement, such as:

  • Import/export of data from/to the system requiring manual action, as for example uploading the resulting file to the EDI system and manually correcting the data, if required.
  • Manual re-entry of data between the ERP system and the EDI, system available as a web page. Such solutions, also known as Web-EDI, don’t offer many benefits as they double the workload and pose risks to data quality.

Considering the limitations of such “manual” systems, it’s advisable to avoid to use them on a larger scale.

 

Initial Requirements

It is worth adding that the implementation of electronic data exchange requires a certain level of “technical maturity” of the business:

  • Internal processes should be digitalized. If your company issues invoices in Word, you’re not there yet.
  • Articles should have unique codes understood by both partners. In EDI documents GTIN (EAN13 code) is typically used.
  • Individual companies and warehouses (locations) should also be coded. Also here EAN13 codes are used, referred in this context as GLN (Global Location Number).

 

Takeaway Notes

In conclusion, implementing EDI is quite a complex project, especially since it may require adjustments to the way your organization operates. However, with a clear understanding of its fundamentals, you can steer clear of costly pitfalls and generate significant benefits for the entire business.

 


If you have questions, you can book an appointment for a free online consultation or use the contact form to send a message.

 

Related articles: