This article went on to describe the beginnings of EDI in the business world and how far we’ve advanced with technology to simplify these B2B transactions with EDI2XML. Read more
EDI2XML offers reliable EDI and cloud integration solutions—enhance your B2B communication and streamline data exchange with ease and expertise.
Tag Archive for: EDI2XML
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:
- A communication software (a third party software) would connect and get incoming EDI files using network communications.
- The translator software translates the data from EDI Standard format to JD Edwards World application file format.
- 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?
For a while, EDI was not well liked amongst Small & Medium Enterprises. These companies were finding it to be too slow, too complex and way too expensive. They then resorted to a lot of manual data entry for orders as they would receive orders and invoices via email or fax. However, over the years, things have changed…a lot and for the better. Read more
This post was updated to reflect current trends and information.
EDI communication, although it may still have a bad rep for being too complex and expensive, is growing in popularity amongst businesses. It still remains to be the best and most secure method of exchanging electronic information between Trading Partners. Does it have to be so complex and expensive? Not at all! It’s whom you choose to hire as your EDI Provider that makes all the difference. Most large Providers are not flexible enough to deal with Small and Medium Enterprises. This was a problem in which our EDI experts realized over 20 years ago and eventually found a solution.
The Solution – Fully Managed EDI Service
EDI2XML is a translation tool that converts EDI documents to XML/CSV format (based on a pre-defined schema) for incoming documents (and vice versa for outgoing documents). XML is a format that is easily readable by any business person, no matter their IT or EDI knowledge. It is also easier to integrate this XML document into the company’s management system – automating and simplifying the whole communication process. On top of all this, we understand that not all businesses have an internal IT team, which makes implementing new software solutions difficult and complicated for the business executives. We then needed another solution to another problem. We came up with EDI2XML Managed Services.
Basically, this SaaS cloud offering enabled companies to exchange via EDI with their Trading Partners without lifting a finger. How great is that? Our team picks up any incoming EDI documents straight from the customer’s Trading Partner’s mailbox, converts it into the desired XML format of the customer, and sends it to the customer or integrates the data straight into their management system. Outgoing documents works in the opposite way; we pick up any outgoing XML files extracted from the management system, we convert it into EDI format to then send it straight to the Trading Partner.
Key Benefits of Managed EDI Solution
- Improves customer/partner relationships
- Doing business with the large retailers, who require their partners to use EDI, is finally made possible
- Staff can focus on their core business tasks rather than on manual data entry for incoming orders
- The B2B flow of information is enhanced and simplified
- Exchanging via EDI is affordable for the smaller companies
- Improves order processing cycle time reductions; invoices and POs can be processed within hours rather than days/weeks
- Documents are more accurate (reduced errors) as there is no manual data entry required
- Cash flow is also improved since electronic invoicing via EDI increases the speed of payment by the customers
- Employees can quickly access order statutes or other important information to make strategic decisions
All in all, EDI2XML has indeed eliminated many supply chain inefficiencies that companies are living with today and has provided accuracy and timeliness for order processing. Our team is also very flexible and understands that EDI communication can differ between companies, retailers, etc. After being in the EDI communication business for over 20 years, we’ve seen a lot! Selling a solution is not the way to go – it’s about solving a problem by improving processes. Let us handle your EDI communication process.
Contact us for a free EDI Consultation so we can better understand your EDI requirements, specific to your business
__________________________________________________________________________
This post was updated to reflect current trends and information.
Should we migrate our EDI integration and processing platform to a SaaS EDI platform or instead, adopt an EDI translation software on-premises?
The above question is asked by many business executives when involved in EDI integration projects, either when a contract or license with their current EDI provider or translation software comes to an end or before signing for a new EDI business relationship with a new partner. All of these reasons are valid and lately, this topic of discussion is being brought up much more, simply due to the popularity of “cloud” enhanced capabilities and security and Software as a Service (SaaS).
More and more enterprises are working to improve their supply chain management, which leads to companies adopting software applications (as a service). This allows them to increase efficiency, provide higher availability, reduce costs and increase profitability.
Today’s article will address the points every business owner should be evaluating when looking for an answer to the above question.
Enterprise IT Governance & Policy
The first thing to look at before making a decision on whether to go with SaaS EDI or to adopt an EDI translation software, is the company’s policy and IT governance, i.e. the rules and procedures that govern technological implementations and processes. What is the policy and general rule to implement software systems (including EDI)? What are the security measures and privacy rules?
Most companies of different sizes establish strict IT governance rules and procedures and follow these guidelines as much as possible. From my own observations, I have noticed that many enterprises, that have more than 20M of revenues per year and that use enterprise software such as JDE or SAP, have strict rules stating that they can only deploy software solutions on their own premises. However, today we are seeing more of these enterprises going for cloud and SaaS offerings, as it fits their needs much better.
EDI Volume
The second important point to look at is the volume of EDI data you wish to exchange with your business partner (or the current volume if you are already on EDI). This will give a good indication as to what direction your company should be leaning towards. In my professional opinion, the volume of EDI transactions is not the only factor when deciding to convert to SaaS EDI or to adopt translation software, but it is an important parameter.
Point-to-point EDI or VAN
The third point is to look at statistics about EDI connectivity with your current EDI partners, or forecast them if you are new to the EDI world. In today’s digital world, most EDI transactions are going point-to-point between business partners in a very secured manner using the Internet pipeline and secured protocols such as AS2, sFTP, FTP, etc. There are less transactions going through a VAN in comparison to a few years ago, as VANs charge additional expenses for EDI connectivity, which can add up and become quite costly.
Current IT Architecture & Team
A company’s IT architecture and team are extremely important when making decisions about EDI integration and implementation. If the company decides against the SaaS EDI model, does it have all the necessary hardware infrastructures, connectivity protocols and security to internally handle all kinds of EDI processing? Is the IT team equipped to handle such a project? Do they have the expertise and know-how to implement, manage and monitor EDI processes, transactions and translations? If the answers to the above questions are ‘no’, then the enterprise is better off with the SaaS EDI model.
EDI Translation Software Licensing
Don’t forget to evaluate the EDI translation software itself, from cost to functionalities to yearly maintenance and support to the ongoing development and programming during and after the implementation phase. It is also important to evaluate the capability of the IT team working with the EDI translation software.
Read: Take this QUIZ: Is your business cut out for on-premises EDI software?
SaaS EDI Service Provider
Whether using the services of a provider under the SaaS model or on-premises, it is crucial to select the right service provider for EDI. SaaS EDI providers should have a lot of experience in not only EDI but also in EDI and systems’ integration. In addition, the turnaround and customer service and support for that provider are key points for a decision. Keep in mind that some major SaaS EDI providers only see your business as an opportunity to increase revenue and stock value instead of focusing on giving a personalized and amazing customer service.
Conclusion: SaaS EDI or EDI Translation Software?
We are aware that the selection process and choice between SaaS EDI and EDI translation software is a challenging one. We believe that by having the right mechanism and people in place, enterprises of any size can make educated decisions based on what’s best for their business.
If you need more information or help in determining which model you should go with, please contact our EDI team for a free consultation.
Today’s business environment is full of complex business processes; lead time to deliver, merchandise fulfillment, forecasting and more. On top of these processes, there are constantly new strict regulations imposed on businesses by major retailers, like Amazon, Sears and Wal-Mart. Most often, restrictions are enforced when dealing with data exchange, stock and inventory availability and other compliances.
Luckily for companies, a diversity of efficient ERP systems, EDI tools and enterprise software applications, such as JDE, Salesforce, SAP, are running businesses of all sizes. Integration between different systems is becoming more than a luxury, it is a necessity. Enterprises of all sizes are making greater efforts to equip their IT systems with the capability to comply with requirements imposed on them by major retailers. One such issue is EDI integration and the ability to exchange and comply with retailer’s requirements. The key is to ensure you have chosen the right technology and the best team to handle the integration projects.
In my previous article, I addressed the major issues related to EDI integration with JDE. In today’s blog, my focus is on EDI integration with Salesforce or any other software CRM application. These projects can be long and costly if not done right, therefore read below to have an efficient, cost effective and solid integration for EDI communication.
What is Salesforce?
Salesforce is a cloud-based CRM (Customer Relationship Management) software system. It is very popular amongst enterprises of all sizes as it is best known for its openness for integration. Developers and integrators can read and write data using API and web services. Many companies use Salesforce as a unified tool for leads, campaigns, opportunities and customer tracking.
EDI Integration with Salesforce
Salesforce is simply a CRM system but add-on modules have been developed so users can enter sales orders for clients and confirm processing. However, when it comes down to needing to complete further business processes, which are included in an ERP solution, such as EDI communication, a different approach should be followed. Integrating EDI orders sent by retailers to a CRM user requires further expertise by a team of IT professionals with a solid knowledge of integration and EDI.
Read: Why we love EDI2XML for EDI Integration with JDE (And You Should Too!)
Following are the top 3 challenges that any EDI integration project manager should consider and overcome:
1) The Technology
It is essential in any EDI integration project with Salesforce to be using good technology; that is scalable, flexible and easy to use, with little training necessary. Such technologies exist in the IT marketplace and if properly used, it can be leveraged to save a lot of time, effort and money in the integration process. The ideal tool should be able to interact with XML and Salesforce and all its interfaces (API, SOAP…).
2) EDI via AS2 or VAN
The second issue to consider during an EDI integration project with Salesforce is in regards to the communication protocol to transmit EDI data between you and the retailer. More and more, retailers such as Amazon, Wal-Mart and Sears, are mainly offering AS2 connectivity for suppliers wishing to exchange EDI with them. AS2 is a protocol of secured communication of EDI files from point A to point B. When setup and implemented correctly, this kind of implementation saves a lot of money.
However, most often, companies go with a VAN due to the retailers’ incompliance with AS2. It is difficult to do business with these big players without them enforcing their rule by using the service of EDI VAN to all their suppliers. Therefore, the choice to even go with a third party service provider is not given but it does exist.
3) EDI Translation
The EDI translation and integration into the Salesforce databases is the biggest challenge of all. It truly takes some major evaluation and analysis of the situation before beginning. One major question to consider and ask is whether to do the EDI translation and mapping on-premises or as a service. Of course, it all depends on the company’s budget and the capacity of the company’s IT team and knowledge of EDI communication. Also, another consideration is the type of technology. Nowadays, there are experienced service providers that are capable of taking on the service of:
- Receiving EDI transactions from the retailer
- Processing the EDI files
- Translating the EDI files and integrating it into the company’s Salesforce system
What’s Next?
As you might know, a lot of parameters are involved in EDI integration projects, whether you want to integrate with Salesforce or any other software application. A professional opinion from EDI experts is important and very much needed for any business.
Namtek’s IT & EDI Consultation is free and at your convenience. Do business the right way – contact us today.
In today’s article, I will be addressing the best option to process EDI data, exchanged between business partners, by identifying the advantages and inconveniences of two methods; an EDI Service Bureau and a Translation/Integration solution.
It’s not a surprise to business people that exchanging business data using EDI protocols and formats has been around for a while and is clearly here to stay. If you’ve stumbled upon this EDI article, then you are perhaps either interested in enhancing your EDI capabilities or looking to implement EDI in your business environment. Either way, it is proof that EDI is still in demand in the business community.
As this is my first time addressing EDI through a Service Bureau in my blogs, I will clearly define and explain what a Service Bureau does and provide my opinion on the topic.
EDI Service Bureau
EDI Service Bureaus have been around for many years. They were created as a third party provider sitting between business partners. How it works is simple. The Service Bureau receives EDI data from one partner to process into a human readable format (on behalf of the destination partner) and then send out to that destined business partner.
How A Service Bureau Processes EDI Data
As mentioned above, upon receiving the EDI data from a VAN or directly from a business partner, a Service Bureau will take that data and process it to generate a format that is agreed upon by the destination partner. The most commonly used formats are:
- Paper document
- PDF document
- Excel format or CSV (Comma Separated Values)
- Web-based document
Once the EDI data received by the Service Bureau is translated to one of the above formats, the Service Bureau would then transmit the translated document to his client (final destination partner) using one of the following methods:
- Fax
- FTP or sFTP
For outgoing EDI documents, the partner would return the information to the Service Bureau in the same formats as mentioned above (i.e. paper, PDF, Excel or CSV documents). Nowadays, some Service Bureaus provide web-based interfaces for their clients, to manually enter the data in order to generate outgoing EDI files to be sent to their partners.
How Businesses Process Data Received From Service Bureaus
Depending on which format the Service Bureau translates the EDI data into, the business partner would have to deal with it differently. Here are the possible scenarios for incoming EDI documents:
- If the data is treated in a web-based format, the business would need to login to the Service Bureau web portal, retrieve the data (orders, invoices, etc.), print or export the document, and then either key it in manually into their own management system or import it from CSV, only if their internal system supports this kind of process.
- When the EDI converted data is sent as a paper document or PDF (received by either fax or e-mail), the user will then have to key the information received in manually into their system, without question.
- When the data is received in Excel or CSV format, the user can either key in the data manually or import it into his internal ERP system.
The same concept applies for outgoing EDI documents through Service Bureaus. In all cases, the business has to either key in data in Excel or manage it through a web-based interface provided by the Service Bureau.
Service Bureau Inconveniences
As you may have noticed by now, exchanging EDI via a Service Bureau is not the most efficient way of communicating with business partners (click to tweet). In fact, the likelihood of human errors and inefficiencies are very high. In this day and age, where there are constant improvements in technology, it is extremely inefficient for SMEs to be keying in orders received by EDI (through paper document or PDF) (click to tweet). Even with the web-based alternative that Service Bureaus offer, it is still unproductive to manage multiple systems rather than having one single platform with full EDI capability.
Read: Convert EDI to XML: the Winning SaaS Option
EDI Translation & Integration
Once businesses have switched from using a Service Bureau to implementing an EDI translation and integration solution, they have eliminated all kinds of inefficiencies and human errors and have become much more efficient. The way it works is by having a fully integrated business solution in place that has built-in capability to process incoming and outgoing EDI documents. Refer to my previous article entitled See What It Means To Be Fully Integrated with an Efficient Business Software Solution that expands more on integrated solutions.
However, it is very common for business owners to be hesitant to implement a fully integrated solution into their small business, as they believe all ERP systems are expensive. That is simply not the case anymore, as we are in 2014 and IT solutions have become very affordable. EDI2XML offers affordable EDI integration that fits into the budgets of small and medium sized businesses (click to tweet).
What Is The Best Option: EDI via a Service Bureau or a Translation & Integration method?
As a professional IT consultant and developer, I have helped many small and mid-sized businesses streamline their business processes for over 20 years. I truly believe a fully integrated process and solution would be the best option to go with. Not only is it more efficient for your company as a whole but is also affordable. I have already published my arguments in a previous article entitled EDI integration projects: Advantages and Benefits.
If you are interested to learn more about this topic or any other issue related to IT or EDI, please click on the image below and I will be more than happy to contact you for a FREE consultation.
This post was updated to reflect current trends and information.
As an EDI expert, I receive many questions related to deployment of the EDI software. “Should our business go with on-premises or “in the cloud”?” As many business executives are not sure which way to go, I have listed a few questions that will make their EDI deployment decision easier.
Below are the right questions to ask yourself in order to make the best decisions for your company when it comes time to implementing EDI software.
Please note: if your major problem is how to integrate EDI with JDE, please refer to my previous blog entitled, ‘How to Solve the Biggest EDI Integration Problems with JDE’.
1. Do we have the proper in-house EDI expertise?
Before making any decision about how to deploy EDI2XML, Namtek’s EDI conversion solution, or any other EDI software internally, one should ask the very basic question: Do we have an IT professional in-house with a basic understanding of EDI? A basic understanding is all an IT expert needs when dealing with EDI2XML on premises.
2. Do we have the expertise to work with XML?
The second question is of course asking whether your internal IT team has the necessary capabilities and expertise to work with XML and its schemas. An IT professional having expertise in XML is much more probable than EDI expertise. However, never assume, as it is always best to confirm this beforehand.
3. Do we have enough time for our IT resources?
Once you realize you have an in-house IT team with the expertise in EDI and XML, you need to evaluate if they have enough time to handle an EDI implementation project. Many executives underestimate the time and effort involved in EDI communication, especially if their IT team is handling other priority projects and tasks. The same question should be asked if the company does not have an in-house team and has hired outside IT consultants for their day-to-day IT needs.
Read: SaaS EDI or On-Premises EDI Translation Software: What you should know
4. Do we have the necessary IT infrastructure?
Another very important factor to consider before deploying EDI translation software on premises is your company’s current IT infrastructure. If your current hardware and infrastructure cannot support an EDI software solution, then it is time to invest, which can of course add more costs to your project’s budget. Nowadays, many business executives do not want to worry about this and have opted for “cloud-based” software services. Adopting SaaS solutions (Software as a Service) does not require any investment in IT hardware and infrastructure.
5. Can my current ERP software handle EDI integration?
Any time there is an integration project within a company, a crucial question to ask is if your current ERP software (if your company even has one) can handle EDI integration, or any add-on software integration. If your company is still running a legacy software system or out-dated software, with no support and maintenance, integration becomes very difficult. The best way to go for any integration project, including EDI, is to begin with an upgradable and scalable management software solution where integration is easy and quick.
Please review my article about the importance of fully integrated software in a business of any size.
Where do we go from here?
If you’ve answered “YES” to all 5 questions above, then your company is suited for an on-premises EDI implementation process. However, if you’ve answered “NO” to at least one of the questions, then it is best to go with an EDI conversion service that does the complex work while your team of IT consultations take care of the integration with your internal software system. If however you do not have an internal IT team, then simply go with an EDI software solution “in the cloud” with full service. At this point, you wouldn’t need any IT infrastructure or in-house IT team as all you would need to do is hire an outside team of EDI experts to implement and handle the EDI communication. Please check out our EDI2XML as a Service for more information on how an EDI solution “in the cloud” works.
If you need further help in determining what the best steps are for your company, I am be happy to offer my team’s long time EDI and systems’ integration expertise for a Free Consultation.
This post was updated to reflect current trends and information.
Why convert EDI to XML?
In this blog post, I will explain why our team decided to convert EDI to XML as well as the advantages and benefits of using this conversion from EDI to XML. On many occasions, EDI consultants, project managers and EDI developers and implementers brought up the following questions:
What are the benefits of having an EDI X12 file format converted to XML?
Why do we need to convert from EDI to XML and not to a database, csv or other file formats directly?
Quick review of EDI2XML
As you might already know, EDI2XML is a technology to convert X12 EDI to XML for incoming EDI documents. At the same time, the engine is intelligent and capable of converting an XML document to an EDI X12 format. This process of turning an X12 EDI file to XML happens because we have taken the time to build pre-defined xml schemas (xsd files) that respond to the business needs of 99.99% of EDI consumers.
EDI developers and integrators are able to use any loop, node or element they need to push to their database for incoming EDI documents. While for outgoing EDI documents in XML format, they are able to pick and choose the node, or EDI element they want to transmit out, fill it in, and send over to EDI2XML engine in order to create the EDI file in X12 format.
Read: Best EDI Processing Options: Service Bureau VS Translation & Integration Solution
Convert EDI to Database or other formats
In the beginning stages of development, we established a list of objectives and a list of possible formats we can use. This was essential, as we needed to evaluate which file format would be best to use as a destination format for incoming EDI documents and outgoing EDI documents.
Objectives to convert EDI
We wanted our EDI conversion technology to respond to the following criteria, as much as possible:
- Cross-platform: could be triggered on multiple platforms (at least Windows and Linux)
- Scalable: easily upgradable without the need for heavy work and programming to add a new document or process
- Portable: could run without any limitation on database, file format or operating system
- Simple to operate and launch: at the time, we wanted to have the solution as simple as possible so no need to have a very extensive EDI expertise and knowledge in order to work with our EDI conversion tool.
Options for EDI conversion
Below is the list of formats we had put together when we started the R&D, during our brainstorming sessions prior to developing the engine to convert EDI.
- Convert EDI to Database: this was the first option we had in mind since it was simple and easy to deploy. However, we went into the limitations of portability and compatibility as well as the choice of the Database. What database is the most portable?
- Convert EDI to CSV: option #2 was also on the table early on, since the csv format is commonly known and heavily used. However, because of the quality of data that anyone might receive within an EDI transmission (carriage return, line feed, special characters…), which might cause the data to be a little less “sanitized”, we opted out of this option and eliminated this format from our list.
- XML: this was the last option we had on the table. We decided that this would be the best choice due to its flexibility, good structure and ease of use. It responded extremely well to all our technological objectives and more.
Why EDI to XML
Read: Free EDI to XML converter: What’s the catch?
There are many reasons why we selected the XML format as a destination to translate EDI, over other means. Following are some of these reasons:
Simplicity and self-descriptive: data encoded in XML is easy to read and understand by humans (i.e. EDI developers,) and it was becoming easier to process by computers
- XML format is standardized: XML is a W3C standard and it is endorsed by software industry market leaders
- XML is structured: No fixed tags; it represents perfectly the hierarchical structure of an EDI file.<
- Support of multi-lingual and Unicode: very important for exchanging EDI documents at the international level
- Rapid adoption by programmers and developers: since the use of XML was on the rise, converting EDI to XML was a good decision. Nowadays, it is very rare to find a developer or a consultant who does not work with XML
Having the ability to convert X12 EDI to XML gave us a competitive advantage over other developers involved in EDI projects. We have already implemented this converter in many businesses as well as helped IT consultants leverage EDI2XML in their EDI integration projects.
If you would like to know more about the plans offered for EDI2XML (Free Consultation), or would like to see it in action (live Demo), please do not hesitate to contact us.
This post was updated to reflect current trends and information.
Free EDI to XML converter
Recently, I have received many questions and inquiries about our EDI2XML technology and why it is not offered for “free” like many apps or tools available on the Internet. Just the other day, an acquaintance of mine was contesting that he could find another API for EDI conversion to XML, download it and use it “free of charge”. I decided to write this blog post to share my past experience with free EDI to XML conversion tools and hopefully give you more insight into why a Free EDI to XML converter is NOT a good option for your business.
Being an EDI professional, I realize and implement EDI projects. I have encountered many situations where I needed to accomplish urgent and quick results using any code I could find in the moment; library or API that can be downloaded quickly from the Internet for FREE! Everyone likes free things and I am no exception to this.
Therefore, during one of my first experimental EDI projects, I found a free tool to convert EDI to XML. Once I downloaded the tool, I started to work on how to turn EDI X12 to XML, and vice versa. Below are the observations I noted from that experience:
Limited help
After running the setup program, I hit a few installation errors. I then started the process of identifying these issues, however, I found this process to be very hard, long and tedious since only some of the errors were documented, while most of them were not. In addition, I had to write to the community of the support team. I received a reply two days later, which is a terrible response time if you are in a hurry. We found the issue to be some .NET compatibility between the installer and the operating system I had on my machine.
Features: fell below expectations
After the long installation process, I was finally glad that my Free EDI converter to XML was setup properly. It was now time to experiment its conversion features. Unfortunately, it wasn’t long before I was disappointed over the fact that this converter had many limitations. It was not converting the EDI to XML based on a format I was expecting. It simply put the XML tags before and after each EDI element and grouped each one of the segments into node. This is not any easier than working with raw EDI. In addition, the tool was not able to convert XML back to EDI. Therefore, the simple features it promised were not even working.
“Black Box” solution
I didn’t give up just yet. I then figured that if I can tweak the code through parameters or code modification, it could work. Unfortunately, that was not possible; I had downloaded a “black box” solution where I cannot do any modifications or tweaks to my needs.
Little or no support
At this point, I decided to contact, yet again, the community of support as well as the software developer. Unfortunately, the support offered by the developer was an expensive paying option. In addition, if I wanted to customize the engine, I would need to pay a high fee. Bottom line, I wasn’t left with many choices. I had to live with the community support, which was relatively good, but not like any commercial support where response time is on average 2-4 hours.
Read: Convert EDI to XML: the Winning SaaS Option
Lack of scalability
In the end, we hit a wall with the converter. In order for me to reach my expectations with this converter, I would need to pay for a custom job. Once it is custom made, scalability becomes on us, based on how much money we can invest in developing the tool and make it scalable. At this point, I was hesitant, since I would have gone from a Free EDI to XML converter to a very expensive tool. However, if we stuck with the basic free option, then it is quite clear, the EDI conversion tool would not perform, as we had needed.
Is it a feasible approach?
Having gone through all of the above, we took a step back to reassess what our options were. Should we invest in upgrading a Free EDI to XML converter or should we build it from scratch in-house?
We needed to ask ourselves if it was a feasible approach to have a business depend on a free tool, knowing in advance it is a “black box” without support and scalability.
Our answer was “NO”. This is when we decided to go ahead with our alternative solution.
EDI2XML, an alternative
Having spent much time exploring the possibilities of using a Free EDI to XML converter, we came to the conclusion that we would be better off building it ourselves. Our goal was to make it quick, easy, affordable and simple to deploy for us and for our clients with the capability of translating XML to EDI, and vice versa. Other pre-requisites were to ensure scalability and flexibility of EDI2XML as well as the availability of a great support team for EDI2XML. In the end, we succeeded! Our very own EDI2XML solution is offered as a Services and HTTP service for companies of all sizes.
EDI2XML Web Service is for developers and businesses, interested in building their own EDI (Electronic Data Interchange) integration flows and programs. Normally, these individuals, are capable of interacting with external API and Web Services to translate EDI to XML and XML to EDI, and have the resources and expertise to work with Web Services and HTTP requests in order to achieve their goals. EDI2XML web service, is the premier choice for IT people as a reliable service to accomplish such Integration projects.
