about ALE,Idoc, EDI

sir,

what is the purpose of ALE,Idoc and EDI, what is the difference and how they will useful for sap

suggest me

SAP Managed Tags:
SD (Sales and Distribution)

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (9)

Hi Supraja,

Please find below the Complete notes on ALE, EDI and IDOCs

ALE & IDOC’s and EDI

IDOCS:

IDOCS are intermediary documents which are like CARRIERS of the data.

IDOCs are safe to transfer data, but less volume of data. User is not allowed to access (modify) the data like PSA. IDOCs have 3 parts.

1. Control Record - SOURCE & TARGET details,

2. Data Record - Here comes your query....

Info IDOC - It contains all the technical details related to the data load i.e. Request NO, No of Data Packages, USER, DATE, TIME, LOGICAL SYSTEM, etc. Info IDOC is also ONE segment, the 1 sr segment.

Here data will not be there.

Data IDOC - These are the ones which hold the data. The total no of records are made into Data IDOCs i.e. if 99 records are there then 99 Data IDOCs will be there and all these will be divided into 99 segments.

Hence the total number of Segments in IDOC is 100.

Info IDOC + Data IDOCs = Total no of Segments

1 + 99 = 100.

3. Status Record - Here the status of the data transfer will be available.

ALE:

ALE is Application linking & enabling which enables to interface SAP with other modules.

ALE is used for communicating between sap systems to sap system.

Pl go through below links as they provide all the required info on ALE & IDOC's:

ALE / IDOC:

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 where by 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.

Please check this online document for ALE and IDoc.

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEIO/BCMIDALEIO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEPRO/BCMIDALEPRO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFAALEQS/CABFAALEQS.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDISC/CAEDISCAP_STC.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDI/CAEDI.pdf

Also check this links for additional information.

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

u will have enough material from above .....

Mostly SD consultant doesn’t deal with EDI, Idocs but it’s always good to have knowledge,

EDI

EDI is used to communicate between non sap system to sap system vice versa.

EDI concept in SD: the EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronical documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.

If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every time send a change to the existing order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).

So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, and INVOIC.

That's all concerning the SD-EDI.

Additional processes in SD, where EDI are used:

1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS

2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD

3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT

4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.

It is all processes which are realized in the SD module via EDI.

Go through this, You will get better idea on EDI,ALE,IDOCS

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.

IDOC Creation - Manual:

If a batch job is not running. First thing is go into to code of the batch job and find out what type of IDOC's it is processing.

Let's assume, it is creating / processing DELINS type IDOC's, then follow the below steps:

Go to T-code WE02, input DELINS in the logical message, give date range of say 10 days or so and Direction = 2 and execute it. You will get a list of IDOC's

Then select any one of those IDOC"s in status 53 and go to T-code WE19 and input the same and execute.

Later in the same T-code you can change the sender and receiver parameters including the plant.

In the header level you need to change the delivery schedule number and release number. Put the same PO number as in the scheduling agreement. Enter values of sold to, ship to, partner description and customer material along with the desired quantity.

Then on the application tool bar you will find "Standard Inbound", click on this and check for the green light against the partner profile and click OK / Enter.

You will be processing the IDOC manually. Then once you get the IDOC number, input the new number in WE02 and execute to check the status. If it is not 53 status, then go to T-code BD87 and input that number and execute. Inside select the last line of status and click on "Process" icon to finally get the IDOC in Status 53 "Successfully Processed"

This is the standard process followed for processing IDOC's manually.

IDOC'S CONFIGURATION FOR SD

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.

https://secure.topxml.com/biztalkutilities/walkthroughs/SAP%20IDoc%20Configuration.pdf

IDOC Creation: -

You can Create IDoc in this process: and transfer master data from one system to another.

You can transfer Master data in Bulk through SMD (Share master data tool) Tool.

The main SMD tools in SAP are BD10 for Material Master

BD12- customer

BD14- Vendor

suppose u want to transfer material in bulk.

U have configure the systems:

TA: SALE for ale customization -

create logical system here.

Steps:

1) Create port(WE21) and logical system and RFC destination(SM59)

1) Create Distribution Model in BD64.

2) Create Partner Profile (WE20) in both systems and distribute the model and in receiver system the model will be created itself after distribution.

3) Go to TA: BD10 (SMD for material)

4) message type will be MATMASand specify the logical system and press execute.

it will generate the master IDoc and communication IDoc in sender system

now u can check the receiver system the Inbound IDOC must be there with all the materials

TA for IDOC CHK :WE02,WE05.

Go through This link too: PDF Index.IDoc

Gapping/mapping - This process is done when your client wants to send some application document (can be sales order confirmation, Purchase order, Invoice) to it's customer (or vendor). For discussion purpose, lets say your client needs to send billing document to a customer. So one way is print it on invoice format and send it via mail or Faxing the printout or emailing it. Or finally sending it via EDI.

EDI is the data exchange medium, which is going to send the data relevant for billing to the customer. Standard 810 EDI is used for invoice transaction. SAP billing document creates an IDOC which is triggered from a message type (output type at billing header level).

An IDOC contains Data records, which contain billing document data. Now not all the data on this IDOC is required to be sent to customer, only certain fields are enough to tell the customer about the bill - fields like Payer #, payment terms, Customers PO #, SO#, delivery #, line #, Material #, Net value # and overall billing document value. But on IDOC we have much more data available then this.

Now on EDI mapping we will sit with an EDI contact, and map what fields on IDOC means and where it can be put on EDI segments. Like

idoc field name EDI Field name

Purchase order # E1EDK02-BELNR BIG04

Invoice # E1EDK02-BELNR BIG02

Payer E1EDKA1-PARTN N104

Payment terms E1EDK18-PRZNT ITD01

Material E1EDP19-MATNR IT101

Like this you will have to map all the fields on a excel spreadsheet so EDI can have logic in their subsystem to send the invoice to customer successfully.

Sample of mapping document - http://www.erpgenie.com/sapgenie/docs/template_o810v4010_partner.xls

map in IDOC depends on the IDOC message type.

ORDERS - creation of a sales order

ORDCHG - change of an existing sales order

ORDRSP - confirmation/replication of the sales order

DELINS - creation of a delivery schedule in scheduling agreement

DELORD - creation of a delivery order to the scheduling agreement

EDLNOT - creation of an external agent delivery to the scheduling agreement

GSVERF - creation of a credit advice

SBINV - creation of the invoice

SBWAP - creation of debit/credit memo(requests)

INVOIC - sending the invoice

In the transaction WE60 you can see the fields to every basic IDOC type. Not all fields which could be mapped via IDOC will be transferred automatically (only some ones). All other fields can be mapped to the application with the help of numerous user-exits provided.

The most important transactions:

BD87 - to apply the incoming IDOC

WE19 - to copy / to edit the IDOC and apply this copy

WE02 - to display the IDOC

WE05 - to select IDOCs

WE60 - to see the declared IDOC fields

And here is a general information about IDOC concept in SD:

The EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronically documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.

So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, and INVOICE.

That's all concerning the SD-EDI.

Additional processes in SD, where EDI are used:

1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS

2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD

3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT

4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.

It is all processes which are realized in the SD module via EDI.

There is not so much Customizing for EDI. The most entries are required by EDI for the scheduling agreement processing (DELINS, EDLNOT, and SBINV). The Customizing of these processes is located in the Customizing of scheduling agreements: SPRO => Sales and Distribution => Sales => Sales Documents => Scheduling agreements with delivery schedules => Control EDI Inbound processing.

General EDI Customizing in SD is available under: SPRO => Sales and Distribution => Electronic Data Interchange => EDI messages =>...

Please Reward If Really Helpful,

Thanks and Regards,

Sateesh.Kandula

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

HI,

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.

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.

ALE provides intelligent mechanisms where by 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.

You determine the PSA or IDoc transfer method in the transfer rule maintenance screen. The process for loading the data for both transfer methods is triggered by a request IDoc to the source system. Info IDocs are used in both transfer methods. Info IDocs are transferred exclusively using ALE

A data IDoc consists of a control record, a data record, and a status record The control record contains, for example, administrative information such as the receiver, the sender, and the client. The status record describes the status of the IDoc, for example, "Processed". If you use the PSA for data extraction, you benefit from increased flexiblity (treatment of incorrect data records). Since you are storing the data temporarily in the PSA before updating it in to the data targets, you can check the data and change it if necessary. Unlike a data request with IDocs, the PSA gives you various options for additional data updates into data targets:

InfoObject/Data Target Only - This option means that the PSA is not used as a temporary store. You choose this update type if you do not want to check the source system data for consistency and accuracy, or you have already checked this yourself and are sure that you no longer require this data since you are not going to change the structure of the data target again.

PSA and InfoObject/Data Target in Parallel (Package by Package) - BW receives the data from the source system, writes the data to the PSA and at the same time starts the update into the relevant data targets. Therefore, this method has the best performance.

The parallel update is described in detail in the following: A dialog process is started by data package, in which the data of this package is writtein into the PSA table. If the data is posted successfully into the PSA table, the system releases a second, parallel dialog process that writes the data to the data targets. In this dialog process the transfer rules for the data records of the data package are applied, that data is transferred to the communcation structure, and then written to the data targets. The first dialog process (data posting into the PSA) confirms in the source system that is it completed and the source system sends a new data package to BW while the second dialog process is still updating the data into the data targets.

The parallelism relates to the data packages, that is, the system writes the data packages into the PSA table and into the data targets in parallel. Caution: The maximum number of processes setin the source system in customizing for the extractors does not restrict the number of processes in BW. Therefore, BW can require many dialog processes for the load process. Ensure that there are enough dialog processes available in the BW system. If there are not enough processes on the system side, errors occur. Therefore, this method is the least recommended.

PSA and then into InfoObject/Data Targets (Package by Package) - Updates data in series into the PSA table and into the data targets by data package. The system starts one process that writes the data packages into the PSA table. Once the data is posted successfuly into the PSA table, it is then written to the data targets in the same dialog process. Updating in series gives you more control over the overall data flow when compared to parallel data transfer since there is only one process per data package in BW. In the BW system the maximum number of dialog process required for each data request corresponds to the setting that you made in customizing for the extractors in the control parameter maintenance screen. In contrast to the parallel update, the system confirms that the process is completed only after the data has been updated into the PSA and also into the data targets for the first data package.

Only PSA - The data is not posted further from the PSA table immediately. It is useful to transfer the data only into the PSA table if you want to check its accuracy and consistency and, if necessary, modify the data. You then have the following options for updating data from the PSA table:

Automatic update - In order to update the data automatically in the relevant data target after all data packages are in the PSA table and updated successfully there, in the scheduler when you schedule the InfoPackage, choose Update Subsequently in Data Targets on the Processing tab page

Reward if helps

manoj

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi supraja,

ALE Integration Technology

Purpose

The integration technology Application Link Enabling (ALE) is an important middleware tool in SAP's Business Framework Architecture (BFA). BFA is a component-based architecture enabling software components from SAP and from other software vendors to communicate and be integrated with each other.

ALE can integrate business processes between R/3 Systems and non-R/3 systems as well as between R/3 Systems.

Data is exchanged between applications and remains consistent in all applications.

Company-wide applications such as accounting, human resource management and sales planning may be carried out in the company’s headquarters, whereas production and materials management may be carried out in decentralized plants.

Application systems are loosely coupled in an ALE integrated system. Data is exchanged asynchronously, whereby the data arrives in the receiver system, even if the receiver system cannot be connected to at the time the data is sent. ALE uses synchronous communication for reading data only.

ALE provides administration, development and testing tools.

To use the ALE tools choose Tools  ALE.

ALE business processes are part of the standard R/3 delivery. They are documented in the Library of ALE Business Processes.

For more information about the required system settings see the R/3 Implementation Guide.

Tools  AcceleratedSAP  Customizing  Project Management

SAP Reference IMG

Basis  Application Link Enabling (ALE).

For information on programming see the ALE Programming Guide.

To make it easier to assign ALE functions to specific user types, the following user roles have been defined:

• ALE Administration SAP_BC_MID_ALE_ADMIN

• ALE Development SAP_BC_MID_ALE_DEVELOPER

• Logistics - Master Data Distribution SAP_BC_MID_ALE_MD_LO

• Accounting - Master Data Distribution SAP_BC_MID_ALE_MD_FI

• Human Resources - Master Data Distribution SAP_BC_MID_ALE_MD_HR

Idoc, EDI

The SAPforms interface allows you to fill an IDoc (Intermediate Document) using an electronic form. The EDI-IDoc interface in R/3 is used for this purpose.

The IDoc interface supports electronic data communication between various computers and/or systems. In our case, communication takes place between the SAPforms interface (via an electronic form) and an R/3 System.

The use of IDocs is demonstrated here using a BAPI call as an example ( Example: Create customer master record via IDoc). This is just one way to use this function. Naturally, the entire functionality of the IDoc interface can be leveraged with electronic forms. Reference will be made to the corresponding online documentation where necessary.

IDocs are complex hierarchical data structures.

One IDoc type (structure) consists of several segment types (naming convention: E1 ... or Z1 ...), that are arranged in a hierarchy. Each segment type, in turn, consists of segment attributes or fields that play a central role when the binding is defined at a later stage.

IDoc instances are instantiations of an IDoc type. They can be compared to text files that contain rows of concrete information. At the "meta level", these instances are divided into a control record ( EDI_DC40 ), data record ( EDI_DD40 ), and a status record ( EDI_DS40 ). The control record contains administrative information, such as the recipient, sender, client, port, or message type. The status records describe the current status of the IDoc (for example "processed"). The data records contain the actual useful data. This useful data is structured by the segment types.

This technology is used in the following scenario to call a BAPI in the R/3 System using an IDoc. This will be carried out using the ALE-IDoc interface, which enables IDoc types to be generated on the basis of BAPIs. Using an appropriate partner profile and port definition, the BAPI can be called from an incoming IDoc.

Generating an ALE-IDoc Interface

BAPIs are used as a basis for generating an ALE-IDoc interface. This means that the BAPI’s transfer parameters are mapped to segments in the IDoc type. When an IDoc is received, the call parameters of the BAPI are filled with the contents of the corresponding segments. Return values issued by the BAPI are stored in the status records of the IDoc.

To send IDocs to the R/3 System, you must first configure the inbound processing function in R/3. All of the generated interfaces use the BAPI process code. This code refers to the BAPI_IDOC_INPUT1 function module. This function module calls the BAPI (as a standard interface) that is to be started by the electronic form.

Defining a Partner Profile

A partner profile is an entry in which the communication parameters are defined. The values entered in the profile are primarily information that is required in the IDoc control record. The recipient (in our case, an R/3 System) must have a corresponding inbound partner profile for these values so that an assignment can be made.