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:
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.
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.
Here the entire coding of ZRBDMIDOC: