SAP details: Events News - Training - World wide sites  - Sap Labs SAP Magazine  - SAP Screen saver - Stock Price
EDI is here to stay    (article by Prabha Jha)

"Electronic Data Interchange is here to stay. SAP has provided many tools to ease the integration to EDI subsystems and these, together with a methodology of how to implement EDI are described in the following pages."

Mystery EDI Unveiled:

EDI(Electronic Data Interchange) works by providing a collection of standard message formats and element dictionary in a simple way for businesses to exchange data via any electronic messaging service. 

EDI and e-commerce are miracle words in today’s IT world. Like any other mystery it draws its magic from the ignorance of the potential users. It is true that there are many fortune making companies in the IT world who specialize on EDI. They sell software and know-how for giant sums of money. Looking behind the scenes reveals, that the whole EDI business can simply be reduced to writing some conversion programs. This is not too easy, but the secret of EDI companies is, that the so-called standards are sold for a lot of money. As soon as you get hold of the documentation, things turn out to be easy.

Internet enabling, or e-enabling, enterprises and applications to form trading networks and marketplaces is not a trivial task; it is a challenge, especially when you wish to develop it as a product.

Electronic Commerce actually began in the early 70's when companies began completing business transactions via networks. This was referred to as Electronic Data Interchange or EDI. As time went on, EDI began to evolve into transaction processing over the Internet rather than through networks. This is where the term Electronic Commerce was born. Traditionally, the term EDI is still used for transaction processing over networks. Now the term Electronic Commerce is used to describe transaction processing over the Internet.

A definition

"Electronic Data Interchange (EDI) is about doing business and carrying out transactions with your trading partners electronically. EDI covers most things that are traditionally done using paper-based communication." 

"EDI is described as the interchange of structured data according to agreed message standards between computer systems, by electronic means. Structured data equates to a simple and direct method of presenting the data content of a document. The method of ensuring the correct interpretation of the information by the computer system is defined by the EDI standard." 

"EDI is a technique used to communicate business transactions between computer systems of different companies and organizations. Note that sometimes the EDI mechanism deployed at a company is often used to interface to other systems within the same organization." 

What is EDI? (A comprehensive definition).

Electronic Data Interchange, or EDI, is the electronic exchange of business data. Using a standard format, EDI provides a method of transmitting business data from one computer to another, without the need to re-key data. This electronic link can result in more effective business transactions. 

What does "more effective" mean?

"More effective" means potentially time-saving and money-saving. With EDI, paper transactions can be replaced with electronic transmissions, thus time is saved, and the potential for error is minimized. Data can be exchanged at any time. Related business expenses, such as postage, printing, phone calls, and handling, can also be significantly reduced. EDI can aid in the support of manufacturing efforts, such as Just-in-Time and Third Party Warehousing, and financial efforts, such as Electronic Payments.

Some thoughts

One should not to attempt to switch to a full SAP EDI implementation overnight. It takes time for people, systems, and processes to adapt to any new methodology. Implementing SAP EDI is a project in its own right and needs to be handled phase by phase as in any other information system implementation. We describe some of the issues and how to implement an SAP EDI solution in the following pages. 

The painful issues of implementing EDI are considered to be:

         Application level configuration - Message control, partner determination, output determination

         Technical configuration - Just getting the systems to talk to each other. SAP, translator, modem...

         Testing - How do you test with someone you may never meet? How do you do your own testing without sending data to your partner? How do you differentiate between a test message and a real one?

·         M.Mapping - How do you map an IDoc to an EDI message? What fields go where?  

Two types of EDI

In summary, there are TWO types of EDI:

· Manual (printed) EDI.

Where EDI messages are sent automatically, but messages are printed out by recipient for processing. This type of EDI can be "switched on" in one day.

· Integrated EDI.

Where EDI messages are sent automatically and are received by recipient for automatic processing. This type of EDI requires both parties to have advanced systems.

Most organisations are currently pushing "Manual EDI" only. This has commonly been referred to as "just another FAX machine only more complex and expensive!".

Why implement EDI?

         Improves data accuracy: You can eliminate the need to re-enter data from paper documents and thus prevent potential data entry errors. It is estimated to be one-tenth the cost of handling its paper equivalent.

         Reduces technical complexity: With EDI, companies use standardized data formats to exchange documents. EDI allows companies using different systems to achieve computer-to-computer electronic exchange of business documents.

         Lowers personnel needs: EDI can help companies reduce the need for personnel involved in paper business transaction processing.

         Accelerates information exchange: The lead-time between start and completion of order processing is greatly reduced. By timeout scheduling companies can plan production more accurately and thus reduce stock inventories.  

What parts of the business cycle can be supported by EDI?

Most business documents that are currently exchanged using paper can probably be supported by EDI. Standards exist for electronic documents and are defined for a wide variety of paper-based communications. Standards include ANSI X12 and EDIFACT. ANSI X12 is primarily used in the United States, while EDIFACT is used in Europe and Asia. The EDIFACT standard is becoming a global EDI standard.

What industries are using EDI?

Any company that buys or sells goods or services can potentially use EDI. Because it supports the entire business cycle, EDI can streamline the relationship that any company has with its customers, distributors, suppliers, and so forth.

The retail, automotive, grocery, freight, and financial industries were early users of EDI. The electronics industry and the U.S. government are currently big users of EDI.

Now the question arises.

Should our company use EDI?

EDI offers many potential benefits. EDI is a productivity tool that is beneficial to both suppliers and customers. It is a service to customers and is often viewed as an indicator of technical ability. 

What kind of software is needed to implement EDI?

EDI translation and communication software is available for most computers, whether PCs, minicomputers or mainframes. Basically all EDI software packages do the same thing. Translation software translates business documents into a standardized format that complies with ANSI X12 or EDIFACT, and communication software sends and receives documents.

What kind of hardware is needed to implement EDI?

Hardware selection is dependent upon your preferences for speed, operating system, and level of integration with the current systems. The EDI system may be able to run on your existing hardware.

What is the flow of EDI?

The flow of EDI depends on the sophistication of your systems and your EDI software. If you have internal purchasing/order entry systems, you will need interface programs that can extract and insert data out of and into these systems. EDI programs that interface with your internal systems are preferred over software that requires re-keying of data.

Using a purchase order as an example of a business document you would send to us, the flow of EDI documents is as follows. A purchase order is first created in your internal purchasing system. Your purchasing system communicates the order to your EDI software in a specially formatted syntax. Your EDI software then creates an EDI standardized document and sends it to a predetermined VAN. (A VAN, or Value Added Network, is a third party company whose job it is to receive, store, and forward documents for interchanges between trading partners.) Using EDI communication software, we dial the VAN at predetermined intervals and receive all waiting documents. These documents are then processed through our EDI translation software and output to our order entry system. Finally, an EDI document called a functional acknowledgment is sent to you as a receipt of the purchase order. 

Range of Applications

Any business document or information can be exchanged via EDI. The criteria The Fresh People consider in deciding what applications or processes to convert to EDI are:-

· High Manual Administration Labour Content.

· High Transaction Volumes.

· High Error Frequency.

· Highly Critical Information.

· Highly Time Consuming.

· Highly Repetitive.

· Unnecessary Steps Eliminated.

The effectiveness and success of EDI is measured by the degree of integration of EDI as the communication mechanism for the business systems. The extent of this integration is the true measurement of a successful EDI program and will be the driving force.

The focus is upon the interchange of data as opposed to simply electrifying the exchange of paper documents. 

SAP R/3 Business Software and EDI: 

SAP R/3 does not have its own built-in EDI logic, but instead it provides a clearly defined interface which third-party vendors can use to integrate their systems, providing an 'EDI sub-system' for SAP R/3. SAP provide a certification programme, so individual products from third party vendors can become 'SAP Certified', meaning that they comply with the interface correctly. A list of certified EDI subsystems is available on the SAP web site.

The EDI interface is used to connect an EDI subsystem to the SAP system. EDI subsystems perform all EDI-related tasks such as Converting the data Handling messages or interchanges Communications Managing the partner profiles Monitoring processing. The EDI interface is based on IDoc technology. IDoc technology is independent of EDI standards. All data is exchanged via files between the SAP System and the EDI subsystem. The synchronous RFC (remote function call) is used to define the time of transfer of the files between both systems. Via the EDI interface, the following data can be exchanged: 

         Outbound IDocs. IDocs are transferred from the SAP System to the EDI subsystem.

         Inbound IDocs. IDocs are transferred from the EDI subsystem to the SAP System.

         Status report. To inform the SAP System of the progress of processing of the outbound IDocs, the EDI subsystem transfers the status report to the SAP System.

The object of the certification is the technical test of the interface between SAP System and EDI subsystem. The transfer of outbound IDocs, inbound IDocs and the status report are tested. The test is performed for the EDI standard UN/EDIFACT. As an example, the messages used are:

         Outgoing order (ORDERS)

         Incoming order (ORDERS)

         Outgoing order response (ORDRSP) and

         Incoming order response (ORDRSP).

EDI technologies have evolved as a data carrier replacing the paper document. It is not a new concept or a new practice. EDI has existed for more than 2 decades in Europe and North America.

Early electronic interchanges used proprietary formats agreed upon between two trading partners requiring new programs each time a new partner was added to the existing system. Later on some industry groups began a cooperative effort to develop industry EDI standards for purchasing, transportation, and financial applications. Many of these standards supported only intra-industry trading, which led to a large number of EDI formats.

In 1979, the Accredited Standards Committee (ASC) X12 was formed to develop a generic EDI standard. In 1993, Version 3, Release 4 contained 192 standards. There are over 100 additional standards in development. In the U.S., the most commonly used standard is ANSI X12, coordinated by the American National Standards Institute (ANSI). While in Europe, it is the Electronic Data Interchange for Administration, Commerce, and Transportation (EDIFACT) standard. SAP maps it message types by EDIFACT naming conventions.

IDoc or Intermediate Document is a standard SAP document format. IDocs allow different application systems to be linked via a message-based interface.

There are three main aims behind the use of IDocs:

         The structured exchange of business documents so that they can be processed automatically.

         The various degrees of structural complexity as displayed by different application systems can be reduced to a structure which is as simple as possible.
Example: the structure of an SAP application document and the structure of the corresponding EDI message under the UN/EDIFACT standard.

         IDocs allow for extensive exception handling before the data are posted to the application.

IDocs are defined and considered on two levels, the technical and the business level. The former allows them to support application-independent functions, e.g. routing and handling technical exceptions.

         Technical level
Defined by the three record types compatible with the IDoc interface:

         Control record

         Data record

         Status record

         Business level
Defined by the segments of an IDoc. Segments are structures used to interpret field SDATA in the data record. An IDoc type is defined by the relevant:


         Attributes of these segments
(e.g. maximum usage, hierarchical sequence, segment status)

The Problem

Enterprises today are burdened with a set of problems that leaves IT managers and CIOs with the daunting task of making heterogeneous computing environments communicate with each other. Furthermore, they face the challenge of leveraging their legacy and ERP investments while trying to achieve internal integration (front office to back office). Also of paramount importance to businesses these days is "external integration," or business-to-business (B2B) -- the integration of buyers, suppliers, marketplaces, and the imminent "S" word, the "supply chain."

These problems affect most businesses and organizations today. But what are the shortcomings of traditional technologies, such as electronic data interchange (EDI) and enterprise application integration (EAI)? EDI provides point-to-point solutions that are both expensive and inflexible. In addition, EDI transactions are not real time and are difficult to implement. The problem with EAI products is that they are inwardly focused and do not support cross-enterprise integration. Also, for EAI to work, both sides of the "pipe" require proprietary software. ERP and other enterprise applications have similar inherent shortcomings; they provide no support for external integration. And if you are wondering about the HTML-based e-commerce Web sites, their problem is that they are manual, tedious, and error prone. Although these arguments are debatable (especially around EDI), early deployment of next-generation technologies such as webMethods B2B has illustrated that these traditional technologies are insufficient when compared to the newer tools.

Now a day companies like webMethods solution comprises three products: webMethods B2B, webMethods B2B for Portals, and webMethods B2B for Partners. These products achieve integration between enterprises, provide an integration platform for marketplaces, and offer rapid integration with trading partners, respectively. These products also support multiple protocols: EDI, XML, commerce XML (cXML), RosettaNet, and the like.

WebMethods and SAP


When SAP realized the need to e-enable their solutions, it entered into a strategic alliance with webMethods as a development partner for B2B e-commerce and integration. Furthermore, SAP invested in webMethods. This partnership provides for licensing and joint development of products, such as SAP Business Connector (the transaction engine for and SAP B2B eProcurement. Although webMethods does develop connectivity products for other ERP systems, webMethods has a pool of developers and architects based in Walldorf, Germany, the headquarters of SAP AG.

SAP Business Connector

The SAP Business Connector is a comprehensive, jointly developed product with several features that e-enable SAP solutions. (See Figure 1.) It is completely integrated with the R/3 system and provides for both synchronous and asynchronous communications. The product supports remote function calls (RFCs) and transactional remote function calls (tRFCs), which are transparent to the system. It also enables the integration of R/3 with New Dimension products over the Internet. In addition to routing intermediate documents (IDOCs) and RFCs, it plays a vital role as's portal connector. As a basic function, it lets you convert application link enabling (ALE) and BAPI messages to XML, and vice versa, while supporting the IDOC and BAPI XML specification. Because it exposes the R/3 system through XML, it provides the capability of interfacing the R/3 system with non-SAP systems. No XML standards have been approved yet, but the SAP Business Connector is supposedly adaptable to evolving standards (although this ability remains to be seen). Internet security is bundled with these features, as well.
The SAP Business Connector comes with easy-to-use tools and nifty GUIs that make most of the development "drag and drop" or "point and click." For example, mapping RFCs from the R/3 system is a three-step process wherein you look up the RFC from a panel, construct an inbound map, and specify the interface and service to invoke. The B2B Developer tool provides visual data-flow and transformation services (see figure 2). Along with providing the capability of mapping IDOCs and RFCs to XML structures, it also lets you perform structural, value, and name transformations of the data in the

FIGURE 1 SAP Business Connector.

Pipeline. This tool can be used as a test bed for B2B services. One perform data mapping by pointing the IDOC fields on the left-hand side column to the XML fields on the right-hand side. What remains to be seen is if webMethods will provide prepackaged mapping for standard business documents based on its deployment of solutions across industries or specifically within an industry. (This prepackaging is already available with certain EAI vendors such as CrossWorlds and Active.) This feature would definitely add value to the product. Another aspect of the SAP Business Connector is the Routing Rule Manager that provides

FIGURE 2 Visual data flow and transformation.

robust methods for routing messages and data from various sources to different destinations. Creating routing rules entails specifying several entries on a panel, such as sender, receiver, message type, and destination URL. The routing rules specify the preprocessing invocation, transport method, XML dialect, and so on. The SAP Business Connector also serves as a message store of all data flowing through the software and contains logs of its "transactions." The audit log records all the states and processes the data has been through

Is EDI the Answer, or Part of the Problem?

At the beginning of the 1990s, publishing appeared, compared to many other businesses, to be grossly unwieldy, unpredictable, unprofitable, out of control -- in short, chaotic.

Here was an industry afflicted by huge advances that led to disappointing sales, skyrocketing returns, loss of vision, and loss of control in the distribution

Channel, which meant that some important trading partners were forced to wait as long as 180 days to be paid for their products.

Top management of the large publishing houses, many of whom came from other industries, felt that things must change.

One of the chief forces driving that opinion was the development of computer systems that promised Electronic Data Interchange (EDI): the exchange of completely electronic information among trading partners regarding job specifications, purchase orders, job status notifications, invoices, advance-ship notices, paper usage, and component inventory. Data about customer behavior, channel costs, production processes, and the like would flow easily and instantaneously. By tapping those rivers of data strategically, and analyzing their patterns, it would be possible for publishers to create new and better products, marketing, and channels of distribution, which in turn would increase sales, revenues, and profits.

Peter Olson, CEO of Random House, the largest publishing house in the world, was quoted in a U.S. News & World Report article: "We saw a need (five years ago) to have an integrated system that would provide, at the push of a button, information that would go throughout the company and be available to customers if necessary."

If that is the dream, how do we get there? The answer that major publishers are currently embracing is: re-engineering through the adoption of "enterprise-wide" software based on relational databases. Relational databases can be very powerful tools, and an enterprise-wide approach should generate the greatest strategic control and efficiency.

The relational databases with which most people are familiar are those checkbook programs that automatically add to your balance after you enter every deposit, subtract after you enter every check or ATM withdrawal, and keep your balance information always accurate, up-to-date and instantly available.

Can the hugely complex business of publishing, with all its facets of creation, production, and distribution, be similarly modeled? As Jonathan Newcomb, CEO of Simon & Schuster, explains: "If you don't understand where exactly you are in all your copyrights, how much you put into each project, and how much has to go back out for rights and permissions and advances and royalties, and how much you're going to invest in plant and paper and printing and binding, and what the likely returns are going to be from each project -- and each project is different -- if you can't track that incredibly complex matrix, then you aren't going to be able to be successful in this business. 

How EDI can help:

EDI will enable re-engineering of business processes.

Or EDI can simply automate existing business processes. The big value of EDI is in enabling re-engineering.

EDI can automate business existing business processes

         Decreasing data entry costs

         Decreasing document costs (printing, mailing, etc.)

EDI can improve customer service

         Provides data so customer can automated/re-engineer their business processes

         Creates a competitive advantage over other suppliers

         Increases relationship with customer (creates barriers of entry for other suppliers)

EDI improves inventory control (and inventory turns) by updating the stock requirements list

         Inbound PO acknowledgment

         Inbound shipping notification

EDI can be used to communicate with carriers

         Shipment status

         Inventory forwarding

         Release/consolidation of forwarded inventory

EDI Re-engineers the order cycle


         Vendor Managed Inventory (VMI) outsources inventory control for purchased items to the vendor

         Lockbox outsources the accounts receivable process to the financial institution

         Payables (EDI or EFT) outsources accounts payable function to the financial institution

Replacing Inventory with Information

         Communicating MRP forecast information to vendors decreases inventory in the pipeline due to demand spikes

Enabling SAP transactions for EDI usually takes three weeks (per transaction)

         Assumes that the SAP transaction is EDI enabled. Non-enabled transactions will take longer due to the development effort.

         This depends on the gap between the data exchanged and the data SAP stores in its database (as well as gaps created/removed through SAP configuration).

EDI enabled transactions provided in 3.0E include



Sales order

Purchase order

Sales order change

Purchase order change

Purchase order acknowledgment

Sales order acknowledgment

Shipping notification

Shipping notification



Lockbox (remittance advice)

Payables (EDI & EFT)

Customer ship to setup

Releases against scheduling agreements

The tasks for distributing data via EDI are


         Gap analysis

         Core configuration

         Message specific configuration

         Development to fulfill gaps (as needed)



IDocs, A Universal Tool for Interface Programming:

Although R/3 IDocs had been introduced as a tool to implement EDI solution for R/3, it is now accepted as a helpful tool for any kind of interface programming. While this is not taught clearly in SAP’s learning courses, we put our focus on writing an interface quickly and easily.

The EDI interface is used for the connection of an EDI subsystem to a SAP system. EDI subsystems take over all EDI oriented tasks like

         Conversion of data

         Message and interchange handling


         Administration of partner profiles

         Monitoring of processing

The EDI interface based on the IDOC technology. The IDOC technology is independent of EDI standards. All data exchange between the SAP-system and the EDI subsystems is handled via files. The synchronous RFC (Remote Function Call) is used to determine the date of disposal of the files between the two systems.

Following data can be exchanged via the EDI interface:

IDocs transfer to the EDI-subsystem by the SAP-system.

IDocs transfer to the SAP-system by the EDI subsystem.

         Status report
To communicate the process of adaptation to the SAP system, the EDI subsystem transfers the status report to the SAP system.

Once a decision has been made to implement EDI within your company, you will:

         Establish your own plan for implementation.

         Purchase or develop EDI software.

         Determine and assign internal resources required to implement the program.

         Select a Value Added Network.


The following is a list of questions that our company should consider prior to making an investment in an EDI program. The answers to these questions will impact the resources required, the financial investment to be made, and ultimately, the success of EDI within our company.


How soon do we need to have some type of EDI capability?

Many companies find their initial venture into EDI is in reaction to a request from a key trading partner. If you do not currently have a program in place, but wish to satisfy needs of your trading partners, you may want to implement an interim EDI Program to pilot the use of EDI in your company.

In which functional areas should we focus our attention?

Unless we are willing to invest a number of resources into EDI initially, consider focusing efforts in either the Purchasing area (your company as the Customer) or the Order Management area (your company as the Supplier).

Which transaction sets should we send/receive? The priority of implementing a particular EDI document will be determined by the volume of paper documents processed, trading partner requirements, and other business needs.

Are we anticipating a major systems change in the near future?

If so, you may want to delay full-scale integration of EDI and develop an interim approach.

What is our timetable for implementing EDI within each functional area?

Will our internal business systems support EDI? Business systems with import/export capabilities or MIS resources to develop these capabilities are essential to a full-scale integration of EDI.

Will implementation of EDI require that we purchase additional computer hardware?

In most cases, existing hardware can be used. Ultimately, this will be determined by your selection of a software option.

A Value Added Network provides the service of storing and forwarding EDI documents to and from Trading Partners. VANs often provide additional services, such as audit reporting and translation. Typical costs are dependent upon volume, at a minimum cost of approximately $600 per year. While you may want to select a VAN that is currently being used by your key trading partners, most of the major VANs have agreements to "interconnect" with their competitors, so you should not feel restricted in choice of a VAN. When interviewing VANs, user will want to verify they have agreements to interconnect with the VANs used by partners and determine what additional costs are incurred for the interconnect.

EDI only specifies a format for business information; the transmission of the information is covered under other standards. A real world analog is sending a business form from one company to another. The "form" could be sent via US mail, US Registered mail, via private carrier (UPS/FEDEX) or simply faxed between the companies. EDI only requires that the trading partners follow the content standards

All VANs connected to the Internet are connected to one another, thus avoiding most of the problems of interconnecting proprietary networks. VANs can then focus on services to their customers such as automatic bid submission, market and business opportunity analysis, and translation software.


SAP professionals are finding that the integration of SAP and EDI systems is fundamental to many of the e-commerce applications they are being asked to support. All too often, however, SAP teams do not have a working knowledge of their organization's in-house EDI subsystem, and vice versa.

This article aims to bridge that gap by providing SAP professionals with an understanding of the basic tenets of EDI technology, what capabilities an in-house EDI subsystem needs to provide, and the role they should be prepared to take in order to ensure a smooth and successful integration between these two systems.

A business can always be up-to-date with direct Internet procurement and prompt EDI support.

If the company identifies that accurate and punctual information about their suppliers' deliveries and shipments an advantage for the company, If They want to rely on the planned goods receipt in the MRP/Scheduling and if processing of their goods receipt with electronically sent delivery notes particularly effective?

EDI implemented with an EDI system like SAP is the ultimate solution as we have already realized while discussing that good integration will provide 

ü       Flexible and user-friendly Partner Customization

ü       Customer specific business logic in SAP R/3 Integrated SAP R/3,

ü       translator and labeling solution Automated processing of all important customer,

ü       supplier and banking EDI messages  

There is a tendency for each organization to establish is own rules and administrative policies, leading to rising costs of dealing with multiple trading partners, each in turn with its own requirements and procedures. However, new technologies and business practices are necessary if EDI is to move beyond the 30 to 40,000 organizations presently using EDI. According to Department of Labor and Internal Revenue Service statistics, there are about 6.2 million entities with employees and about 14 million other "business" entities. A business that wants to sell chairs, for example, would have to check with many different customers to see if they had any requirements. By making it possible for a business to use a common method to look for customers, the barriers entering to the electronic marketplace are greatly eased. This does not mean that there is only one source that everyone goes to for a list of current business opportunities. Rather, a prospective supplier only needs to go to a single electronic marketplace. To communicate with each other, the various participants in electronic commerce need to harmonize their procedures and processes. Examples include common trading partner registration and the adoption of standard implementation conventions for EDI messages.




















































































































































































































































































































































Home     Post an article    Suggestion   Contact
Disclaimer    Copyright; 1998-2002 Softron Systems, Inc. All rights reserved.
Home Discussion Forum Services Advertise Contact About Us Sign Up