The same questions and concerns keep arising when designing the requirements for an EDI integration project into JD Edwards (JDE) system. As I have been involved in my fair share of EDI integration projects, I have witnessed companies struggling with integrating EDI in JDE systems. I’ve decided to share my experience, not as a JDE expert but as an EDI integration expert and consultant, to help those with this kind of project. Let’s begin…

Why EDI integration is important

More and more companies are adopting different communication protocols to exchange business-related messages electronically. Today’s business environments are working harder to be well connected with outside parties for improved communication. It is almost impossible nowadays for a company to trade and do business without having the capability to electronically exchange messages and important documents with its suppliers and customers. This is why EDI has gained tremendous attention in recent years; businesses, no matter how large or small they are, are looking to receive EDI documents (i.e. customer orders) and send out responses such as invoices, or advance shipping notices (ASNs).

On top of this, with the expansion and popularity of eCommerce (electronic commerce), businesses have no choice but to integrate EDI into their systems as consumers expect quick response times in providing more accurate inventory availabilities and quick order processing for better customer service.

All of the above make it almost impossible for any company to ignore electronic processing of sensitive data, all in real-time. However, what’s been challenging for most, is that various business partners adopt different EDI standards, some even choosing a “custom made” version, which all adds new layers of complexity to an EDI integration project in JDE and more pressures to comply with tons of different EDI standards (i.e. X12, EDIFact, XML, CSV,…).

Benefits of integrating EDI into a company’s system

EDI has been around for quite some time now. At this point, there’s no question about the real benefits that come from using this B2B communication method. Companies are seeing more advantages and improvements when they integrate EDI transactions (incoming and outgoing) into their management software system. Some of these EDI integration benefits include:

• An increase in a company’s response time and a decrease in their fulfillment cycle
• Increased information integrity and a reduction in errors due to the elimination of manual data entry and human intervention
• Fast and accurate delivery of goods and services

There’s no doubt that companies gain a competitive advantage by successfully integrating EDI into their management system. They are better equipped to handle more orders and have no problem doing business with large retailers who expect electronic messaging. 

How EDI processing works in JD Edwards

Let me give a quick description of the EDI processing cycle in JDE, as described by Oracle’s own documentation of the JDE system.

“When you receive inbound documents, the translator software retrieves the data using network communications and translates the data from EDI Standard format to JD Edwards World application file format”.

Here is a simple drawing posted in their online documentation:

In simple terms, when a company running JD Edwards World or its previous version (Enterprise One) needs to process EDI data received from a business partner for example, the data will go through different stages:

1. A communication software (a third party software) would connect and get incoming EDI files using network communications.
2. The translator software translates the data from EDI Standard format to JD Edwards World application file format.
3. Once the above two steps are completed, the system 47 of JD Edwards application, will take the data from the JDE flat format to JD application files.

JDE has its own EDI (Electronic Data & eCommerce) integration module. This module, can be configured to integrate EDI data formatted in JDE acceptable format and turn it into JDE application files. While doing so, tons of automatic triggers are fired up, such as billing address, items and pricing verification. In addition, error reports are generated and email alerts are sent.

Unfortunately, the file format that JDE is capable of processing is still a flat file format. I invite you to read this article where the author had explained a lot about JDE EDI integration and its file format.

It is important to know that the user must complete several tasks in order to customize the Electronic Commerce system to interact with your other applications and to fit your company’s needs, as per JDE’s online documentation.

Challenges with EDI integration in JD Edwards World

As I mentioned at the beginning of this article, there are many challenges that business executives struggle with when deciding to implement EDI and integrate it into their JDE system. I will highlight the most important ones and give my recommendations as an EDI integrator and expert on the topic.

Writing directly in JDE application file or using the EDI interface module

A very good question that comes up regularly is “Should we plan the integration engine to translate and write DIRECTLY inside the JD Edwards World applications files or use the Electronic Commerce module in JDE?

I personally recommend to work with the EDI module of JDE for the following reasons:

• Out of the box, it works well once the right data in the appropriate format is provided to the engine.
• Obviously, in the beginning, your JDE team will need to spend some time and effort setting things up; they can either do this all themselves or with the help of your EDI consultants.
• Out of the box, when set up is completed correctly, the JDE engine is capable of taking the data and passing it through tons of validation steps (i.e. price, items, billing instructions…) prior to moving the clean data to JDE application files, without any human intervention.
• Please note, however, that if you choose to have the EDI integration engine write directly to the JDE application files, a new JDE update or application upgrade can result in potential damages to this process. Upgrading the JDE application will require a full cycle of QA to make sure the integration engine of EDI into JDE is still working 100% efficiently.

Exchanging and translating XML, JSON, and other non-Flat File formats

The other challenge many have faced is knowing how to enforce JDE with the capability to translate non-standard EDI files such as XML, JSON or any other format given the fact that JDE’s EDI module is only capable of integrating with one single file format (more specifically a Flat file).

My recommendation would be to adopt a strategy where any file no matter its format received from your Trading Partner is automatically translated into a single format that is acceptable by your JDE EDI module, prior to initiating the process in JDE. I know it may seem difficult to achieve for such a mechanism considering the level of limitations provided by JDE, but this option is more feasible than you may think. I will go on to explore this possibility in the following section.

Looking to integrate your EDI or eCommerce processes with Oracle JDE enterprise one, look no further, since we have the best integration option where we turn your Oracle JDE system into a modern REST API, that receives https requests and acts accordingly. LEARN MORE>

What is the best option to integrate EDI in JD Edwards

Having listed the major challenges above, it is clear that the best option for a seamless, simple and quick EDI integration with your Trading Partners or your eCommerce platform is to adopt one single protocol of communication between your outside world and your JDE system.

In fact, Oracle’s JDE team have anticipated for such a protocol. They refer to in their documentation as the “translation software (third party)”.

I understand that managing a third party translation software internally by your team will add another layer of complexity, additional resources and expertise, not accounting for the countless number of EDI file formats found in today’s business world: TXT, CSV, EDIFACT, X12, XML, Json, etc.

You’re in luck though! There are a few companies out there, like Namtek Consulting Services, that can outsource the job of managing your translation software. Our EDI2XML cloud integration platform can act as your translation software; it can turn all your incoming files, no matter its format, into one format that your JDE loves to work with. The opposite works for outgoing files; your JDE-preferred format is easily and automatically converted into the specified format of your Trading Partners.

What challenges have YOU faced regarding EDI integration into your JD Edwards World system?