What is EDI EDI stands for “Electronic Data Interchange.” The practice involves using computer technology to exchange information – or data – electronically between two organizations, called “Trading Partners.” Technically, EDI is a set of standards that define common formats for the information so it can be exchanged in this way.

Processes that used to be completed manually with paper have been replaced with an invisible, electronic flow of formatted data.  EDI has replaced paper forms of many documents, including invoices, bills of lading, advance shipping notifications, student transcripts, healthcare claims and many others.

Many businesses, government agencies and other organizations use EDI every day in the regular course of business. That’s because EDI makes doing business together a more automated and efficient process. Plus, digital technology can help ensure greater information security compared to paper documents.

How EDI Works – the Process

For the most part, EDI-based transactions are really the same as their manual, paper counterparts. The difference is that the EDI transactions are sent and received electronically, as packets of data formatted according to EDI standards.

There are effectively three major processes involved in the exchange of EDI data: mapping, translation and communications.

Mapping involves transforming an EDI document into another format (such as XML, a flat file, a delimited file, etc.) or vice versa. Mapping is essential for proper system integration.

Translation is the process of accepting inbound EDI data, or preparing an outbound file for transmission.

Communications refers to the transmission of the EDI transaction. This can be done indirectly, through an external clearinghouse or VAN (“Value Added Network”) or direct via AS2 using EDI software, a web-based EDI tool or outsourcing with an EDI service provider.

Why You Need EDI – the Benefits

For many companies, EDI is really not a choice. It may be a requirement of doing business with larger organizations, including big retailers, manufacturers and government agencies.

Once you are communicating via EDI, the door is open to maximizing its value to your business. By integrating your EDI workflow with your back-end business or accounting system, you can streamline the entire process of how information flows through your organization. The benefits can be tremendous, including:

Lower costs – By reducing the manual keying of data, handling of documents and other processes, you can potentially reduce the costs of labor and paper, and reduce errors (and their associated costs).

Higher efficiency – Sending and receiving EDI data happens in seconds, and the information can be acted on immediately. This means time savings for you and your trading partners.

Improved accuracy – You can reduce errors by using EDI because manual and duplicate entry is eliminated. Everything flows untouched, leaving a trail for easy future tracking.

More supply chain visibility – With EDI, product sales data, product inventory status, demand forecasts and other metrics can be shared with suppliers and their suppliers. This allows for better inventory management and supports just-in-time delivery.

Enhanced security – Thanks to numerous communications protocols addressing encryption and other security issues, critical business or personal data may be exchanged with higher levels of security via EDI than by any other means.

Greater management information – Because EDI data is electronic data, you have a source of information to guide management decisions or to mine for further analysis.

Ready to take advantage of the many benefits of EDI? Contact the experts at 1EDISource to discuss the best approach for your organization.

Want to learn more? Read about EDI Standards, EDI Translation and EDI Data Mapping. Or, download EDI 101, our industry-leading EDI resource booklet. It provides a complete overview of EDI…and it’s FREE.

EDI Partner Profile Configuration A partner profile is defined for every business partner with whom you exchange business documents. In EDI, a partner can be a customer, a vendor, a bank, or any entity with which your company does business.

In ALE, a partner is a remote SAP system or legacy system with which you exchange data. A partner profile specifies the various characteristics of data that you exchange with a business partner, the mode of operation, and an organization or person responsible for handling errors for that business partner.

Its transaction code is WE20 and its Path is : From the Area menu of EDI, choose IDoc, Partner Profile.

A partner profile has three views, which maintain different parameters for a partner.

1.The General Parameters view. Values are stored in table EDPP1.

2·The Outbound Parameters view. Values are stored in table EDP13, except for the Message control parameters, which are stored in table EDP12.

3·The Inbound Parameters view. Values are stored in table EDP21.

The General View

The main Partner Profiles screen, shown in figure below, displays the general parameters view at the top of the right frame. The outbound and inbound views are also accessed from this screen; they appear below the general view fields.

The General Parameters view contains very basic information about the partner, such as partner number, partner type, partner status, and default individual to notify in case an error occurs.

These partner attributes appear at the top of the main Partner Profiles screen and under the Post Processing: Permitted Agent and Classification tabs. The entries under the Telephony tab are generally not relevant to EDI or ALE. You enter this information only once for each partner, and these values are stored in table EDPP1.

We define the attributes in the general parameters view like

1.Partn. number: In EDI, the partner number can be a customer number, vendor number, or bank ID. In ALE, it is the logical name assigned to the partner SAP system or legacy system. The standard system validates the partner number against the customer master, vendor master, or bank master data, depending on the type of business partner.

2·Partn. type: The partner type represents the type of your business partner. For example, in EDI it is customer (KU), vendor (LI), and bank (B). In ALE, it is the logical system (LS).(72.4)

EDI Partner Profile Configuration part two This is in continuation with EDI Partner profile configuration part one. In the Post Processing: Permitted Agent tab, you define the individuals to be notified when an error occurs in IDoc processing at a point where the system has identified the partner, but not the message type. The fields on this part of the general parameters view are

Typ: This field identifies the workflow object type of the Agent to be notified in case of error (for example, US for user ID, S for position, or O for organization).

Agent: This field indicates the workflow object (for example, user, position, or organizational unit) used for notification. This object is notified when a corresponding outbound or inbound record is not found for a message that is being sent to or received from this business partner.

"Configuring Workflow," for details on how the system sends workflow notifications for errors. For example, if a person with position ID 12345678 is responsible for handling errors for this business partner, the value of the various fields are S for Typ, 12345678 for Agent, and E for Lang.

Lang : This field identifies the language in use for this agent.

Avoid using a user ID in the Agent field. You should use more abstract object types, such as position, job, or organizational unit. This approach saves you the headache of changing the entry when the user leaves the company or changes jobs. Compared to users, objects such as positions, jobs, and organizational units tend to be more stable.

On the Classification tab, we define the following:

Partner Class : This field is for documentation only and has no intelligence behind it. You use this field to classify your partners. For example, if you want to classify automotive vendors versus railroad vendors, you can enter particular codes representing automotive or railroad.

Archv: This field is also for documentation purposes only. It indicates whether a partner agreement exists. Partner agreement is an EDI term for legal documents that define each partner's responsibilities in a business relationship.

Partner Status: This field makes a partner active or inactive. If a partner is deactivated, no documents are passed to it.

If you maintain partner profiles in the production system, you can use the Partner Status field to indicate that a partner profile is under construction. After the partner profile is complete, you activate it to mark it ready for use.(72.8)

Difference Between EDI and IDOC EDI is nothing but Electronic data interchange. SAP will support EDI through Intermediate documents (IDOCS).

EDI (Electronic Document interchange) - EDI is the electronic exchange of business documents between the computer systems of business partners, using a standard format over a communication network. 

EDI is also called paperless exchange. 

Advantages:  Reduced Data entry errors Reduced processing time Availabilty of data in electonic form Reduced paperwork Reduced Cost Reduced inventories and better planning Standard means of communications Better business process

EDI has two process 1. Outbound process 2. Inbound process

OP: 1.Application document is created.

2.IDOC is generated 3.IDoc is transferred from SAP to Operating system layer 4.Idoc is converted into EDI standards 5.Edi document is transmitted to the business partner 6.The Edi Subsystem report status to SAP

IP: 1.EDI transmission received 2.EDI document is converted into an IDOC 3.IDOC is transferred to the SAP layer 4.The application document is created 5.The application document can be viewed.  

IDOC: IDOC is a container that can be used to exchange data between any two process. Each iDoc is assigned a unique number for tracking and future reference. iDoc Consist of several segments,and segments contain several fields. iDoc contains the following three type of records... 1.One Control Record. 2.One or many Data Record 3.One or many Status record.

PORT: Port is used in the outbound process to determine the name of the EDI subsystem program,the directory path where the idoc file will be created at the operating system level,the idoc file names and the rfc desinations.

RFC Destination: Used to define the characteristics of communication links to a remote system on which a functions needs to be executed.

Partner Profile: Partner profile specified the various componets used in an outbound process ( Partner number,IDoc type,message type,Port,Process code),the mode in which it communicates with the subsystem(batch or immediate) and the person to be notified in case of errors.

Message Control Used in pricing,account determination,material determination,and output determination.The message control component enables you to encapsulate business rules with out having to write abap programs.

Process: Setup RFC destinations SM59 Port Destinations WE21 Partner Profile WE20 Message control NACE Purchase Order ME21

Check IDOCs WE02,WE05

Explain to me about Idoc?

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. 

IDocs are used for asynchronous transactions:  Each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. 

Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.  A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another. 

IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands. 

An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. 

The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.       *-- Ashok 

ALE, EDI & IDOCS in SAPALE, EDI & IDOCS in SAP

We will discuss a practical scenario here (specifically master data distribution using ALE ) . Here is what we will discuss in this article. If you want a more detailed explanation, please take our professional training course on SAP ALE, EDI & IDOCS

1. What is ALE ?2. What is EDI ?3. Difference between ALE & ED

4. Customization involved in Master Data distribution using ALE.

Related Trainings

SAP Training

SAP Access

SAP EDI Training

What is ALE ?

ALE stands for Application Link Enabling. Application Link Enabling is a very common technology used in SAP to transfer master and transactional data between different Logical Systems. ALE is a proprietary SAP technology.

What is EDI ?

EDI stands for Electronic Data Interchange. EDI is a much older term and has been used in existence much before SAP. EDI is a generic technology that has been standardized using ANSI and EDIFACT standards. EDI is a very standard Industry standard used for business communication across partners.

What is IDOC ?

IDOC stands for Intermediary DOCument. IDOC is an SAP proprietary format for storing business data that needs to be communicated across systems. When we mean systems, this could be between multiple systems ( Both SAP as well as non-SAP systems).

What is the Difference between EDI & ALE ?

ALE is used for distributing large volumes of similar data between different Logical systems. For example, distributing customer master data between two SAP systems is easily done using ALE. Similarly, when invoices from the core SAP system needs to be transferred to a different non-SAP invoice processing system, ALE is used.

EDI is also used to communicate data between different logical systems. For ex., sending out invoices, or order acknowledgements to customers is a perfect example to use EDI. Similarly, we could use EDI to receive inbound orders from customers.

There is a general confusion that ALE is a technology to be used between different SAP systems and EDI is the technology to be used between SAP and non-SAP systems. While this is true statistically, in principle the difference is much more subtle.

EDI is used to communicate with Partner Systems, while ALE is used to communicate between Logical Systems. Please do however observe that a Partner System could also be a logical system.

Customization

Customization of ALE & EDI is pretty similar technically. Let’s concentrate on ALE first.

[SALE] -> This is the transaction code used for ALE configuration

[WEDI] -> This is the transaction code used for ALE Development.

We will be doing all the customization in an ECC 6.0 IDES system. So, please get access to one before following along.

Logical System :

In SAP, a logical system means a client in an SAP instance. A logical system is just a label that needs to be assigned to a client in SAP. Goto [SALE]->Basic Setting->Logical Systems. Here is where you define logical systems and assign them to a client.

A shortcut to view the list of clients is [SCC4].

Let’s pick client 800 (double click ) and as you can see, the name of the logical system is T90CLNT090. You can change it if you want to.

Similarly, there is another client 810. Now, lets try to establish master data communication between client 800 and client 810. (ie) between the two logical systems.

If a new logical system needs to be defined, it can be defined here. Each logical system needs to be assigned to a client.

Configuration to be done on SENDER system

RFC Connection

RFC stands for Remote Function Call.SAP mandates that the name of the RFC destination should be the same as the logical system. An RFC connection provides a level of abstraction over the actual connection details between 2 different systems. In this case the communication should happen between client 800 and client 810 on the same SAP instance. We are now trying to create an RFC connection for client 810 on 800. This would require connection details ( IP Address ), client number and authentication details ( user id and password ). What we are essentially doing is establishing a conduit to another system.

In this example, we are trying to establish an RFC connection between two clients on the same SAP instance. However, this procedure is same even if it is across different SAP instances.

As you can see, there are different types of RFC connection. Without confusion ourselves further, lets just say, ABAP connections are used when the source and destination systems are SAP. TCP/IP connections are used when communicating with a non-SAP system.

Let’s try to create the RFC connection with the same name as the RFC destination – CUSTDEM810. ( In a standard SAP IDES system, this name could be different )

The system automatically picks up the IP address if the host is on the same subnet.

Enter the user id and password to test the RFC connection.

Cross Company Code

When transferring master data that has company code relevant data ( For example, the Finance view of the customer master data ), SAP mandates that we maintain a cross-company code. This is more of an SAP hack and might be taken away in the future.

Define a new cross-system company code say “GL2300″ -

And follow further configuration to assign the company code to Chart of Accounts and actual company code.It is pretty self-explanatory.

All of these functions can be handled in the menu path shown above. As discussed, these are just labels and do not have any controls.

Here is assigning cross-system company code GL2300 to company code 2300 and to INT chart of Accounts.

Distribution Model

A Distribution Model defines the following

Sender Logical System Receiver Logical System Message Type ( logical Message type , Not the IDOC type )

Goto [BD64], select the pencil button and click on “Create Model View”. Enter a technical name and a short text.

After generating the distribution model, goto Environment -> Generate Partner Profiles. Enter the name of the target logical system.

The log of the partner profiles will be generated. Sometimes SAP does not do this automatically and we might have to create the partner profiles manually.

If you go to [WE20] you can see that SAP has generated partner profiles for us automatically based on the previous step. (Select Partner Type LS ).

Pushing a Customer Through

Now lets push a customer through. Goto [BD12] (Tools -> ALE -> Master Data Distribution -> Cross Application -> Customer )

Enter a customer number, the output type ( DEBMAS in this case ). If you execute the system now, a master IDOC will be created and as many number of communication IDOCS will be created as there are distribution models set for the output type. If you select the right logical destination, only 1 communication IDOC will be generated.

If you want to see the IDOC that has been processed, goto [WE02] and select the IDOCS created for today and sort by date to get the latest IDOC. As we can see from the green square, the IDOC has been processed successfully. If in case the IDOC has failed, use [BD87] to re-process the IDOC.

Now, in order to check the IDOC on the other logical system ( Client 810 in this case ) , log onto the client 810 and use [WE02] to look at the IDOCS in bound.