EDI as the core system for electronic data interchange and partner integrations

Features of EDI Exchange Expert Opinion: How an EDI Integration Customer Evaluates This Technology

What EDI Is. History and Development. Standards

The development client needs to decide whether they need the exchange of legally significant documents, reporting, or system integration. These are different things. Naturally, businesses have many legally significant documents that need to be exchanged with customers, suppliers, and the tax authority at a minimum. The specific feature of EDI in CIS is the variety of formats: there are several electronic reporting systems on the market ("SKB Kontur",

SBIS); UTD format (short for "universal transfer document"

) is advisory in nature; there are several operators

ECP (short for "unified digital signature"

) and so on. But exchange is easier when all parties use a single format and common rules. Such integration requires electronic document exchange. In this case, EDI refers to a set of standards (legacy) related to electronic document exchange. EDI as a means of reporting and exchanging legally significant documents is a broad topic, but in this article we will talk about EDI as an integration technology: this is the part of the work we deal with.

To learn the opinion of large business on EDI, we interviewed a representative of the international logistics company FM Logistic. Our interviewee is Jonathan Woloszczyk, Head of IS Build & Deploy, our long-time client and partner. - In our joint work, we used API to integrate with delivery services, and EDI as the means of integration with WMS.

We also know that FM Logistic has EDI exchange with some partners.

- Why do you think EDI is still of interest to the transport and logistics business and its counterparties? What are its advantages? -

These WMS systems are not just old now, but extremely old, and creating API for them is often impossible. Second, in logistics there is still a very high level of trust in file exchange via EDI.

Logistics professionals are pragmatic people; they are more used to thinking of a file as a physical object, an artifact. With EDI, a logistics specialist can say, "I sent you the file" and "I received your file."

Accountability is transparent: each participant in the exchange can always prove what they sent, when they sent it, and to whom. API and transactional exchange are much harder to understand.

It is hard to conceptualize a data transfer format via API and trust it. I think this is the main reason why EDI exchange is so popular.

But many logistics companies are already seeing changes: a younger generation is arriving with different views on EDI and API. Third, writing a script and connecting it to API is much more difficult than using EDI. Most IT solutions have a standard EDI specification on input or output, and it is fairly easy to use: when you want to connect one client's ERP system to a WMS or another information system, you only need to do mapping - there is no need to write scripts, methods, connect them to API, and so on. -

Now let's look at the example with Auchan. They have EDI Orders, and your WMS has Orders. Did you integrate via EDI?

- How do you receive order data from Auchan? -

When we were just starting out, we integrated via EDI.

You have to analyze the specifications and reformat their Orders so that they match ours. The good thing is that even someone far from programming can do such analysis - not a technical specialist, but any analyst who only needs to make a list in Excel and show which fields need to be aligned.

Broadly speaking, you could simply expose the EDI interface to your e-commerce partners and integrate with them that way.

The remaining 50% of clients still exchange XML files through EDI.

This is not UN/EDIFACT, ANSI X12, or anything similar, but it is EDI nonetheless.

Data exchange is fast and intensive, and there are many documents.

Whereas in B2B logistics, we deal with large batches of goods, and all the data for a day can be captured in a single document.

A major advantage of API is that after each data submission you get a response, either "OK" or "not OK." With EDI, you do not get feedback: you simply send a file and wait, not knowing what happened to it next. Some time ago, EDI tried to add flags inside files to indicate whether the sender needed a response, but that did not work.

To this day, EDI does not confirm that integration is correct, and although there are workarounds to obtain that confirmation, they are implemented very rarely.

Or I can send a request designed to return a reference directory. I call a method that returns part of the catalog to me and displays it in the UI and in the mobile app. - So EDI is so popular because there are still many companies that exchange paper documents, and converting those papers into electronic messages and exchanging them is currently relevant for them.

That is why EDI sells well, even though it is an outdated technology and an old format. - Yes, but for those people who require EDI and do not want API, this is the first step of digital transformation.

For them, it is psychologically important to go through this stage so that later they can appreciate the advantages of API.

It is easy to decide to replace paper with a file containing the same data as the paper document. It looks almost the same. But API? "No, I won't figure out this technology of yours, give me EDI instead, that's easier."

- Why don't WMS developers want to build API into the system itself, since data exchange speed matters to them and, for example, ERP systems, especially SAP, are already moving quite actively toward API? -

In fact, WMS solutions are also looking toward API, but it is very difficult for them to take concrete steps because all popular WMS systems are tied to EDI by a large number of algorithms.

To attach API to a WMS, a huge amount of work is required to conceptualize and remodel objects, functions, and so on.

At the moment, there are very few WMS products on the market that can be controlled via API, and those that do exist have a very limited set of actions. Mostly, they just translate a unified API, meaning that when you make a request, they run it through an EDI import script and return the response and result synchronously.

But creating a new method for them that would directly affect databases or exchange data into the core is an unrealistically labor-intensive task.

Thanks for the interview to our partner: we learned the opinion of a representative of a large international company about EDI and the prospects for using this technology in the logistics business.