IDOC

Hello SAPpers,

i would like to know where and when interferes IDOC in the SD Business Flow, Was is therefore the link with ALE. I am new in the subject. Could anyone send me step by step the way we use it in SD and how?

Thanks it will be rewarded with good points

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 (3)

Hi,

IDOC or Intermediate Document:

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

• Technical level

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

o Control record

o Data record

o Status record

• Business level

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

o Segments

o Attributes of these segments

(e.g. maximum usage, hierarchical sequence, segment status)

IDocs allow different application systems to be linked via a message-based interface.

There are three main aims behind the use of IDocs:

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

• The various degrees of structural complexity as displayed by different application systems can be reduced to a structure which is as simple as possible.

Example: the structure of an SAP application document and the structure of the corresponding EDI message under the UN/EDIFACT standard.

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

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 types 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 destinations.

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 components 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:

1.Setup RFC destinations SM59

2.Port Destinations WE21

3.Partner Profile WE20

4.Message control NACE

5.Purchase Order ME21

6.Check IDocs WE02,WE05

IDoc Interface:

Standard SAP format for electronic data interchange between systems (Intermediate Document).

Different message types (for example, delivery confirmations or purchase orders) normally represent the different specific formats, known as IDoc types. Multiple message types with related content can be assigned to one IDoc type

Example:

The IDoc type ORDERS01 transfers the logical message types ORDERS (purchase order) and ORDRSP (order confirmation).

Among other areas, IDocs are used in both Electronic Data Interchange (EDI) and for data distribution in a system group (ALE).

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.

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

Comment

Hello,

you just go through transaction NACE. and study under V1,V2 etc application.

Chk the procedures,o/p types.

you will get the points where SD interacts with EDI/ALE.

go through TA:WEDI ,SALE

go through this link too :

@reward pts ,if helpful.[

Regards,

Nisha

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

Comment

Hi Ngassom,

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.

SAP IDoc Configuration

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

http://www.allsaplinks.com/idoc_sample.html

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

http://www.allsaplinks.com/idoc_sample.html

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

For more info Follow the Above Link..

Reward If Helpful..

Regards...