Electronic Data Interchange

The electronic communication of business transactions, such as orders, confirmations and invoices, between organizations. Third parties provide EDI services that enable organizations with different equipment to connect. Although interactive access may be a part of it, EDI implies direct computer-to-computer transactions into vendors' databases and ordering systems.

The Internet gave EDI quite a boost. However, rather than using privately owned networks and the traditional EDI data formats (X12, EDIFACT and TRADACOMS), many business transactions are formatted in XML and transported over the Internet using the HTTP Web protocol. See X12, EDIFACT, TRADACOMS, extranet, externalization, XML and HTTP.

Marketing Dictionary: electronic data interchange (EDI)

The exchange of information from one company to another using a computer network, such as the Internet. Electronic data interchange involves computer-to-computer exchanges of invoices, orders, and other business documents and therefore effects cost savings and improves efficiency because it minimizes the errors that can occur if the same information has to be typed into computers more than once. At the same time, EDI provides an easily accessible mechanism for companies to buy, sell, and trade information. In the business-to-business market, major corporations have embraced EDI systems, and in order to reduce costs and improve efficiency and competitiveness, many corporate giants are now demanding that their suppliers convert their sales and purchasing operations into EDI systems as well. In the retail market, the use of EDI systems allows the retailer to implement quick response strategies that can reduce the time they must hold merchandise in inventory, which can result in substantial cost savings for the retailer.

Accounting Dictionary: Electronic Data Interchange (EDI)

Transmission of business transactions from one company's computer to another company's computer. Transmission is achieved through an electronic communication network that uses translation software to convert transactions from a company's internal format to a standard EDI format. Companies that participate in EDI are referred to as trading partners. Trading partners may be involved in on-line banking, on-line retailing, and electronic funds transfer. There are paperless transactions in an electronic format. In the case of EDI, the auditor should be cognizant of the possible impact on the gathering of evidential matter.

Small Business Encyclopedia: Electronic Data Interchange

Electronic data interchange (EDI) is the electronic movement of data between or within organizations in a structured, computer-retrievable data format that permits information to be transferred from a computer program in one location to a computer program in another location without rekeying. EDI includes the direct transmission of data between locations; transmission using an intermediary such as a communication network; and the exchange of computer tapes, disks, or other digital storage devices. In many cases, content-related error checking and some degree of processing of the information are also involved. EDI differs from electronic mail in that an actual transaction is transmitted electronically, rather than a simple message consisting primarily of text.

EDI is used for electronic funds transfer (EFT) between financial institutions, which facilitates such common transactions as the direct deposit of payroll checks by employers, the direct debit of consumer accounts to make mortgage or utility payments, and the electronic payment of federal taxes by businesses. Another common application of EDI involves the direct exchange of standard business transaction documents—such as purchase orders, invoices, and bills of lading—from one business to another via computer. EDI is also used by retail businesses as part of their electronic scanning and point-of-sale (POS) inventory replenishment systems. Overall, EDI offers a number of benefits to businesses and—thanks to the rapid evolution of the related technology—is becoming more readily available to small businesses all the time.

Benefits of Edi

"EDI saves money and time because transactions can be transmitted from one information system to another through a telecommunications network, eliminating the printing and handling of paper at one end and the inputting of data at the other," Kenneth C. Laudon and Jane Price Laudon wrote in their book Management Information Systems: A Contemporary Perspective. "EDI may also provide strategic benefits by helping a firm 'lock in' customers, making it easier for customers or distributors to order from them rather than from competitors." EDI was developed to solve the problems inherent in paper-based transaction processing and in other forms of electronic communication. In solving these problems, EDI is a tool that enables organizations to reengineer information flows and business processes. It directly addresses several problems long associated with paper-based transaction systems:

Time delays—Paper documents may take days to transport from one location to another, while manual processing methodologies necessitate steps like keying and filing that are rendered unnecessary through EDI.

Labor costs—In non-EDI systems, manual processing is required for data keying, document storage and retrieval, sorting, matching, reconciling, envelope stuffing, stamping, signing, etc. While automated equipment can help with some of these processes, most managers will agree that labor costs for document processing represent a significant proportion of their overhead. In general, labor-based processes are much more expensive in the long term EDI alternatives.

Accuracy—EDI systems are more accurate than their manual processing counterparts because there are fewer points at which errors can be introduced into the system.

Information Access—EDI systems permit myriad users access to a vast amount of detailed transaction data in a timely fashion. In a non-EDI environment, in which information is held in offices and file cabinets, such dissemination of information is possible only with great effort, and it cannot hope to match an EDI system's timeliness. Because EDI data is already in computer-retrievable form, it is subject to automated processing and analysis. It also requires far less storage space.

Infrastructure for Edi

Several elements of infrastructure must exist in order to introduce an EDI system, including: 1) format standards to facilitate automated processing by all users, 2) translation software to translate from a user's proprietary format for internal data storage into the generic external format and back again, 3) value-added networks to solve the technical problems of sending information between computers, 4) inexpensive microcomputers to bring all potential users—even small ones—into the market, and 5) procedures for complying with legal rules. It has only been in the past several years that all of these ingredients have fallen into place.

FORMAT STANDARDS. To permit the efficient use of computers, information must be highly organized into a consistent data format. A format defines how information in a message is organized: what data goes where, what data is mandatory, what is optional, how many characters are permitted for each data field, how data fields are ordered, and what codes or abbreviations are permitted.

Early EDI efforts in the 1960s used proprietary formats developed by one firm for exclusive use by its trading partners. This worked well until a firm wanted to exchange EDI documents with other firms who wanted to use their own formats. Since the different formats were not compatible, data exchange was difficult if not impossible. To facilitate the widespread use of EDI, standard formats were developed so that an electronic message sent by one party could be understood by any receiver that subscribes to that format standard. In the United States the Transportation Data Coordinating Committee began in 1968 to design format standards for transportation documents. The first document was approved in 1975. This group pioneered the ideas that are used by all standards organizations today.

North American standards are currently developed and maintained by a volunteer organization called ANSI (American National Standards Institute). The format for a document defined by ANSI is broad enough to satisfy the needs of many different industries. Electronic documents are typically of variable length and most of the information is optional. When a firm sends a standard EDI purchase order to another firm, it is possible for the receiving firm to pass the purchase order data through an EDI translation program directly to a business application without manual intervention. In the

late 1990s, international format standards were established and introduced as well to facilitate international business activity.

TRANSLATION SOFTWARE. Translation software makes EDI work by translating data from the sending firm's internal format into a generic EDI format. Translation software also receives a sender's EDI message and translates it from the generic standard into the receiver's internal format. There are currently translation software packages for almost all types of computers and operating systems.

VALUE-ADDED NETWORKS (VANS). When firms first began using EDI, most communications of EDI documents were directly between trading partners. Unfortunately, direct computer-to-computer communications requires that both firms 1) use similar communication protocols, 2) have the same transmission speed, 3) have phone lines available at the same time, and 4) have compatible computer hardware. If these conditions are not met, then communication becomes difficult if not impossible. A value-added network (VAN) can solve these problems by providing an electronic mailbox service. By using a VAN, an EDI sender need only learn to send and receive messages to or from one party: the VAN. Since a VAN provides a very flexible computer interface, it can talk to virtually any type of computer. This means that to conduct EDI with hundreds of trading partners, an organization only has to talk to one party. In addition, VANs provide important security elements for dissemination of information between parties.

INEXPENSIVE COMPUTERS. The fourth building block of EDI is inexpensive computers that permit even small firms to implement EDI. Since microcomputers are now so prevalent, it is possible for firms of all sizes to deal with each other using EDI.

PROCEDURES FOR COMPLYING WITH LEGAL RULES. Legal rules apply to the documents that accompany a wide variety of business transactions. For example, some contracts must include a signature or must be an original in order to be legal. If documents are to be transmitted via EDI, companies must establish procedures to verify that messages are authentic and that they comply with the agreed-upon protocol. In addition, EDI requires companies to institute error-checking procedures as well as security measures to prevent unauthorized use of their computer systems. Still, it is important to note that some sorts of business documents—such as warranties or limitations of liability—are difficult to transmit legally using EDI.

Wikipedia: Electronic Data Interchange

An inter-company, application-to-application communication of data in standard format for business transactions Electronic Data Interchange (EDI) is a set of standards for structuring information that is to be electronically exchanged between and within businesses, organizations, government entities and other groups. The standards describe structures that emulate documents, for example purchase orders to automate purchasing. The term EDI is also used to refer to the implementation and operation of systems and processes for creating, transmitting, and receiving EDI documents.

Despite being relatively unheralded, in this era of technologies such as XML services, the Internet and the World Wide Web, EDI is still the data format used by the vast majority of electronic commerce transactions in the world.

Standards

Generally speaking, EDI is considered to be a technical representation of a business conversation between two entities, either internal or external. Note, there is a perception that "EDI" consists of the entire electronic data interchange paradigm, including the transmission, message flow, document format, and software used to interpret the documents. EDI is considered to describe the rigorously standardized format of electronic documents.

The EDI (Electronic Data Interchange) standards were designed to be independent of communication and software technologies. EDI can be transmitted using any methodology agreed to by the sender and recipient. This includes a variety of technologies, including modem (asynchronous, and bisynchronous), FTP, Email, HTTP, AS1, AS2, WebSphere MQ, etc. It is important to differentiate between the EDI documents and the methods for transmitting them. While comparing the bisynchronous protocol 2400 bit/s modems, CLEO devices, and value-added networks used to transmit EDI documents to transmitting via the Internet, some people equated the non-Internet technologies with EDI and predicted erroneously that EDI itself would be replaced along with the non-Internet technologies. These non-internet transmission methods are being replaced by Internet Protocols such as FTP, telnet, and e-mail, but the EDI documents themselves still remain.

As more trading partners use the Internet for transmission, standards have emerged. In 2002, the IETF published RFC 3335, offering a standardized, secure method of transferring EDI data via e-mail. On July 12th, 2005, an IETF working group ratified RFC4130 for MIME-based HTTP EDIINT (aka. AS2) transfers, and is preparing similar documents for FTP transfers (aka. AS3). While some EDI transmission has moved to these newer protocols the providers of the value-added networks remain active.

EDI documents generally contain the same information that would normally be found in a paper document used for the same organizational function. For example an EDI 940 ship-from-warehouse order is used by a manufacturer to tell a warehouse to ship product to a retailer. It typically has a ship to address, bill to address, a list of product numbers (usually a UPC code) and quantities. It may have other information if the parties agree to include it. However, EDI is not confined to just business data related to trade but encompasses all fields such as medicine (e.g., patient records and laboratory results), transport (e.g., container and modal information), engineering and construction, etc. In some cases, EDI will be used to create a new business information flow (that was not a paper flow before). This is the case in the Advanced Shipment Notification (856) which was designed to inform the receiver of a shipment, the goods to be received and how the goods are packaged.

There are four major sets of EDI standards:

The UN-recommended UN/EDIFACT is the only international standard and is predominant outside of North America.

The US standard ANSI ASC X12 (X12) is predominant in North America. The TRADACOMS standard developed by the ANA (Article Numbering

Association) is predominant in the UK retail industry. The ODETTE standard used within the European automotive industry

All of these standards first appeared in the early to mid 1980s. The standards prescribe the formats, character sets, and data elements used in the exchange of business documents and forms. The complete X12 Document List includes all major business documents, including purchase orders (called "ORDERS" in UN/EDIFACT and an "850" in X12) and invoices (called "INVOIC" in UN/EDIFACT and an "810" in X12).

The EDI standard says which pieces of information are mandatory for a particular document, which pieces are optional and give the rules for the structure of the document. The standards are like building codes. Just as two kitchens can be built "to code" but look completely different, two EDI documents can follow the same standard and contain different sets of information. For example a food company may indicate a product's expiration date while a clothing manufacturer would choose to send color and size information.

Standards are generally updated each year.

Specifications

Organizations that send or receive documents from each other are referred to as "trading partners" in EDI terminology. The trading partners agree on the specific information to be transmitted and how it should be used. This is done in human readable specifications (also called Message Implementation Guidelines). While the standards are analogous to building codes, the specifications are analogous to blue prints. (The specification may also be called a mapping but the term mapping is typically reserved for specific machine readable instructions given to the translation software.) Larger trading "hubs" have existing Message Implementation Guidelines which mirror their business processes for processing EDI and they are usually unwilling to modify their EDI business practices to meet the needs of their trading partners. Often in a large company these EDI guidelines will be written to be generic enough to be used by different branches or divisions and therefore will contain information not needed for a particular business document exchange. For other large companies, they may create separate EDI guidelines for each branch/division.

Transmission

Trading partners are free to use any method for the transmission of documents. In the past one of the more popular methods was the usage of a bisync modem to communicate

through a Value Added Network (VAN). Some organizations have used direct modem to modem connections and Bulletin Board Systems (BBS), and recently there has been a move towards using some of the many Internet protocols for transmission, but most EDI is still transmitted using a VAN. In the healthcare industry, a VAN is referred to as a "Clearinghouse".

Value Added Networks

In the most basic form, a VAN acts as a regional post office. They receive transactions, examine the 'From' and the 'To' information, and route the transaction to the final recipient. VANs provide a number of additional services, e.g. retransmitting documents, providing third party audit information, acting as a gateway for different transmission methods, and handling telecommunications support. Because of these and other services VANs provide, businesses frequently use a VAN even when both trading partners are using Internet-based protocols. Healthcare clearinghouses perform many of the same functions as a VAN, but have additional legal restrictions that govern protected healthcare information.

VANs also provide an advantage with certifcate replacement in AS2 transmissions. Because each node in a traditionally business-related AS2 transmission usually involves a security certificate, routing a large number of partners through a VAN can make certificate replacement much easier.

Internet

Until recently, the Internet transmission was handled by nonstandard methods between trading partners usually involving FTP or email attachments. There are also standards for embedding EDI documents into XML. Many organizations are migrating to this protocol to reduce costs. For example, Wal-Mart is now requiring its trading partners to switch to the AS2 protocol.

Interpreting data

Often missing from the EDI specifications (referred to as EDI Implementation Guidelines) are real world descriptions of how the information should be interpreted by the business receiving it. For example, suppose candy is packaged in a large box that contains 5 display boxes and each display box contains 24 boxes of candy packaged for the consumer. If an EDI document says to ship 10 boxes of candy it may not be clear whether to ship 10 consumer packaged boxes, 240 consumer packaged boxes or 1200 consumer packaged boxes. It is not enough for two parties to agree to use a particular qualifier indicating case, pack, box or each; they must also agree on what that particular qualifier means.

EDI translation software provides the interface between internal systems and the EDI format sent/received. For an "inbound" document the EDI solution will receive the file (either via a Value Added Network or directly using protocols such as FTP or AS2), take

the received EDI file (commonly referred to as a "mailbag"), validate that the trading partner who is sending the file is a valid trading partner, that the structure of the file meets the EDI standards and that the individual fields of information conforms to the agreed upon standards. Typically the translator will either create a file of either fixed length, variable length or XML tagged format or "print" the received EDI document (for non-integrated EDI environments). The next step is to convert/transform the file that the translator creates into a format that can be imported into a company's back-end business systems or ERP. This can be accomplished by using a custom program, an integrated proprietary "mapper" or to use an integrated standards based graphical "mapper" using a standard data transformation language such as XSLT. The final step is to import the transformed file (or database) into the company's back-end enterprise resource planning (ERP).

For an "outbound" document the process for integrated EDI is to export a file (or read a database) from a company's back-end ERP, transform the file to the appropriate format for the translator. The translation software will then "validate" the EDI file sent to ensure that it meets the standard agreed upon by the trading partners, convert the file into "EDI" format (adding in the appropriate identifiers and control structures) and send the file to the trading partner (using the appropriate communications protocol).

Another critical component of any EDI translation software is a complete "audit" of all the steps to move business documents between trading partners. The audit ensures that any transaction (which in reality is a business document) can be tracked to ensure that they are not lost. In case of a retailer sending a Purchase Order to a supplier, if the Purchase Order is "lost" anywhere in the business process, the effect is devastating to both businesses. To the supplier, they do not fulfill the order as they have not received it thereby losing business and damaging the business relationship with their retail client. For the retailer, they have a stock outage and the effect is lost sales, reduced customer service and ultimately lower profits.

In EDI terminology "inbound" and "outbound" refer to the direction of transmission of an EDI document in relation to a particular system, not the direction of merchandise, money or other things represented by the document. For example, an EDI document that tells a warehouse to perform an outbound shipment is an inbound document in relation to the warehouse computer system. It is an outbound document in relation to the manufacturer or dealer that transmitted the document.

Advantages of using EDI over paper systems

EDI and other similar technologies save a company money by providing an alternative to, or replacing information flows that require a great deal of human interaction and materials such as paper documents, meetings, faxes, email, etc. Even when paper documents are maintained in parallel with EDI exchange, e.g. printed shipping manifests, electronic exchange and the use of data from that exchange reduces the handling costs of sorting, distributing, organizing, and searching paper documents. EDI and similar

technologies allow a company to take advantage of the benefits of storing and manipulating data electronically without the cost of manual entry or scanning.

Barriers to implementation

There are a few barriers to adopting electronic data interchange. One of the most significant barriers is the accompanying business process change. Existing business processes built around slow paper handling may not be suited for EDI and would require changes to accommodate automated processing of business documents. For example, a business may receive the bulk of their goods by 1 or 2 day shipping and all of their invoices by mail. The existing process may therefore assume that goods are typically received before the invoice. With EDI, the invoice will typically be sent when the goods ship and will therefore require a process that handles large numbers of invoices whose corresponding goods have not yet been received.

Another significant barrier is the cost in time and money in the initial set-up. The preliminary expenses and time that arise from the implementation, customization and training can be costly and therefore may discourage some businesses. The key is to determine what method of integration is right for your company which will determine the cost of implementation. For a business that only receives one P.O. per year from a client, fully integrated EDI may not make economic sense. In this case, businesses may implement inexpensive "rip and read" solutions or use outsourced EDI solutions provided by EDI "Service Bureaus". For other businesses, the implementation of an integrated EDI solution may be necessary as increase in trading volumes brought on by EDI force them to re-implement their order processing business processes.

The key hindrance to a successful implementation of EDI is the perception many businesses have of the nature of EDI. Many view EDI from the technical perspective that EDI is a data format; it would be more accurate to take the business view that EDI is a system for exchanging business documents with external entities, and integrating the data from those documents into the company's internal systems. Successful implementations of EDI take into account the effect externally generated information will have on their internal systems and validate the business information received. For example, allowing a supplier to update a retailer's Accounts Payables system without appropriate checks and balances would be a recipe for disaster. Businesses new to the implementation of EDI should take pains to avoid such pitfalls.

Increased efficiency and cost savings drive the adoption of EDI for most trading partners. But even if a company would not choose to use EDI on their own, pressures from larger trading partners (called hubs) often force smaller trading partners to use EDI.

See also B2B cXML Xcbl E-business

EDIFACT Enterprise application integration HL7 OASIS (organization) RosettaNet Smart contracts Standard Carrier Alpha Codes Workgroup for Electronic Data Interchange X12 X12 Document List X12 EDIFACT Mapping

External links EDI Introduction — Minnesota Department of Labor & Industry website. EDI: An Introduction — a visiting fellow on Australian National University

website.

Understanding the components of SAP IDocs

(http://articles.techrepublic.com.com/5100-10878_11-1051228.html)

SAP’s presence in the IT world is justified by a central premise: It turns a company’s many individual systems into one, big supersystem. More than a linking together of applications, SAP’s implementation causes a redirection of the flow of information through a company and its partner companies that enhances the potential of its business functions.

This flow of information is enabled by a core element in SAP technology: the Intermediate Document, or IDoc. Technically, the IDoc is an example of Electronic Data Interchange (EDI). Unlike conventional EDI, IDocs are not based on a descriptive language.

The IDoc concept borrows the best features of EDI and combines them with the best features of conventional transaction file formats. The result is a lean data transport mechanism that is the engine of SAP data flow, tying together applications, databases, companies, and networks. Here is a look at the makeup of IDocs within the application architecture.

Form and content: IDoc terminologyAs is often the case with proprietary technologies, SAP assigns specific, object-oriented meanings to familiar terms. When referring to IDocs, the term document refers to a set of data comprising a functional group of records with a business identity. (For example, all the data in a purchase order, or all the profile information of a supplier in a supplier master record.)

A message refers to the contents of a specific implementation of an IDoc; it’s a logical reference. This differs from a reference to the IDoc itself, which specifies the message’s physical representation. Think of it this way: If you’re watching a parade pass by, the mayor waving to the crowd from his limousine is the message, and the mayor’s limousine (which is specific to the mayor) is the IDoc. You’re building a logical object, and the IDoc is both its container and the vehicle that moves it.

The IDoc control recordEach IDoc has a single control record, always the first record in the set. The structure of this record describes the content of the data records that will follow and provides administrative information, such as the IDoc’s functional category (Message Type/IDoc Type), as well as its origin (Sender) and destination (Receiver) as in conventional EDI (see Figure A).Figure AIDOC number Sender Receiver Port Message type IDoc type 1234567890 R3NYC R3LA FILE INVOICES INVOICE01 Layout of an IDoc control record

This “cover slip” format informs the receiving system of the IDoc’s purpose, and the receiving system uses it to determine the correct processing algorithm for handling the

arriving IDoc.

Data recordsThe data records following the control record are structured alike, including two sections: a segment information section and a data section.

In the first part of a data record, the segment information section describes the structure of the data that follows, for the benefit of the IDoc processor. There is a segment name (like an EDI segment identifier) that corresponds to a data dictionary structure to which the IDoc processor has access. The remaining information is useful for foreign systems, such as a partner company’s Oracle system, which has no such data dictionary.

The second part of the record is the data itself, a storage area of 1,000 characters.

Status recordsIf you’ve ever ordered a package from a faraway location and tracked its progress using the Internet-based tracking utilities now provided by most major parcel carriers, you’re familiar with the list of stops and transfer points through which a package passes on its way to you.

This collection of records is exactly what you’ll see in an IDoc that has begun its work. Following the data records in an IDoc, status records accumulate as an IDoc makes its way from one point in a process to another.

Typically, an IDoc will acquire several of these records as its does its job. They are simple records, consisting of a status code (there are more than 70 codes, covering a broad range of conditions and errors), a date/time stamp, and some additional status information fields for system audit purposes. In addition, as errors occur in the processing of an IDoc, status records (see Figure B) are used to record these errors and the date/time of their occurrence.Figure B(Display Status Record) IDoc number 0000000000123456 Direction 1 Outbound Status information           38 IDoc archived     (additional descriptive text)     Log time         Date 6-30-02       Time 14:35:21   Portion of IDoc status display

IDoc BaseIDocs, as data formatting tools, enable the easy sharing of data between databases and applications within a company as well as being an efficient data courier between companies. Typically in SAP, a database of IDoc definitions exists, to which any

application may have access.

This “IDoc Base” gives all the applications and processes in your company domain the capacity to send, receive, and process a document in a contextually appropriate way, without doing anything to the data. For example, a purchase order IDoc can filter through every process it touches, passing from system to system, accumulating status records to track its progress.

Every department using the data can use it appropriately without any cumbersome intermediate processes, because each department draws its key to interpreting the IDoc from the same source.

Multiple messagesOne cumbersome feature of conventional EDI is the embedding of more than one functional record type in a document. The unwieldy X-12 888 Item Maintenance transaction set is an example: It purports to handle so many different configurations of product master data that it is horrifically difficult to integrate into an existing system.

IDocs, on the other hand, handle multiple messages with ease. Given the centralized IDoc interpretation that SAP provides to all its parts, it’s no problem to define an IDoc that will contain more than one message, that is, more than one data record type.

A customer master IDoc, for example, may contain customer profile information records for a customer with many locations. But it may also contain location-specific pricing information records for that customer in the same document. This is an incredibly efficient way of bundling related records, particularly when passing large amounts of complex information from system to system (see Figure C).Figure CCONTROL RECORD DATA RECORD - CUST PROFILE LOC #1 DATA RECORD - CUST PROFILE LOC #2 DATA RECORD - CUST PROFILE LOC #3 DATA RECORD - CUST DISCOUNT STRUCTURE LOC #1 DATA RECORD - CUST DISCOUNT STRUCTURE LOC #2 DATA RECORD - CUST DISCOUNT STRUCTURE LOC #3 STATUS RECORD STATUS RECORD STATUS RECORD Records in a multiple-message IDoc

Final thoughtThere is no mastering SAP without mastering its workhorse, the IDoc. ERP environments utilizing SAP and similar platforms are made necessary in the first place by the increasing demands of ever more integrated business relationships. IDoc technology addresses this trend with a simple but powerful design philosophy: Data is no longer something to be stored; it’s something to be moved.

IDOC INTRODUCTION & STRUCTURE

Written by Anon.

IDOC type and IDOC. An Intermediate Document (IDOC) type represents the structure of the data associated with a message type (DEBMAS02 for message type DEBMAS — Customer Master, and WMMBID02 for message type WMMBXY— Goods Movements), while an IDOC is an object containing the data of a particular message type. IDOCs are data containers with intelligence built in. Each IDOC contains one and only one business object. For example, an IDOC of type SHPMNT01, message type SHPMNT, will contain data only of one Shipment Document. Generally, the architecture of an IDOC is independent of the message type by virtue of ALE’s ability to redefine it for any message type.

{mosgoogle} 

An IDOC consists of three record types: the control record, the data record, and the status record (see Figure 1).

Figure 1 Structure of an IDOC.

• The control record, or EDI_DC, is a control structure that contains several fields with information about the IDOC, such as what IDOC type it is, the message type, sender and receiver information, and direction (1 for outbound, 2 for inbound). This information provides control data on the outbound, and processing options on an inbound IDOC. It also has as its key the Client (MANDT) and the IDOC number (DOCNUM). The EDI_DC record of an IDOC is stored in table EDIDC. Every IDOC has one control record.

• The data record, which conforms to the structure EDI_DD, contains the application data. Every EDI_DD record has a key portion that is 55 bytes in length (or 63, depending on the SAP release), which consists of several fields describing the content of the record. The key of 55/63 bytes is followed by a field SDATA, which is 1000 bytes in length and of data type Long Character. The SDATA field holds the application data, and its structure is determined by the key field SEGNAM (Segment Name). An IDOC consists of one or more data records, and its sequence and structure are dictated by the sequence and structure of segments in a given IDOC type. The SDATA portion of the data record is redefined for every occurrence based on the

structure of the segment, with the first 55/63 bytes of the data record identifying the segment name, sequence, and hierarchy. In an outbound interface, ALE/EDI function modules populate these segments with application data. In an inbound interface, the application modules process the data contained in the segments. Data records are stored on table EDID2 that belongs to the cluster EDI30C.

In SAP, from a Data Dictionary perspective, IDOC segments adhere to a naming convention. Each segment has three components, each marked by a different prefix —E1 for segment type, E2 for segment definition, and E3 for segment documentation. For example, the first segment of IDOC type DEBMAS02 is E1KNA1M. Its definition is contained in structure E2KNA1M, and its documentation is in E3KNA1M. When the IDOC is externalized, we see the segment name addressed by its E2 prefix. For all practical purposes, we will use only the E2 prefix when referring to IDOC segments. Also, most segment names represent Data Dictionary tables.

• The status record conforms to the dictionary structure EDI_DS. It contains information on the state of the IDOC as it passes through the various stages of processing. The STATUS field has a length of two bytes (data type CHAR), with a range of values: 01–41 for outbound and 50–73 for inbound IDOCs. The status record also includes date and timestamps for when that particular state was reached. The status records maintain a history of the IDOC states. An IDOC may have one or more status records, which are stored in table EDIDS (see Figure 2, page 82). These records can be accessed or created only by SAP function modules (APIs), and are not externalized.

Figure 2 the IDOC database.

IDOC objects consist of a Basic IDOC type, an Extension type, and an IDOC type.

In an R/3 system, IDOCs are identified by a unique IDOC number (field DOCNUM), and all three record types are tied together with this number. The IDOC number is internally assigned by SAP. It is possible to maintain the number range of IDOCs.

You can display information about IDOC record types by executing transaction WE61 or using the following menu path from the main R/3 menu: Tools -> Administration -> Administration -> Process Technology -> IDOC -> IDOC Basis (*) -> Documentation -> IDOC Record Types. You can reach IDOC Basis (*) by executing transaction WEDI, which is frequently used in ALE and EDI. You can display information about IDOC types, such as DEBMAS02 and INVOIC01 by executing transaction WE60 or using the following menu path from WEDI: Documentation -> IDOC types.

What is ALE?

(http://www.erpgenie.com/consultant-tips/62-ale--edi--b2b/597-what-is-ale)

Written by Anon.

ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. When a new enterprise resource planning (ERP) solution such as R/3 is implemented, companies have to interface the ERP system with legacy systems or other ERP systems. ALE provides intelligent mechanisms whereby clients can achieve integration as well as distribution of applications and data. ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time. The ALE components are inherently integrated with SAP applications and are robust, leading to a highly reliable system. ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data definitions, and methodologies that you can easily configure to get an interface up and running.

The message-based architecture of ALE comprises three layers:

Application layer. This layer provides ALE with an interface to R/3 to originate or receive messages containing data to or from external (or other R/3) systems.

Distribution layer. The distribution layer filters and converts messages containing data based on predefined or custom-defined rule sets. These conversions may occur to ensure compatibility between different releases of R/3 and R/2.

Communications layer. ALE communications are carried out both synchronously and asynchronously. Synchronous message transmissions are typically used for the direct reading of control data, while asynchronous message transmissions are used for transmitting or receiving application data. It is also possible to achieve a pseudo-real-time exchange of application data using transactional Remote Function Calls (tRFC), which I’ll detail later in this article series.

ALE scenarios fall into three categories: master data, transactional data, and control data distribution. Although the underlying principles are the same for the different categories, there are differences in their functions and configurations. SAP delivers over 200 ALE scenarios; and by extension there are approximately 200 application areas that can leverage ALE technology for data distribution or communication. A subset of these scenarios is supported by R/3 for Electronic Data Interchange (EDI).

There are several advantages to using ALE technology:

• SAP ensures release independence.• Robust mechanisms capture changes to master data or transactional data.• ALE offers better inbound interface performance compared to traditional techniques

such as Batch Data Communications (BDC) or Call Transactions. ALE does not use screen-based batch input.• ALE provides black-box technology, so the user is at a higher level.• Most ALE interfaces can be prototyped in a couple of days, resulting in smaller implementation timelines.• There is little or no ABAP program development. In most cases, the SAP-delivered ALE functionality meets the requirements.• ALE offers a systematic and organized approach to custom enhancements and extensions.• An ALE interface is easy to maintain due to the structured approach and minimal number of development objects.• ALE is the strategic architecture for R/3 “loose coupling” with legacy and third-party applications and is a Business Framework key element. It provides a message-based architecture for asynchronous integration of Business Framework components, including Business Components, Business Objects, and BAPIs.

ALE Building Blocks and Concepts

The following building blocks are fundamental to ALE functionality:

Logical System. A Logical System (LS) is the representation of an R/3 or external system in SAP R/3 for the distribution of data to and from the R/3 System. Every R/3 client used for ALE or EDI has to have a base LS associated with the client. This LS becomes the “sender” for outbound messages and a “receiver” for inbound messages. In addition to the base LS, a second LS should be created within that R/3 system for each R/3 or external system used for ALE interfaces. In an inbound ALE interface, this second LS represents the sender (another R/3 or external system) with respect to the base LS (receiver). In an outbound ALE interface, this second LS is the receiver on behalf of the R/3 or external system with respect to the base LS (sender).

Message type. A message type represents the application message exchanged between R/3 systems and R/3 and an external system. A message type characterizes the data sent across systems and relates to the structure of the data called an IDOC type (see below). For example, MATMAS is a message type for Material Master, and INVOIC is a message type for an Invoice (Billing Document). ALE supports over 200 message types in R/3 and about 200 application areas.

IDOC type and IDOC. An Intermediate Document (IDOC) type represents the structure of the data associated with a message type (DEBMAS02 for message type DEBMAS — Customer Master, and WMMBID02 for message type WMMBXY— Goods Movements), while an IDOC is an object containing the data of a particular message type. IDOCs are data containers with intelligence built in. Each IDOC contains one and only one business object. For example, an IDOC of type SHPMNT01, message type SHPMNT, will contain data only of one Shipment Document. Generally, the architecture of an IDOC is independent of the message type by virtue of ALE’s ability to redefine it for any message type.

Customer Distribution Model. In an R/3 system, the Customer Distribution Model is a tool that stores information about the flow of messages across various systems. The Customer Distribution Model uses an SAP-delivered Distribution Reference Model as its basis (the Customer Distribution Model can have distribution scenarios other than ones stored in the Distribution Reference Model.) The Customer Distribution Model stores data that dictates which messages (message types) flow to which Logical Systems. Many messages can flow to one Logical System, and one message can flow to several systems. With the use of filter objects and listings (which I’ll describe shortly), it is also possible to specify in a model the criteria for filtering information for a specific system. A Customer Distribution Model can be created in an R/3 system with that client’s base Logical System as the “sender” Logical System.

Use transaction BD64 or the following menu path to maintain the model: From the IMG (Implementation Guide), Cross-Application Components -> Distribution (ALE) (*) -> Distribution Customer Model -> Maintain Distribution Customer Model Directly -> Maintain Distribution Customer Model Directly.

The IMG for ALE, Distribution (ALE) (*), can also be directly invoked by using transaction SALE. This transaction is used very frequently in ALE. (I’ll discuss the process of creating, maintaining, and distributing a Customer Distribution Model later in this article.)

Filter object type and filter objects. A filter object type is used in the Customer Distribution Model to impose a selection criterion on the message (type) flowing to a Logical System. A filter object type with a value associated with it is called a filter object. For example, BUKRS (Company Code) is a filter object type available for message type DEBMAS (Customer Master). To distribute Customer master data of only Company Code “1001” to a particular Logical System, you would use filter object type BUKRS to create a filter object with value BUKRS = 1001. You can have multiple filter objects with different values for the same message type associated with that LS. While determining the receiver(s) of a particular message based on the Distribution Model, ALE performs object filtering. As with the Customer Distribution Model, filter objects are relevant only to ALE.

(I’ll explain the steps to create a filter object, as well as how to create a new filter object type, later in this article.)

Listings. Listings are a special filter object type occurrence and are also used to specify a selection criterion for distributing master data. Listings are based on the SAP Classification system (classes and characteristics), and are applicable only to Material, Customer, and Vendor master data. Once a list has been created, based on certain classification information using the ALE customizing menu, it is associated with an LS. The listing is then used to create a filter object with type LISTING, for a message type associated with that LS.

Lists are maintained and allocated to an LS from the ALE customizing guide using transaction SALE, or Distribution Scenarios -> Master Data Distribution -> Distribution via Listings.

Change pointers. Change pointers are R/3 objects that mark changes to SAP master data. Change pointers are managed by mechanisms in a Shared Master Data (SMD) tool and are based on Change Document (CD) objects. CD objects record the changes occurring to master data at a field level. These changes are stored in tables CDHDR (header table) and CDPOS (detail table). ALE configuration provides a link between CD objects and change pointers. Internal mechanisms update tables BDCP and BDCPS, which host the change pointers. While CD objects are application-data-specific, the processing status of change pointers is message-type-specific. Also, the ALE change pointers are activated first at a general level and then at the message-type level.

ALE provides powerful capabilities to capture changes occurring to master data and to distribute them via the IDOC interface. This feature can be used to keep two or more systems synchronized with respect to master data.

Ports. A port is a logical representation of a communication channel in SAP, with the data communicated being IDOCs. There are four types of ports that can be defined in R/3: tRFC, File, R/2, and Internet. ALE can use all port types to distribute IDOCs, while EDI typically uses a file-based port. tRFC and File ports can link to RFC destinations connected to R/3-to-R/3 or TCP/IP. By linking ports to RFC destinations, the port can also trigger scripts to invoke EDI subsystems, IDOC mapping software, and FTP.

You can maintain ports by executing transaction WE21 or WEDI, or selecting IDOC -> Port Definition. RFC destinations can be maintained using transaction SM59.

Process codes. Process codes are used in ALE and EDI to identify the function module or API to be invoked for subsequent processing. An inbound interface uses a process code to determine the application module that will process the inbound IDOC to an SAP application object such as a sales (Customer) order (process code — ORDE), Material Master record (MATM), or a shipment (SHIP). An outbound interface uses process codes only in the case of applications that use message control (which I’ll get to shortly). In this case, the process code identifies the application module that populates the IDOC with application data. Each process code is associated with a message type. Outbound process codes are stored in table TEDE1, while inbound process codes are stored in TEDE2.

Use transaction WE41 to display outbound process codes and WE42 to display inbound codes, or from WEDI select Control -> Outbound Process Codes/Inbound Process Codes, or from ALE customizing SALE select Extensions -> Outbound -> Maintain Process Code, or Extensions -> Inbound -> Maintain Process Code.

Message control and output type. In R/3, message control is a mechanism by which documents are output based on certain selection criteria, requirements, and sequences. Message control determines the type of document, its timing, number, and medium (print,

fax, ALE, or EDI.). Outbound messages in SD (Sales and Distribution) and MM (Materials Management, Purchasing) are created and processed by message control records. The output records are stored in the NAST table.

Message control uses the condition technique. The conditions for creating an output message are stored in condition tables that have selection fields picked from a catalog of application fields/tables. To determine if an application document qualifies for output, search strategies are used through access sequences, output procedures, and requirements. Once a message qualifies for output, message control modules use the parameters set in the condition type or output type to determine the timing of transmission and the medium of the message. The output type also specifies the program or module to be invoked to create the output.

Message/output determinations are concepts applicable not only to EDI and ALE, but also to other output mediums.

Partner profile. A partner profile is an identifier for a system used for communicating messages. There are four types of partner profiles: KU for Customer, LI for Vendor, B for Bank, and LS for Logical System. KU, LI, and B are used for EDI partners, while LS is used for ALE communications. Every partner profile used for ALE must be based on an existing LS.

A partner profile brings together several ALE and EDI elements to define the parameters of communication between two or more systems. Other than general information, you have to maintain inbound parameters, outbound parameters, and message control. The main parameters are message types, IDOC types, process codes, partner functions, application identifiers, message functions, output types, and ports. Other parameters also determine the mode of processing and error handling.

A partner profile plays a major role and can be viewed as a gateway for ALE and EDI communications. It routes the specified messages through defined IDOC types to a given port after invoking the appropriate function modules for outbound processing. It receives IDOCs of a specific type, and it identifies modules to post data to the application databases in the case of inbound interfaces.

Use transaction WE20 to maintain partner profiles, or from WEDI select IDOC -> Partner Profile, or from SALE (ALE Customizing guide) -> Communication -> Manual maintenance of partner profiles -> Maintain partner profiles.

The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.

The process can be divided into the following sub-processes:

1. Outbound Processing

1. • Receiver determination 2. • Calling the generated outbound function module 3. • Conversion of BAPI call into IDoc 4. • Segment filtering 5. • Field conversion 6. • IDoc version change 7. • Dispatch control

2. IDoc dispatch

IDocs are sent in the communication layer by transactional Remote Function Call (tRFC) or by other file interfaces (for example, EDI).

tRFC guarantees that the data is transferred once only.

3. Inbound Processing

1. • Segment filtering 2. • Field conversion 3. • Transfer control 4. • Conversion of IDoc into BAPI call 5. • BAPI function module call 6. • Determination of IDoc status 7. • Posting of application data and IDoc status 8.  Error Control

Interrogating the Distribution Model

You do not have to interrogate the distribution model, it is optional.

There are two function modules that can interrogate the ALE distribution model: ale_model_determine_if_to_send and ale_model_info_get. ale_model_determine_if_to_send is called with the message type and possibly with the logical receiving system if it is already known in the application. A check is made in the ALE distribution model that a message flow has been maintained for the input parameters. If this is not so, the export parameter idoc_must_be_send is set to initial; otherwise, an "X" is returned. If there are filter objects in the distribution model that control this message flow, they are not evaluated. An IDoc must only be created if ale_determine_if_to_send returns an "X".

Module ale_model_info_get is used for more complex queries made to the ALE distribution model. It is called with the message type to be dispatched. In return, you get a table containing all the potential recipients of this message type, as well as the associated filter objects. Note that there may be several entries for one receiver in the table returned. If there are no entries in the distribution model, the exception no_model_info_found is issued. If an exception is issued, an IDoc does

not have to be created. Otherwise an IDoc does have to be created. You will find the receiving logical system in the rcvsystem field in a table entry.

The end result, that is, whether the receivers receives an IDoc and what the IDoc looks like, is only determined after all the filter objects for a message flow in the distribution model have been evaluated. This is carried out in the ALE layer.

Structure of Control Records The control record consists of a field string for the structure edidc. The relevant fields are listed below; all other fields should be left with their initial values. List of fields for the control record Field Description Comment mestyp Logical message type. Conveys the business meaning of the message. Mandatory field idoctp Basic structure of the IDoc. Identifies the layout set that uses this message. Mandatory field cimtyp Structure of customer extension. If the customer extends an SAP basic structure, he must give a name to the structure of his extension. Mandatory field if customer has made an enhancement. Otherwise initial. rcvprt Partner type of the receiver; “LS” (i.e. logical system) for ALE. Optional field. See below. rcvprn Partner number of the receiver; the logical system for ALE. Optional field. See below. rcvpfc Partner function of the receiver; normally initial for ALE. Optional field. See below. When the receiving system has been determined from the distribution model, it can be written to field rcvprn. Then field RCVPFC must be filled with "LS" (for logical system). If necessary, the partner function can be written into the field RCVPFC. However, the partner function is not normally used in ALE. What is important, is that either both rcvprt and rcvprn are left empty or that both are filled. If rcvprt and rcvprn are passed with their initial values, the receivers are determined entirely in the ALE layer.

Structure of the Data Records Replacing SAP Codes with ISO Codes [Seite 67] The data records of an IDoc are created in an internal table with structure EDIDD. The relevant fields are shown below. Important Table Fields for Creating IDoc Data Records Field Description SEGNAM Segment type of the IDoc data record SDATA 1000 byte-long character field for the data used by the IDoc The remaining fields in EDIDD should be left initial. All the segment types and their sequence are specified in the IDoc structure. The data records are structured according to this sequence and included in the internal table. For each segment type of the IDoc structure, there is a DDIC structure with the same name. A field string with this structure is used for creating a data record. The application data is mapped to the field string. The segment type is written to the field SEGNAM, and the field string is written to the field SDATA. This data record is then included in the internal table with the structure edidd.

Converting Currency Amounts Currency amounts have to be converted from an SAP system format to a format that can be understood externally. In the SAP system, all currency amounts are stored with two decimal places. If a currency has a different number of decimal places, the currency amount has to be converted. You can use function module CURRENCY_AMOUNT_SAP_TO_IDOC for this

conversion; it performs a suitable currency amount conversion for IDocs. We recommend that you encapsulate the code in a subroutine <SEGMENT-TYP>_CURRENCY_SAP_TO_IDOC.

Replacing SAP Codes With ISO Codes There are ISO codes for country keys, currency keys, units of measure and shipping instructions. According to SAP design guidelines, you should use ISO codes for an IDoc if they are available. When you set up the IDoc, the SAP codes have to be replaced by ISO codes. To do this, you can use these function modules: Function modules for converting SAP codes Domain Function module Currency keys CURRENCY_CODE_SAP_TO_ISO Country keys COUNTRY_CODE_SAP-TO_ISO Units of measure UNIT_OF_MEASURE_SAP_TO_ISO Shipping instructions SAP_TO_ISO_PACKAGE_TYPE_CODE We recommend that you encapsulate the code in a SUBROUTINE <SEGMENT-TYP>_CODES_SAP_TO_ISO.

Left-justified Filling of IDoc Fields All fields must be filled left-justified. This happens automatically for character fields. If the original field of the application is a non-character field, you must execute a condense on the corresponding field in the IDoc segment. To find out which fields require a condense, see the documentation structure for a segment type. The name of the documentation structure begins with "E3" or "Z3" (instead of “E1” or “Z1”); otherwise it is the same. This structure contains the same fields as the "E1" or "Z1" structure. But here you will find the original data elements and domains of the application. All fields with a data type unequal to char, cuky, clnt, accp, numc, dats, tims or unit require a condense. We recommend that you encapsulate the code in a subroutine <SEGMENT-TYP>_CON

Calling MASTER_IDOC_DISTRIBUTE After the MASTER_IDOC_DISTRIBUTE has been called, you must specify a COMMIT WORK; the standard Database Commit at the end of the transaction is not sufficient. The COMMIT WORK does not have to directly follow the call; it can be specified at higher call levels or after multiple calls of MASTER_IDOC_DISTRIBUTE. Note that the IDocs created remain locked until the called transaction has been completed. If you want to unlock them earlier, you can call one of the following function modules: • DEQUEUE_ALL releases all locked objects • EDI_DOCUMENT_DEQUEUE_LATER as a parameter releases the transferred IDocs If the application document is created via the update program, the call of MASTER_IDOC_DISTRIBUTE must also be performed in update task (if an update call has not already been performed at a higher level).

Exceptions and Export Parameters of MASTER_IDOC_DISTRIBUTE The module uses the table parameter COMMUNICATION_IDOC_CONTROL to return the control records of the IDocs that were created in the database. To find out the IDoc number and the current status for example, see fields DOCNUM AND STATUS. In general, this table is not relevant to the calling application. If

the IDoc recipient was passed in the control record when MASTER_IDOC_DISTRIBUTE was called, but the distribution model does not allow the recipient to receive this IDoc, exception ERROR_IN_IDOC_CONTROL is output with an appropriate error message. If a receiver was not given in the control record and ALE does not find a recipient in the distribution model, an exception is not issued. If you want to react to this case, you must query the return table COMMUNICATION_IDOC_CONTROL. If this table is empty, no IDoc was created. This different behavior for the initial and non-initial receiver has historical reasons. The initial recipient is the standard case for master data replication: here it is of no further interest whether an IDoc was actually created. Presetting the receiver is the standard for dispatching transaction data: if an IDoc is not created, this is interpreted as an error.

Sample ALE scenarios

Now let’s explore a couple of sample ALE scenarios. The first illustrates a few interfaces with an external warehouse management system using ALE technology. The second depicts the distribution of master data between two or more R/3 systems. These scenarios are a small sample of the multitude of possible ALE interfaces.

Example 1: Consider a business scenario in which R/3 needs to be interfaced with an external warehouse management system (WMS) (see Figure 3). This scenario assumes that the Inventory Management module is being implemented. In an outbound interface, the SAP application communicates to the WMS picking requests — Materials in the warehouse that need to be picked for packing and shipping. Message type PICKSD, whose corresponding IDOC type is SDPIOD01, is used. This IDOC consists of a header with fields for delivery number, shipping point, total weight of delivery, units of measurement, and the name and address of the ship-to party. The header is followed by one or more detail segments that contain the delivery items with fields for item number, Material number, quantity, and units of measure.

Figure 3 Sample ALE scenario-Interface with Warehouse Management System.

After the receipt of the picking request and completion of the operation, the WMS sends a pick confirmation back to SAP. This is an inbound interface to SAP from the external

system where message type SDPICK is used. Its corresponding IDOC type is SDPIID01. This IDOC type also has a header segment followed by one or more detail segments. The IDOC communicates the Material quantities picked by the warehouse based on deliveries sent earlier. It can handle batch splits, movement type splits, and also invoke a “post goods issue” process.

As seen in Figure 3, there are several inbound inventory interfaces that can be handled by one single message type WMMBXY. These inbound interfaces are typically goods movement transactions, including inventory receipts (with or without a purchase order), inventory status change, goods receipts against production orders, and inventory reconciliation. Most goods movement types are supported by this message type. The corresponding IDOC type is WMMBID01 (or WMMBID02 in 4.x releases), which can handle multiple line items for a single header. In the case of inventory reconciliation, ALE function modules need to be enhanced to modify the data contained in the inbound IDOC for inventory adjustments based on comparing the stock in WMS versus SAP. This can be achieved easily with a few lines of code in a Customer function (user exit) provided by SAP in the ALE function module.

Example 2: Let’s look at another simple ALE scenario distributing master data across multiple R/3 systems (see Figure 4, page 86). In large companies, there are advantages to distributing applications and databases, especially if the differentiating parameters can be used to segment the data discretely, such as plants, lines of business, geographic locations, and departments. In this example, the company headquarters is responsible for maintaining master data such as Customer Master and Material Master. This is loosely coupled with two different plants/companies, 1001/US01 and 2001/EU01, to which master data is distributed. ALE provides the capability to filter data and distribute it only to relevant systems. We can distribute the master data pertaining to that particular plant/company code. The filter object type used for message type MATMAS (Material Master) is WERKS (plant), and for DEBMAS (Customer Master), it is BUKRS (company code). Initially, after the Customer Master and Material Master are loaded during conversion at the headquarters, we can transmit the relevant data to each plant or company. Then, on an ongoing basis, we can capture the changes occurring to the master data at headquarters and communicate them to the corresponding plant/company.

Figure 4 Sample ALE scenario-distributing master data.

R/3-to-R/3 InterfaceS

Now let’s talk about how to build interfaces between two or more R/3 systems. While the underlying concepts are almost the same for either R/3-to-R/3 or R/3-to-external system interfaces, there are important differences in configurations and in the mode of communications. We will work with an example of distributing characteristics and classes from one R/3 instance to another. While using objects such as Materials, Customers, and Vendors, it is often necessary to classify these objects to further describe their nature and to distinguish them from other objects. In SAP, we use characteristics and classes to classify objects. Characteristics are attributes that further describe an object. For example, a chemical’s temperature sensitivity and a customer’s store shelf square-footage are characteristics of objects that can be maintained in the R/3 classification system. Classes are groups of characteristics that conform to a class type — such as Material or Vendor. While the term classification data refers to the actual values of the characteristics, classes and characteristics can be considered configuration data. In SAP, it is not possible to transport class and characteristic data using the Correction and Transport System (CTS) across systems (such as development, QA, or production). ALE provides message types, IDOC types, and function modules to distribute class, characteristic, and classification data to other systems. Let’s walk through the process of building an interface to distribute characteristics and classes from one R/3 instance to another.

The message types available for this purpose are:

CHRMAS — Characteristics masterCLSMAS — Class masterCLFMAS — Classification data.

If you are using the Classification system for master data, such as Materials, Customers, and Vendors, in addition to distributing the master data, you will need to distribute the classification data and use the message type CLFMAS. In this example, we’ll focus on distributing the characteristics and class master using message types CHRMAS and CLSMAS, respectively; We’ll communicate these messages to another R/3 system using tRFC, and we’ll learn to configure RFC destinations and R/3 connections. We’ll also discuss monitoring aspects of tRFC and get to know programs that will confirm the status of communications. While configuring the Distribution Model, we need to create new filter objects to distribute only the configuration data created in the Classification system, because SAP delivers certain characteristics with the system that we do not need to transport to other systems.

Step 1: Maintaining the Logical System and the Distribution Model. Let’s create a new LS called CHRCLSR301 that represents the receiving R/3 system.

Here are the steps for configuring the Distribution Model:

• Execute transaction BD64.• Enter the base LS defined for your client (say, BK1CLNT010). This LS should have been created and should be allocated to the client using transaction SCC4.• Enter CHRCLSMODL (as an example) for the name of the Distribution Model.• Click on Create. You will see a hierarchical listing with BK1CLNT010 as the parent and all other LSs, including CHRCLSR301, under it.• After placing the cursor on CHRCLSR301, click on create message type.• Enter CHRMAS.• Repeat this operation for CLSMAS.• If you want to distribute classes pertaining to, for example, Material and Customers only, then you have the option of specifying a filter object for message type CLSMAS. One of the object types available is KLART — Class Type. To specify the filter, place cursor on message type CLSMAS under LS CHRCLSR301. Click on create filter object. You will see a pop-up screen with open fields Object Type and Object. Pull down the list of object types (F4), and select KLART. Enter value “001” for class type Materials in the field Object. Repeat operation for object value “011” for class type Customers.

• SAP delivers certain characteristics that are used throughout the system. We do not need to transport (distribute) these to the other R/3 system. We need to use a filter object to restrict the characteristics to perhaps those pertaining to Materials and Customers. Follow the instructions described in the next section to create new filter object types.

Step 2: Creating new filter object types. Filter objects are criteria used for selecting data of a particular message type in order to create the required IDOCs. A filter object type is basically a field on one of the IDOC segments of the IDOC type corresponding to that message type. We first need to identify the field on the IDOC that can be used for filtering data. For example, if we use the field ATKLA (Characteristics Group) to group similar characteristics that we create, then we can use the field to create the filter object type. Upon scrutinizing the IDOC type CHRMAS01, we find that ATKLA is a field on the segment E1CABNM (see Figure 5). Further:

Figure 5 Defining a new filter object type.

• From transaction SALE Extensions -> ALE Object Maintenance -> Maintain object types (for separate message types), select Execute.

• You will see a pop-up screen for message type. Enter CHRMAS.• Click on new entries.• Enter ZATKLA (for example) for Object Type, E1CABNM for Segment Type, 1 for Sequential Number, ATKLA for Field Name, 86 for Byte Offset (from documentation on IDOC type CHRMAS01), and 10 for Internal Length.• Save.

Now that we have created a filter object type for use with message type CHRMAS, let’s complete the configuration of our Customer distribution CHRCLSMODL by executing transaction BD64:

• Expand the tree for the CHRCLSR301 Logical System.• Place cursor on message type CHRMAS.• Click on create filter object.• Pull down the menu (F4) on field Filter Object Type, and select the object type that we created—ZATKLA. • Enter value CUSTOMER in the field Object.• Repeat this operation and enter MATERIAL in the field Object (see Figure 6).• Save.

Figure 6 Customer Distribution Model for characteristics and classes.

Note: Menu paths may vary slightly depending on your version of R/3.

Step 3: Creating a CPIC user on target system. To communicate and process messages in the remote system, SAP uses a user ID on the target system. This user ID needs to be of type CPIC. Though the user could be a normal dialog user, a user of type CPIC should be used to preclude performance problems such as “maximum number of logons exceeded.” Ask your Basis administrator to set up this user ID. Ensure that the ID has all the authorizations required to update that system’s databases for characteristics and classes.

Step 4: Maintaining the RFC destination. R/3-to-R/3 communication uses tRFC. RFCs are Remote Function Calls used to invoke function modules for transactional or asynchronous activities, typically on remote systems. The word transactional prefixed to RFC merely indicates that particular function is invoked per logical unit of work, which could be one Material Master, one delivery, or one invoice. SAP tRFC and aRFC (asynchronous Remote Function Call) both have advanced mechanisms to track data

packet communications and to maintain status. For example, to ensure delivery of data, tRFCs are “retried” until the calls are successfully completed.

To set up an RFC destination for our interface:

• Execute transaction SM59.• Place the cursor on R/3 Connections. Click on create.• Enter the name of the RFC destination, say CHRCLSR301.• Enter “3” for connection type—this is an R/3 connection.• Enter a description of the RFC destination.• Press Enter. You will see a few additional fields appear on the screen.• Enter the name and system number of the other R/3 server in the field Target Machine.• Enter logon information such as Client, Language, User ID (the CPIC user ID defined earlier), and password.• Save.• Click on test connection. You will get a list of connection and communication timings for logon and transfer of a certain number of bytes. This does not verify the password entered earlier. If the password is incorrect, you will notice system problems on the target instance.• Click on remote logon. If you are using a CPIC user ID, there will be no action taken. If it is a dialog user, you will be logged on to the target system. This is only a test (see Figure 7, page 90).

Figure 7 Creating an RFC Destination.

It is important to ensure that the name of the LS and the RFC destination are the same. You can also access this function using SALE -> Communications -> Define RFC destination.

Step 5: Generating RFC port and partner profile. Here we learn how to generate RFC ports and partner profiles for an R/3-R/3 interface using SAP functionality. The port

definition is generated based on the RFC destination that we created in the previous step, while the partner profile is generated based on the Customer Distribution Model we created, along with the port generated.

Follow these steps to generate these objects:

• Go to SALE (ALE Customizing) -> Communications -> Generate Partner Profiles.• On the screen that appears, enter the Customer Model CHRCLSMODL as defined earlier.• Enter details for receiver of notifications. This is to identify the recipient of workflow messages in case of errors.• Switch the Outbound Parameters to Collect IDOCs.• Switch the Inbound Parameters to Background, so there is no overriding by express flags.• Execute.• You will see a list of messages confirming the generation of a port and partner profile.

The tRFC port has an internally assigned number. If you browse the partner profile CHRCLSR301 generated in this step, you will notice there are three entries generated for Outbound Parameters for message types CHRMAS, CLSMAS, and SYNCH. The message type SYNCH is for synchronous communications between the two R/3 systems and is used for validation of ALE functions. The port associated with the three outbound parameters’ entries is the port generated in this step.

The objects created in this process must be generated in the client/instance from which the communications are originating.

Step 6: Creating a receiving partner profile on the target system. We must now create an LS and a partner profile for receiving messages from the sending system. This is a mirror image of the sending LS on the target system.

Here are the steps of the process:

• Create a Logical System BK1CLNT010 on the target system.• Create a partner profile with partner number BK1CLNT010 on the target system.• Maintain its Inbound Parameters. Create a new entry for message type CHRMAS, with process code CHRM, and processing mode Background, with no express override flag. Create a similar entry for message type CLSMAS, with process code CLSM, and processing mode Background, with no express override flag.• Save.

Step 7: Distributing the Customer model. The Customer Distribution Model CHRCLSMODL was created on the “sender” system. This determines and dictates the flow of certain message types — CHRMAS and CLSMAS in this case — to other systems. This information has to be communicated to the recipient system as well, so that

it can accept and process the inbound IDOCs. ALE provides tools to “distribute” Customer models.

Here are the steps of the process:

• Go to SALE -> Distribution Customer Model -> Distribute Customer Model -> Distribute Customer Model.• Specify the Customer Model to be distributed — CHRCLSMODL.• Specify the Receiving Logical System — CHRCLSR301.• Execute.

You should receive a message confirming the success of the action. Browse the Customer Distribution Model on the target system to see that it has been created correctly.

Working the Interface

Now that we have configured the system for an R/3-to-R/3 interface, let’s examine the methods for executing this interface and for understanding its results. This section will also go over techniques for monitoring the communications and will discuss performance issues related to R/3-R/3 ALE communications.

Sending data. SAP provides standard ALE programs for sending and processing IDOCs. The two programs we are going to use to send data to the target system are RBDSECHR for sending Characteristics Master and RBDSECLS for sending Class Master. Note that characteristics data has to be sent before the Class Master, since characteristics belong to classes — classes are like envelopes for characteristics. As a first step, let’s create the communication IDOCs on the sending system. To do this:

• Go to BALE Æ Master Data -> Classification System -> Characteristics -> Send. This is the same as executing program RBDSECHR or transaction BD91.• Enter the name of the Logical System — CHRCLSR301 in this case.• Execute.

If the number of characteristics is large, then you should schedule RBDSECHR as a background job after having defined an appropriate variant. Use transaction WE05 to view the created IDOCs. They should be in status “30” — IDOC ready for dispatch (ALE service). Browse the IDOCs to understand and verify the data.

For the Class Master:

• Go to BALE Æ Master Data -> Classification System -> Class -> Send. This is the same as program RBDSECLS or transaction BD92.• Enter the class types — 001 for Material and 011 for Customer in this case. Enter the names of classes you want to distribute. Enter the name of the Logical System — CHRCLSR301 in this case.• Execute.

If the number of classes is large, you should schedule program RBDSECLS as a background job with an appropriate variant. Display the created IDOCs, and browse them to understand and verify the data.

Dispatching IDOCs to the target system. Once you have created the communication IDOCs, the next step is to dispatch them to the target system. This is when the tRFC calls are invoked to connect and communicate to the remote system. Using transaction SM59, test the connection for RFC destination CHRCLSR301 to ensure that the communication channels are open and working.

• Go to WEDI -> Test -> Outbound from IDOCs. This is the same as program RSEOUT00 or transaction WE14.• Enter the parameters, such as message types (CHRMAS, CLSMAS), partner number of receiver, and date last created.• Execute.

If there is a large number of IDOCs, schedule program RSEOUT00 as a background job with an appropriate variant. After processing, you should find all IDOCs to be in a status of “03”—Data passed to port OK. Bear in mind that a status of “03” does not necessarily imply that the tRFC communication was successful. I’ll discuss a method of updating this status with the results of the final processing later in this section.

Monitoring transactional RFC. While dispatching IDOCs from one R/3 system to another using tRFC, it is possible to monitor the communications and take appropriate actions to ensure its success. The main tool is the tRFC monitor, which can be accessed via BALE -> Monitoring -> Transactional RFC. This is the same as executing transaction SM58 or program RSARFCRD. Enter the period and user who initiated the RFC. This log displays only RFC calls that had an error. If there are entries in the log, you can analyze them by reading the system logs and dumping analysis for that period using transactions SM21 and ST22 successively. Carefully analyze these errors to take the correct action. The R/3 Connection may not be active, or the user may not have the necessary authorization for creating entries in the target system. If the problems are other than certain mandatory settings, most RFC transactions should get processed within a small period of time. In case of errors in communication, you may find several jobs in the Job Overview (transaction SM37) with a prefix ARFC. These are normal, since the system is scheduling jobs to reprocess the RFC transactions. However, an excessive number of such jobs could bog down the system, since all batch processors would get flooded, resulting in a repetitive loop causing more jobs to be created. The status records of RFC calls sent from the system are stored in table ARFCSSTATE, while those of RFC calls on the receiver system are stored in table ARFCRSTATE.

Processing IDOCs on the target system. When the IDOCs arrive on the target system from the host machine, they are created with a status of “64” — IDOC ready to be passed to application. This is because we chose the option of “background” on the target system, rather than processing them immediately. We now need to run a program that will process these IDOCs and post the data to the application. To do this:

• Go to BALE -> Periodic Work -> ALE Inbound IDOCs. Choose the radio button for “64” — IDOC ready to be passed to application. Execute. This is the same as executing program RBDAPP01.• In the panel displayed, enter parameters such as message type (CHRMAS and CLSMAS in this case), creation date, or IDOC numbers. Execute.• A list will be displayed indicating the status of the processing.

Also check the status of the IDOCs, using transaction WE02 or WE05. All IDOCs must have a status of “53”—Application document posted.

If workflow has been set up, you will receive work items in your inbox in case of errors. There you can edit the IDOCs if the errors are related to data and then reprocess them. However, in case of application errors, you can check the logs to determine the cause of these errors and take remedial action.

The necessary steps include:

• Execute transaction SLG1.

• Enter CAPI for Object (Classification system) and CAPI_LOG for Subobject. If necessary, enter time restrictions and user information. Execute.• You will see a display of errors pertaining to characteristics, and you will also see log messages for all successful class (CLSMAS) transactions.

In case of errors due to system availability, deadlocks, or temporal data problems, it is possible to schedule program RBDMANIN in the background to reprocess the IDOCs in a status of “51” — Error: Application document not posted.

How does the sending system know that the tRFC calls to the remote system were successful? There is a program you can execute that collects information about the result of the tRFC calls on the remote system and reports the information to the host client.

To do this:

• Go to BALE -> Periodic Work -> Check IDOC Dispatch. This is the same as executing program RBDMOIND or transaction BD75.• Enter the IDOC creation date and the number of IDOCs after which the process can be committed, say 100. This implies that after checking the status of 100 IDOCs, the program will update its status.

If the tRFC calls were successful, the aforementioned process should update the status of the IDOCs dispatched to “12” — Dispatch OK.

IDoc Inbound Reports Described

Written by Kevin Wilson

The following is a short list of key reports that process inbound IDocs. They are sometimes usefull to have run in a batch mode.

1) RBDMANIN - Start Error Handling for Non-Posted IDocs

Description: This report attempts to post the inbound IDocs with status '51' (Application document not posted)

2) RBDAGAIN - Process Outbound IDocs with Errors Again

Description: This report reprocesses outbound IDocs which contain errors. IDocs containing errors have one of the following statuses:

02: Error transmitting data to port 04: Error in EDI subsystem control information 05: Error in conversion 25: Continue processing despite syntax error (outbound) 29: Error in ALE service

3) RBDAGAIE - Reprocessing of Edited IDocs

Description: This report reprocesses an edited IDoc in inbound or outbound processing. The edited IDoc has one of the following statuses:

32: IDoc edited (outbound) 69: IDoc edited (inbound)

4) RBDAGAI2 - Re-processing of IDocs after ALE Input Error

Description: You use this report to reprocess inbound IDocs containing errors. IDocs containing errors have one of the following statuses:

56: IDoc containing errors added 61: Continue processing despite syntax error (inbox) 63: Error passing IDoc to the application 65: Error in ALE service

5) RBDAPP01 - Inbound Processing of IDocs Ready for Transfer

Description: Report for processing inbound IDocs not passed to the application immediately. This report forwards all IDocs with:

Status 64 "ready to be passed to application" Status 66 "IDoc is waiting for predecessor IDoc (serialization)

What is the difference between ALE, EDI, IDocs and BAPI?

(http://searchsap.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid21_gci879631,00.html)

The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.

IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.

The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.

Data Exchange via IDoc with ALE or EDI

(https://www.sdn.sap.com/irj/sdn/ale#section2)

IDoc or Intermediate Document is a standard SAP document exchange format. IDocs allow different application systems to be linked via a message-based interface. The IDoc interface consists of the definition of a data structure (where the data structure is the IDoc) and a processing logic for this data structure. 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 is posted to the application.

The following techniques use the IDoc interface to exchange business data between different systems:

Electronic Data Interchange (EDI) was the first form of data transfer to use IDocs. In EDI application scenarios, the processes, by definition, involve two partners: The sender and the recipient of an EDI message. EDI is a bilateral, document-oriented form of data transfer.

Application Link Enabling (ALE) enables integration of business processes that are developed across several SAP systems or non-SAP systems. Thus, ALE is oriented to connect different applications on different systems. System-wide ALE message flows are modeled in a so called 'distribution model'. A typical scenario is the system data administration, where material master records have to be distributed from one central to several satellite systems. Nowadays, pure EDI scenarios are more and more executed on the basis of ALE technology, only that the system connection is 'just' bilateral.

You find detailed information on ALE under the following links:

Literature Presentations Frequently Asked Questions Certifiable Interfaces Important Links

EDI/IDoc: How is an EDI project carried out?

Note Number 0047071 Released on 29.01.1997 Release

SymptomHow should you go about an EDI project? What steps are required?Additional key wordsIDoc, EDI, EDIFACT, ANSI X12, ODETTE, VDACause and preconditionsSolutionWhen executing an EDI project, different aspects must be considered. The expense for such a project must be determined on an individual basis, as such projects are customer-specific and require a lot of consultation.The following aspects are involved in an EDI project:

1. Selection of business partners You must choose the business partners involved in the EDI. The EDI standard to be used and the messages to be exchanged must be the same for all partners.

1. Selection of the EDI Subsystem An EDI Subsystem (translator, converter) is required to convert the SAP format IDoc into the message format of an EDI Standard. You must select a corresponding product. The IDoc interface is open, so that various EDI Subsystems can be added.SAP does not offer any EDI subsystem itself!Within our Authentication Program (Complementary Software Program CSP), SAP has certified some of these systems. Please note here, that this is a purely technical and functional authentication of the interface. That is, we test whether IDocs can be sent and received and whether a status report is created for sent IDocs. The authentication is not a business-based, functional test.

1. Implementation of the EDI procedure You are recommended here to follow four steps:

a. Complete implementation of the SAP application b. Internal SAP test of the IDoc interface c. Test the IDoc interface with the EDI Subsystem d. Start production

In particular the internal SAP test of the IDoc interface great attention is be dedicated since he allows in a very early stage to recognize errors and lacks of implementation.Complete implementation of SAP applicationBefore you start implementing the EDI or IDoc functionality, the affected SAP applications must be implemented and their functionality must be available.Internal SAP test of the IDoc interfaceThe test is made up of a combination of the technical, functional test as well as the business-based, functional test.

Technical, functional testHere, you should test whether IDocs from the SAP application are created and that they can be transferred to the file system (Outbound processing). Furthermore, you should test whether IDocs are copied in the file system and can be processed by the SAP application (Inbound processing).The individual steps can be supported with test tools:Output: Test from the NAST record (message control for MM and SD) with transaction WE15. An application document must previously be created in the application. Output: Test from the IDoc with transaction WE14. An application document must previously be created in the application. Inbox: Test from a formally correct inbound file with transaction WE16. The file can be made available first, or must be manually created with an editor in the usual way. Inbox: Test from an outbound file with transaction WE12. The file comes from one of the two named output tests. Inbox: Test from IDoc, including manual creation of the IDocs, with transaction WE19 (only from Release 3.1). Business-based, functional testFor the created output IDocs, you must check that the IDoc contains all the data that was agreed on with the partner. This means that the data must be checked and compared field by field. If differences are found, proceed as follows:Can the data be produced by maintaining the basic data (customer, vendor, material or information record)? Can the data be produced by additional input in the transactions for the documents (purchase order, order, etc)? Is the corresponding application function that processes this data available at all? You should, of course, proceed in the same way for incoming IDocs. However, this check can be made using the SAP application. This decides, whether the data is sufficient to create or change an application document. Exceptions which cause notification via the SAP Business Workflow are triggered if necessary.In the tests, you should also check that these notifications reach the correct people.Once the tests described here have been completed and were successful, you can start connecting the EDI subsystem.Test the IDoc interface with the EDI SubsystemWith the EDI Subsystem, you must conduct both local and remote tests.Local testIn the local test of outgoing messages, you must ensure that the EDI messages created from the IDocs are in accordance with your partner. Via transaction WE17, you should also test that the status report of the EDI subsystem contains the required information on the initial IDocs and that exceptions are forwarded to the correct people. For incoming messages, you should check that the IDocs created from these messages can be processed by the SAP application. That is, the corresponding application documents can be created or changed. Remote testWith the remote test, you should pay attention to the communication with the partner as well as the processing of the messages by the respective partner system.Please note, that many EDI standards allow messages to be transferred in a test mode. Thus, you can test the chain of processing, transmission and further processing and distinguish these messages from "productive" messages at the same time.

The test mode is indicated in the IDoc in the control record in the field TEST. In the EDI standard EDIFACT, this is made clear in the service segment UNB, data element 0035, and in the EDI standard ANSI X12, in the service segment ISA, data element I14.For SAP, it is entered in the partner profile for output. In the input, it is the key field of the partner profile, so that the business processes can also be controlled by this.Start productionThe productive phase of the EDI application may only be started if the tests were completed successfully.The tests here represent the minimum requirements for a successful EDI project. Further information can be obtained from the National Standardization Office (in Germany, the DIN) or through your EDI consulting partner.Source code correctionsRelated notes

0032121 EDI/IDoc: Workflow in the EDI and IDoc basis0041365 EDI/IDoc: Certified EDI subsystems for 3.0 and 3.10044416 EDI/IDoc: Messages from IDoc processing0114714 EDI/IDoc: Certified EDI subsystems for 4.x0116610 EDI/IDoc: Notifications from IDoc processing

Wikipedia: EDIFACT

United Nations/Electronic Data Interchange For Administration, Commerce, and Transport (UN/EDIFACT) is the international EDI standard developed under the United Nations. The work of maintenance and further development of this standard is done through the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) under the UN Economic Commission for Europe, in the Finance Domain working group UN CEFACT TBG5. EDIFACT has been adopted by the International Organization for Standardization (ISO) as the ISO standard ISO 9735.

The EDIFACT standard provides

A set of syntax rules to structure data, An interactive exchange protocol (I-EDI), Standard messages which allow multi-country and multi-industry exchange.

Example

See below for an example of an EDIFACT message used to answer to a product availability request:

UNB+IATB:1+6XPPC+LHPPC+940101:0950+1’UNH+1+PAORES:93:1:IA’MSG+1:45’IFT+3+XYZCOMPANY AVAILABILITY’ERC+A7V:1:AMD’IFT+3+NO MORE FLIGHTS’ODI’TVL+240493:1000::1220+FRA+JFK+DL+400+C’PDI++C:3+Y::3+F::1’APD+74C:0:::6++++++6X’TVL+240493:1740::2030+JFK+MIA+DL+081+C'PDI++C:4’APD+EM2:0:1630::6+++++++DA’UNT+13+1’UNZ+1+1’

' is a segment terminator + is a data element separator  : is a component data element separator  ? is a release character

Note: The line breaks after each segment in this example have been added for readability. There are typically no line breaks in EDI data.

UNH+1+PAORES:93:1:IA’- This is the header segment which is required at the start of every message. This code specifies that the message name and version is PAORES 93 revision 1 and it was defined by the organisation IA (IATA).

IFT+3+NO MORE FLIGHTS’ - This is an 'Interactive Free Text' segment containing the text 'NO MORE FLIGHTS'

UNT+13+1’ - This is the tail segment. It indicated that the message sent contains 13 segments.

Structure

EDIFACT has a hierarchical structure where the top level is referred to as an interchange, and lower levels contain multiple messages which consist of segments, which in turn consist of composites. The final iteration is an element which is derived from the United Nations Trade Data Element Directory (UNTDED) and are normalised throughout the EDIFACT standard.

A group or segment can be mandatory (M) or conditional (C) and can be specified to repeat. For example, C99 indicates between 0 and 99 repetitions of a segment or group, while M99 signifies between 1 and 99 repetitions.

A group, like a message, is a sequence of segments or groups. The first segment or group beneath a group must be mandatory, and the group should be made conditional if the logic of the situation demands it.

Current state of EDIFACT

There is an apparent battle between XML and EDIFACT. An equivalent XML message has a larger file size than an EDIFACT message, but it is easier for users to read (although this is not necessary because the contents are created to be read by computers). Another possible explanation is that compatibility is being favored over performance, since more tools exist to work with XML data than with EDIFACT. EDIFACT-messages can be up to ten times smaller than XML-messages, and are not recommended for large message contents.

An advantage of EDIFACT is the availability of agreed message-contents, which XML must leverage to develop its own similar agreed contents. RosettaNet is one of the emerging XML standards and is widely used in semiconductors and high tech industries.

UBL is another currently being adopted by Scandinavian governments as a legally required standard for sending invoices to governments, and was enforced in February 2005 that all invoices to the Danish government must be sent in an electronic format.

ebXML is another XML standard built by UN/CEFACT (along with EDIFACT), and is often seen as a standard best suited for small and medium enterprises.

However, EDIFACT is likely to remain the most widely used in high tech, civil aviation, retail and tourism industries, due to the amount of software that leverages the standard, and the need for integration between new systems and legacy systems.

Europe has a large EDIFACT installed base because it adopted the technology early, while the Asian region adopted B2B in later implementations and is therefore using more XML standards.

EDIFACT will grow further in Europe's energy market where it is a current requirement.

See also Electronic Data Interchange X12 EDIFACT Mapping X12 XML/EDIFACT

External links UN/EDIFACT Main Page

Wikipedia:

Workgroup for Electronic Data Interchange

WEDI, pronounced "wee dee" is a not-for-profit user group in the United States for users of Electronic Data Interchange (EDI) in public and private healthcare. The organization is sometimes referred to by other names that include some or all of the words: Workgroup for Electronic Data Interchange.

It was established to provide leadership and guidance to the healthcare industry on how to use and leverage its collective knowledge, expertise and information resources to improve the quality, affordability and availability of healthcare, via forums, conferences and online resources, especially in matters of conformance to EDI standards required by the Health Insurance Portability and Accountability Act, also known as HIPAA which was enacted by the U.S. Congress in 1996.

WEDI has regional affiliates in 27 US States and the Virgin Islands.

History

In November 1991, the Workgroup for Electronic Data Interchange (WEDI) was established in response to the challenge from the Bush administration, specifically, Louis Sullivan MD, Secretary of HHS to reduce administrative costs in the nation's health care system by up to 10%.

Joseph Brophy, President of Travelers Insurance Company, and Bernard Tresnowski, President of the Blue Cross and Blue Shield Association agreed to establish and lead a voluntary, public-private task force, named WEDI, to develop an action plan to streamline health care administration by standardizing electronic communications across the health care and health insurance industry.

Initial task force

The initial task force included members from the following organizations:

The Travelers Insurance Company Blue Cross and Blue Shield Association Self-Insurance Institute of America American Medical Association ANSI ASC X12 Mutual of Omaha American Hospital Association Drug Benefit Management United Healthcare Group American Clinical Laboratory Association Columbia Healthcare Corporation Medical Group Management American Nurses Association Aetna Life Insurance Company American Dental Association Health Insurance Association of America National Committee to Preserve Social Security and Medicare Health Technology Management, Inc National Association for Home Care Health Care Financing Administration American Association of Retired Persons American Health Information Management Association Blue Cross of California American Health Care Association Department of Income Maintenance State of Connecticut.

WEDI 1992 report highlights

In July 1992, WEDI published a report that outlined the steps necessary to make electronic data interchange (EDI) a routine business practice for the health care industry by 1996. The Workgroup envisioned the entire health care industry transacting business electronically, under a nationwide set of coding and format standards for all transactions. The transaction records would be transmitted electronically, in a secure manner to protect privacy, over private and public interconnecting networks like the internet and intranet. In the year following the publication of the WEDI report, the health care industry made substantial gains with EDI implementation:

ANSI ASC X12 approved the claim and eligibility standards for trial use

The Insurance Subcommittee of ANSI ASC X12 formed new workgroups to develop other standards required by the health care industry

HCFA initiated the use of Health Care Claim and Health Care Claim Payment/Advice standards and developed Efforts toward standardizing data content increased. EDI implementation guidelines for Medicare Part A Intermediaries and Part B Carriers consistent with the ANSI ASC X12 standards

The private sector began developing EDI implementation guides

EDI awareness and participation heightened as well as efforts to standardize data content

WEDI 1993 report highlights

WEDI reconvened in 1993 to resolve remaining implementation obstacles and to:

strengthen the understanding of and commitment to EDI among the health care industry, policymakers, and consumers by: developing a targeted plan for using industry resources to educate key audiences on EDI, encouraging participation in demonstration projects that prove EDI benefits and cost savings, and expanding membership to reflect more broadly the key constituencies affected by EDI

work for enactment of preemptive federal confidentiality protection for individually identifiable health care information in an electronic environment

develop a strategy to facilitate quick, industry-wide transition to EDI, including universal identifiers for patients, providers, and payors; health identification cards; coordination of benefits in electronic environments; and implementation guidance for data standards

work with appropriate parties to ensure the health care industry can meet WEDI's target of universal adherence to uniform data content by 1996

provide additional data to the industry on the cost benefits of EDI, using WEDI demonstration projects as a primary source

monitor the industry's progress toward the use of data standards and EDI

provide basic telecommunications requirements and promote WEDI's goal of clearinghouse accreditation by 1994

serve as a resource to work cooperatively with the National Association of Insurance Commissioners and state governments to coordinate state and national efforts on administrative simplification.

WEDI financials identify $42 billion in potential savings

WEDI expanded its financial analysis to encompass eleven health care transactions. Newly available data were added to estimate the potential savings for providers and to update the estimated savings for payors and employers. Additionally, the cost of implementing EDI was added to achieve a more comprehensive picture of EDI's financial impact on the health care industry.

WEDI's 1993 financial analyses concludes that combining the estimated implementation costs and the gross administrative savings potential, the cumulative net savings over the next six years (to the year 2000) is estimated to total over $42 billion. Although the estimated net savings may not translate directly to hard dollar savings for the nation's health care system, EDI savings will allow health care enterprises to reallocate resources from administrative activities to enhance quality, patient care, and customer service.

To achieve this large cost savings, WEDI's eleven Technical Advisory Groups developed the following major recommendations. These recommendations are summarized below according to the Technical Advisory Group that developed the recommendation:

require specific and defined instructions through implementation guides to support uniform data content and coding structures (Standards Implementation and Uniform Data Content)

develop a network architecture to support a broad array of applications, communications, access methods, protocols, and line speeds (Network Architecture and Accreditation)

enact the model federal preemptive legislation drafted by WEDI to preserve confidentiality and privacy rights of individually identifiable health care information (Confidentiality and Legal Issues)

identify unique, standard identification numbers to promote industry standardization and uniformity of health care data (Unique Identifiers for the Health Care Industry)

develop and promote a comprehensive education and publicity work plan designed to provide standardized, economically affordable and geographically accessible education opportunities for all EDI constituents (Education and Publicity)

develop an ASC X12 standard for data content and format for health identification cards (Health Identification Cards)

continue demonstration projects that are ecumenical, identifiable to the public, demonstrate industry cooperation, leverage existing infrastructures, add something new, measure results, and meet aggressive time frames to demonstrate that technology is currently available to implement WEDI recommendations (Short-Term Strategies)

clearly delineate state and federal roles for EDI implementation (State/Federal Role)

provide ongoing analysis of the financial implications of EDI implementation (Financial Implications)

automate the Coordination of Benefits process (Coordination of Benefits)

use electronic environments and standardized data to improve fraud detection (Health Care Fraud Prevention and Detection).

HIPAA

The leadership and guidance provided by WEDI to the healthcare industry on how to use and leverage its collective knowledge, expertise and information resources to improve the quality, affordability and availability of healthcare, via forums, conferences and online resources, especially in matters of conformance to EDI standards required by the Health Care Financing Administration (HCFA), now known as the Centers for Medicare and Medicaid Services (CMS) led to the development of Health Insurance Portability and Accountability Act (HIPAA) which was enacted by the U.S. Congress in 1996.

See also Electronic Data Interchange (EDI) Health Insurance Portability and Accountability Act (HIPAA) Centers for Medicare and Medicaid Services (CMS)

External links WEDI

Wikipedia: ASC X12

ASC X12 (also known as ANSI ASC X12) is the official designation of the U.S. national standards body for the development and maintenance of Electronic Data Interchange (EDI) standards. The group was founded in 1979, and is an accredited standards committee under the American National Standards Institute (ANSI). The acronym stands for "American National Standards Institute Accredited Standards Committee X12", with the designation of X12 being a sequential designator assigned by ANSI at the time of accreditation with no other significance.

ASC X12 has sponsored more than 315 X12-based EDI standards and a growing collection of X12 XML schemas for health care, insurance, government, transportation, finance, and many other industries. ASC X12's membership includes 3,000+ standards experts representing over 350 companies from multiple business domains.

CICA

CICA (or Context Inspired Component Architecture) is a new approach to message design aimed at resolving the costly proliferation of differing (and often incompatible) XML messages used for business-to-business data exchange. CICA gives developers access to reusable components that can be used to construct interface standards to satisfy common business requirements as well as industry-specific needs.

CICA is a syntax-neutral architecture which supports both business content and implementation information. CICA messages ("documents") can currently be expressed as XML schema.

CICA's reusable syntax-neutral message components are maintained in a central data store that supports a variety of functions including: data entry and maintenance, data retrieval (from full message structure to individual components), flexible reporting capabilities for development support, and end-user documents including XML schemas and user-friendly reference guides.

Complementing the CICA data store is the X12 CICA Metadata Interchange Format (CICA-MIF). The CICA-MIF is a structured guideline for the bi-directional exchange between X12 development tools, the central data store and other technology providers' software that supports the interchange format. This XML schema will enable X12 developers to use world-class commercial off-the-shelf tools to develop message standards for submission into the CICA database.

See also Electronic Data Interchange EDIFACT X12 EDIFACT Mapping List of X12 EDI transaction sets

External links Accredited Standards Committee X12

Wikipedia: X12 Document List

The following is a list of the approved EDI ANSI X12 documents for EDI version 4 Release 1 (004010):

Order Series (ORD)180 Return Merchandise Authorization and Notification290 Cooperative Advertising Agreements810 Invoice816 Organizational Relationships832 Price/Sales Catalog850 Purchase Order855 Purchase Order Acknowledgment856 Ship Notice/Manifest857 Shipment and Billing Notice860 Purchase Order Change Request - Buyer Initiated865 Purchase Order Change Acknowledgment/Request - Seller Initiated875 Grocery Products Purchase Order876 Grocery Products Purchase Order Change877 Manufacturer Coupon Family Code Structure880 Grocery Products Invoice881 Manufacturer Coupon Redemption Detail885 Retail Account Characteristics887 Coupon Notification888 Item Maintenance

Materials Handling Series (MAT)511 Requisition517 Material Obligation Validation527 Material Due-In and Receipt840 Request for Quotation843 Response to Request for Quotation845 Price Authorization Acknowledgment/Status847 Material Claim851 Asset Schedule878 Product Authorization/De-authorization

879 Price Information893 Item Information Request

Tax Services Series (TAX)149 Notice of Tax Adjustment or Assessment151 Electronic Filing of Tax Return Data Acknowledgment152 Statistical Government Information155 Business Credit Report157 Notice of Power of Attorney170 Revenue Receipts Statement521 Income or Asset Offset540 Notice of Employment Status813 Electronic Filing of Tax Return Data826 Tax Information Exchange

Warehousing Series (WAR)883 Market Development Fund Allocation884 Market Development Fund Settlement886 Customer Call Reporting891 Deduction Research Report940 Warehouse Shipping Order943 Warehouse Stock Transfer Shipment Advice944 Warehouse Stock Transfer Receipt Advice945 Warehouse Shipping Advice947 Warehouse Inventory Adjustment Advice990 Response to a Load Tender

Financial Series (FIN)248 Account Assignment/Inquiry and Service/Status810 Invoice811 Consolidated Service Invoice/Statement812 Credit/Debit Adjustment818 Commission Sales Report819 Operating Expense Statement820 Payment Order/Remittance Advice821 Financial Information Reporting822 Account Analysis823 Lockbox824 Application Advice827 Financial Return Notice828 Debit Authorization829 Payment Cancellation Request

831 Application Control Totals859 Freight Invoice980 Functional Group Totals

Government Series (GOV)105 Business Entity Filings150 Tax Rate Notification151 Electronic Filing of Tax Return Data Acknowledgment152 Statistical Government Information153 Unemployment Insurance Tax Claim or Charge Information154 Uniform Commercial Code Filing175 Court and Law Enforcement Notice176 Court Submission185 Royalty Regulatory Report195 Federal Communications Commission (FCC) License Application256 Periodic Compensation280 Voter Registration Information

Manufacturing Series (MAN)196 Contractor Cost Data Reporting830 Planning Schedule with Release Capability844 Product Transfer Account Adjustment846 Inventory Inquiry/Advice849 Response to Product Transfer Account Adjustment852 Product Activity Data861 Receiving Advice/Acceptance Certificate866 Production Sequence867 Product Transfer and Resale Report869 Order Status Inquiry870 Order Status Report894 Delivery/Return Base Record895 Delivery/Return Acknowledgment or Adjustment

Delivery Series (DEL)219 Logistics Service Request220 Logistics Service Response222 Cartage Work Assignment223 Consolidators Freight Bill and Invoice224 Motor Carrier Summary Freight Bill Manifest225 Response to a Cartage Work Assignment250 Purchase Order Shipment Management Document853 Routing and Carrier Instruction

854 Shipment Delivery Discrepancy Information856 Ship Notice/Manifest857 Shipment and Billing Notice858 Shipment Information862 Shipping Schedule882 Direct Store Delivery Summary Information

Engineering Management & Contract Series (ENG)196 Contractor Cost Data Reporting501 Vendor Performance Review503 Pricing History504 Clauses and Provisions536 Logistics Reassignment561 Contract Abstract567 Contract Completion Status568 Contract Payment Management Report620 Excavation Communication625 Well Information650 Maintenance Service Order805 Contract Pricing Proposal806 Project Schedule Reporting836 Procurement Notices838 Trading Partner Profile839 Project Cost Reporting841 Specifications/Technical Information871 Component Parts Content896 Product Dimension Maintenance

Insurance/Health Series (INS)100 Insurance Plan Description112 Property Damage Report148 Report of Injury, Illness or Incident186 Insurance Underwriting Requirements Reporting252 Insurance Producer Administration255 Underwriting Information Services267 Individual Life, Annuity and Disability Application268 Annuity Activity270 Eligibility, Coverage or Benefit Inquiry271 Eligibility, Coverage or Benefit Information272 Property and Casualty Loss Notification273 Insurance/Annuity Application Status274 Health Care Provider Information

275 Patient Information276 Health Care Claim Status Request277 Health Care Claim Status Notification278 Health Care Services Review Information288 Wage Determination362 Cargo Insurance Advice of Shipment500 Medical Event Reporting820 Premium Payments834 Benefit Enrollment and Maintenance835 Health Care Claim Payment/Advice837 Health Care Claim924 Loss or Damage Claim - Motor Vehicle925 Claim Tracer926 Claim Status Report and Tracer Reply928 Automotive Inspection Detail

Miscellaneous ANSI X12 Transactions Series (MIS)101 Name and Address Lists159 Motion Picture Booking Confirmation242 Data Status Tracking814 General Request, Response or Confirmation815 Cryptographic Service Message864 Text Message868 Electronic Form Structure996 File Transfer997 Functional Acknowledgment998 Set Cancellation

Mortgage Series (MOR)197 Real Estate Title Evidence198 Loan Verification Information199 Real Estate Settlement Information200 Mortgage Credit Report201 Residential Loan Application202 Secondary Mortgage Market Loan Delivery203 Secondary Mortgage Market Investor Report205 Mortgage Note206 Real Estate Inspection260 Application for Mortgage Insurance Benefits261 Real Estate Information Request262 Real Estate Information Report263 Residential Mortgage Insurance Application Response

264 Mortgage Loan Default Status265 Real Estate Title Insurance Services Order266 Mortgage or Property Record Change Notification833 Mortgage Credit Report Order872 Residential Mortgage Insurance Application

Product Services Series (PSS)140 Product Registration141 Product Service Claim Response142 Product Service Claim143 Product Service Notification180 Return Merchandise Authorization and Notification244 Product Source Information889 Promotion Announcement

Quality and Safety Series (QSS)138 Testing Results Request and Report249 Animal Toxicological Data285 Commercial Vehicle Safety and Credentials Information Exchange286 Commercial Vehicle Credentials842 Nonconformance Report848 Material Safety Data Sheet863 Report of Test Results

Student Information Series (STU)130 Student Educational Record (Transcript)131 Student Educational Record (Transcript) Acknowledgment135 Student Loan Application139 Student Loan Guarantee Result144 Student Loan Transfer and Status Verification146 Request for Student Educational Record (Transcript)147 Response to Request for Student Educational Record (Transcript)188 Educational Course Inventory189 Application for Admission to Educational Institutions190 Student Enrollment Verification191 Student Loan Pre-Claims and Claims194 Grant or Assistance Application

Transportation

Air and Motor Series (TAM)104 Air Shipment Information

106 Motor Carrier Rate Proposal107 Request for Motor Carrier Rate Proposal108 Response to a Motor Carrier Rate Proposal110 Air Freight Details and Invoice204 Motor Carrier Load Tender210 Motor Carrier Freight Details and Invoice211 Motor Carrier Bill of Lading212 Motor Carrier Delivery Trailer Manifest213 Motor Carrier Shipment Status Inquiry214 Transportation Carrier Shipment Status Message215 Motor Carrier Pick-up Manifest216 Motor Carrier Shipment Pick-up Notification217 Motor Carrier Loading and Route Guide218 Motor Carrier Tariff Information250 Purchase Order Shipment Management Document251 Pricing Support601 U.S. Customs Export Shipment Information602 Transportation Services Tender715 Intermodal Group Loading Plan920 Loss or Damage Claim - General Commodities

Ocean Series (TOS)109 Vessel Content Details300 Reservation (Booking Request) (Ocean)301 Confirmation (Ocean)303 Booking Cancellation (Ocean)304 Shipping Instructions309 U.S. Customs Manifest310 Freight Receipt and Invoice (Ocean)311 Canadian Customs Information312 Arrival Notice (Ocean)313 Shipment Status Inquiry (Ocean)315 Status Details (Ocean)317 Delivery/Pickup Order319 Terminal Information322 Terminal Operations and Intermodal Ramp Activity323 Vessel Schedule and Itinerary (Ocean)324 Vessel Stow Plan (Ocean)325 Consolidation of Goods In Container326 Consignment Summary List350 U.S. Customs Status Information352 U.S. Customs Carrier General Order Status

353 U.S. Customs Events Advisory Details354 U.S. Customs Automated Manifest Archive Status355 U.S. Customs Acceptance/Rejection356 U.S. Customs Permit to Transfer Request357 U.S. Customs In-Bond Information358 U.S. Customs Consist Information361 Carrier Interchange Agreement (Ocean)

Rail Series (TRS)161 Train Sheet404 Rail Carrier Shipment Information410 Rail Carrier Freight Details and Invoice414 Rail Carhire Settlements417 Rail Carrier Waybill Interchange418 Rail Advance Interchange Consist419 Advance Car Disposition420 Car Handling Information421 Estimated Time of Arrival and Car Scheduling422 Shipper's Car Order423 Rail Industrial Switch List425 Rail Waybill Request426 Rail Revenue Waybill429 Railroad Retirement Activity431 Railroad Station Master File432 Rail Deprescription433 Railroad Reciprocal Switch File434 Railroad Mark Register Update Activity435 Standard Transportation Commodity Code Master436 Locomotive Information437 Railroad Junctions and Interchanges Activity440 Shipment Weights451 Railroad Event Report452 Railroad Problem Log Inquiry or Advice453 Railroad Service Commitment Advice455 Railroad Parameter Trace Registration456 Railroad Equipment Inquiry or Advice460 Railroad Price Distribution Request or Response463 Rail Rate Reply466 Rate Request468 Rate Docket Journal Log470 Railroad Clearance475 Rail Route File Maintenance

485 Ratemaking Action486 Rate Docket Expiration490 Rate Group Definition492 Miscellaneous Rates494 Rail Scale Rates

Automotive Series (TAS)120 Vehicle Shipping Order121 Vehicle Service124 Vehicle Damage125 Multilevel Railcar Load Details126 Vehicle Application Advice127 Vehicle Baying Order128 Dealer Information129 Vehicle Carrier Rate Update160 Transportation Automatic Equipment Identification163 Transportation Appointment Schedule Information

See Also Electronic Data Interchange EDIFACT X12 EDIFACT Mapping

Wikipedia: X12 EDIFACT Mapping

In 1979, the American National Standards Institute (ANSI) chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards for interindustry electronic exchange of business transactions-electronic data interchange (EDI)

In 1986, the United Nations Economic Commission for Europe (UN/ECE) approved the acronym "UN/EDIFACT," which translates to United Nations Electronic Data Interchange for Administration, Commerce and Transport. UN/EDIFACT is an international EDI standard designed to meet the needs of both government and private industry.

The UN/EDIFACT Working Group (EWG), a permanent working group of the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), develops and maintains UN/EDIFACT

X12 is used in the USA but most of the rest of the world uses the EDIFACT transaction sets.

Mapping

This is a partial list of the more popular transaction sets.

TRANSACTION SET/DOCUMENT ANSI SET

EDIFACT

PRODUCT/PRICING TRANSACTIONSPrice Sales Catalog 832 PRICATPrice Authorization Acknowledgement/Status 845 --Specification/Technical Information 841 PRDSPERequest For Quotation 840 REQOTEResponse To Request For Quotation 843 QUOTESElectronic Bid Form 833 --ORDERING TRANSACTIONSPurchase Order 850 ORDERSPurchase Order Acknowledgement 855 ORDRSPPurchase Order Change 860 ORDCHGPurchase Order Change Acknowledgement 865 ORDRSPOrder Status Inquiry 869 ORSSTAOrder Status Report 870 ORDREPContract Award 836 --MATERIALS MANAGEMENT TRANSACTIONSPlanning Schedule/Material Release 830 DELFORShipping Schedule 862 DELJITProduction Sequence 866 --Ship Notice/manifest (ASN) 856 DESADVReport of Test Results 863 QALITYMaterial Safety Data Sheet 848 --Contract Award 836 --SHIPPING/RECEIVING TRANSACTIONSShipment Information (Bill of Lading) 858 IFTMCSReceiving Advice 861 RECADVNon-conformance Information-Disposition Transaction, Cause/Correction

842 NONCON

INVENTORY MANAGEMENT TRANSACTIONSInventory Inquiry/Advice 846 INVRPT

Product Transfer and Resale Report 867 SLSRPTProduct Transfer Account Adjustment 844 --Response To Product Transfer Account Adjustment 849 --FINANCIAL TRANSACTIONSInvoice 810 INVOICFreight Invoice 859 IFTMCSPayment order/Remittance Advice (EFT) 820 REMADVLockbox 823 --Financial Information Reporting 821 --CONTROL TRANSACTIONSFunctional Acknowledgement 997 CONTRLApplication Advice 824 BANSTATrading Partner Profile 838 PARTIN

See also Electronic Data Interchange EDIFACT X12 List of EDI ANSI X12 documents

External links Accredited Standards Committee (ASC) X12 UN/CEFACT Forum Management Group UN/EDIFACT Working Group (EWG) United Nations Centre for Trade Facilitation and Electronic Business Tradegate - Non-Government eCommerce Promotion Organisation

Computer Desktop Encyclopedia: e-business

(Electronic-BUSINESS) Doing business online. The term is often used synonymously with e-commerce, but e-business is more of an umbrella term for having a presence on the Web. An e-business site may be very comprehensive and offer more than just selling its products and services. For example, it may feature a general search facility or the ability to track shipments or have threaded discussions. In such cases, e-commerce is only the order processing component of the site. See e-commerce.

Wikipedia: Electronic business

Electronic Business, or "e-Business", may be defined broadly as any business process that relies on an automated information system. Today, this is mostly done with Web-based technologies. The term "e-Business" was coined by Lou Gerstner, CEO of IBM.

Electronic business methods enable companies to link their internal and external data processing systems more efficiently and flexibly, to work more closely with suppliers and partners, and to better satisfy the needs and expectations of their customers.

In practice, e-business is more than just e-commerce. While e-business refers to more strategic focus with an emphasis on the functions that occur using electronic capabilities, e-commerce is a subset of an overall e-business strategy. E-commerce seeks to add revenue streams using the World Wide Web or the Internet to build and enhance relationships with clients and partners and to improve efficiency using the Empty Vessel strategy. Often, e-commerce involves the application of knowledge management systems.

E-business involves business processes spanning the entire value chain: electronic purchasing and supply chain management, processing orders electronically, handling customer service, and cooperating with business partners. Special technical standards for e-business facilitate the exchange of data between companies. E-business software solutions allow the integration of intra and inter firm business processes. E-business can be conducted using the Web, the Internet, intranets, extranets, or some combination of these.

Subsets

Applications can be divided into three categories:

1. Internal business systems: o customer relationship management o enterprise resource planning o document management systems o human resources management

2. Enterprise communication and collaboration: o VoIP o content management system o e-mail o voice mail o Web conferencing o Digital work flows (or business process management)

3. electronic commerce - business-to-business electronic commerce (B2B) or business-to-consumer electronic commerce (B2C):

o internet shop o supply chain management o online marketing

Models

When organizations go online, they have to decide which e-business models best suit their goals. [1] A business model is defined as the organization of product, service and information flows, and the source of revenues and benefits for suppliers and customers. The concept of e-business model is the same but used in the online presence. The following is a list of the currently most adopted e-business models:

E-shops E-procurement E-malls E-auctions Virtual Communities Collaboration Platforms Third-party Marketplaces Value-chain Integrators Value-chain Service Providers Information Brokerage

Classification by provider and consumer

Roughly dividing the world into providers/producers and consumers/clients one can classify e-businesses into the following categories:

business-to-business (B2B) business-to-consumer (B2C) business-to-employee (B2E) business-to-government (B2G) government-to-business (G2B) government-to-government (G2G) government-to-citizen (G2C) consumer-to-consumer (C2C) consumer-to-business (C2B)

It is notable that there are comparably less connections pointing "upwards" than "downwards" (few employee/consumer/citizen-to-X models).

See also Electronic commerce Electronic business Extended enterprise

References1. ̂ Paul Timmers, (2000), Electronic Commerce - strategies & models for

business-to-business trading, pp.31, John Wiley & Sons, Ltd, ISBN 0-471-72029-1

External links

Wikibooks E-Commerce and E-Business zh-yue: 網上生意

What is an EDI Subsystem?The EDI subsystem (called an EDI translator for most non-SAP EDI people) is a system that translates SAP IDocs from and into industry standard electronic documents. These documents are then traded with suppliers, customers, and partners electronically.

Basically, SAP has its own format (IDoc), as do most ERP systems. Since these don't align with industry standards, a need exists for an application that can do this. Otherwise, you can't really do EDI.

Do I need one?If you're trading standard EDI documents (X.12, EDIFACT, UCS, TRADACOMS, etc) with other companies, then, yes, you probably do.

The reason is because SAP understands IDoc format; but not everyone is running SAP. And those folks running SAP are usually running different versions. And even if they're on the same version? Well, they'll have it configured differently.

So the bottom line is that if you're trading standard documents electronically, then you probably need a translator of some kind. And it's a good idea to buy one, even if they seem to be expensive at first glance. Remember, this is an important purchase, so consider the alternatives wisely.

A word of advice: don't try to write your own translator. This may sound like a great idea after a couple beers; but your business partners will generally not be excited to know you're running a homegrown translator that probably won't ensure accurate compliance with EDI standards. And you will be overwhelmed eventually by the maintenance nightmare as your scale increases and you need to manage multiple EDI versions (and possibly standards).

Who sells them?Sterling Commerce

Gentran (Windows, UNIX, OS/400), Gentran Integration Suite (most platforms)

Inovis Harbinger TrustedLink (Windows, OS/400)ATOS:Origin ACTIS EDImanagermendelson mendelson business integration (mbi) (JAVA)Others (additional translators)

Tip: To make things easier, most vendors also sell extenders (additional cost, cha-ching), which help you connect their product to SAP. They usually include command scripts and/or transport software. Be sure your connector also includes application definitions for the IDocs you'll use (ORDERS04, INVOIC02, etc) and template maps you can copy and

use. While this sounds trivial, you'll find it a major time-saver in the long run.  

EDI translator A program which converts stored data in a DATABASE into a ELECTRONIC DATA INTERCHANGE (EDI) format. The term is also used to describe programs which convert from one EDI format to another.

EDI Translators described

Written by anon

What is an EDI Subsystem?The EDI subsystem (called an EDI translator for most non-SAP EDI people) is a system that translates SAP IDocs from and into industry standard electronic documents. These documents are then traded with suppliers, customers, and partners electronically.

Basically, SAP has its own format (IDoc), as do most ERP systems. Since these don't align with industry standards, a need exists for an application that can do this. Otherwise, you can't really do EDI.

Do I need one?If you're trading standard EDI documents (X.12, EDIFACT, UCS, TRADACOMS, etc) with other companies, then, yes, you probably do.

The reason is because SAP understands IDoc format; but not everyone is running SAP. And those folks running SAP are usually running different versions. And even if they're on the same version? Well, they'll have it configured differently.

So the bottom line is that if you're trading standard documents electronically, then you probably need a translator of some kind. And it's a good idea to buy one, even if they seem to be expensive at first glance. Remember, this is an important purchase, so consider the alternatives wisely.

A word of advice: don't try to write your own translator. This may sound like a great idea after a couple beers; but your business partners will generally not be excited to know you're running a homegrown translator that probably won't ensure accurate compliance with EDI standards. And you will be overwhelmed eventually by the maintenance nightmare as your scale increases and you need to manage multiple EDI versions (and possibly standards).

Who sells them?Sterling Commerce

Gentran (Windows, UNIX, OS/400), Gentran Integration Suite (most platforms)

Inovis Harbinger TrustedLink (Windows, OS/400)ATOS:Origin ACTIS EDImanagermendelson mendelson business integration (mbi) (JAVA)Others (additional translators)

Tip: To make things easier, most vendors also sell extenders (additional cost, cha-ching), which help you connect their product to SAP. They usually include command scripts and/or transport software. Be sure your connector also includes application definitions for the IDocs you'll use (ORDERS04, INVOIC02, etc) and template maps you can copy and use. While this sounds trivial, you'll find it a major time-saver in the long run.

Difference Between BADI and User Exits

Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. They can be inserted into the SAP System to accommodate user requirements too specific to be included in the standard delivery. Since specific industries often require special functions, SAP allows you to predefine these points in your software. 

As with customer exits two different views are available:

In the definition view, an application programmer predefines exit points in a source that allow specific industry sectors, partners, and customers to attach additional software to standard SAP source code without having to modify the original object. 

In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard logic if one is available.

In contrast to customer exits, Business Add-Ins no longer assume a two-level infrastructure (SAP and customer solutions), but instead allow for a multi-level system landscape (SAP, partner, and customer solutions, as well as country versions, industry solutions, and the like). Definitions and implementations of Business Add-Ins can be created at each level within such a system infrastructure.

SAP guarantees the upward compatibility of all Business Add-In interfaces. Release upgrades do not affect enhancement calls from within the standard software nor do they affect the validity of call interfaces. You do not have to register Business Add-Ins in SSCR.

The Business Add-In enhancement technique differentiates between enhancements that can only be implemented once and enhancements that can be used actively by any number of customers at the same time. In addition, Business Add-Ins can be defined according to filter values. This allows you to control add-in implementation and make it dependent on specific criteria (on a specific Country value, for example).

All ABAP sources, screens, GUIs, and table interfaces created using this enhancement technique are defined in a manner that allows customers to include their own enhancements in the standard. A single Business Add-In contains all of the interfaces necessary to implement a specific task.

The actual program code is enhanced using ABAP Objects. In order to better understand the programming techniques behind the Business Add-In enhancement concept, SAP recommends reading the section on ABAP Objects.

What is difference between badi and user-exists? What is difference between enhancements and user-exists? and what is the full form of BADI?

I have another doubt in BDC IN BDC WE HAVE MSEGCALL (i did not remember the > correct name) where the error logs are stored, MSEGCALL is a table or structure.

What is the system landscape?

1) Difference between BADI and USER-EXIT.     i) BADI's can be used any number of times, where as USER-EXITS can be used only one time.        Ex:- if your assigning a USER-EXIT to a project in (CMOD), then you can not assign the same to other project.     ii) BADI's are oops based.

2) About 'BDCMSGCOLL' it is a structure.  Used for finding error records. 3) Full form of BADI 'Business addins'. 3) System land scape will be depends on your project      Ex:- 'Development server'-->'Quality server'---> 'Production server'......