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:
These EDI standards have many subsets with focus on a variety of specific industries. These various industries include:
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. |
|||||
| Copyright 1999-2014 Amosoft EDI | Home | ||||
