Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
serdarulgen
Discoverer
INTRODUCTION

We utilize ChangePointer in SAP to mirror changes in main data (customers, vendors, materials) visible to other clients listed in the customer distribution model through ALE/IDOCs. ChangePointer is based on a change document technique monitoring alterations in essential documents such as materials, customers, vendors, and sales orders. Modifications in a document are logged in the CHDHR table, and additional change markers for ALE-related changes are written in the BDCP table. The BDCPS table stores the status of processed or unprocessed modified documents. SAP maintains change documents for various objects including materials, customers, invoices, and bank data to track audits of changes made within an object. Each change document object represents a set of tables recording the changes. For example, a change document for material master data, named MATERIAL, includes various tables like MARA and MARC. When an application process makes a change in an object, it writes change documents stored in CDHDR and CDPOS tables for each modification.

STEP 1: SCDO

Execute the SCDO transaction to view a list of change document objects and their tables. The Shared Master Data (SMD) tool writes change markers. When a change is made in an object, the SMD tool checks ALE settings and refers to the ALE distribution model to determine if the receiver is interested in the changed object. If a suitable recipient is found, the system creates a changepointer in the BDCP table, indicating changes documented in the CDHDR table. ALE programs analyze changepointers and generate IDocs. SAP provides standard function modules that read the changepointer table and generate IDocs for modified objects. These programs are designed to ignore multiple changes, creating only one IDoc. For example, if a material is changed four times before the function module is called, only one IDoc containing the latest data from the material master is generated. These function modules are called by the standard program RBDMIDOC. This report's selection parameters allow specifying the message type for analyzing change markers. To enable master data distribution based on changes in the Configuration Object, the following configuration steps should be applied. For our example, we selected the object related to customer changes.


 

STEP 2: BD61

This option enables the general change marker function. If it's not active, it should be activated.


 

STEP 3: BD50

In this step, we need to activate the IDoc types suitable for our ChangePointer functions. For customer master data, we have activated the DEBMAS IDoc types.


 

STEP 4: BD52

For standard main data objects like materials, customers, and vendors, SAP already provides a list of fields where changepointers are written. If you are satisfied with the standard field group, this step can be skipped. If you want to add new fields, you need to enter the required fields. If you are not interested in creating IDocs for changes in a specific field, you can remove it from the list. For example, if you do not wish to distribute the material master list for changes in the Catalog Profile (RBNRM) field, you can delete this entry from the table.


 


 

STEP 5: SE38

Run the RDBDMIDOC program to initiate an IDoc creation process. Specify the message type on the selection screen, such as MATMAS. After executing, it displays the number of processed entries.

Note: Typically, this program is set up as a job to run frequently and start creating IDocs for various message types.

 

STEP 6: WE02

Use this to check the status of IDocs.

-----------------------------------------------------------------------------------------------------------------------------------------------------------

To ensure the proper functioning of the established ChangePointer, it's necessary to complete the logical destination steps, which include:

STEP 1: BD54

A logical destination name is assigned.


 

STEP 2: WE20

A logical destination profile must be defined. Here, we adjust the partner type according to our needs, placing it under 'LS'. We also add our IDoc preferences in the output parameters.


 

STEP 3: BD64

Distribution and filtering settings are created for the established logical destination.


 

Subsequently, after the job setup and the changes made, IDocs are triggered.


 


 

Thus, with the logic of ChangePointer, changes in the main data can be sent to external systems without the need to create a program.

You can contact us if you have any questions.

 

Serdar Ülgen
1 Comment
Labels in this area