Skip to Content
author's profile photo Former Member
Former Member

let me know

hi what is the difference between master idoc and communication idoc

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Mar 31, 2008 at 03:28 AM

    The Master Idoc contains only the information regarding to the data which we are sending to the partnet system or the reciever, like the PO data or the Sales Order Data.

    But the Communication Idoc also contains the aboive details along with the Parnter system name and the port name and the status record of the paricular idoc.

    The no.of cmmunications Idocs for a given master idoc depends on the no.of receivers to which the idoc should be sent.

    For example for the same Master idoc if 2 recievrs exsits then two cmmunication idocs would be generated.

    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.

    Form and content: IDoc terminology

    As 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 record

    Each 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

    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 records

    The 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 records

    If 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 are used to record these errors and the date/time of their occurrence.

    IDoc Base

    IDocs, 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 messages

    One 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 Records in a multiple-message IDoc

    Reward points..

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Mar 31, 2008 at 03:33 AM

    HI,

    Refer this thread

    [difference b/w Master & Communication IDocs;

    Regards

    Sandipan

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Mar 31, 2008 at 08:59 PM

    I Don't Confuse you.Just rad these points. Award points if useful

    The outbound ALE process in SAP

    1.Identify the need for sending an IDo-c. This step can occur immediately upon creating an application document, can relate to a change to a master data object, can be user initiated, or can simply be a point in a process that necessitates the exchange of data. The outbound ALE process for the IDoc data is started. For example, when a material master is created, it consults the ALE layer to determine whether any system is interested in the data. If so, the ALE layer starts the process to send material master data to the interested party.

    2.Generate the master IDoc. The document or master data to be sent is read from the database and formatted into an IDoc format. This IDoc is called a master IDoc. At this point, think of IDoc as yet another format in which a document can be represented. You know how a date can be stored in different formats, so imagine the date as a document with three components: day, month, and year. You can represent the date as MM/DD/YYYY, the standard American way. To make the information meaningful to a German business partner, though, you have to represent the date as DD.MM.YY. IDocs are based on a similar concept of representing one set of data in various ways. The data in the application document format is suitable for application modules, screens, and internal programs. The same data in an IDoc format is suitable for exchange with external systems.

    3.Generate the communication IDoc. The ALE service layer generates a separate IDoc from the master IDoc for each recipient who is interested in the data. Separate IDocs are generated because each recipient might demand a different version or a subset of the master IDoc. These recipient-specific IDocs are called communication IDocs and are stored in the database. The recipients are determined from a customer distribution model that maintains a list of messages exchanged between two systems and their direction of flow.

    Note :Communication IDocs are stored in the database, but the master IDoc is not. The master IDoc is kept in memory buffers until communication IDocs are generated.

    4.Deliver the communication IDoc. This step delivers IDocs to the appropriate recipients using an asynchronous communication method. This allows the sending system to continue its processing without having to wait for the destination system to receive or process the IDoc.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.