ALE - display the idoc

Hi all,
I am doing material data transfer from one system to another using ALE.
Once the transaction BD10 is executed, i need to display the idoc number as information message.
is it possible to get the idoc number and its entire status directly, instead of viewing it in we02 tcode.
(i.e) once if bd10 tcode is executed , i need to display the information such as idoc number and its details in the same screen .
Regards,
vinoth.

Here is the code which will give the exact Idoc.
To Populate the "CRETIM", Capture the Time in separate variable lets say V_TIME before calling the BD10 & use that Time as CRETIM > V_TIME.
     SELECT * FROM EDIDC INTO TABLE INT_EDIDC
        WHERE       UPDDAT = SY-DATLO
        AND         IDOCTP  IN IDOCTP "Basic IDoc type
        AND         MESTYP  IN MESTYP"Message Type
        AND         SNDPOR  IN ownPOR "Sender port
        AND         SNDPRT  IN ownPRT"Partner type of sender
        AND         SNDPRN  IN ownPRN"Partner Number of Sender
        AND         RCVPOR  IN ppPOR
        AND         RCVPRT  IN ppPRT
        AND         RCVPRN  IN ppPRN
        AND         CRETIM  IN CRETIM.
<b>Note: Reward all useful post.</b>
Raja T

Similar Messages

  • How can I display the IDOC message type descriptions

    I've been asked to provide a listing of all the IDOC message types and it's associated description.
    Does anyone know what table holds this information or a t-code that will allow me to create a file listing the message tpyes and descriptions?

    Hi Timothy,
    The correct table to get this information is from SAP table EDIMSGT. You can view/download the contents of this table via transaction SE16.
    Hope this helps and please don't forget to reward points.
    Cheers,
    Sougata.

  • A warning message in the Inbound part of the IDOC

    Hi all,
    A warning message is being displayed for the Inbound part of the IDOC.
    Here is the message.
    No filters , No conversion , No version change .
    IDoc successfully processed in the ALE layer
        The IDoc has passed through the ALE layer successfully and can now be
        passed to the application. This transfer is either done online or as a
        background job, depending on the settings in the partner profile.
        If there are no further status records, the IDoc waits for the next run
        of the transfer report to the application.
        Success or failure when passing the IDoc to the application is
        documented in the subsequent status records.
    Actions in the ALE layer
        The parameter 'No filters' indicates whether the processing in the ALE
        layer led to segments of the inbound IDoc being omitted. The important
        criteria here are the settings in the segment filter and in the
        distribution model for this sender.
        The parameter 'No conversion' indicates whether field values were
        converted in the ALE layer. This is the case if the IDoc contains
        organizational units to be converted, or if the ALE conversion tool for
        this sender is activated.
        The parameter 'No version change' indicates whether the IDoc was
        converted into an earlier version of the IDoc type. This happens if the
        IDoc type of the sender is different from its own IDoc type.
    I have checked all the necessary Config settings and all of them are in place.
    Your help on this will be highly appreciated.
    - Surya.

    Hi,
    The IDOC  may have successfully passed through the application, but check whether the status of the IDOC is changed to 53.
    No filters, No conversions, No version change
    occurs when the IDOC is not processed fully.
    It may have stopped the processing without raising any error...
    Check the program, whether there is any piece of code which stops the processing of the IDOC without changing its status to 51.
    Sharin.

  • How the idoc interfaces works..

    Hi...
    When we design a interfaces using Idocs... what is the actual process so that data get updated in SAP..
    I want to know the flow of the process...
    I have created Idoc structure in the system....but how the data will get into this...and from Idoc what makes the data to get updated into system....
    Just few lines will be helpfull..

    Hi,
    An IDoc is simply a data container that is used to exchange information between any two processes that can understand the syntax and semantics of the data...
    1.IDOCs are stored in the database. In the SAP system, IDOCs are stored in database tables.
    2.IDOCs are independent of the sending and receiving systems.
    3.IDOCs are independent of the direction of data exchange.
    The two available process for IDOCs are
    1) Outbound Process
    2) Inbound Process
    There are basically two types of IDOCs.
    1) Basic IDOCs: Basic IDOC type defines the structure and format of the business document that is to be exchanged between two systems.
    2) Extended IDOCs: Extending the functionality by adding more segments to existing Basic IDOCs.
    For creating a IDOC
    see the below steps for outbound processing IDOCS..
    1. Analyse Hierarchy Levels
    2. Create New segment
    3. Create New IDoc Type
    4. Create New Message Type
    5. Link Message with IDoc Type
    6. Create an entry in EDP13 via transactions WE20 and BD64
    7. Populate the Custom IDoc via ABAP Program
    7b Error Handling
    7c. Send Status Email
    8. Test the Population of the Custom IDoc
    Step 1 – Analyse Hierarchy Levels:
    Analyse the data relationships being processed in the interface. Define the appropriate hierarchical Parent-to-Child relationships.
    Navigate to transaction code WEDI
    Transaction WEDI displays the IDOC main menu. This allows navigation around the various development and control areas to create a customised IDOC.
    Step 2 – Create a new segment:
    via wedi : Development - IDOC Segments or Transaction code WE31.
    • Enter segment name and click on Create.
    name of the segment type must start with Z1 , and have a maximum&#61662;The of eight characters.
    • Enter description and enter the relevant field names and data elements.
    The segment should represent a structure in the program so each field in the segment a field name and a data element must be&#61662;for defined.
    • Save the segment and enter Person Responsible and Processing Person .
    • Go to Edit and Set Release.
    • Repeat this procedure for each new Segment in the IDOC.
    Step 3 – Create a new IDOC Type
    via wedi Development - IDOC Types or Transaction WE30.
    • Enter segment name (starting with Z), click on Basic Type and then Create.
    • Create as new, enter Person Responsible and Processing Person and enter description.
    • On ‘Create Basic Type’ screen decide where segments should be inserted and go to Edit/Create Segment.
    • Complete relevant fields in the Maintain Attributes screen:
    • From the relevant segments created in Step 2 enter the Segment type and if mandatory segment.
    • The Minimum and Maximum number of segments to be allowed in the sequence. (One minimum and one maximum if segment is mandatory).
    • The Parent Segment and Hierarchy Level will be automatically created depending on where in the IDOC tree you decided to create that particular segment.
    • Repeat this process for each segment needed in the IDOC type, deciding whether to add the next segments at the same level or as a ‘Child’.
    • When IDOC created return to initial screen. Go to Edit and Set Release.
    • Go to Transaction WE60 to view the IDoc Type you have created.
    Step 4 – Create new Message Type
    via wedi Development - Message Types or Transaction WE81.
    • Display/Change and click on New Entries
    • Create a new Message Type and Save.
    Step 5 – Link Message Type to IDOC Type
    via wedi Development - IDOC Type/Message or Transaction WE82.
    • Display/Change and then click on New Entries.
    • Enter Message Type, Basic Type (IDOC Type) and Release (46C) and Save.
    Step 6 – Create an entry in EDP13 via transactions WE20 and BD64.
    The partner profile for the Idoc must be set up and generated in the transaction BD64 and transaction WE20.
    • WE20 – Add Message Type to appropriate Partner Type, Enter Message Type, Receiver Port and Idoc Type and Save.
    • BD64 – Create a Model View, Enter Sender and Receiver Ports, Attach Message Type. Go to ‘Environment’ on Menu and click on Generate Partner Profiles and generate (not save) profile.
    Step 7 – Populate the custom IDOC via ABAP Program
    See Test Program ZOUTBD_IDOC_TEMPLATE, Appendix IV.
    • Create an Internal Table for each segment type, this should be exactly the same structure as the segment type.
    • The control record is filled into a structure like EDIDC. The message type and the Idoc type for the Idoc must be populated into the eddic structure.
    PERFORM populate_Control_structure USING c_mestyp
    c_SEGMENT_type1.
    • The data segments are filled into a structure like edidd-sdata; sdata and the segment name are populated into the edidd structure.
    PERFORM transfer_Parent_data_to_seg.
    • The standard SAP function module MASTER_IDOC_DISTRIBUTE is called to pass the populated IDOC to the ALE Layer.
    PERFORM master_idoc_distribute.
    • NOTE: This function module is only called for stand alone programs and Shared Master Data programs (SMD). It is not called when using extensions or output determination.
    • The ALE Layer handles the sending of the IDOC to the receiving system.
    • Error Handling (see Step 7b).
    • Commit work.
    Project SpecificStep 7b – Error Handling
    • Analyse which fields in the interface are mandatory for the receiving system and who needs to receive error notification.
    • Declare a structure of type ‘MCMAILOBJ’ for sending instructions.
    • Enter values for the internal table based on structure ‘MCMAILOBJ’
    • For selection processes, on SY-SUBRC checks and where fields are mandatory for the receiving system; insert Function Module ‘MC_SEND_MAIL’.
    • Enter values in the following parameters: -
    MS_MAIL_SENDMODE = ‘B’ (Batch Mode)
    MS_MAIL_TITLE = 'Mail Title'
    MS_MAIL_DESCRIPTION = ‘Error description’ (e.g. MATNR not given)
    MS_MAIL_RECEIVER = ‘Name of Receiver’ (To be determined)
    MS_MAIL_EXPRESS = ‘E’ (Express Delivery)
    MS_MAIL_DLINAME = Leave Blank
    MS_MAIL_LANGU = 'E' (Language)
    MS_MAIL_FUNKOBJ_NAME = Leave Blank
    TABLES
    MS_MAIL_CONT = I_MCMAILOBJ
    Note:
    It has to be determined separately for each interface how these errors and mail notifications are to be grouped – dependant upon the number of errors that are potentially likely. One possible approach is to send an email for each reason for rejection and include all the records that failed for that reason in the mail notification. Another possible approach is to send an email for every failure.
    When error checking for mandatory fields it is common SAP practice to reject a record on its first failure (irrespective of subsequent errors in that record)
    Step 7c – Send status mail
    • Append to table I_MCMAILOBJ details of the time the interface was processed, how many Idocs were created and how many of these produced a status of 03.
    • Select the user to receive the mail from ZINT_RECEIVER, using the name of the program as a key (SY-CPROG).
    • Use function Module ‘MC_SEND_MAIL’ to send a mail to the user containing the contents of I_MCMAILOBJ at the end of the interface processing.
    Step 8 – Test the population of the custom IDOC
    via wedi IDoc - Display IDoc or Transaction WE02.
    • Enter your message type and execute.
    • Status should be green, double click on one of the Idocs you have created to view its contents.
    • If a problem has occurred click on Status which will give you a description of the error.
    • Drop down Data Records arrow and this should list the data in the IDoc in the correct hierarchical structure.
    • Click on each individual segment and view the content to check that the correct data has been read.
    • If you have UNIX access by using AL11 you can view the file that you have created.
    Note:
    For some interfaces it may be valid to send an empty file to SAP. This empty file is converted to the custom IDOC format expected by SAP. This custom IDOC will contain dummy information. In the inbound processing code, if the dummy information is identified then the processing of the IDOC is considered to be complete and the IDOC should then be assigned a successfully processed status of 53, even though it has not been processed at all.
    hi,
    2.2 Inbound Interface
    Follow steps 1 to 5 inclusive as detailed above in outbound interface.
    Step 6
    Write a custom function module to handle custom inbound processing. This custom function module must
    • Check for the correct message type
    • Read the IDoc data segment
    • Perform data conversion and validate the data as appropriate
    • Post the data to the database
    • Handle any error situations
    • Set the correct return values for the status record
    Note that the Function Module must not make a commit to the database. This is because the status record is not written until control returns to the ALE layer. So if you commit work in the Function Module and an error occurs in returning to the ALE Layer, the status record must not be updated with a successful outcome.
    The commit work is executed in the ALE Layer after the status records are updated, via the standard SAP function module IDOC_INBOUND_PROCESS. This attributes of this function module are set up in (Transaction BD51), click on ‘New Entries’ and fill in data; the main input parameters being ‘Input Type’ and ‘Dialog Allowed’.
    Take care as some standard SAP transactions contain a Commit Work as part of their processing. Therefore using a BDC to process inbound data to SAP may not be acceptable. You need to check that the SAP transaction is ALE enabled.
    Step 7
    (Transaction WE57)
    Assign the custom function module to the IDoc type and the message type.
    Set function module to type ‘F’ and direction ‘2’ for inbound.
    Step 8
    (Transaction WE42)
    Create a new process code and assign it to the function module. The process code determines how the incoming IDoc is to be processed in SAP.
    Step 9
    (Transaction BD67)
    Assign the function module to the process code created above. Got to ‘New Entries’ and enter the process code and the function module name.
    Step 10
    (Transaction WE20 and Transaction BD64)
    Create a partner profile for your message and ensure that in transaction WE20 the process code is the one that points to your function module. (See step 6 of creating Outbound Idocs).
    Step 11
    Ensure that error handling functionality is present.
    Or Check these links.....
    ALE/ IDOC
    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
    http://www.sappoint.com/abap/ale.pdf
    http://www.sappoint.com/abap/ale2.pdf
    http://www.sapgenie.com/sapedi/idoc_abap.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm
    http://www.allsaplinks.com/idoc_sample.html
    http://www.sappoint.com/abap.html
    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
    http://www.allsaplinks.com/idoc_sample.html
    Reward points if useful....
    Regards
    AK

  • Display archived IDOCs in transaction WE10 - click on IDOC number

    Hi experts,
    If you run transaction WE10 and display IDOCs not archived (from the database), from the list of IDOCs you can click on the IDOC number and then go to the screen that displays the IDOC information (Control, Data and Status records).
    However, if you run WE10 with archived IDOCs (Data Source is archive), you get to see the list of IDOCs but when you click on the IDOC number it doesn't go to another screen showing you the IDOC information but it stays on the same screen.
    Is this expected behaviour? I have had a looked at the OSS and Internet Search and there is no reference to this behaviour.
    Many thanks for your help in advanced.

    Hi Jurgen,
    Thanks for moving my post to the correct space.
    Our Auth team is very confident that this is not a user auth issue. This could possibly be true because the idoc data resides on the following tables when in the database (before archive) - EDIDC, EDID4 & EDIDS. The idoc could then be viewed via transaction WE02 or the Data Browser (SE16). There is no EDIDD table in our ERP system so obviously no authorization object to assign to.
    Once the idoc is archived, the data is removed from the ERP tables and moved to our archive database/server for storage. So when trying to view the archived record, the system does not access the ERP tables but rather the archive directory (that it's mapped to in settings). I assume the SARA transaction merely displays the data in the same segments/grouping with these table names (mentioned above in my first post) but instead of EDID4 it displays EDIDD.
    According to the error longtext, "The check performed when data is read from the archive is the same as that of the Data Browser (transaction SE16)". So I was not involved with setting up our archiving procedure but could it be that table EDID4 was incorrectly mapped to table EDIDD in archives?
    Regards,
    Fawaaz

  • How to handle the Idoc which is locked

    Hi Experts,
       As per my requirement ,I am triggerring an inbound error Idoc incase when some updation fails for 'VA42' T.code and I have also developed the inbound functional module for reprocessing the error Idoc which has been triggered through my report program.
    Actually the problem I am getting now is
    - The user wants to see the error idoc number.Hence I am displaying the Idoc number in the report output ( i.e in list ) as well.
    - If I try to reprocess that Error idoc number using 'BD87'  It is not calling the inbound functional module.While debugging I came to know that it's raising the exception has ' Idoc && is currently locked '.
    But when I come out of the report output ,BD87 is calling the inbound FM.
    Pls give some suggestions ,So that I can reprocess the Error idoc ( status : 51 ) without coming out of the report output.
    Thanks in advance.
    - Srinivas.

    Hi ,
    if the data is locked the idoc will be in Pratially posted(status 52 ) or not posted ( status 51)..
    so run the Program RBDMANI2 for status 51 & 52..
    or
    go to t-code swo1-->IDOCSTATUS --> enter idoc number execute ..
                                                        first run method -->Processing of IDoc Containing Errors
                                                        next run method-->IDOC.StatusProcess
                                                        and chage the status from 51 or 52 to 53....
    See the SAP Note : - 898626
    http://help.sap.com/saphelp_nw04/helpdata/en/75/4b3c1cd14811d289810000e8216438/frameset.htm
    Regards,
    Prabhudas

  • Relation of ALE , EDI  and idoc

    HI
         what is relation of these ALE, EDI, IDOC , i know the definition of these , i want know ( while the transfer of sap to sap ALE tool is used ,) where this idoc is used ,
    regards
    shivaji

    Hi Shivaji,
    What is EDI…?
    Electronic Data Interchange
    •     The computer-to-computer electronic exchange of machine processable business documents in a standard format
    •     An electronic alternative to paper, fax, and phone-based transactions used by companies to communicate with one another
    Purpose:
    •     Allows for better time management and relieves the entering of duplicate information while cutting down on discrepancies and human intervention.
    •     The Electronic Data Interchange component in Sales and Distribution consists of an Intermediate Document (IDoc) [Ext.] interface. You can use this interface to
    –     send messages (outbound processing) such as an order confirmation through Electronic Data Interchange (EDI)
    –     receive messages (inbound processing) such as a sales order through EDI
    EDI:
    •     What…?
    –     The technology of transmitting documents electronically
    •     Why…?
    –     For Electronic Data Interchange between a company and trading partners
    •     How…?
    –     By means of an electronic document - the IDoc
    From the SAP side, the EDI interface is based on IDoc technology, which is independent of
    EDI standards. All data is transferred in files between the R/3 System and the EDI subsystem.
    Synchronous Remote Function Call (RFC) is implemented to define the time of transfer for a
    file between the two systems. The following data can be transferred using the EDI interface:
    Outbound Idocs: IDocs are transferred from the R/3 System to the EDI subsystem.
    Inbound Idocs: IDocs are transferred from the EDI subsystem to the R/3 System.
    Status report: The EDI subsystem sends a status report to the R/3 System on the progress of
    the processing of the outbound Idoc.
    Contents of IDOC
    The data in every IDoc is exchanged between the SAP system and a subsystem in the following three record types, irrespective of the IDoc type:
    •     Control record (Table: EDIDC): Contains information about Sender and Receiver. There is only one control record per IDoc. It consists of
    • IDoc Number
    • Sender and Receiver information
    • IDoc Message Type* / Port.
    • IDoc Type / Direction / Current status / Partner No / Partner Type (Vendor/customer)
    •     Data record (Table: EDIDD): Contains the message to be exchanged between Sender and Receiver. An IDoc can contain multiple data records, as defined by the IDoc structure. Data records store application data such as purchase order / sales order header information, sales order details like sales doc #, Material / Qty and other relevant information.
    •     Status record (Table: EDIDS): Contains Status of IDoc at various stages, during the transmission of IDoc between Sender and Receiver. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process like status code, date and time at every stage
    Know Me
    Basic Type: The form of IDOC type that is originally created in the system. Like ORDERS01 is a basic type IDOC for order messages. It is using the basic types only you would be able to enhance them to suit new requirements within the same IDOC structure. Any enhancement to the basic type IDOC will produce an Extension IDOC that would be more or less similar to the basic type with some new additions (of segments or fields). Here, I would go on to say that IDOC type and Basic type is the same thing that would be referred to interchangeably.
    Message type: Again, obvious from the name, it’s the message that is being conveyed. A message type is assigned to the Basic type. Here, logical messages are assigned to the basic type to reflect a business message being transacted. For example, ORDERS is the message type for a purchase order sent by buyer to vendor. The use of which Basic type in this message will differ from buyer to vendor. Basic types used for ORDERS are ORDERS01/02/ etc...Also, one may come up with a custom built IDOC type (or basic type as you can say)...But it is essential to associate a message type with a basic type IDOC. This feature will enable the same IDOC type to be used for a related message. For example : ORDERS01 can be used for message ORDERS for posting a order, the same IDOC can be associated with message ORDCHG to indicate that the message is an order change and so the processing of this IDOC will change accordingly.
    IDoc Type:
    &#61607;     Defines the structure of data records
    &#61607;      IDoc Type is used to understand the message in string form available in the data records.
    &#61607;      IDoc type is version dependent i.e an Idoc type can be used only in versions in and above the version in which IDoc is released. 
    &#61607;      Transaction WE30 is used to define and release IDoc Types
    &#61607;      Newly created Idoc is a BASIC IDoc and modifications
                 (Additions of segments) to IDoc after it has been released can be done by creation of extension      of IDoc.
    &#61607;      IDoc type can be defined by structuring Segments
    Function Module: The most important player in the IDOC processing. This is nothing but an ABAP program to process the IDOC. SAP has supplied function modules to process all standard basic IDOCs and messages. A function module is determined based on the Basic IDOC type and the message type (also message code). So from the above descriptions about basic and message type, the combination of two would primarily determine which IDOC will process this idoc. As an instance, ORDERS01 with message ORDERS is configured to be processed by FM IDOC_INPUT_ORDERS. Similarly, ORDERS01 + ORDCHG will be processed by IDOC_INPUT_ORDCHG. Likewise, you can see all associations in WE57 for inbound. For out bounds, you would refer to process codes (WE41).
    Segments: The idenfiers in the IDOC structure which indicates the data, their level, state of occurrence....You can take them as records in the IDOC. Each individual segment will come to you as a record in the IDOC. (Go to EDID4, provide an IDOC # and it will list all included segments as records.) Segments are logically nested to indicate various levels of data (header, item etc).
    Qualifiers: Inside the segments, there are fields that can carry actual data often signified by use of qualifiers. A qualifier for a segment field would provide the exact meaning of the data. For example, E1EDK03 segment is configured for dates related data. Segment field IDDAT qualifies the date type and the DATUM field gives out the actual date. So you may see a date qualified as 002, which can be interpreted as requested delivery date. Likewise you can see all qualifiers and their meanings in the associated segment fields in SE12. Give the segment name and go to the domain the ranges for the ID fields.
    How EDI Works
    Sending Data
    •     Computer system serves as a data repository.
    •     EDI extracts information from existing computer applications.
    •     Transmits paperless, computer-readable documents via telephone lines.
    Receiving Data
    •     Fed directly into a computer system.
    •     Automatically processed and interfaced with internal applications.
    Processing Time
    •     Accomplished in minutes.
    •     No re-keying.
    •     No paper shuffling.
    •     No attendant costs of manual document processing and delivery.
    What is the difference between ALE, EDI, IDocs and BAPI?  
    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.
    ALE/EDI - Purpose
    Electronic Data Interchange (EDI) and Application Link Enabling (ALE) are used for exchanging business data between different systems.
    For both these forms of communication, you require the IDoc Interface. The IDoc interface is made up of the definition of a data structure and the processing logic of this data structure. The data structure is the IDoc. The IDoc is the general exchange format of the communicating systems. IDocs can be sent using different methods (for example,  RFC or as a file).
    Application Link Enabling (ALE)
    You distribute data using ALE if you want to communicate from one system to one or more other (mostly internal) systems. ALE transfers data in IDoc format and uses the methods of tRFC for data transfer.
    1.     ALE enables the integration of business processes across several SAP or non-SAP systems.
    Electronic Data Interchange (EDI)
    You use EDI if you want to exchange business application documents with an (external) partner system (for example, a customer or vendor). The SAP system sends EDI messages in IDoc format to an EDI subsystem, where they are converted to a universal EDI standard (UN/EDIFACT or ANSI/X12). This enables communication with non-SAP systems.
    1.     By definition, two partners are involved in the process in an EDI application scenario: The sender and the recipient of an EDI message. 
    IDoc Interface/ALE
    Purpose
    The IDoc interface exchanges business data with an external system.
    The IDoc interface consists of the definition of a data structure, along with processing logic for this data structure.
    The data structure is the IDoc. The IDoc is the exchange format common to all the communicating systems. You can specify exception handling in the SAP Business Workflow, with IDocs, without the data already having to exist as SAP application documents.
    You need the IDoc interface in the following scenarios:
    Electronic data exchange (EDI)
    Connect other business application systems (e.g. PC applications, external Workflow tools) by IDoc
    Application Link Enabling (ALE).
    Application Link Enabling (ALE) is a technology to create and run distributed applications
    Hope this would help you.
    Reward points if helpful.
    Vamsi.

  • Cannot display archived idoc data records in SARA

    Hello,
    In our ERP system, we regularly archive idocs older than 6 months. To view these archived idocs I use transaction SARA (with archive object IDOC and infostructure SAP_IDOC_001) to search for the relevant idoc that has been archived. Once the idoc is displayed, I drill down further by clicking the magnify glass button which then displays the idoc levels:
    EDIDC               Control record (IDoc)
    EDIDD               Data record (IDoc)
    EDIDS               Status Record (IDoc)
    SRL_ARLNK      SREL: Archive Structure for Links
    When I try to view the Data Records, I get a message saying "You are not authorized to display table EDIDD". According to our Authorizations department, this is not an Auth issue but rather config setup or program issue.
    Why can't I view the archived idoc data records? Is there another way to view archived idoc data?
    Regards,
    Fawaaz

    Hi Jurgen,
    Thanks for moving my post to the correct space.
    Our Auth team is very confident that this is not a user auth issue. This could possibly be true because the idoc data resides on the following tables when in the database (before archive) - EDIDC, EDID4 & EDIDS. The idoc could then be viewed via transaction WE02 or the Data Browser (SE16). There is no EDIDD table in our ERP system so obviously no authorization object to assign to.
    Once the idoc is archived, the data is removed from the ERP tables and moved to our archive database/server for storage. So when trying to view the archived record, the system does not access the ERP tables but rather the archive directory (that it's mapped to in settings). I assume the SARA transaction merely displays the data in the same segments/grouping with these table names (mentioned above in my first post) but instead of EDID4 it displays EDIDD.
    According to the error longtext, "The check performed when data is read from the archive is the same as that of the Data Browser (transaction SE16)". So I was not involved with setting up our archiving procedure but could it be that table EDID4 was incorrectly mapped to table EDIDD in archives?
    Regards,
    Fawaaz

  • How to download the IDOC when i performing WE02 to display?

    Hi ,
    How to download the IDOC into local drive when i performing WE02 to display an IDOC?
    Thanks.

    Hi,
    Check this

  • Modified idoc values are not reflecting in the IDOC display (ie we02)

    Hello Team
    I wrote one inbound interface for posting GR by using the IDOC MBGMCR03. In the inbound FM, i wrote some code for retrieving some data and mapping to its relevant fields of the segments. It is working fine but when i see the idoc values in WE02/WE05, i am not able to see the values which i have added in the FM. so please suggest me how to get the values in the IDOC display.
    Regds
    Raj

    Hello Team
    Thanks for your replies. Let me put my question in this way to you.
    In the inbound FM (ie idoc_input_mbgmcr), i have fetched some values from SAP by using the values which came from PI to that IDOC through mapping. what ever the values i have fetched from SAP in inbound FM, i have mapped them to the relevent segments and finally the complete structure i have passed to BAPI, where it will post GR. All these things are working fine, idoc is also getting successfull.
    But when i go and see the successfull idoc values, it is not showing the values which i have mapped in inbound FM. Now i want those values in that Final idoc.
    So pls check and suggest.
    Regards
    Rj

  • How to use the Idoc number.(generated by prgram) and ALE

    Hi All
    I have a problem to use Idocs. I go thru the following steps but can not able to see the final output.
    1.Create Segment ( WE31)
    2.Create Idoc Type ( WE30 )
    3.Create Message Type ( WE81 )
    4.Assign Idoc Type to Message Type ( WE82 )
    5.Make a report which gives us Idoc number.
    Now my problem is where this Idoc number can we used .and how to relate this with ALE.
    Regards
    Manoj

    Hi Manoj,
    Use transaction code we02 or we05 to get the idoc no.
    The table used are
    EDIDC - Control record
    EDID4 - Data record
    EDIDS - Status record
    Regards
    Arun

  • ALE Configuration to Download the IDOC to a FTP Location

    Hello SDN,
    I need to generate the IDOCs and save them in text format onto an FTP Location specified by the client.
    I understand, I need to setup the an TCP/IP RFC Destination and Create a FIle Port Specifying the FTP directory path.
    Please suggest the necessary setup/configuration for the same along with checkpoints.
    Thanks,
    Manu
    Moderator message: duplicate post locked.
    Edited by: Thomas Zloch on Apr 7, 2011 9:49 AM

    Hi,
    Guess it looks like the output is getting proposed but its not getting processed. Check the output type configuration. Check the TIme Settings in the output type configuration.
    It is possible to set the Time when the output must be processed. Is it on SAVE or is it set to other settings. If its set to via background job then the background job must be run to process the output types.
    Check and let me know if all is fine at the output type configuration.
    Cheers
    VJ

  • ALE , EDI and IDOC with MM??

    hii
    What is ALE, EDI and IDOC in SAP??
    How its linked with MM??
    Explain the above things with example
    Thanks

    Hi!
    IDOC = Intermediate Document
    IDoc or Intermediate Document is a standard SAP document format. IDoc's allow different application systems to be linked via a message-based interface.
    For more detailled information look in SAPNET under
    http://service.sap.com/EDI
    For exapmle in purchasing:
    The IDoc message type ORDERS is used to send a purchase order to a vendor.
    EDI = Electronic Data Interchange
    EDI stands for Electronic Data Interchange, which means that data is electronically transmitted from one system to another. The main requirement of EDI is that the systems of the communicating partners understand each other. Usually, the data from one partner gets mapped into the format of the other partner and vice versa.
    Supporting this there exist EDI standards (named EDIFACT, ANSIX12, ODETTE, VDA, TRADACOMS, SPEC2000, ...), where the data formatting for exchanging documents are specified. Normally the partners agree using a special standard message (for example EDIFACT message ORDERS for a purchase order).
    In the SAP system the outgoing data are stored in IDoc format. When processing a receiving document, the Inbound SAP system receives the data in IDoc format too.
    Further processing (converting/mapping from IDoc in another format and vice versa) depends on the partner agreement:
    If the partners have agreed using a special EDI standard, mapping between IDoc and  the  EDI standard is necessary. This mapping is not supported by SAP, external converters or EDI subsystems must be installed by the customers for this purpose.
    If both systems use SAP software, there is usually no need for mapping  (which can save users a lot of money). The two systems are often connected via ALE (Application Link Enabling).
    If partners are using XML, the SAP Business Connector can be used. The business connector is a tool used to help customers connect via EDI. It includes routing and mapping and is XML compatible. To read more about XML at SAP go to SAPNet Alias 'XML' (http://intranet.sap.com/XML).
    For example:
    Vendor can send the invoice by EDI creating an IDoc with message type INVOIC using IDoc Type INVOICxx. He can determine (depending on the partner agreement) how to create an IDoc for Inbound processing with FI or MM-IV.
    ALE  = Application Link Enabling
    ALE is short for Application Link Enabling. Special Basic programs support this functionaliity (see documentation of BC_MID_ALE).
    To link applications you have to configure an ALE model. It contains all relevant data about how a system's configuration (normally a central system and assigned local systems) exchange data.
    With help of the ALE technology, the distribution of contracts is possible in MM via the following business process:
    Contracts that a central purchasing organization distributes to local purchasing organizations to allow the latter to utilize the more favorable conditions they contain for the procurement of materials or external services.Each local purchasing organization sends information on its own release orders back to the central purchasing organization.
    For this purpose the contract in the central system can be copied to the local systems (with message BLAORD and COND_A). When a release order to a distributed contract is created in a local system, the release docu is automatically sent to the central system (with message BLAREL) updating the release docu of the contract in the central system.
    Precondition for this scenario is, that in all systems the used master data (material, vendor, sources of supply, ...) are the same. This master data can be distributed by ALE, which should be done before sending the contract from the central system. Available message types  for distribution of master data are:
    MATMAS (ARTMAS in retail system) for material master
    CREMAS for Vendor master
    INFREC for  info record
    SRCLST for source list
    COND_A for conditions of info record
    SRVMAS for service master data
    Technical documentation to ALE can be found by path:
              Basis Components / Middleware (BC-MID) / Application Link Enabling (BC-MID-ALE)
    The most important Transactions for testing Idoc:
    WE02 Display IDOC
    WE05 IDOC list
    WE19 Testing IDOCs
    BD87 Status Monitor for ALE Messages (reprocess)
    Notes:
    456127 FAQ: Electronic Data Interchange (EDI) in Purchasing
    536411 Sample scenario for ALE contract distribution (only internally released)
    I hope I could help you fruther
    Best regards
    Erika

  • How to define the IDOC adapter in XI  ?

    Hi Experts,
        We are having a scenario where in we are taking an INVOICE Idoc from SAP & sending it to various Non SAP-systmes. e.g. Billing details from SAP is goint to SQL database / Db2 & for XML as B2b.
         In the above scenario how do i need to configure the IDOC communication channel which can give the same information to all three systems.
         I am looking for IDOC configuration in R/3 as well as XI what all steps are required to receive this IDOC & how to divert the same IDOC to all the target system at the same time.
    Regards,
    Umesh

    Hi Umesh
    Check these it may help you out :
    https://wiki.sdn.sap.com/wiki/display/XI/SAPR3%28Idocs%29ToXI--Steps+Summarized
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cdded790-0201-0010-6db8-beb9bb2b2660
    http://help.sap.com/saphelp_47x200/helpdata/en/af/7e844367c24d4a950df3205052769d/frameset.htm
    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
    take a look at "application component" section:
    http://help.sap.com/saphelp_nw04/helpdata/en/b9/c5b13bbeb0cb37e10000000a11402f/content.htm
    you can also have a look at:
    question 4 (document section) on the XI FAQ
    /people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions
    Pls rewards if useful

  • Regardig the extension of the Idoc

    Hi Experts,
                    We are using an Inbound Idoc.
                  I extended the idoc COND_A, becoz we are having some custom fields in the IDOC.
             For this we have an Exit in the FM IDOC_INPUT_COND_A.
    But the data coming to inbound would be of various tables which contains the custom fields.
          How do i update the data in the database tables.
    For EX table A contains 4 custom fields that are to be updated,table b contains 2
    custom fields that are to be updated.
           How do i do this??
    Thanks and Regards
    Rajesh.

    Hii..
    SAP provides the Function module exits to process the Extended idoc type.
    Check this info...
    ALE FUNCTION MODULE ENHANCEMENTS
    Having extended the IDOC type to contain additional fields for an inbound or outbound application, you now want to enhance ALE function modules for populating the additional segment on the outbound or applying the additional segment data on the inbound application.
    The core working code for ALE processes for a given application area is always encapsulated in ABAP/4 function modules. These function modules are associated with such control information as message types and process codes. So the ALE process checks this control information and derives the name of the function module to invoke for that particular IDOC processing from certain database tables. These function modules contain objects known as customer functions, which can be considered SAP Enhanced user exits. A function module is called at a particular point during the processing of the main program or function module, and it can be used to influence data processing at that point by adding code to the customer function. The customer function behaves like a normal function module and has import and export parameters, tables (internal tables) statement, and exception processing. Unlike a conventional user exit, customer functions give you the ability to modify only data available to you by the function moduleâs parameters and internal tables. While most ALE/EDI function modules are supported by customer functions, there are ALE/EDI processes that still use conventional user exits. There are a few ways to determine which function module to enhance for a given message type/process code:
    • For master data distribution, from SALE go to Extensions -> Master data distribution -> Setup additional data for message types. Search for message type DEBMAS in this example. You see an entry for DEBMAS associated with function module MASTERIDOC_CREATE_SMD_DEBMAS. This data is stored on table TBDME. The function module names for all master data message types follow this pattern: MASTERIDOC_CREATE_SMD_messagetype. This function module calls another function module of name MASTERIDOC_CREATE_DEBMAS or MASTERIDOC_CREATE_messagetype. Search for the words customer function, and you find several hits that can be used to add code to the function module.
    • From WEDI got to Control -> Inbound process codes -> Inbound with ALE service -> Processing by function module (transaction WE42), or from WEDI go to Control -> Outbound process codes -> Outbound with ALE service -> With function module (transaction WE41). There will be function modules associated with the process codes. For inbound, the function modules usually follow this pattern: IDOC_INPUT_messagetype: for example, IDOC_INPUT_CHRMAS for inbound characteristics master.
    • Use transaction WE57 or from WEDI go to Development -> Message/Application Object. The entries list the function module, Business Object, message type, and IDOC type that are used for inbound ALE/EDI interfaces.
    Customer functions are not specific only to ALE and EDI but also to all programs/modules in SAP R/3. Customer function is a SAP enhancement component; the other two types are menu and screen enhancements.
    All customer function exits are maintained in SAP enhancements and are found by using transaction SMOD. After executing transaction SMOD, pull down (F4) on the enhancement name field, and execute again. This provides you with a list of all SAP enhancements available. SAP enhancements are grouped by development class pertaining to an application area. Choose Application development R/3 SD master data distribution for development class VSV to lead to a screen that lists VSV00001 as an enhancement (see Figure 5). Press Component +/- to display its function exit components. There are four possible components listed, all of which are function exits (and are function modules) that are called from the ALE function modules in the form Call Customer Function Î001â. This is a special occurrence of the ABAP statement Call. Go to item Exit_SAPLVV01_ 001, which you need to enhance for the Customer Master outbound example of an IDOC extension. In the ALE-function module MASTERIDOC_CREATE_DEBMAS, the statement CALL Customer Function 001 is translated in the background to call component EXIT_SAPLVV01_001. Although this function exit can be edited using transaction SE37, you will use a simpler approach.
    When you use SAP enhancements and their components, you manage them with an SAP object known as a project, which is like an envelope containing the selected enhancements and their components. A project can be used to control the execution of components and to transport them to other clients and instances in SAP. Basically, the process involves creating a project, including enhancements and components that are to be enhanced, editing the components, and then activating the project. The following process creates a project for our example Customer Master IDOC extension:
    • Execute transaction CMOD.
    • Enter name of project, say CSTMAST1.
    • Click on Create.
    • Enter a description of the project.
    • Save.
    • Click on SAP Enhancements.
    • Enter VSV00001 for Enhancement.
    • Save.
    Once youâve created the project, edit the function exit components and activate the project. Remember that the code in the function exit enhancement will execute only if the project is activated. In fact, this is a convenient SAP enhancements feature, whereby the work in progress (developing code in the customer function) will not affect users of that application. When the code is completed, the project can be activated so the enhanced functionality takes effect. It can also be deactivated for maintenance.
    As mentioned earlier, customer functions (function exits) are embedded in ALE function modules and can be used to influence the creation and modification of IDOC data on an outbound application or to post additional or modified IDOC data to an inbound R/3 application. Function exits are similar to regular function modules, with import/export parameters, tables (internal tables), and exceptions.
    The two important factors to consider while developing the customer function are:
    1. The point in the ALE function module where the function exit occurs
    2. The data made available by the customer function that can be modified or posted to the R/3 application, based on the direction.
    Because some function modules have several customer functions, it is critical to choose the function exit best suited for that particular enhancement. Do not attempt to perform activities that the function exit is not designed for. The importance of this point is illustrated by the following description of enhancing function modules for outbound and inbound ALE interfaces.
    Outbound interfaces. In an outbound ALE interface you use function exits (customer functions) to populate additional segments created by an IDOC extension or to modify the existing IDOC data segments as per business requirements. Previously, you identified that enhancement VSV00001 has a component EXIT_SAPLVV01_001 (function exit), which can be used for populating the additional data segment Z1SADRX that you created in the IDOC extension ZDEBMASX (IDOC type ZDEBMASZ, based on Basic IDOC type DEBMAS02). You also learned that the ALE function module that calls this function exit is MASTERIDOC_CREATE_DEBMAS, which has a statement Call Customer Function 001.
    Browse the function module MASTERIDOC_CREATE_DEBMAS using transaction SE37. You will find that this customer function is invoked for every segment of IDOC type DEBMAS02. In fact, the function exit is called soon after the creation of an existing segment has been populated with data and appended to the IDOC data table (internal table). Also, the function exit is exporting the message type, IDOC type, and the segment name and is importing the IDOC extension type. It is also passing the IDOC data internal table. This indicates that the ALE function module is allowing you to populate additional segments for every existing segment and modify the existing segmentâs data.
    Letâs write ABAP/4 code to accomplish the task of populating IDOC segment Z1SADRX with a contact personâs business address:
    • From SE37, display function module MASTERIDOC_CREATE_ DEBMAS.
    • Find Customer Function 001.
    • Double-click on 001.
    • The function EXIT_SAPLVV01_001 will be displayed.
    • Double-click on INCLUDE ZXVSVU01.
    • You will be asked to create a new include object. Proceed as desired.
    • Enter code (as in Listing 1).
    • Be sure to perform a main program check (Function Module -> Check -> main program) and extended program check (Function module -> Check -> Extended check).
    Now that you have extended the IDOC and enhanced the ALE function module based on the requirements for the contact personâs business address on the Customer Master, letâs test the interface. You should create a logical system and define a port for this interface. You should also configure the Customer Distribution Model to indicate that message type DEBMAS is being distributed to this logical system. The only difference in configuration between a regular outbound ALE interface and an enhanced one is the partner profile definition. While maintaining the outbound parameters of the partner profile, make sure the IDOC type is ZDEBMASZ. The fields for Basic IDOC type and extension type are automatically populated with DEBMAS02 and ZDEBMASX, respectively.
    To maintain the contact personâs business address of a customer:
    • Use transaction BD12 or from BALE go to Master Data ->Customer -> Send and send that Customer Master record by executing the transaction after filling in the relevant fields such as customer number, message type, and logical system.
    • Use transaction WE02 or WE05 to verify the IDOC created. You should see the new segment Z1SADRX populated with the correct data.
    With SAP releases below 4.5B, you cannot capture changes to business address through change pointers because a change document object is not available for capturing business address changes, and also earlier releases have not been configured to write change documents for a contact personâs business address. If you would like this functionality, you can either create change document objects, generate function modules to create change documents, and perform ALE configuration to tie it in, or make a cosmetic change to the contact person screen data while changing the contact personâs business address so that it gets captured as a change to the Customer Master. Subsequently, the ALE enhancement that you performed captures the contact personâs business address.
    Inbound interfaces. The process for enhancing inbound ALE interfaces is similar for outbound, with a few exceptions; specifically in the coding of customer functions (function exits) for the ALE/EDI function modules.
    The first step is to create an IDOC extension for the specific Basic IDOC type by adding new segments at the appropriate hierarchy level: that is, associated to the relevant existing segment. Populate the data fields on the new segments with application data by the translator or external system/program before importing them into the R/3 System. Then, find the ALE function module that is invoked by the inbound processing. By browsing through the code or reading the documentation on the function exit enhancements using the SMOD transaction, identify the function exit in which you should place your code. The technique used in the code to post the additional or modified IDOC data to the application can vary based on the application rules and requirements, the data available at that point in processing, and the application function modules available to update the application tables. It is important to search first for application modules that process the data and see if they can be called within the function exit. If the additional data in the extended segments in specific to a custom table or resides in nonkey fields of a single or small set of tables, you may be able to update it directly by SQL statements in the function exit. This approach should be carefully evaluated and is certainly not highly recommended.
    Another option is to use Call Transaction from within the function exit to process the additional data. For example, in the case of message type WMMBXY for inbound goods movements from a warehouse management system, the standard interface creates batches for materials, but does not update its characteristics. In such a case, you can use Call Transaction MSC1 to create the batch and assign characteristic values to it from within the function exit provided.
    reward if Helpful

Maybe you are looking for