Z segment population in DEBMAS07

Hi Experts,
I have copied DEBMAS07 to ZDEBMAS07 and added one segment ZTAX at very last to the tree where it should be populated with some logic. I am using BADI (CUSTOMER_ADD_DATABI) to populate the node (As someone suggested). I am also done with message type-idoc type assignemts in we82. But I am not able to populate the data in ZTAX at the very end of the the line
in the logic.
Can anyone show me d way ?
-=Soni=-

I have solved the issue. For adding z segment to the desired location or at the last of the idoc tree, all  you need to use USER EXIT as EXIT_SAPLVV01 (VSV00001).

Similar Messages

  • Vendor master IDOC segment population ?

    Hi All,
    I have to create vendor master idoc and pass it to a third party system.
    The fields required by the third party system are from tables lfa1 , lfb1,lfm1. The data required is mapped to segments in idoc
    I am using the MASTERIDOC_CREATE_CREMAS FM to generate the idoc.(idoc tyoe :cremas04)
    The idoc is created and generated but I can see only the E1LFA1M segment populated with data. No other segments are getting populated , Can anyone tell me why is that so and how it can be solved.
    Thanks,

    Hi,
    Please check CREMAS message type, perhaps there is <b>reduced message type</b> or <b>segment filter</b>. Go to transaction code <b>BD53</b> or <b>BD56</b> to find out.
    Hope this will help.
    Regards,
    Ferry Lianto

  • Idoc segment population logic needed

    Hi experts,
    I am creating a custom idoc. The custom idoc has one parent segment(zhead1) and a child segment(zinvoice).
    I am populating the  invoice numbers(BELNR) and their line items in the child segment against a particular check number(PAYR_CHECT).
    The structure is coming something like this: If a check has 2 different invoices each having two diff. line items, then  4child segment(containing invoice no. and it's respective line item in one child segment) is getting created against a parent segment(containing check header details).
    But I require a parent segment to get populated against each check no. as well as invoice number and the invoice line items to be in the child segment of the invoice header segment.
    How to do this.
    My current code is:
    LOOP AT T_ZCHKHDR INTO WA_ZCHKHDR.
        CLEAR T_IDOC_DATA.
    Fill the header segment
        ZCHKHDR-ZBUKR  = WA_ZCHKHDR-ZBUKR.
        ZCHKHDR-CHECT  = WA_ZCHKHDR-CHECT.
        ZCHKHDR-ZALDT  = WA_ZCHKHDR-ZALDT.
        ZCHKHDR-VOIDD  = WA_ZCHKHDR-VOIDD.
        ZCHKHDR-RWBTR  = WA_ZCHKHDR-RWBTR.
        ZCHKHDR-STATUS = WA_ZCHKHDR-STATUS.
        ZCHKHDR-BANKA  = WA_ZCHKHDR-BANKA.
        ZCHKHDR-RZAWE  = WA_ZCHKHDR-RZAWE.
        ZCHKHDR-XBLNR  = WA_ZCHKHDR-XBLNR.
        ZCHKHDR-LIFNR  = WA_ZCHKHDR-LIFNR.
        ZCHKHDR-WMWST1 = WA_ZCHKHDR-WMWST1.
        ZCHKHDR-BKTXT  = WA_ZCHKHDR-BKTXT.
        T_IDOC_DATA-SDATA = ZCHKHDR.
    *-- Reduce fields for the segment
        CALL FUNCTION 'IDOC_REDUCTION_FIELD_REDUCE'
          EXPORTING
            MESSAGE_TYPE = C_MSG_TYPE
            SEGMENT_TYPE = C_SEGNAM_ZCHKHDR
            SEGMENT_DATA = T_IDOC_DATA-SDATA
            EMPTY_SYMBOL = C_SLASH
          IMPORTING
            SEGMENT_DATA = T_IDOC_DATA-SDATA.
        T_IDOC_DATA-SEGNAM = C_SEGNAM_ZCHKHDR.
        T_IDOC_DATA-MANDT = SY-MANDT.
        APPEND T_IDOC_DATA.
    Fill the item segment
        LOOP AT T_ZCHKLN INTO WA_ZCHKLN WHERE CHECT = ZCHKHDR-CHECT.
          ZCHKLN-CHECT = WA_ZCHKLN-CHECT.
          ZCHKLN-EBELN = WA_ZCHKLN-EBELN.
          ZCHKLN-PO_EBELP = WA_ZCHKLN-PO_EBELP.
          ZCHKLN-PO_WERKS = WA_ZCHKLN-PO_WERKS.
          ZCHKLN-PO_KOSTL = WA_ZCHKLN-PO_KOSTL.
          ZCHKLN-PO_WBS = WA_ZCHKLN-PO_WBS.
          ZCHKLN-PO_SAKTO = WA_ZCHKLN-PO_SAKTO.
          ZCHKLN-BELNR = WA_ZCHKLN-BELNR.
          ZCHKLN-IN_BUZEI = WA_ZCHKLN-IN_BUZEI.
          ZCHKLN-IN_MENGE = WA_ZCHKLN-IN_MENGE.
          ZCHKLN-IN_MWSKZ = WA_ZCHKLN-IN_MWSKZ.
          ZCHKLN-IN_WRBTR = WA_ZCHKLN-IN_WRBTR.
          ZCHKLN-IN_BSTME = WA_ZCHKLN-IN_BSTME.
          T_IDOC_DATA-SDATA = ZCHKLN.
    *-- Reduce fields for the segment
          CALL FUNCTION 'IDOC_REDUCTION_FIELD_REDUCE'
            EXPORTING
              MESSAGE_TYPE = C_MSG_TYPE
              SEGMENT_TYPE = C_SEGNAM_ZCHKLN
              SEGMENT_DATA = T_IDOC_DATA-SDATA
              EMPTY_SYMBOL = C_SLASH
            IMPORTING
              SEGMENT_DATA = T_IDOC_DATA-SDATA.
          T_IDOC_DATA-SEGNAM = C_SEGNAM_ZCHKLN.
         T_IDOC_DATA-HLEVEL = 2.
          T_IDOC_DATA-MANDT = SY-MANDT.
          APPEND T_IDOC_DATA.
          ENDIF.
          CLEAR: WA_ZCHKLN.
        ENDLOOP.
        AT LAST.
          PERFORM SUB_MASTER_IDOC_CONTROL.
          T_IDOC_HEADER-MESTYP = C_MSG_TYPE.
          T_IDOC_HEADER-IDOCTP = C_IDOC_TYPE.
          SELECT SINGLE PARNUM FROM EDPP1
                               INTO V_SDNPRN
                               WHERE PARTYP = C_LS.             "#EC
          T_IDOC_HEADER-SNDPRN = V_SDNPRN.
          T_IDOC_HEADER-SNDPRT = C_LS.
          T_IDOC_HEADER-OUTMOD = C_OUTMOD.
          T_IDOC_HEADER-STDMES = C_STDMES.
          T_IDOC_HEADER-RCVPFC = V_RCVPFC.
          T_IDOC_HEADER-RCVPRN = V_RCVPRN.
          T_IDOC_HEADER-RCVPOR = V_RCVPOR.
          T_IDOC_HEADER-RCVPRT = C_LS.
          DESCRIBE TABLE T_IDOC_DATA LINES V_LINES.
          IF V_LINES > 0.
            CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
              EXPORTING
                MASTER_IDOC_CONTROL            = T_IDOC_HEADER
              TABLES
                COMMUNICATION_IDOC_CONTROL     = T_COMM_IDOC_CONTROL
                MASTER_IDOC_DATA               = T_IDOC_DATA
              EXCEPTIONS
                ERROR_IN_IDOC_CONTROL          = 1
                ERROR_WRITING_IDOC_STATUS      = 2
                ERROR_IN_IDOC_DATA             = 3
                SENDING_LOGICAL_SYSTEM_UNKNOWN = 4
                OTHERS                         = 5.
            IF SY-SUBRC = 0.
              READ TABLE T_COMM_IDOC_CONTROL INTO WA_COMM_IDOC_CONTROL INDEX 1.
              IF SY-SUBRC = 0.
                MESSAGE S000(ZFI) WITH WA_COMM_IDOC_CONTROL-DOCNUM.
              ENDIF.
            ELSE.
              MESSAGE W001(ZMM) WITH TEXT-003.
            ENDIF.
          ENDIF.
          CLEAR T_IDOC_DATA.
          REFRESH T_IDOC_DATA.
        ENDAT.
        CLEAR: WA_ZCHKHDR.
      ENDLOOP.
    Regards,
    Sangeeta.

    As many entries you have in t_zchkhdr those many headers will be created for header and as many entries you have in t_zchkln , those many entries will be created in line.
    I hope you have the occurences as 1 to many for lines.
    Also you are distributing the IDoc within the loop at t_zchkhdr so one IDoc will be created per t_zchkhdr line.
    If you want one Idoc containing all the headers, then move the MASTER_IDOC_DISTRIBUTE outside the outer loop.
    regards,
    Advait
    Edited by: Advait Gode on Nov 5, 2008 3:46 PM

  • ZBATMAS03 - extended idoc segment population

    Hi,
    I've found an extended IDoc ZBATMAS03 (basic type: BATMAS03). It's being used for generating outbound IDOc usiong change pointers. A new segment Z1BATMAS has been added to the extended one.
    Now I'm not able to find where this segment is being populated.
    I tried searching in FM: MASTERIDOC_CREATE_SMD_BATMAS and the where used list for the new segment.
    can anyone tell me how to find where the above new segment is being populated?
    regards,
    Ravi

    Hi,
    First up all the FM name is MASTERIDOC_CREATE_SMD_BATMAS, I surprised after dont find any exit for this FM.. May be you need to copy this FM and do the changes... Yes this the FM used to create an Idoc BATMAS.
    You need to create custom function module with reference to standard FM, fill your extension segment.
    Regards,
    Suresh.D

  • Why T-RFC Port canu2019t handle Partner Profile Segment Release Version.

    Can TRFC Port handle the segment release of each of the segment if configured in Partner Profile.
    As per sap, in Partner Profile,  if we maintain the two field "Seg. Release in IDoc Type"  and "Segment Application release" to a SAP Release lower than the current release version then all the segment populated by the IDoc adapter should be populated as per the lower release structure.
    For test Purpose I have created two IDoc using File Port and TRFC port and for both of then I have maintained the Partner Profile Fields  "Seg Release in IDoc Type" and "Segment Application Release" as 46C although the latest release is 701. 
    In the IDoc there is a custom segment ZE1PMX with two Version Release 46C & 701. 46C is having 7 Fields and 701 is having 9 fields.
    Test using TRFC Port: Using TRFC port the IDoc that is getting generated are not having the segment structure of release 46C instead of that it is taking the segment structure of latest release 701 which is having 9 fields.
    Test using File Port: Using File port the IDoc that is getting generated are having the segment structure of release 46C instead of latest release 701 which is having 7 fields which is desirable.
    I have also done these testing in other SAP release like 700 and found that while saving the partner profile with a lower  segment release number it throws an warning message as "Segment definitions missing for release 620/620" and IDocs are not getting generated with a error status Code 2 "Segment E1BPMEPOITEM1 is unknown in Release 620 /". But from release 701 sap allows us to save the Partner Profile without warning and also creates the IDoc without error but the segments takes the latest release structure instead of the release maintained in the Partner Profile.
    If any one has already done some investigation on this issue please let me know why there is a difference in TRFC Port and File Port. Is there any other configuration that is missing for T-RFC Port.

    Hi Dennis
    This forum is focused on [SAP NetWeaver Gateway|http://www.sdn.sap.com/irj/sdn/gateway], i.e. the (relatively) new OData/REST-orientated mechanism to expose ERP data and functions.
    You're talking about the ('classic') Gateway i.e. the service that runs on port 33<SYSNR>. As a result, you are better off posting in the forum that covers that Gateway, i.e. [Application Server Infrastructure|SAP NetWeaver Application Server;
    The names do make it confusing, for sure.
    Good luck!
    dj

  • Do any standard functions populate all segments?

    I have been using the ALE Send transactions for MATMAS and BOMMAT.  But now I am discovering that all of the segments in the IDOC it creates are there.  Is there a different mechanism (other than writing ABAP) to get more of the segments populated?  I'm especially interested in the E1CUCFG that is not available in MATMAS05.
    I would also like to have the BOMMAT IDOC generated for all effectivities instead of just one.  Is this possible, and how?

    Hi Paul,
    Please check this links which will help you to know more detail on how to use user exits.
    http://sap-img.com/abap/a-short-tutorial-on-user-exits.htm
    http://sap-img.com/abap/what-is-user-exits.htm
    http://sap-img.com/abap/what-is-the-difference-between-smod-and-cmod.htm
    The best user exits to populate E1CUCFG segments is EXIT_SAPLMV01_002.
    It depends on your business requirements. You can use change pointers to send MATMAS and BOMMAT IDocs if there are master data changes by running or schedule program RBDMIDOC.
    Hope this will help.
    Regards,
    Ferry Lianto
    Please reward points if very helpful.

  • Balancsheet GL Contains Profit Segments in SV type doc type

    Hi Gurus,
    As in my system i am showing some inconsistency in accounting Document
    posting.e.g
    i had Created 1 Balance sheet account '111132' & assign to the SV
    document type in CRM server & R/3. Now when my Contract got Posted in
    CRM server it generates Accounting document with Profit Segment
    Populated in that document.
    Secondly, when same GL account '111132' i had assign to the IS
    document type & when it's got Posted in Accounting at that time
    it can't Generate the Profit Segment in that document.
    Can any budy please tell me thay why in one document type Profit Segment
    posted while in other docuemnt type it not posted ..
    thanks
    Devang

    Hi, you need to activate cost center in AA,and make it optional for account and posting key, then PC'd derive from Cost center
    Also check While posting F-90 profitcenter is blank and Grey mode
    Edited by: alex ice on May 23, 2011 8:28 AM

  • Issue in "Inheritance" New GL

    Hi Experts,
    Could you help me solve the issue.
    I feel inheritance is not working properly for me.
    I have checked the inheritance check box in doc splitting activation.
    When I post a FB50 document with 2 line items, one line item having profit center and segment, in GL simulation view, I am not able to see PC and segment populated in 2nd line item.
    I hope this should happen using "inheritance" concept.
    SAme issue with FB60 and FB70.
    It works well only if I mention splitting rules. PC and segment get inherited id splitting rules exists.
    If no splitting rules, 2nd line item is not inheriting PC and segment of 1st line item even if inheritance is checked and splitting active.
    Could you please help me if I am missing any config or concept.
    So it not "Inheritance" check box issue?
    Thanks

    Hi,
    Activate Scenarios PC & Seg for document splliting.
    Assign Scenarios and Customer Fields to Ledgers
    IMG à Financial Accounting (New)à Financial Accounting Global Settings (New)à Ledgers à Ledgerà Assign Scenarios and Customer Fields to Ledgers
    plz let us know still you have any issue.
    Regards
    Viswa

  • F-92 asset retirement-where document splitting is active

    I have a situation where I have activated document splitting for the characteristics profit centre and segment. When i post an asset retirement however that the customer and the VAT postings do not get populated with profit center and segment. The asset disposal accounts, the assets, the gain or loss on disposal do have the profit center and segment populated.
    I have made FSG  profit centre required for customer, not required for VAT general ledger accounts
    I have made the posting key 01 and 50 FSG- profit centre required and cost centre optional
    Where else can i check. as i thought the customer would inherit the profit center from the cost centre in the asset being sold.

    Hi,
    This is surely related to Document splitting configuration
    For Document type DR, what is the business trans. and trans. variant assigned ?
    I think it should be 0000 (unspecified posting) and then create a new variant and assign the below categories:
    Menu: Financial Accounting (New)-> General Ledger Accounting (New) - > Business Transactions -> Document Splitting -> Define Business Transaction Variants
    01000     Balance Sheet Account
    01100     Company Code Clearing
    01300     Cash Discount Clearing
    02000     Customer
    02100     Customer: Special G/L Transaction
    03000     Vendor
    03100     Vendor: Special G/L Transaction
    04000     Cash Account
    05100     Taxes on Sales/Purchases
    05200     Withholding Tax
    06000     Material
    07000     Fixed Assets
    20000     Expense
    30000     Revenue
    40100     Cash Discount (Expense/Revenue/Loss)
    40200     Exchange Rate Difference
    80000     Customer-Specific Item Category
    Assign the new variant to DR document under Financial Accounting (New)-> General Ledger Accounting (New) - > Business Transactions -> Document Splitting -> Classify Document Types for Document Splitting
    Hope this helps
    Regards
    Tarek

  • Idoc Control record - Change to msg type not working

    Hi,
    We have a field in the control record that we are trying to update but it will not take.  The FM is IDOC_OUTPUT_TPSDLS.  Inside this FM is a call to function customer-function '020'.  double click on the '020' and you go to the user exit EXIT_SAPLV56I_020.
    I created the include ZXV56U30.  It has one line of code - idoc_control-mescod = 'GLT'.  We are trying to populate this field with 'GLT'.  I activated the include and the user exit and the customer-function and finally the FM IDOC_OUTPUT_TPSDLS.  The user tested and said while we are getting our custom segments populated we are not getting this idoc_control-mescod = 'GLT' to work.
    What am I missing here?  Do I need to do a commit after the field is populated?  Is there some config that needs to be in place or what?
    Any help would be apprciated since we need this by the EOD for go-live.
    Thanks - many points awarded if someone can figure this out!

    Hi,
      Check if the user exit enhancment is added to a project in CMOD and make sure the project is activated.
    Thanks,
    Naren

  • FILE TO MULTIPLE IDOC QUERY

    Hi,
    I have a file (PO details)from which i create multiple idoc. The structure of file and idoc is as follows
    --BATCH   
       ---HEADER
    ITEM
    --/BATCH
    IDOC IS
    --IDOC
         ---BATCH
    HEADER
    ITEM
    now in order to get multiple idoc from the file structure i changed the idoc segment cardanility to 0-unbounded and mapped
    HEADER of file to IDOC node of idoc so that idoc gets created for each header,
    my requirement is that for each idoc
    1) the batch segment should also get populated
    2) there is a feild batchid in the batch of file value of that feild should be populated in one of the header feilds
    Presently suppose the file has 10 POs, then it creates 10 IDOCS where in only the first idoc has the batch segment populated and the header of first idoc has batch id populated , rest 9 IDOCS the batch segment is blank and even i am not getting the batchid value in the header.
    Edited by: Sudhakar Gongloor on Jun 21, 2010 4:12 PM

    exactly.
    so in your case if source field A has 5 values and you need there values to go into 5 IDocs, you will use
    Source field A -> Split by value -> Idoc field
    Also note that you will have to similarly maintain a context mapping for the parent node of the target field.

  • How to extend an existing IDOC!

    tell me the steps to extend the existing IDOC !
                                                                   Thanks

    1>we31(create new segments with fields u want to populate)
    2>we30(create an extension idoc type).in we30 u will get to radio buttons.1>basic type 2>extension.click on the extension and then copy the basic type.Now will get all the segmnts .Now add the new segments under the parent segement which needs to be extended.
    3>attach the extended idoc type to basic type and message type to tcode WE82.
    4>Now u have to search for an exit where u have to write ur code in order to populate the fields which u have extended.Basically u will write in the Function module.Make sure u r writing in the correct exit.Evry messagetype will have a function module.
    5>create a project in cmod and activate the function exit.
    IDOC EXTENSIONS
    Letâs first look at the concept of IDOC extension. SAP delivers Basic IDOC types such as DEBMAS02, MATMAS02, ORDERS02, and WMMBID01. By extending the Basic IDOC type, you are actually creating a new IDOC type. You create a new segment with the additional fields. This new segment has to be associated with one of the existing Basic IDOC segments. Then you create a new extension type, which is associated with the Basic IDOC type. This results in a new IDOC type. In order for ALE function modules to relate to this new IDOC type, the IDOC type is linked to the corresponding message type. Note that you should not add fields to existing segments but should create a new segment and associate it with an existing segment. This, in a nutshell, is the process of creating IDOC extensions.
    In our example, the Basic IDOC type DEBMAS02 is used to communicate Customer Master data to the SAP Customer Master application. Even though the application has a screen to enter and store a contact personâs business address (see Figure 1), DEBMAS02 does not have a segment or fields that communicate the contact personâs business address. If your business requires that this business address be communicated to the other system through the ALE interface for Customer Master, then you have to extend the DEBMAS02 IDOC type, and enhance the corresponding ALE function module.
    In DEBMAS02 the contact person fields are present in segment E1KNVKM and the business address of the contact person is stored on the SADR SAP table. You need to create a new segment, Z1SADRX, that is associated with E1KNVKM. This will be done in the process of creating an extension type ZDEBMASX. This extension type will then be associated with a new IDOC type, ZDEBMASZ. IDOC type ZDEBMASZ will be linked to message type DEBMAS for Customer Master. The final step in the IDOC extension process is to check the new objects. This check also verifies the structural integrity of the IDOC type. Letâs look at each of these steps in more detail.
    1. Create an Extension Type and a New Segment.
    First, letâs determine the fields on table SADR that you are going to provide for in the new segment Z1SADRX. You need fields for name, street, city, region, and country to give the business address of the contact person. You also need fields for the address number. ADRNR is a field in SAP tables such as SADR that uniquely identifies the address of an entity. This field is cross-referenced from other tables to the SADR table to obtain the full description of the address. Because this is an IDOC type for master data, the first field of the new segment will be MSGFN. The message function field informs the receiving system of the action to be taken for that particular segment. In the code that you write for populating the new segment, the value of the message function is the same as that of the parent segment E1KNVKM. In all, you will have 12 fields in segment Z1SADRX (see Table 1).
    To create an extension type and new segment:
    •     Use transaction WE30 or from WEDI go to Development -> IDOC types.
    •     Enter ZDEBMASX for Object Name.
    •     Choose Extension Type.
    •     Click on Create.
    •     You will see a pop-up screen. Choose Create New, and enter a description. For version 4.x, enter DEBMAS02 in the Linked Basic Type field. Enter.
    •     You will see a screen with ZDEBMASX and its description in the first line. Click on this line, and press Create. For version 4.x, expand the tree of segments, and place the cursor on E1KNVKM.
    •     You will see a pop-up screen. Enter E1KNVKM as the reference segment. Enter.
    •     For 4.x, press Create after placing the cursor on segment E1KNVKM.
    •     You will see a line appear with E1KNVKM hierarchically below ZDEBMASX, with a description "Customer Master contact person (KNVK)."
    •     Click on this line and press Create. You will receive a message indicating that the new segment being created will be a child segment of E1KNVKM. Enter. A pop-up box appears for the new segment.
    •     Enter Z1SADRX as the segment type, 1 for Minimum, 1 for Maximum. Leave Mandatory segment unchecked. These entries imply that there is only one Z1SADRX segment for every occurrence of the E1KNVKM segment, and also that this segment is not mandatory. Note that if the parent segment is not mandatory, then the child segment should not be mandatory, because this could result in a syntax error during the creation or processing of the IDOC.
    •     For 4.x, you must first create the IDOC segment Z1SADRX (Iâll explain why in a moment) from the menu path WEDI -> IDOC -> Development -> IDOC Segment.
    •     Click on Segment Editor.
    •     On the next screen, click on Create.
    •     Enter a development class for the object. Enter.
    •     This will take you to the screen for segment definition. Enter a description for the segment. Enter the field name, data element, and the data element documentation name. In most cases, all three fields may have the same values. If you are using a field in the segment that is not present in the ABAP/4 data dictionary, you must first create the domain, data element, field, and appropriate documentation before using it in the new segment.
    •     Enter these three columns for all 12 fields. Save.
    •     Click on Generate/Activate, F3 to step back.
    •     From screen Maintain Segment, go to Segment Type -> Release. A checkbox now appears beside the segment definition Z1SADRX (see Figure 2). Check this box. Save.
    •     Save again to store the descriptions of the segment, F3 to step back.
    •     Save the extension type.
    It is possible to have several new segments with relevant Basic IDOC type parent segments in a single extension type. However, you can form only one IDOC type based on a single extension type.
    2. Create an IDOC Type.
    The next step is to create an IDOC type by associating the extension type that you created with the Basic IDOC type. This is a simple process:
    •     From transaction WE30 or WEDI go to Development -> IDOC Types.
    •     Enter ZDEBMASZ for Object Name.
    •     Click on IDOC Type.
    •     Click on Create.
    •     Enter DEBMAS02 for Basic IDOC type.
    •     Enter ZDEBMASX for extension type.
    •     Enter a description.
    •     Enter.
    •     You will see a display of the composite IDOC type with all segments, including Z1SADRX (see Figure 3).
    It is possible to associate only one extension type with a Basic IDOC type for a given IDOC type. However, you can have multiple new segments in an extension type.
    3. Link IDOC Type to Message Type.
    The next step is to link the new IDOC type to its corresponding message type. This is important, because this relationship is referenced in the partner profile parameters where you specify the message type and IDOC type to be used for that particular representative system. To link the message type:
    •     Use transaction WE82, or from WE30, go to Environment -> IDOC Type / Message Type, or from WEDI go to Development -> IDOC Type -> Environment Î IDOC Type / Message Type.
    •     Click on Display <-> Change.
    •     Click on New Entries.
    •     Enter DEBMAS for message type.
    •     Enter DEBMAS02 for Basic IDOC type.
    •     Enter ZDEBMASX for extension type.
    •     Enter your SAP R/3 release number for Release.
    •     Save.
    This data is stored on the EDIMSG table and is accessed by several ALE processes to relate the message type to the IDOC type.
    4. Check the IDOC Type.
    Before checking the IDOC type for consistency, it is important to perform another step that releases the extension type to the IDOC type:
    •     From WEDI go to Development -> IDOC Types -> Extras -> Release Type, or from transaction WE30 go to Extras -> Release Type.
    •     For the Object Name ZDEBMASX and radio button Extension Type, click Yes.
    •     The extension type has now been "released."
    You canât edit the extension type once itâs released. To cancel the release for further editing or deactivation, go to WE30 Î Extras Î Cancel release. The final step in the IDOC extension process is checking the validity of the IDOC type:
    •     From transaction WE30 or WEDI go to Development -> IDOC types.
    •     Enter ZDEBMASX for Object name.
    •     Click on Extension Type.
    •     From the Development Object menu select Check.
    •     Repeat the operation for IDOC type ZDEBMASZ.
    •     A check log will be generated for each run with details of correctness or errors (see Figure 4).
    In some situations it is possible to receive errors during the check process, especially segment length errors. The incorrect IDOC segment can be repaired and corrected by executing program RSEREPSG. This program checks the formal consistency and repairs incorrect segments. In test mode it will generate a log of formal correctness for the specified segment only. For the program to repair segments in normal mode, the underlying IDOC structures (DDIC structures) must be active. This program rectifies the lengths of the DDIC structures and not the fields themselves. RSEREPSG can also be used to change the person responsible for the object and the release flag.
    Menu paths may vary slightly depending on the release/version of SAP R/3, but the procedures and the principles are the same.
    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. It may be necessary to enhance an ALE function module even in situations where an IDOC extension has not been performed if the IDOC data being passed to and from the application requires modifications. The following approach applies to both situations.
    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.
    Error handling is a very important consideration when making enhancements to inbound ALE/EDI objects. In ALE and EDI inbound processing, workflow is used for handling errors at different levels such as technical and application. If workflow has been configured for the interface, the error messages and workflow items flow to the inbox of the named recipient(s).
    It is also critical to enhance the workflow that handles notifications of the inbound ALE/EDI process. In most scenarios this is not a very difficult task because SAP lets you influence the workflow parameters and messages in function exits (customer functions). You typically do this using flags and message codes to trigger certain workflow actions. If you conform to the status codes and flags stipulated for workflow processing, the enhancement could be error-free and seamless. In the case of an inbound IDOC with an extension, you should populate the EDIDC fields IDOCTYP (new IDOC type) and CIMTYP (extension type) accordingly.
    IDOC REDUCTIONS
    When distributing or communicating master data to other systems, the volumes of data transmitted over communication lines may be large, resulting in performance problems and/or excessive usage of resources such as disk space and bandwidth. Careful scrutiny of the master data Basic IDOC type may reveal that many of the segments are redundant or are simply not being used. If this is true, then the basic IDOC type is a candidate for a technique known as IDOC reduction. The R/3 System provides the ability to eliminate unused segments and irrelevant segment fields from the Basic IDOC type. This procedure is relatively simple and easy to implement. IDOC reduction is available for only a few message types such as DEBMAS, CREMAS, GLMAST, MATMAS, and certain POS messages.
    When performing an IDOC reduction, a new message type is created based on an existing message type. The IDOC segments associated with that message type are proposed for editing. Mandatory segments of the IDOC type canât be excluded. By default optional segments are excluded, but you can choose to include an optional segment and only certain fields in the optional segment. If you have extended the Basic IDOC type and created a new IDOC type associated with a corresponding message type and you are creating a new message type (view) based on it for purposes of IDOC reduction, then the enhanced IDOC type is presented for editing along with the additional segments.
    Letâs use the Vendor Master IDOC type CREMAS01 as an example to demonstrate IDOC reduction. Message type CREMAS is used for communicating Vendor Master data to other R/3 or external systems. If you browse the IDOC type CREMAS01 youâll see that it has 10 segments, with E1LFA1M being a mandatory segment (see Figure 6). To reduce this IDOC type:
    •     Use transaction BD53 or from SALE go to Distribution scenarios -> Master data distribution -> Reduce IDOC type for master data.
    •     Enter ZCREMS for View (message type).
    •     Click on Create.
    •     You will see a pop-up box. Enter CREMAS in the Derived From field. Enter.
    •     Enter a description. Enter.
    •     You will see a list display with segment E1LFA1M in green and a * symbol. The symbols used in IDOC reduction are: * for mandatory, 1 for selected, - for deselected, x for core selected, and the Î.â for core not selected. The corresponding elements are highlighted in green, white, red, violet, and gray, respectively.
    •     Expand all trees. You will see nine other segments in red.
    •     Place your cursor on the E1LFB1M segment for company code data and click on Select. It turns white with a 1 symbol.
    •     Double-clicking on it will display a list of fields. You can select fields that you require (see Figure 7).
    •     Note that if a child segment is selected, its parent is also selected automatically in order to maintain the hierarchical integrity.
    •     After youâve selected the segments required and its fields, save.
    •     From the main screen, click on Activate.
    Activating the new message type ZCREMS will turn on the message type change pointer generation on a particular client. While creating a reduced IDOC type message is a client-independent activity, activation is client-dependent. An entry is created in table TBDA2 for a specific message type in a specific client and is activated. To delete this message type, you need to deactivate it from all clients on that instance. These message types are transportable.
    Now that weâve created a new message type for a reduced IDOC type, letâs build the rest of the ALE configuration to work the interface with the following steps:
    •     Define a logical system to represent the other R/3 or external system.
    •     Configure the Customer Distribution Model to send message ZCREMS to this logical system.
    •     Define a port, if needed, for this system.
    •     Define a partner profile based on the logical system and maintain its outbound parameters. Make sure to use ZCREMS as the message type and CREMAS01 as the IDOC type.
    •     Use transaction BD14 or execute program RBDSECRE or from BALE go to Master Data -> Vendors -> Send. Then, to specify a vendor or range of vendors and enter message type, go to ZCREMS and its target logical system.
    •     Execute.
    You can also capture changes to Vendor Master data and create IDOCs by executing transaction BD21 or program RBDMIDOC. Use transaction WE02 or WE05 to view the IDOCs created as a result of the preceding test. Notice the segments populated and the basic segments that are absent due to the reduction. You will find that the fields deselected from the segments have a value of /. This is equivalent to a null value. Eliminating segments may result in saving resources, while eliminating fields may not, unless the data is compressed. Also, if you look at the master data ALE function modules for these few message types, youâll see that a function module IDOC_REDUCTION_FIELD_REDUCE is called for every segment being populated. This in itself may be an overhead. It is important to weigh the pros and cons before implementing IDOC reduction. Of course, in certain cases, it may be a necessity for adjustment of data.
    Enhancing ALE/EDI and IDOC extensions and conducting IDOC reductions is fairly simple. However, before proceeding with these tasks, you must carefully research the many options available in ALE and develop the best design for your business scenario.
    IMPLEMENTING BAPI WITH ALE: A SAMPLE SCENARIO
    Business application programming interfaces (BAPIs) provide an interface to Business Objects in the R/3 System. Business Objects are based on object-oriented technologies and represent an application objects, such as an address or a sales order. This next section prototypes an ALE interface that incorporates BAPI methods. When weâve finished, you should have a good idea of how easy it is to incorporate BAPIs with ALE and of how beneficial leveraging the 1000+ BAPIs available in the R/3 System can be when you want to interface with R/3 application objects.
    Letâs start with a brief overview of SAP Business Objects and BAPIs.
    SAP Business Objects. An SAP Business Object envelopes R/3 data and business processes while making the details of data structure and access methods transparent to a user interfacing with it. It consists of four layers: kernel, integrity layer, interface layer, and access layer. The kernel represents the R/3 data and its attributes. The integrity layer represents the business logic of the object and contains the business rules that govern the values of the kernel. The interface layer describes the interface mechanisms to external applications. BAPIs belong to the interface layer. The access layer represents communication methods, such as COM/DCOM, RFC, and CORBA.
    SAP Business Objects and their details are stored in the Business Object Repository in the R/3 System.
    BAPIs. BAPIs are "methods" of SAP Business Objects and represent their interface layer. BAPIs are essentially function modules in the R/3 System that are capable of invoking remote function calls (RFCs) for the purpose of communicating data through the function moduleâs import/export parameters and internal tables. BAPIs do not invoke screen dialogs. Like blackbox technology, BAPIs do not require the programmer or user to know the coding and implementation details of the interface to the Business Object. The user simply invokes the BAPI with its appropriate parameters and values in order to accomplish a task such as getting a list of materials from an external system or sending a list of contact person details to another system.
    BAPIs can be executed synchronously or asynchronously while using the ALE communication layer for exchanging data. Typically, with asynchronous BAPI communications, an ALE IDOC is used to distribute the data. As we will learn in the following prototype, the ALE distribution model has to be configured in order to use the appropriate BAPI methods for the RFC destination that provides a gateway to the external system (R/3 or other). For this type of communication, an ALE IDOC interface must exist. If a particular BAPI (SAP-delivered or user-written) does not have an ALE IDOC interface, the interface can be generated using certain R/3 tools and procedures.
    BAPIs are fast becoming the communication standard for exchanging data between business systems (including R/3). SAP Business Objects conform to Open Application Group (OAG) standards, and BAPIs support the COM/DCOM and CORBA guidelines. ALE and BAPIs is the strategic direction for all SAP interface technologies and will replace SAPâs traditional techniques in the future.
    A BAPI/ALE PROTOTYPE ÷ CONTACT PERSON DETAILS
    In the previous section, we learned how to enhance ALE functionality using the example of Customer Contact Person details. We extended the IDOC and enhanced a customer function with a few lines of ABAP code to achieve the additional functionality of distributing contact person details. While this was an exercise to learn IDOC extensions and customer-function enhancements, we can prototype a BAPI/ALE interface in this section that accomplishes the same purpose ÷ the distribution of contact person details. In release 4.5 of the R/3 System, message type ADR3MAS and IDOC type ADR3MAS01 have been provided to distribute contact person details with the aid of a BAPI method. The steps weâll walk through in a moment will illustrate the ease with which we can integrate BAPIs with ALE to get an interface up and running for many standard business scenarios or specialized cases that were not supported by ALE prior to the advent of BAPIs.
    The ADR3MAS is considered to be a master data message type because it complements business master data, such as customer and vendor master. It is now supported by change document functionality, implying that change pointer mechanisms can be used to capture and then distribute changes occurring to contact person data using ALE IDOCs. The function module that accesses the R/3 data is a BAPI. In the R/3 System, contact person address is a business object. If we search the Business Object Repository (via transaction SWO1) with the keyword "address," for example, we will find business object BUS4003 under Cross-Application Components -> General Application Functions -> Address Management -> BUS4003: Address of a person in a company. This is the business object that pertains to our scenario, and a drill down on it reveals the details of the object, including its methods (see Figure 8). The method that would be of interest to us is "AddressContPart.SaveReplica." For your information, the corresponding BAPI function module is BAPI_ADDRCONTPART_ SAVEREPLICA in the function group SZAM.
    Having gathered this information, Letâs build the outbound interface:
    •     Create a logical system (via transaction SALE) to represent the receiver system.
    •     Configure the distribution model. From transaction SALE, use option Maintain Distribution Model to create a model view for this scenario. Specify the sender system (the base logical system for the client you are working in, such as the logical system that has been assigned to that client) and the receiver system (the logical system). After positioning the cursor on the receiver system, click on Method and enter AddressContPart in the Object Name field on the panel that pops up. Also enter SaveReplica in the Method field on the pop-up panel. Enter and save the Distribution Model (see Figure 9).
    •     From transaction WE20, create a partner profile based on the logical system for the interface. Use message type ADR3MAS and IDOC type ADR3MAS01, with an appropriate port.
    •     Activate the change pointer for message type ADR3MAS. From SALE go to Set up Data Distribution -> Master Data Distribution -> Activate Change Pointers. Ensure that change pointer generation is active at the general level as well.
    Now that weâve completed the configuration, letâs test the interface. The purpose of this test is only to create outbound IDOCs. Appropriate settings, such as port definitions and RFC destinations, can be made as required for purposes of communicating the IDOCs to the external system (or other R/3 system).
    From the Customer Master or Vendor Master screens, create or make changes to contact person address. This should result in the creation of change pointers. (Check table BDCPS for change pointer entries with message type ADR3MAS.) After this, from transaction BALE go to Periodic Processing -> Process Change Pointers, enter ADR3MAS as the message type, and execute the transaction. This should result in a message indicating the number of master IDOCs created. Use transaction WE05 to display the IDOCs.
    THE ALE AUDIT
    In this section letâs take a look at the prototyping of the ALE Audit. ALE Audit is a powerful mechanism for verifying the success of ALE transactions/messages sent to another system. As you will see, implementing ALE Audit is not only easy but also very beneficial, because it facilitates the monitoring and tracking of transactions across systems while providing an entry point into error handling.
    Program RBDSTATE is used for audit confirmation of ALE transactions between two R/3 systems; in other words, it indicates the success or failure of the ALE transaction on the target system. The program reports the status of the transaction on the target system back to the sending system. This process also serves as an interface itself from the target system to the sender system, facilitated by message type ALEAUD. In the following section, weâll look at the various steps needed to set up ALEAUD and execute program RBDSTATE.
    SETTING UP ALEAUD and EXECUTING PROGRAM RDBSTATE
    Letâs consider two different R/3 systems with base logical systems BK1CLNT010 (sender system) and BK2CLNT020 (target system). Assume that you are distributing characteristics master (message type CHRMAS) from BK1CLNT010 to BK2CLNT020. When you send CHRMAS02 IDOCs from BK1CLNT010, their status is 03 (data passed to port OK) if they were successfully externalized from the sender system. If the IDOCs were received and processed successfully on the target system, the status of those IDOCs on the target system is 53 (application data posted). Remember that you have to create a partner profile for BK1CLNT010 on the target system in order to receive the CHRMAS messages. The inbound parameters of BK1CLNT010 partner on the target system have CHRMAS as the message type and CHRM as the process code.
    You now need to configure BK2CLNT020 to send ALEAUD messages to BK1CLNT010, the sender system. And you also need to configure BK1CLNT010 to receive those messages in order to update the status of CHRMAS IDOCs sent to the target system:
    •     On the target system BK2CLNT020, configure the distribution of message flow of type ALEAUD to logical system BK1CLNT010.
    •     Create filter object using object type MESTYP with a value of the message type for which you need audit confirmation. This message type must flow from the sender, BK1CLNT010 to BK2CLNT020. In this example, the value of the filter object type MESTYP is CHRMAS, message type for characteristics master. Save the distribution model. Use transaction BD64 to do this.
    •     On target system BK2CLNT020, create an RFC destination with name BK1CLNT010. Choose the relevant connection type and enter the logon parameters and password for the R/3 system on which BK1CLNT010 resides. Use transaction SM59 to do this.
    •     On target system BK2CLNT020, generate partner profile and port definition using transaction SALE, go to Communications -> Generate partner profile. Specify the customer model as described. Check the partner profile to ensure outbound parameter entries for message types ALEAUD and SYNCH.
    •     On sender system BK1CLNT010, create a logical system for BK2CLNT020. Create a partner profile for logical system BK2CLNT020 with inbound parameters for message type ALEAUD, with process code AUD1.
    •     Distribution of customer model on BK2CLNT020 to BK1CLNT010 is not necessary.
    TESTING THE ALE CONFIRMATION PROCESS
    Now you are ready to test the ALE audit confirmation process:
    •     From the sender system, BK1CLNT010, send a couple of CHRMAS02 (characteristics master) IDOCs down to the target system, BK2CLNT020. Make sure that the status of the IDOCs is 03 (data passed to port).
    •     Check the target system for receipt of these IDOCs. Make sure that they are in a status of 53 (application data posted).
    •     Execute program RBDSTATE with appropriate parameters. Specify BK1CLNT010 for Confirm to System, CHRMAS for Message type, and date, if necessary.
    •     Upon successful execution, informational messages will be issued indicating the IDOC number and status of the ALEAUD IDOC. (Note that a single ALEAUD audit IDOC can contain audit messages for multiple application IDOCs. This capability reduces the traffic of IDOCs between the two systems and keeps the overhead of audit confirmations at a minimum.)
    •     Check the sender system for the receipt of the ALEAUD message. The status of the CHRMAS IDOCs that you sent to the target system must be changed to 41 (application document created in target system).
    This completes the test of ALE audit confirmations (see Figure 10 and Figure 11 for IDOC display of target and sender system).
    Audit confirmations can play a significant role in the reporting and monitoring of production systems. You can schedule program RBDSTATE periodically on target systems to report back to sender systems. Keep in mind that you need to maintain a sufficient time lag between the sending of application IDOCs to the target system and the execution of this audit program because the application documents need to be posted on the target system. This program can also be accessed from BALE using Periodic work -> Audit confirmation.

  • Capture Idoc numbers for outbound INVOIC02

    Hi,
    We have a requirement where we need to capture the idoc numbers before it is dispatched.
    IDOCS are populated by FM IDOC_OUTPUT_INVOIC using process code SD09 for custom output type(EDI processing).
    Our requirement is to capture these idoc numbers into a custom table which will be used for further custom processing. The user exits in the above FM are good for just for segment population.
    What is the best approach to capture these idocs? Is there a user exit to capture these idocs?
    Thanks,
    Pratik

    sorry wrong forum

  • Populating  the segments of idocs

    Hi,
        How do segments of the idoc get populated with data from SAP tables ?  (for SAP standard idoc or newly created idoc and outbound process)
    Can anyone say in details?
    Good answer will be rewarded
    Thanks ,
    Manas Behera

    For any IDOC there is a specific standard function module assigned that is called to fill the IDOC segments.
    For orders it is e.g. IDOC_OUTPUT_ORDERS.
    This function takes care of the filling of the IDOC segments. You also usually have user exits available in those function modules that you can use to manipulate the IDOC data or fill/add custom segments/fields.
    The function modules usually start with IDOC_OUTPUT_* for outgoing IDOCS and IDOC_INPUT_* for incoming IDOCS.
    Hope that helps,
    Michael

  • Populating the Conditions segment in PORDCR102-PO create IDOC

    Hi Gurus,
    Iam populating some fields in the E1BPMEPOCONDHEADER segment of the IDOC PORDCR102. But the condition record is not getting generated in the PO.
    Kindly can anyone throw some light on the mandatory fields that needs to be populated in this segment and is there any necessity to populate some other linked segments along with this segment inorder to get the condition record created.
    I am populating some fields below :
      E1BPMEPOCONDHEADER-COND_TYPE = 'ZA00'.
      E1BPMEPOCONDHEADER-COND_VALUE = '12'.
      E1BPMEPOCONDHEADER-CURRENCY = 'USD'.
      E1BPMEPOCONDHEADER-CURRENCY_ISO = 'USD'.
      E1BPMEPOCONDHEADER-COND_UNIT  = 'EA'.
      E1BPMEPOCONDHEADER-COND_P_UNT = '1'.
      E1BPMEPOCONDHEADER-APPLICATIO = 'EF'.
    Please help
    Thanks
    Venkatesh P

    you need to pass
    CONDITION_NO
    ITM_NUMBER 
    in 1BPMEPOCONDHEADER and 1BPMEPOCONDHEADERX also..

Maybe you are looking for

  • Debugging a web item when executing a web template in BI7

    Hi,   I would like some help in the following 1> Class name (or package that contains all the class/methods) when a particular SAP delivered web item get executed in a Web template in SAP BI 7.0 2> what’s the class that gets executed for an 'Analysis

  • Network topology for extending wireless range with WAP321

    Hi all, I have an WAP321 accespoint connected to my router/firewall. There are 2 SSID active each assigned to a different VLAN. Now I want to extend the range of my wireless network and looking into options. Adding another WAP321 is the first thing o

  • No contract connectivity?

    Have iphone 4s contract with Voda, wifi is fine but do not seem to be able to connect to contract internet. Is there an issue with the phone?

  • Updating to iOS 6 Bricked my device!!

    I tried to update to ios 6 from ios5.In the middle it showed error 23 and my device stuck in DFU or Recovery mode. I tried everything wrote on apple support uninstall security softwares, chage USB port etc. Then I Tried to restore to iOS 5 but then i

  • Playlist order - i can only get it in alphabetical order

    when i set up itunes on my pc i can only get the playlist SONGS in alphabetical order, either descending or ascending. is there a way that i can place my individual playlist songs in any order i want? thanx