Skip to Content

Introduction

When I came back from my holidays one of the first issues I had to solve at work was to distribute complete IDocs for material master data generated from change pointers. Fortunately Michal Krawczyk’s The specified item was not found. hit the bull’s eye and provided the solution.

However, since we are still on SAP release 4.6c enhancement techniques are not yet available. Modifying function module CHANGE_POINTERS_READ was not an option either because we would need to dig deeply into the ALE layers.

 

Chain of Calls

We have scheduled report RBDMIDOC which generates the MATMAS IDocs using change pointers. This report does not yet generate the IDocs but is responsible for locking table BDCPS (Change pointer: Status) for the selected message type.

The report calls another report RBDMIDOX which makes a call to fm MASTERIDOC_CREATE_SMD_CLSMAS in which the change pointers are read using fm CHANGE_POINTERS_READ. Thus, the chain of calls looks like this:

RBDMIDOC -> RBDMIDOX -> MASTERIDOC_CREATE_SMD_CLSMAS -> CHANGE_POINTERS_READ

I assume you understand my reluctance against any modification better now. 

 

The Change Pointer Trick

Change pointer records are save in table BDCP. The field BDCP-FLDNAME contains the name of the field that was changed in the master data resulting in a change pointer. 

The quintessence of the trick devised by Michal is: When we change the contents of BDCP-FLDNAME to ‘ALELISTING’ the master data are transferred in its entirety.

 

The Solution (available on 4.6c, too)

Instead of changing the change pointer records dynamically at the end of the process my solution modifies the records persistently at the beginning of the process.

1. Copy RBDMIDOC to ZRBDMIDOC

In the selection-screen section of the report I just added a new checkbox parameter used to trigger full distribution.   

 

 

2. Persistently modify change pointer records on demand

In the main section of the report I added the routine for updating the change pointer records. Note that finally the standard report RBDMIDOC is executed.

 

This routine does the same as already described by Michal except that the changes are persistent in the DB table.

 

The following screenshot shows the different selection-screens of the standard and the Z-report:

 

Summary

The advantages of the solution described above are:

  • The functional difference between standard and Z-report is highly visible to the user by just looking at the selection-screens. If the flag is unmarked the Z-report just executes the standard report.
  • There is no need for any user-exit or modification (I subsume “enhancements” under modifications…).
  • The solution can be implemented on older SAP releases (e.g. 4.6c). 

 

Admittedly the direct DB update is “bad” programming but at the end of the day that is how we wanted the change pointer records to look like.

 

Conclusion

Before rushing towards user-exits or modifications (and enhancements) twist your solution around and see it from a different angle. You may come up with a tiny little “plug-in” that you can put on top (or ahead) of the standard and whose function is obvious to the user.

 

Appendix

Here the entire coding of ZRBDMIDOC:

To report this post you need to login first.

7 Comments

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

    1. Mich micheal
      Hi Michal,

      Can you tell us how to distribute for other Message Types like DEBMAS, CREMAS etc.

      It didn’t work for other Message Types.

      Can you give us your inputs or solutions.

      Thanks

      (0) 
  1. Manish Garg
    Hi Uwe

    Excellent blog, but just wanted to point out that changing the fieldname to ‘ALELISTING’ works just for Material master. It doesnt work for Vendors or Customers.  Also now we can use the new change pointer table BDCP2 for the message types we want, thus the code is not going to be generic.

    I will put what we did for Customers/ Vendors  / Articles ( Material ) in a single program to achieve the same functionality without using the direct DB update.

    (0) 
    1. Uwe Schieferstein Post author
      Thank you for pointing out this restriction. Actually I did not test my solution for any other message type because we did not have such a requirement.

      I’ll keep my fingers crossed that we will be on ERP 6.0 next years as well (like several other Lindt companies) so that we can use the latest available features.

      Regards
        Uwe

      (0) 
    2. Edward Bullen
      Hi Manish

      I am currently trying to do something equivalent but for Customers using DEBMAS, and have found (as you pointed out) that this solution does not work.

      Have you found an alternative solution?  Can you suggest a way I can force the whole DEBMAS message to be generated?

      (0) 
      1. Martin Schmid

        The idea of updating the change pointer table (now BDCP2) is still good. Even though enhancements are very popular nowadays I prefer this transparent solution.

        To send full DEBMAS IDOCs my report updates the BDCP2-CDOBJCL from “DEBI” to “DEBITOR”. Afterwards the function module MASTERIDOC_CREATE_SMD_DEBMAS will “resend” complete IDOCs. Read there from line 734.

        Unfortunately, we did not find out how to make the system create BDCP2 entries with object class “DEBITOR”. Does anybody know how to achieve this?

        Regards,
        Martin

        (0) 

Leave a Reply