Skip to Content

Distribution of full master data objects from change pointers

For many master data objects’ distribution SAP provides two level approach:

a) at first you send a whole master data objects

b) send changes (delta info) only using change pointer technology

This approach works for most of the “typical” master data like Materials, Vndors, Customers. Once you send a whole object only the delta information will be distributed. As far as the receiver is an another SAP system everything seems to be fine but in reality most of the third party systems cannot handle delta information and they expect the whole master data object even if only one parameter got changed. What are the options with SAP then?
Let me present a short description of a few possibilities on the basis of a most common master data object – Material.

1. Manual transfer – For sending initial Material Master IDoc you use transaction BD10 (after you configure a distribution model and partner profiles). It would be possible to run the same transaction everytime any material gets changed. The main drawback would be manual action which is required in this scenario. If you’d like to schedule BD10 somehow then all materials would be send each time and in cases there are thousands of hundrets of thousands of materials this is not the most efficient way.

2. User exit transfer – usually there are many user exits for master data maintanance transactions but some of them have a user exit during the save event. Such an exit can be used to invoke transaction for sending master data like BD10 with a specific material numer.

3. Change pointer “trick” – in standard change pointer technology allows sending delta information only so if you change one field in any master data object only this particular field will be distributed as an IDoc. Fortunately there are ways this can be changed even without doing any modifications/repairs to the SAP standard. With the introduction of Implicit Enhancement Options in ABAP Source Codes we can now change the part of code which is responsible for master data distribution to force sending only whole master data objects. One of the places in which an Implicit Enhancement can be added is at the end of a function module – check out  <br />The module that we need to change is – CHANGE_POINTERS_READ and the code which can be added at the very end of this module is shown below:   <br /> </p><table border=”0″><tbody><tr><td>FIELD-SYMBOLS <fs_bdcp> TYPE bdcp.<br />checking for correct IDoc message type as we only <br />want to distribute material master data in this way

You must be Logged on to comment or reply to a post.
  • hi,

    >>Do you know - is it possible to use this trick in user exits for IDOCs other than MATMAS (for ex CREMAS/DEBMAS)?

    if the IDoc uses change pointer technology
    then it's probably possible but you need to check if the module in which I do this change it used
    but I guess it should work 🙂

    Michal Krawczyk

    • Hi Michael,<br/><br/>I just tried this for CREMAS and entered the code as decribed.  I also put a breakpoint in the enhancement to make sure the code gets executed and it did.<br/><br/>However, the IDOC was only partial.  It did not contain all the data for the vendor.<br/><br/>Any idea?<br/><br/>This is my code:<br/>"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(2 ) Function Module CHANGE_POINTERS_READ, End                                                                                D<br/>$$-Start: (2 )--

      $$<br/>ENHANCEMENT 1  ZSEND_COMPLETE_CREMAS_IDOC.    "active version<br/><br/> Need to send complete IDOC everytime a Vendor is changed otherwise XI mappings will fail.<br/>FIELD-SYMBOLS <fs_bdcp> TYPE bdcp.<br/>checking for correct IDoc message type as we only<br/>want to distribute vendor master data in this way<br/>if MESSAGE_TYPE = 'CREMAS'.<br/><br/>loop at change_pointers assigning <fs_bdcp>.<br/><br/>      <fs_bdcp>-FLDNAME =  'ALELISTING'.<br/><br/>endloop.<br/><br/>endif.<br/><br/>ENDENHANCEMENT.<br/>$$-End:   (2 )--


        • Hi Michal & Gustavo

          I am using DEBMAS and for change pointer, i need to populate all segments, but after implemeting the code at the end of FM- change_pointers_read, i am not getting all segments.

          Please help in this regard


  • Micheal,
    awesome blog and thanks for this trick. We both know that this is (now was 😉 ) a main problem while distributing Master Data to NON SAP Systems.

    BTW: The "MDM Extractor" can be customized like the "change pointer trick" 😉

    Kind Regards,

    • hi,

      >>To achieve this functionality I have written all sorts of code in many exits,

      that's the point to have it all in once place
      and not in many exits:)

      thank you for reading 🙂

      Michal Krawczyk

  • Hello Artem,

         Did you check the possibility of this for other IDocs. Because, we need to do it for CLFMAS, but it seems it's not working. Can you confirm whether it had worked for you for other IDocs?


  • Hi there,

    We're implementing HRMD_A using change pointer, but I would like to know how we can enhance the change pointer to just send those changes in the infotype that are current and not send the ones that are future dated.

    For example:

    A user created a change in Infotype 1 that is going to be effective 1 week later. When BD21 is run we dont want the IDoc to be created until the system date is the same as the date in the actual data saved in the change pointer.

    Is this possible.


  • In the implementation of BADI BDCP_BEFORE_WRITE (SE18) you can add the following code to send more than the infotype that is changed:

    data sytabix        type sytabix.
    data r_infty type range of infotyp.
      append 'IEQ0000' to r_infty.
      append 'IEQ0001' to r_infty.
      append 'IEQ0002' to r_infty.
      append 'IEQ0105' to r_infty.
    * the infotypes you want to send

    loop at change_pointers into wa_bdcpv where mestype = 'ZIAM_HRMD_A'.
        sytabix = sy-tabix.
        if wa_bdcpv-tabkey+12(4) = '0000' or wa_bdcpv-tabkey+12(4) = '0001' or wa_bdcpv-tabkey+12(4) = '0002' or wa_bdcpv-tabkey+12(4) = '0105'."changepointers van deze infotypes wel verzamelen

          submit rhaleini
                  with pchplvar = wa_bdcpv-tabkey+0(2)
                  with pchotype = wa_bdcpv-tabkey+2(2)
                  with infty in r_infty
                  with insert = space
                  with mestyp = 'ZIAM_HRMD_A'
    *        with pchactiv ...
    *        with pchbegda ...
    *        with pchcuttr ...
    *        with pchdepth ...
    *        with pchdymod ...
    *        with pchendda ...
    *        with pchistat ...
    *        with pchobeg ...
                  with pchobjid-low = wa_bdcpv-tabkey+4(8)
    *        with pchoend ...
    *        with pchopera ...
    *        with pchostat ...
    *        with pchotype ...
    *        with pchplvar ...
    *        with pchseark ...
    *        with pchsetgd ...
    *        with pchsobid ...
    *        with pchsvect ...
    *        with pchtimed ...
    *        with pchwegid ...
                  with pchztr_a = 'X'
                  with pchztr_d = space
                  with pchztr_f = space
                  with pchztr_m = space
                  with pchztr_p = space
                  with pchztr_y = space
                  with pchztr_z = space
    *        with proof ...
    *        with psize ...
    *        with rcvprn ...
    *        with rfcgr ...
    *        with snd_orig ...
    *        with subty ...
                  with update = 'X'
                  and return.

          delete change_pointers index sytabix.

          delete change_pointers index sytabix.

    • Heoneveld,

      Your solution does not address Ricky's issue. It will not restrict the future dated changes. The question is how would you restrict BD21 to skip a particular change pointer whose BEGDA is greater than sy-datum? I don't think BAdI BDCP_BEFORE_WRITE can be used to do this. Any ideas?



  • Hi,

    I have the same problem described in the previous comments (distribute the whole idoc, even after changes, for both materials and BP).

    The article linked by Michal Krawczyk is no more available.

    Can you please help me to understand the best solution to provide?


    Thank you