Free EDI Training Guide
Careers | Contact | About | Home
 
Amosoft EDI Services Call (800) 761-4269 Login
 

EDI vs. XML

Article PDF Print Article Email Article

by Ray Atia, ratia@amosoft.com

First I want to start by saying XML will NOT replace EDI !!!

You don't have to look at EDI and XML as competitive solutions. They are, in fact, complementary.
When using the power and richness of XML to complement EDI, it opens the doors to all suppliers. This opens the option to create any-to-any data document type for all sort of suppliers. E-commerce needs standards and both EDI and XML are international standards which accepted around the world.

Electronic Data Interchange (EDI) enable companies to exchange electronic documents quickly between their trading partners (i.e. suppliers, customers, vendor and other), without human typing errors. What it means is that a document that previously used to take a few days to send and process on each side, now takes only couple of minutes to send/receive process, and to confirm as well.

EDI is a collection of standards, formats and file layout.
Currently there are multiple EDI standards around the world:
  • standard and its subsets (i.e. UCS,VICS)
  • HIPAA - USA only based standard for healthcare transactions. It is a subset of the ANSI X12 standard set with additional healthcare specific transactions.
  • EDIFACT - European Standards for electronic commerce.
  • TRADACOMS - UK based EDI standard - currently in declining use.

These EDI standards have many subsets with focus on a variety of specific industries. These various industries include:
  • Automotive
  • Healthcare
  • Electronics
  • Financial
  • Retail
  • Grocery
  • Transportation

The translation of data and business documents is vital to the smooth communication of data between companies. Today's documents can be stored electronically, translated to standard data formats, transmitted (via Internet, value added network or point to point) quickly, and processed by the trading partner's software applications.

In the past few years, many industry groups and various standards organizations have grasped XML as a way to ´┐Żameliorate´┐Ż basic EDI processing of documents. XML is a file with data format that is an approximate outgrowth of the Standard Generalized Markup Language (SGML). SGML is both a language and an ISO standard for describing information embedded within a document. HyperText Markup Language (HTML) is based on the SGML standard.

The main issue with XML, is the level of freedom introduced by the ability to build entire XML systems without any DTD at all. DTD (Document type declarations) are the very basis of SGML. DTD have been put into the standard because they very important tools in consistent design, reusability, exchange and data structuring.

Having XML without any DTD is an option. XML does allow DTDs. DTD design is time-consuming. It is expensive. It is skill-demanding. It pushes you to build long-term plans of your data. In many circumstance a death sentence against your prior data structuring practices, or lack of them. All these requirements go against the Web style.

The main difference between traditional EDI documents and the new versions of XML based EDI documents is the end use. Traditional EDI was designed for machine to machine interface. XML EDI was designed for human use, format and presentation of the basic EDI information; good for Web presentation and internet web-sites. These are two important opposed uses for a similar intended functional usage.

By adding XML, it adds layer upon layer of complexity; not to mention data element complexity. Comparatively, XML EDI is 100 times larger in byte data transfer requirements to transmit than traditional EDI.
XML EDI transactions are way more complex to process, although they are much easier to format for web presentation.

Converting traditional EDI documents to an XML documents substantially increases complexity, bandwidth requirements and confusing due to the fact that most XML documents are transmitted without a structured DTD. This means that each document must be translated by some type of custom software as opposed to the controlled form and format of traditional EDI.

Both traditional EDI and XML-EDI should co-exist. The functional usage of each type is separate and designed for different requirements. The replacement of machine to machine documents by human readable presentation formats makes for poor business efficiency. The vast majority of electronic documents should be machine to machine, maximizing the power inherent in this form of communication, XML-EDI transactions can be used over the web or by human, which are much fewer in volume and most of the time less significant in business financial impact.

Choosing which transactions should be formatted in traditional EDI or XML-EDI depends on the destination of each transaction. If the recipient is a computer, by all means use traditional EDI formats. If the recipient is a human that would manually go through the document data and interpret the information and possibly modify or enhance its content, then XML-EDI is the way to go.

Integrating EDI into a business process requires deep understanding of the business rules, regardless of the format or presentation of the transaction.
It is much more than a simple creation of an EDI map (the process that translates transactions electronically into a standard file format for electronic exchange).
Since many of the manual processes will change to electronic processes, well documentation and understanding automated business processes have to be implemented to compensate for the manual human process rendered during the manual or semi-automated transaction processing operation.
These processes have to be designed by a professional software engineers who understands the business processes as well as the technical requirements of the EDI process. If there is not enough expertise within the organization, it is a good idea to talk with a consultant with experts in the field of EDI implementation.
Once established the EDI process tends to be very stable and easy to manage.

EDI Software & Services   EDI Industries EDI Resources
EDI Software EDI Integration EDI for Retailers EDI Articles
Web Based EDI Solution EDI Outsourcing EDI for Suppliers EDI Documents
AS2 Software EDI Consulting EDI for Manufacturers Partners
ASN Software VAN Services EDI for Grocery Success Stories
QuickBooks EDI Software   EDI for Food Brokers EDI Overview
Microsoft Dynamics AX EDI Software   EDI for Logistics The Future of EDI
Microsoft Dynamics GP EDI Software   EDI Healthcare Supply Why should I use EDI?
Microsoft Dynamics SL EDI Software   EDI HIPAA More about EDI
Microsoft Dynamics NAV EDI Software     ASC-X12
SAP Business One EDI Software     DISA
SAP R/3 EDI Software     HIPAA
Oracle JD Edwards EDI Software     EDI Standards
Epicor Retail EDI Software     Employment Opportunities
Sage MAS 90 EDI Software      
Sage MAS 200 EDI Software      
Sage MAS 500 EDI Software      
Sage PFW ERP EDI Software      
Sage Accpac ERP EDI Software      
Sage Pro ERP EDI Software      
 

Get more business with EDI Outsourcing quote-blue.png
 
or call us (310) 862-4259
 

From our News


EDI Outsourcing: Outsource EDI Project
There are many benefits of EDI, and one of the most conspicuous benefits of EDI is that it is the safest way of transferring data and information to the recipients. Now, the web based EDI service is used comprehensively by the business companies across the world. However,
Read more...

11601 Wilshire Blvd. Suite 500

Los Angeles, CA 90025

Sales Inquiries: +1 800-761-4268

sales@amosoft.com

Contact Us arrow-yellow.gif


twitter-follow-us.png


map.png