Reduced Change Pointers?

Hi,
I have to implement reduced change pointers to MATMAS. ie my requirement is that change pointers will write only for some plants specific materils and not for all materials. So i have implement the badi BDCP_BEFORE_WRITE and used the method FILTER_BDCPV_BEFORE_WRITE.
I like to know is there any other way we can do the same functionality ?
a®s
Edited by: a®s on Dec 19, 2007 9:41 AM

Hi,
The filter can also be applied in BD64 on MARC-WERKS , but the pre-requisite is that the IDOC should always have this segment, then only it will work.
For MARC-WERKS to be available in BD64 , an entry for same should be available in BD59 againest the message type.
BADI 'BADI_MATMAS_ALE_CR' also serves the same purpose of filtering.
Can u tell me how you have appplied the filter at plant level in your BADI i.e. the exact code .. ??
This is required for me since I have put the filter at IDOC generation level , and by using your BADI I can do the same at change pointer creation level itself ....
Thanks in advance
Regards,
Tushar

Similar Messages

Query for Outbound Processing through change pointers

Hi,
I have a reduced Message type for HRMD_A07, for which change pointers are activated. So whenver the changes are tracked, it sends all the changes into 1 IDOC. My requirement is to send Employee wise single IDOC, rather than collection of all the changes at once.
Any inputs would be helpful.
Regards,
Heena

Hi
Since change pointers are specific to the fields based on the change documents for that so i dont think that you may get the Idoc details based on the emplyee.
1.To get the desired ouput we have to either schedule the program RBDMIDOC for lesser intervals of time so that it can collect the data regularly.
2.Based on the chages updated in CDHDR or CDPOS we have to update the details in the user exits for the outbound process code.
3.Else you collect the changes from CDHDR and CDPOS employee wise and manullay populate the idoc.
Thanks & Regards
Jyo

IDOC HRMD_A + Change pointers + Infotypes change objects doesnt exist???

Hi guys,
I Have to send master data from infotypes 0002, 0006, 0032 and 0105 from HR to SAP PI. I've configured BD61, BD50 and BD53 to reduce Idoc HRMD_A. Then in BD52 I've tried to put this fields to activate change pointers when data from this infotypes is changed.
But in BD52 doesnt exist infotypes 0002, 0006, 0032 and 0105. I tried with object HR_IT1002, table HRP1002 and fields BEGDA and ENDDA, then run program RBDMIDOC and the Idoc is sent, but is possible with infotypes metioned????
Regards,
Pablo

Pablo,
are you able to see entries getting created in BDCP* tables
did you activate change pointers in BD53
Thanks
Bala Duvvuri
Edited by: Bala Duvvuri on Jul 29, 2010 10:35 AM

Regd. change pointers and notifications

Hi,
The question might sound a little too broad.
But bear with me...Just give me a brief overview,
of how do I go about using change pointers....
Just correct me if I am wrong.
We create a change document object in the system, or use an existing one. About pointers I am not sure.
Then, through SPRO and ALE we activate the change pointer for some message type. then....??

Hi,
I haven't done this in a while, so please check my answer!
1) You activate change pointers in general in one transaction (I think it was BD61, but I'm not sure)
2) Then you activate them for certain master data (i. e. material, customer, ...) in another transaction which I don't recall atm.
3) Every time one of those master data objects is changed, the system generates a "change pointer", which you can basically just think of as an entry in a transparent table, which includes the type and key of your master data object (such as e. g. the material number).
4) You plan a background job which will go through those change pointers and which will generate a master IDoc (e. g. MATMASxx) for this data object. The change pointers are then reset (i. e. every item will only be sent once).
5) Depending on your ALE customization this master IDoc will be sent to a remote system.
You can refine this scenario using quite a bunch of different techniques. One of them is filtering (e. g. only materials with a certain material group, or based on classification etc.). Other options are reducing the Master IDoc, e. g. sending only relevant data instead of the whole master IDoc. There are even a few customer exits, if that doesn't suffice.
Hope that helps (please reward me if it does)!
Regards, Joerg

Change Pointers and Recovery Index

Hi,
Please give me any more details/docs/links about the Recovery index,indexing and Change Pointers.
Is there any configuration needs to be done for change pointers and indexing.
Regards,
Krishna

hi,
can you provide some more details.
which change pointers (and (reduced) message typesdo you mean?
regards,
Ralf

Change pointers in ALE/IDOCs

Hi guys,
Can any let me know step by procedure to implenent change pointers using IDocs including ALE settings as i am new to this concept.
Any step by step example will be helpful. useful answers will be rewarded.
Thanks in advance.
Regards,
vinay

Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
To generate the IDOCS in case of change pointers we need to use the standard report
RBDMIDOC
we need execute the follwing t.code
BD61:to activate the change pointers globally
BD50,BD52: to activate message types ,and to enable the fileds for change pointers
Hope this link will help you regarding Change Pointer...
http://help.sap.com/saphelp_erp2005vp/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
Change Pointer Configuration and extraction in HRPay.
Infotypes to be logged are in:
V_T585A,
V_T585B,
& V_T585C
Please view the table contents to understand the structure of these tables and how they are linked. These help you identify the cluster tables which store the data.
Payroll Cluster Table PCL4 contains the cluster table reference. (Please refer to the table structure below:
Payroll Custer Tables
http://www.planetsap.com/HR_ABAP_payroll.htm
Cluster tables combine the data from several tables with identical (or almost identical) keys into one physical record on the database.
Data is written to a database in compressed form.
Retrieval of data is very fast if the primary key is known.
Cluster tables are defined in the data dictionary as transparent tables.
External programs can NOT interpret the data in a cluster table.
Special language elements EXPORT TO DATABASE, IMPORT TO DATABASE and DELETE FROM DATABASE are used to process data in the cluster tables.
PCL1 - Database for HR work area; (long text, etc)
PCL2 - Accounting Results (time, travel expense and payroll); (payroll results)
PCL3 - Applicant tracking data;
PCL4 - Documents, Payroll year-end Tax data (change logs, etc)
Database Table PCL4
The database table PCL4 contains the following data areas:
LA change logs (long term documents)
SA Short-Term Documents for HR Master Data
SB Short-Term Documents for Applicant Master
SRTFD (PC400) = trans class always A for master data (1) pernr (8) info type (4) modified date (8) modified time (8) seqnr (4)
Please note that for the extraction of data, you have to use the date portion of the SRTFD and not the field value AEDTM(since it is not primary key).
Naming convention for INCLUDES when defining clusters. These INCLUDES will define the work area key above and the cluster data that is returned from an IMPORT:
RPCnxxy0
n = 1, 2, 3 or 4 (for PCL1, PCL2, PCL3, PCL4)
xx = cluster ID
y = country grouping (0 for international otherwise country indicator T500L)
Description of Cluster Data using Cluster RX as an Example
The data description is stored in the include RPC2RX00 in accordance with the above naming conventions.
RPC1TX00 - Long text cluster ID in table PCL1
RPC2RUU0 - Payroll results for the US cluster ID in table PCL2
RPC4LA00 - Change log cluster ID in table PCL4
Importing Data (I)
The IMPORT command causes data objects with the specified key values to be read from PCLn.
If the import is successful, SY-SUBRC is 0; if not, it is 4.
REPORT ZRPIMPORT.
TABLES: PCLn.
INCLUDE RPCnxxy0. "Cluster definition
Fill cluster Key
Import record
IMPORT TABLE1 FROM DATABASE PCLn(xx) ID xx-KEY.
IF SY-SUBRC EQ 0.
Display data object
ENDIF.
See sample program for long text.
Importing data (II)
Import data using macro RP-IMP-Cn-xy.
Check return code SY-SUBRC. If 0, it is successful. If 4, error.
Need include buffer management routines RPPPXM00
REPORT ZRPIMPORT.
*Buffer definition
INCLUDE RPPPXD00.
DATA: BEGIN OF COMMON PART 'BUFFER'.
INCLUDE RPPPXD10.
DATA: END OF COMMON PART 'BUFFER'.
*import data to buffer
RP-IMP-Cn-xy.
*Buffer management routines
INCLUDE RPPPXM00.
Cluster Authorization
Simple EXPORT/IMPORT statement does not check for cluster authorization.
Use EXPORT/IMPORT via buffer, the buffer management routines check for cluster authorization.
rpcbdt00 - include needed for importing from database PCL4(la) (Change log cluster ID)
Please note that data for change pointers is stored at two levels: 1) Header which has the key info and 2) BELEGE which has the changed info ie. Old value and new value.
Check standard program RPUAUD00
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an application. They also remember the user name and the time when the modification took place.
The decision whether a field modification is relevant for a change document is triggered by a flag of the modified fields data element. You can set the flag with SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else than a second log file specially designed for writing the change pointers which are meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE when saving the generated change document. So change pointers are automatically written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can be set up differently, so fields which trigger change documents are not necessarily the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or selectively. This is not the case: you always turn them on selectively. The switch to turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction updates, you better use the workflow from the change documents.
Arunsri
Posts: 307
Registered: 12/3/07
Forum Points: 246
Re: change pointers method
Posted: Feb 27, 2008 11:08 AM in response to: satish abap E-mail this message Reply
hi,,
Activating Change Pointers
Use
You can activate change pointers in the HR system to avoid distributing the entire structure when you make changes to the HR-ORG model, and distribute instead only the changes that you have made.
Procedure
1. In the Implementation Guide (IMG, transaction SALE), choose Modeling and Implementing ® Master Data Distribution ®Replication of Modified Data ® Activate Change Pointers ‑ Generally.
2. Set the activation status Activate Change Pointers ‑ Generally, and save your entry.
3. Choose the activity Activate Change Pointers for Message Types.
4. Set the active indicator for the message type HRMD_ABA.
5. Save your entries.
also see this link,
http://help.sap.com/saphelp_47x200/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
http://help.sap.com/saphelp_47x200/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
Check the links below;
http://help.sap.com/saphelp_nw70/helpdata/en/f1/035c8cae3d11d3b540006094192fe3/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
Reward if useful

Change pointers for HR master data

Hi I am trying to setup change pointers for HR Master data , in relation to HRMD_A06 idoc , I did all the steps for setting up change pointers.
Transaction bd52 for my reduced IDOC shows 0 entries, When i did the same for customer master data , BD52 had some entries by itself .
I can't produce any HRMD_A06 Idocs , What am i doing wrong? Should the entries in BD52 be added manually for all the fields i need?
Any help is much appriciated.
Sudheer

Hi,
guess it's not necessary to see some entries in bd52 (it's enough to activate in bd53).
Do you have configured RBDMIDOC (otherwise no IDocs will get generated).
Or you run t-code bd21 for testing. Standard way is to run the report RBDMIDOC in a periodic background job.
A good description could be found here (p. 12):
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30139fb0-360c-2a10-1e9f-9d5417754983
Regards
Patrick
Edited by: Patrick Koehnen on Aug 12, 2008 3:40 PM

Change Pointers Issue

Hi
Pls any body can give me step by step settings to save the changes to the DB tables(Change Log)
I am trying to read change pointers for a 1) FAGL_011PC table.But when ever i change the data using T Code FSE2 the data is saving in this table but the changes are not getting saved in CDHDR/CDPOS.
Chagne Log Check Box in tech Settings I Activated.
What shouls i Do ?
Thanks in Advance
PREETI Raj

Hi,
Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
Regards,
Shiva Kumar

Change pointers to trigger the IDOC

HI
I am having a selection screen with fields to create a custom info record (transaction VD51/ VD52 )
Customer
material
salesorganisation
distribution channel
division
if we can use change pointers to determine when procedure is triggered.
Please provide the steps for that (including change document)or we need to check the CDHDR table using the following fields.
Plz suggest

Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
Reward if useful

This is regarding creation of change pointers for a particular table?

Hi to all,
Here is my requirement,
How to create change pointers for a given table.
i know that change pointers record changes of master data at field level......
here now i have to create change pointers for a given table..
how to do this,......\
regards,
swami

Configuration steps :
BD53 -> create reduced message type (use MATMAS as your reference for material master records). Select tables
BD52 -> specify fields to track (use fieldname KEY for new entries)
BD50 -> activate change pointers for new reduced message type
BD61 -> activate change ponter generally (only if not already done) Make sure if this is not already active that you deselect the default enteries in BD50 for the message types you don't care about
The view BDCPV will now contain change pointer entries for the master data that has change or been created
Use function modules
CHANGE_POINTERS_READ - read new unprocessed change pointers
CHANGE_POINTERS_STATUS_WRITE - mark change pointers as processed
Hope it helps.
Chang

Limiting the no of change pointers

Hi,
I have to send around 2 lac change pointers by using the program ZRBDMIDOC (replica of the program RBDMIDOC)
from R/3 to SRM client.
Is there any way to limit the change pointers, such that I can move them in slots, say, some 100 change pointers per single run of the program.
Please reply.
Regards,
Binay.

Hi Binay,
1) Reduce the amount of CP while writing them. Customizing (transaction BD52) and filtering (BADI BDCP_BEFORE_WRITE - use it at least to delete duplicates of the same object) may need adjustments.
2) Look at function group BD01. Function module CHANGE_POINTERS_READ_MODE_SET has sufficient documentation.
have fun!
Holger

Change Pointers - adding a new field to existing Change Document

Hi,
We have a requirement to capture the changes made to the Material object through the transaction C223. The changes to field MKAL-PRFG_F have to be captured.
There is an exisitng Change Document Object - MATERIAL. This is included in Message Type MATMAS. These are the steps we have done:
1. In SCDO - added the Z structure to the Change Document Object - Material. [Z structure contains the field MKAL-PRFG_F. Change pointer option is checked for this Data element.
2. Created a Z Message Type with reference as MATMAS.
3. In BD52 - we have listed the fields for the new Z Message Type created.
4. The Change Pointers - reactivated after the steps are done.
The changes to the field MKAL-PRFG_F through C223 Tcode are not recorded in BDCPV table.
Have we missed any steps here?
Thanks,
Pallavi

HI,
I don't think a new zmessage type is required in this case.. is the structure added to MARA table??The change document programs are there which triggers the iodcs... In SCDO transaction code , click on generation info for MATERIAL.. You will find the includes. The FM MATERIAL_WRITE_DOCUMENT creates entries in CDHDR and CDPOS, if we maintain entries in BD52 , the entries wil be written in BDCP and BDCPS tables.
Try to add your structure in MARA table as append strucre and then you can debug the IDOC from WE19 and use the FM "MASTERIDOC_CREATE_SMD_MATMAS" and then you also need to switch on Update Debugging on, to debug the changes in update FM MATERIAL_WRITE_DOCUMENT.
Please see if the change is reflected or not....
ELSE.
may be you need to create a new entry in SCDO and do all the ALE configurations for change pointers.
Please find the link for change pointers and also you can get lot of information on change pointers in SCN.
http://help.sap.com/saphelp_nw70/helpdata/EN/12/83e03c19758e71e10000000a114084/content.htm
Regards,
Nagaraj

Change Pointers not being created for HR-PA Custom Infotype

Problem Description:
We have a custom Infotype in SAP to store the data for contingent employee - Infotype 9001. Change pointers is
turned on. We are running the program RBDMIDOC to send changes to Oracle IDM using message HRMD_A. The change
detected for all infotypes except 9001. For 9001, the change pointer is not created.
The following are the current configuration details:
IDOC Extension Created to Idoc type HRMD_A07 (ZHR_EXT)
custom segment zhr_seg
Change pointers are switched on.
Change pointers switched on for message Type HRMD_A.
IDOC configuration created for Port / Process code etc.
Maintenance of view T777D - Added ZHR_SEG.
If I add the segment ZHR_SEG as a 2nd segment to Infotype 0000, I dont get a syntax error. But the changes for Infotype 9001 are not picked up.
If I add the segment ZHR_SEG as a segment to Infotype 9001, I get a syntax error - check EDI: Syntax error in IDoc (mandatory segment missing) below.
EDI: Syntax error in IDoc (mandatory segment missing)
Message no. E0072
Diagnosis
The segment ZHR9001 has the attribute 'Mandatory' in the syntax description of the basic type HRMD_A07 (customer enhancement ZHR_EXT). However, the segment is missing in the IDoc. The segment number logged in the status record identifies the item before which the segment is missing.
This error may have been triggered by an unidentifiable segment before the expected mandatory segment.
Procedure
Please check the IDoc or the syntax description of the basic type HRMD_A07 (customer enhancement ZHR_EXT).

Were you able to resolve the issue?
If yes, could you please share what was done to resolve it.
Your help will be greatly appreciated.

Change pointers in case of purcahse order

The scenario is to send data through idoc when i create/change delete certain fields in purchase order.
I hace used change pointer scenario for it
can u plz see what i have missed out in my configuration ..
Here are the steps i followed .
1) created a logical custom message us we81 .
2) created custom idoc using we 30
3) Linked custom mesage and idoc using we 82
4) Activated my custom message using bd50 .
5) Assigned fields to message using bd52 ie
Einkbeleg EKKO waers , EKPO-netpr ..etc
6) Assigned cutom message and custom function module
(z...smd_custommsg) via bd60
7) tried to execute the message using BD21 ..
Now the issue is that entries are being created in change document table(cdhrd/cdpos)
but no entry in BDCP/BDCPS..
please give your valuable inputs to it
Thanks In advance

hi,
You can acheive this by writing a custom program.
in the program you need to use function module 'CHANGE_POINTERS_READ' for reading the change pointers.
Give document object class as the object name in bd52 and give read_not_processed_pointers as 'X'.
Looping at the output table and using function module CHANGE_POINTERS_CREATE_DIRECT you can create an entry in bdcp table for the respective purchase order.
After this you can use SUBMIT rbdmidoc WITH mestyp = message_type AND RETURN.
Regards
Sridevi S

Creation of Idocs from the change pointers by the program RBDMIDOC

Hello,
I'm Creating Idocs from the change pointers by the program RBDMIDOC.
The IDOCS Created using the message type HRMD_A are Correct but when i try to RUN RBDMIDOC for message type HRMD_B no Data is selected for distribution.
All the customizing are similar and i presume that all the change pointers are active (BD50 and IMG->Personnel Management -> Organizational Management -> Basic Settings -> Activate change documents).
Can anyone help me with the necessary steps to create this IDOC types.
Do anyone know if the RBDMIDOC report is the Same for messages HRMD_A and HRMD_B.
Thanks in Advance,
Pedro Ferreira

If the setting is fine, there may be some code in exit or badi for program RBMIDOC. Check the Exit and BADI.
check the exit EXIT_SAPLBD11_001 and
check the badi IDOC_CREATION_CHECK.
Probably there may be some code on these exits which are stoping your code from getting generated.These are the two trigger happen once u execute the RBMIDOC program.for HR, we use RHALEINI program to generate the idoc. but even RBDMIDOC works. These 2 triggere will come with RHALEINI also.
If there is no code here, Then there is problem in the setting only.

Reduced Change Pointers?

Similar Messages

Maybe you are looking for