Reliable EDI to XML converter solutions for seamless data transformation, ensuring compatibility and accuracy in your systems.

Tag Archive for: EDI to XML converter

What is EDI2XML web Service?

EDI2XML Web Service, is an HTTP service running over the internet, on EDI2XML own platform that is capable of receiving HTTP requests to translate EDI messages to XML, and XML messages (based on EDI2XML’s proprietary format) to EDI.

Our EDI Web Service gives developers the power they need to do EDI easily. EDI Web Service solution solves developer’s problem because we have an expertise in an EDI technology that is difficult for the developers to replicate. This solution enables to increase efficiency, and reduce cost of EDI implementation.

Read more about EDI Web Service here

Advantages of using EDI2XML HTTP service:

  1. Get started with less than an hour
  2. No contract: pay as you go
  3. Very simple and dynamic pricing scheme
  4. Availability and reliability
  5. Based on proven technology in the field for over 18 years now
  6. Outstanding technical support

Interested in our EDI2XML Web  Service?  Take the next step to request our EDI Web Service Price List.   This price list also includes an FAQ section for information about our EDI Web Service.

Looking for an EDI Web Service to translate EDI to XML, and XML to EDI? Get started with a 15- days trial of our EDI2XML HTTP Service, and start integrating EDI into your projects!

free edi web service trial


Related Posts:

API Web Service for EDI X12 exchange – Discover the advantages

SOAP or REST Web Services: what you should use for EDI implementation?

Seamless EDI implementation through Web Services

Download EDI Web Service overview

This post was updated  to reflect current trends and information.

 

Overview of EDI

EDI (Electronic Data Interchange) – standardized message formats for the transfer of commercial information between business partners. The two most common documents exchanged using EDI are purchase orders (EDI 850) and invoices (EDI 810). To transfer the EDI data, companies are often using the Internet or VANs (Value Added Networks). EDIFACT is the most popular EDI standard in Europe and ANSI X12 is in active use in North America. In the global  supply chain,  the GS1 EDI  set of standards are predominant. In brief, EDI allows companies to communicate business and commercial information quickly and efficiently.

Read: What is EDI? (A technical introduction to EDI)

Understanding XML

 XML (Extensible Markup Language) is a markup language that allows to standardize the data, in the form of text easily understood by users and computers. In other words, XML is a simple and flexible text format designed to meet the needs of electronic publishing.

XML has two main tasks:

  1. Provide a description of the data structure.
  2. Provide a common syntax for all other specifications.

Thus, XML does not specify how to display a document, it only describes its structure and content.

XML created in 1996 by W3C (World Wide Web Consortium); it is a subclass of the Standard Generalized Markup Language (SGML). XML was conceived to be a flexible format, at the same time as a formal metalanguage for use on the Internet. One of XML’s primary applications was in handling B2B and B2C data interchange.

From the beginning of XML implementation, its advantages over EDI were obvious. Simple and self-descriptive, structured, support of multi-lingual and Unicode (very important for international EDI transaction).

What is EDI2XML?

EDI2XML is a technology to transform incoming EDI documents (X12 EDI files) into XML. At the same time, converting an XML document to EDI X12 format. This process of converting edi to xml is due to the fact that our company took the time to create predefined xml schemas (xsd files) that respond to the business needs of almost 100 % of EDI consumers.

Read: How does EDI2XML work?

EDI2XML converter

The fact that we have over 20 years of experience in converting X12 EDI to XML gives us a competitive advantage over other EDI developers. We have already successfully implemented this converter in many companies of different sizes from various industries. We also helped IT consultants use EDI2XML in their EDI integration projects.

EDI2XML as a Service is our popular translation and communication service. All conversions of EDI files are done on our end, leaving customers with no on-site installation of software or hardware and an EDI project that is on time and within budget.

Read: EDI Integration of B2B e-commerce for small companies

If you would like to know more about the plans offered for EDI2XML (Free EDI Consultation), or would like to see it in action (live Demo), please do not hesitate to contact us.

Free Guide Intro to EDI


Related Posts:

Electronic Data Interchange: Key Information You Need to Know
ANSI ASC X12 Standards Overview
What Are the Differences Between ANSI X12 and UN/EDIFACT
A technical introduction to EDI


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
  • E-mail

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.

EDI solution and ERP

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.

2 copy

 

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.

Free EDI 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.


Free EDI Demo


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.

EDI2XML converter

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.

 


This post was updated to reflect current trends and information. 


A Technical Introduction to EDI

Before I start explaining anything about EDI2XML, I would like to start by giving a more technical introduction to EDI, its usage, and its history. EDI is an acronym for Electronic Data Interchange. It has been around for a long time and has been used by retailers and private corporations in several verticals (health, retail, insurance…). When people in the business community talk about exchanging “EDI transactions“, they refer to a combination of the following:

  • Structured EDI file format including version, revision, standard…
  • Protocol of communication, medium and security (FTP, sFTP, AS2, VAN)
  • Business partners (vendors, retailers…)

Simply speaking, EDI is the process of “electronically” exchanging documents between business partners in a pre-defined format. The information is transmitted in a secured manner. Normally, files with EDI format are structured and follow “EDI standards”.

EDI Standards

There are several widely used EDI standards, including:

  1. ANSI ASC X12: This is the predominant standard used in North America for various industries, such as retail, healthcare, transportation, and finance. It defines specific transaction sets like purchase orders (850), invoices (810), and shipping notices (856).
  2. UN/EDIFACT: This is an international EDI standard developed by the United Nations. It is widely used outside of North America and is popular in sectors like transportation, logistics, and customs. UN/EDIFACT includes a comprehensive set of message types covering various business processes.
  3. GS1 EDI: This standard is developed by GS1, a global organization focused on supply chain standards. It is used primarily in the retail and consumer goods industries. GS1 EDI incorporates the GS1 barcoding standards and provides specific message types for processes like product catalog synchronization, purchase orders, and invoices.
  4. HIPAA EDI: The Health Insurance Portability and Accountability Act (HIPAA) introduced specific EDI standards for healthcare-related transactions. These standards ensure the secure and standardized exchange of sensitive patient data between healthcare providers, insurers, and other entities.
  5. TRADACOMS: Developed in the United Kingdom, TRADACOMS is an EDI standard commonly used in the retail industry. It includes message types for processes like order management, stock control, and invoicing.

These are just a few examples of the many EDI standards available. Each standard has its own message formats, data elements, and communication protocols. Organizations typically choose the appropriate standard based on their industry, geographic location, and trading partner requirements.


Read: What is a VAN ?


EDI X12

EDI has been evolving with different versions, revisions and sub-revisions. For example, in the X12 standard EDI format, I started my EDI career with the EDI version 3010. Today, we are working with much higher EDI versions such as 4010, 5010, 5020… It is important to note that within each one of the above versions, different revisions might exist.

EDI Transactions and Documents

Read: How does EDI2XML work ?

EDI documents are “number coded”; for example, a Purchase Order sent by a retailer to a vendor using EDI format is coded under the number “850”. The same applies for other documents such as 810 (for invoice), 856 (for Advance shipping notice), 820 (for Payment Advice), and 860 (for Retailer triggered Purchase Order Change). The list goes on and it is not limited to the above. For a more extensive list of EDI documents that EDI2XML supports,  visit our EDI Document Library.

Each EDI document sent to a party has to be responded to by the other party by sending back a Functional Acknowledgment (FA 997). The 997 designates that the “structure” of the EDI file was certainly received, without looking at the “content” of the EDI formatted file. Both business partners understand the “content” of the information and they are able to translate into business terms. This is where EDI2XML comes into play to convert and translate the content and make it ready for integration.

To learn more about EDI, read our new blog What is EDI (Electronic Data Interchange)?” 


RELATED POSTS:

What is EDIFACT? | UN / EDIFACT standard overview

Electronic Data Interchange: Key Information You Need to Know

ANSI ASC X12 Standards Overview

What Are the Differences Between ANSI X12 and UN/EDIFACT