What is EDIFACT?
If you have dealt with EDI (electronic data interchange) before then, you must be also familiar with EDIFACT. For the last decades, electronic data interchange and the EDIFACT messaging standard have been essential facilitators of global trade. Business-to-business information exchange has become more critical than ever. Nevertheless, new standards and message formats have appeared to support B2B communication.
At the same time, EDIFACT is still widely used in specific industries, for instance in the ocean shipping industry. However, most integration architects don’t like or want to deal with it. Why is that? EDIFACT is a rigid format that comes with a lot of rules, and it is difficult to work with it. Validating and enriching an EDIFACT message manually is almost impossible due to its structure and the character sets used. Avoiding it is practically impossible though before trading parties wouldn’t agree on a new standard. There are formats used, such as XML, JSON, or proprietary in-house formats, but EDIFACT is not about to disappear any time soon.
WHAT IS EDIFACT?
You may have heard of EDIFACT in the past, but chances are it might be a new concept to you and your organization.
UN/EDIFACT or EDIFACT, which stands for Electronic Data Interchange for Administration, Commerce and Transport, is the international EDI standard developed under the United Nations.
The EDIFACT standard comprises a set of internationally agreed standards, directories, and guidelines for the electronic interchange of structured data, between independent computerized information systems. It allows for a multi-country and multi-industry exchange of electronic business documents and files securely.
EDIFACT is widely used in Europe, as many companies adopted it early on. Today, however, EDIFACT is starting to see more adoption outside of Europe, growing within the U.S. and the Asia-Pacific regions.
WHY WAS EDIFACT DEVELOPED?
The rules of EDIFACT have been approved and published by UNECE, and they also maintain it.
Because of a large number of trading partners a company would typically have, it was critical to develop a format that could be understood by any parties. EDIFACT was designed to simplify and standardize the communication between trading parties that were relying on electronic data interchange (EDI) as their primary form of communication. The widespread adoption of EDI meant that global businesses could thrive: they could completely replace paper documentation and manual procedures and share information with all their ecosystem electronically, a lot faster than if they used paper. It also meant that they were able to cut costs, not by just using less paper, but also by improving operational efficiency.
We can say with confidence that EDI and EDIFACT have had a strategic role in shaping modern supply chains.
When introduced, EDIFACTWhen EDIFACT was introduced, it was revolutionary, and it has continued to help large retailers, manufacturers, and more transfer significant data securely to trading partners that required the capability of EDI. It was the missing link eliminate paper and manual processes and thereby significantly speeding up operations and reducing costs.
It was a safe, effective, and cheap alternative for paper-based communication. It has helped the adoption that many large retailers or manufacturers required the capability of electronic data interchange from their trading parties, no wonder that EDI has quickly become significant (still is today) and there had to be a standard to simplify communication.
WHAT ARE THE STRUCTURE AND COMPONENTS OF EDIFACT MESSAGES?
The intervention of the United Nations (UN) was unavoidable. They needed to assist the development of a standard that could fit the need of any trading party. They needed to identify all information that is typically included in trading messages and deriving from that identifying what shall be included in EDIFACT messages.
United Nations needed to specify the message structure (header, detail, summary) and the content (syntax, data elements, composite data elements, segment, messages). The UN has also defined the number of characters per line and number of lines per box. The logic of EDIFACT is very similar to the logic of languages: the information can be structured into “words” and then “sentences”. The “words” are called data elements (it could be an invoice number or the time of shipment). The United Nations Trade Data Elements Directory (UNTDED) has defined around 700 data elements with associated codes. The data elements can be organized into “sentences” that are called as segments. The segments are then grouped to shape a message based on strict syntax rules. The segments, messages, and syntax implementation guidelines can be found in the United Nations Trade Data Interchange Directory (UNTDID).
The handling of an EDIFACT message sounds simple: once you have generated it, you use a tool like EDI Value-Added Network (VAN) for the processing and transmission. The basic idea behind EDIFACT was to structure the data better before it would have been sent from one system to another and support multi-country and multi-industry exchange of business-critical information. If your trading partner’s system can understand an EDIFACT message, this is a simple and great solution – and that has been the original intention of EDIFACT. This thought leads us to our next chapter that is handling the main challenges of EDIFACT.
CHALLENGES WITH EDIFACT
While a standard, EDIFACT is still somewhat clumsy. Most of the developers don’t like to deal with it since the specifications are complex and the data format is only semi-structured. Just take a look at an EDIFACT sample message.
Below is an example of EDIFACT:
One problem with EDIFACT is that it was developed years before XML became widely adopted in machine-to-machine communication. Since EDIFACT is only semi-structured and appears to be just a blob of text, semicolons, and coded values, the data format is difficult to read for humans and difficult to handle by software tools. Understanding the content of each message requires extensive knowledge about EDIFACT standard and the used message version. Lack of structure also makes implementation projects time-consuming and error-prone.
There are several problems:
VALIDATING EDIFACT
If you need to make sure that all the information is correct in the EDIFACT message, you shouldn’t do it manually. Let’s be honest; it is almost impossible due to all the different rules and characters used even in a short message.
- ENRICHING EDIFACT
Once you realized that something is missing, it is equally challenging to enrich it. This is something that should be simplified and automated.
- Your partners are using other formats than EDIFACT
While EDIFACT has been born to standardize electronic B2B communication, other formats are commonly used across companies. Whether your stakeholders use XML, JSON, X12, or any own format, you should be able to communicate with them, and the messages they send should be in EDIFACT, the preferred format that your systems understand.
Still, it’s a standard that has been widely adopted and offers a common vocabulary and set of messages for trading partners. No wonder, we often still work with companies that are using EDIFACT for business-to-business communication.
EDI HERE MADE SIMPLE
What if there was a way to automatically translate EDIFACT messages to a structured and human-readable format, like XML or JSON, and vice versa?
This would simplify EDIFACT projects so that most of the work would consist of implementing the mappings with a commonly available technology such as XSLT. When the conversion to XML format is done, it’s a lot easier to transform the message to whatever format you wish: JSON, CEFACT, UBL, GS1 XML, X12, your in-house XML format, to name a few.
This shorts on-boarding of new trading partners to a matter of days, instead of weeks or months. This will also dramatically cut the costs of the on-boarding just by accelerating the speed of development and deployment of EDI solutions. It also helps you manage different versions of the same messages and harmonize them to single version to be used in your own information systems, such as transport management, order handling and invoicing systems.
