JSON to EDI Translation: Efficient Data Integration

If you have been tasked with building an EDI integration between your business and a retailer, you may be wondering where to start? A typical evolution path for people to work with EDI is to start with a single trading partner that you need to trade with and focus on a single document you may need to send, like an invoice. Before you send the invoice, you may receive a purchase order from your trading partner, which will most likely be in X12. You will need to take this purchase order information, map it to your ERP or other system, transform it to a format your system will understand, and load it into your system. Then, you will use your ERP to generate an invoice. That invoice will need to be converted to X12 and then sent to your partner. So where do you start?

Typical EDI Integration

The above sounds simple enough. However, there is a lot of work to make this all go smoothly, including:

1. Understanding Business Requirements: The first step is to understand the business requirements for the data that needs to be exchanged. These requirements, called EDI Guidelines, are usually defined by the partner with the most power and are typically documented in a PDF document. These guidelines will most likely be filled with acronyms and jargon that may not be familiar, but they are necessary to follow to do business.
2. EDI X12 Mapping: Next, your team will need to build and/or buy technology that can understand X12 and convert it to a format your backend system can understand as well as take your systems output and convert it to the proper X12 format your partner requires.
3. Integrating your backend systems: A custom integration will need to be built to feed the information received from your partner into your backend systems. You will also need a way to get information out of your system so it can be mapped and translated into your partner’s required format.
4. Communicating EDI Documents: EDI documents need to be sent and received through a defined communication method, most common of which are AS2, SFTP, or VAN. There aren’t many trading partners that can accept X12 over more modern https communication, unfortunately. This means building and/or buying infrastructure that can communicate with your trading partners, which could all have different requirements.
5. Testing and Validation: Once the integration is in place and the data has been mapped, the integration must be tested. The files you send must match the exact detailed requirements laid out by your trading partner to avoid delays and chargebacks.

Once the EDI integration is built, the mapping is complete, and the documents have been manually validated, this process must be repeated for the average 3-5 documents required in a typical trading partner relationship.

You are now “live” with your first trading partner and you are ready to integrate with another. Great! You’ve done this already, and X12 is standard, so the next one should be simple. But this is very far from reality. Unfortunately, each trading partner you do business with will have custom requirements around how they communicate and custom data formats that will need to be sent and received. From an implementation standpoint, this means your team will end up building and maintaining many point-to-point integrations, tens to hundreds of custom mapping files, and multiple communication channels methods. This quickly becomes an EDI headache.

Switching to a JSON API for EDI integration

EDI and X12 have been around for decades and are tedious and complicated. However, it doesn’t have to be. Much of the complexity can be abstracted using modern development APIs that provide more human readable formats like JSON.

JSON is also a much easier format to use than X12. With X12, there’s very little metadata to describe your information. It’s positional-based and can vary from one trading partner to the next—and this variance causes errors and delays. Understanding X12 and building maps back to your ERP or TMS, requires reviewing individual specifications to figure out what your data is and where it belongs in your system. This is time consuming, tedious, and requires a knowledgeable EDI resource.

JSON, on the other hand, is highly descriptive and is rich with metadata. Because it’s a more modern format, every language has great support for it, and it makes integrating into your backend systems much easier.

But there’s a catch: scrapping EDI and using JSON isn’t easy when your trading partners are leveraging X12. Fortunately, there’s an easy way to convert EDI to JSON , and that’s through the cloud.

Modern EDI Integration using APIs

Here is what a more modern approach to EDI looks like when you want to leverage JSON APIs with a Modern EDI platform like Orderful.

1. Cloud Digitized EDI Guidelines: When using Orderful, EDI guidelines are digitized. This means we will publish your partners’ unique requirements electronically into the platform so they can be maintained centrally and reused. By doing this, Orderful can abstract the requirements into an easy to understand JSON format.
2. Single API Integration: Once the requirements are digitized, Orderful provides your development team with a single API endpoint per document type to integrate. Orderful’s Integration Assistance consolidates the requirements across all of your partners for that document type and provides your developers with the JSON expected to meet all of the requirements. This allows your developers to build and maintain a single EDI integration.
3. Automatic JSON to EDI translation: Because the guidelines are digitized, Orderful automatically converts the data received from both partners from JSON to EDI and from EDI to JSON without the need of complex mapping files. Therefore, your team no longer needs to build and maintain tens to hundreds of custom maps.
4. Built in Communication Channels: EDI communication typically happens over AS2, VAN, or SFTP. Orderful provides preconfigured connectivity based on your partner’s guidelines. There is no need to build and maintain this infrastructure – just supply a few connective parameters and you can start sending and receiving documents.
5. Testing and Validation: Before going live, you must test and validate all common EDI transactions. Orderful includes built-in scenario tests to represent the common set of transactions for your type of partnership. If transactions fail to meet the guidelines, an analyst can easily use the Orderful Business Rules Engine to correct errors in real time and resend the transactions. Making real-time changes to transactions no longer requires a developer.

What’s the advantage of using a Modern API Solution for EDI?

Using a Modern API for EDI solution like Orderful has many benefits including:

• Simplified EDI Integrations: Integrated once via API and trade with all your partners
• Faster time to market: Onboarding new EDI partners in days not weeks or months
• Real-time validation: Validate your data instantly against your partners actual guidelines
• Auto Translations from JSON to EDI X12: No more building and maintaining maps
• Zero lock-in to existing ERP, TMS, OMS or other systems of records

Trading with your trading partner is table stakes, so doing it in a way that is more efficient and faster will set you apart. With a modern EDI platform like Orderful that understands EDI, you can streamline all of these necessities and concentrate on building an API integration to a simple JSON format and let Orderful do the rest of the heavy lifting.

We’ve described how Orderful works, but we think it’s far more helpful for logistics providers, retailers, manufacturers, and technology companies to see our platform in action. Request a demo today.