Change Pointers -- HRMD_ABA message type

Hello, there..
I'm using for a while with the message type HRMD_ABA in order to transfer organizational data from one system to another via Idocs and It works fine.
Recently we had defined 2 new infotypes & added them in BD64 transaction (distribution model).
In spite of the changes mentioned above, updates with the new infotypes of an organizational objects such as positions don't create the change pointers.
It must be somthing I forgot.
Does anyone have an idea what I suppose to do ??
Thanks in advance,
R.R.

dfgd

Similar Messages

Problem in BD64 for HRMD_ABA message type

Hi,
Iam using HRMD_ABA Message Type in distribution model(BD64).
My requirement is that i want to add status of the employment in the Filter Group.
i.e.: in BD64 transaction>under HRMD_ABA>data filter active>filter group>infotype-->(will be 0000)
-->Object type(Will be 'P' for person)
Now where i will put status value as '3'.....?
Thanks in advance..
Regards.

HI,
it seems you have to add new filter objects.
Check tcode BD95 and BD59 to add new filter objects.

How to chang the idoc message type

Hi,
I want to change the idoc message type...because the idoc has the status 51...pls advice how to change
I have tried it from we81 .......but i cant open the msg type ...when i double click on it.
Regards,
Somenath

Hi,
This may help u
Steps To Create Custom IDOC
1.Create Segment Type (WE31)
Go to Transaction code WE31
Enter Segment type, click on Create
Give Description
Enter the Necessary Fields & Data Elements for those Fields.
Save the Changes.
2.Create Idoc Type (WE30)
Go to transaction code WE30
Enter the Object Name, select Basic type and click Create icon
Select the create new option and enter a description for your basic IDOC type and press enter
Select the IDOC Name and click Create icon
The system prompts us to enter a segment type and its attributes
Choose the appropriate values and press Enter
The system transfers the name of the segment type to the IDOC editor.
Follow these steps to add more number of segments to Parent or as Parent-child relation
Save it and go back
Go to Edit -> Set release
3.Create Message Type (WE81)
Go to transaction code WE81
Change the details from Display mode to Change modenAfter selection, the system will give this message u201CThe table is cross-client (see Help for further info)u201D. Press EnternClick New Entries to create new Message Type
Fill details
Save it and go back
4.Assign Idoc Type to Message Type (WE82)
Go to transaction code WE82
Change the details from Display mode to Change moden After selection, the system will give this message u201CThe table is cross-client (see Help for further info)u201D. Press Enter.
Click New Entries to create new Message Type.
Fill details
Save it and go back
Regards
Seshagiri

Activate change point for message type - message type FIDCC1 not in list

I want to set up idoc for sending entire FI documents.
For this I want to use the change points in the message type FIDCC1 but this message type is not in the list of transaction BD50 (neither if I go via SALE)
I'm not allowed to add it myself, I get a warning the name is not in the namespace (Zxxx or Yxxx).
Is there a way I can add this message type in this list?
-> change points are generally activated
-> ECC 600
edit: I see the message type is in WD81
Edited by: Renaat Vanhaverbeke on Apr 28, 2010 11:05 AM

I found the solution: when I tried to add the message type in BD50 I got the warning the name does not match the namespace rules. But by opening the Performance Assistant I could start the transacion RDDKOR54 to display the namespace rules.
By exiting this transaction I got the question if I want to bypass the namespace check and by answering positive on this I could save the new entry.
PS: I also found that alle message types are defined in table EDMSG

It is possible to change any warning message type to error message type?

Dear All,
Kindly do your need full efforts to solve this problem;
For T code iw32, material avaibility checks works but it gives warning message as per error message required at this point.
It is possible to change that message 281 i.e. Order & has missing parts to an error message rather than a warning message.
Kindly provide your valueable suggestions regarding it.
Do tell about any badi or echancement spot or user exits where error message can be incooperated.
Thanks in advance.
Regards,
MAA

Dear Rohan,
Problem not facing problem due to any code, i think u r not getting wht i am saying.
Let me explain in detail.
While creating order from t code iw31, material avability checks works and it is working fine and generating a warning mess in case of out of stock case. Requirement is to transform that warning mess to error mess.
Just need to know how can i change standard warning mess to error mess so that error mess displays in place of that warning mess.
Kindly suggest its solution for it .
For any query free feel to contact.
Thanks.
Regards,
MAA

Transfer Custom OM Infotype data through ALE for HRMD_ABA Message type

Hello Folks,
I have created a Custom OM Infotype.When i run the PFAL transaction. All the standard infotype data is getting filled, but i dont see custom infotype data getting filled.
Example: HRP9001 is the custom infotype.
Please let me know the step by step process to populate the Custom infotype data in ALE Transfer.
Thanks & Regards,
Nishanth Kumar

I think function module RH_MASTER_IDOC_DISTRIBUTE_HRMD shows some odd behaviour. It calls EDI_DOCTYPS_OF_MESTYP, which returns the name of the extension in an internal table named "doctyps". But later on, function module MASTER_IDOC_DISTRIBUTE is called with a structure "f_idoc_control". In this structure, the field "cimtyp" should hold the name of the extension, but it NEVER gets filled, although the value is present in doctyps-cimtyp.
So what I have done, is to activate userexit #004, which is called just before MASTER_IDOC_DISTRIBUTE and modifies structure f_idoc_control, if desired.
Call transaction CMOD and create a project in a non-SAP namespace: Zxxxx. The enhancement we need is "RHALE001" (HR-CA: Enhancement for ALE functionality in HR). One of its components is EXIT_SAPLRHA0_004, which consists of include ZXHALU08. In this include I called EDI_DOCTYPS_OF_MESTYP again to fill f_idoc_control-cimtyp.
Here is my code for include ZXHALU08
DATA: z_doctyps TYPE STANDARD TABLE OF edidocs WITH HEADER LINE.
CALL FUNCTION 'EDI_DOCTYPS_OF_MESTYP'
EXPORTING
    mestyp         = f_idoc_control-mestyp
TABLES
    doctyps        = z_doctyps
EXCEPTIONS
    invalid_mestyp = 1
    OTHERS         = 2.
IF sy-subrc = 0.
LOOP AT z_doctyps.
    f_idoc_control-cimtyp = z_doctyps-cimtyp.
ENDLOOP.
ENDIF.
Hope this helps

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 Needed

Hi All,
Please give me a scenario to expalin about change pointers.
Regards,
Srik

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 points hope this helps u,

Change pointers problem

I have created message type ZMATMAS and I want to see an entry in BDCP2 (Change pointers table)
when ever any material is created or changed
I did following steps until now.
1. Created ZMATMAS
2. Activated change pointers - BD61
3. Activated change pointers for message type - BD50
What else I've to do?
Thanks in advance..

Hi,
Visit this link for more details on Change pointer.
http://help.sap.com/saphelp_nw04/helpdata/en/12/83e03c19758e71e10000000a114084/content.htm
also i will tell you in short about what next to be done...
To be able to activate the writing of change pointers via the SMD tool for your master data object, you must carry out these steps:
·        Activate change pointers for each message type
·        Maintain change-relevant fields for message type
·        Activating change pointers generally
You also have to:
·        Implement function module for evaluating change pointers
·        Defining the ALE object type MSGFN as a filter object type
NoteIf you distribute master data using a asynchronous BAPI, all the settings below apply to the generated message type of the BAPI-ALE interface.
Thanks and Regards
Anup

When transferring HR data from ECC to CRM via change pointers

When transferring HR data from ECC to CRM via change pointers ,certain data is getting earsed in CRM
paricularly the last name and first name of BUT000
Do you have any idea why this could be happening
Thanks in advance

Hi Kittu,
Change pointers. Change pointers are R/3 objects that mark changes to SAP master data. Change pointers are managed by mechanisms in a Shared Master Data (SMD) tool and are based on Change Document (CD) objects. CD objects record the changes occurring to master data at a field level. These changes are stored in tables CDHDR (header table) and CDPOS (detail table). ALE configuration provides a link between CD objects and change pointers. Internal mechanisms update tables BDCP and BDCPS, which host the change pointers. While CD objects are application-data-specific, the processing status of change pointers is message-type-specific. Also, the ALE change pointers are activated first at a general level and then at the message-type level.
use this links kittu.
http://help.sap.com/saphelp_nw04/helpdata/en/ab/27bde462848440ba70cf8eb348c86f/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/0f/9d563cf19bcb43e10000000a11405a/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/ab/27bde462848440ba70cf8eb348c86f/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
Creating a change pointer and subsequently triggering an IDOC
thanks
karthik

Restricting Message type to 1 receiver-ALE

Dear All
We are using ALE scenario where we ALE idocs from Finance box to HCM box. I am using searlization method for message type and generating idocs from change pointers using program RBDSE01.
One of the message type (CREMAS) is being used in more than one distribution model. The issue is when idocs are generated from change pointers, multiple communication idocs are generated as message type is maintained in more than one distribution model. Is it possible to restrict idocs generated fro change pointers to one receiver?
I have defined distribution model and have added message type SERDAT for searlization. Further filter object(searlization group) is added to this message type. program RBDSE01 is run for this searlization group.
Can someone please help?
Thanks
Sanjeev

Hi Sanjeev,
I can only give you hints as I do not recall the whole procedure exactly
In the easy acces menu go to Tools -> ALE -> IDoc
1. IDoc Type Development -> Logical Messages
2. IDoc Type Development -> IDoc Type for Message
3. Relationships -> Define Link Object Type for Message Type
4. Relationships -> Assign Link Object Type to IDoc Field
5. Relationships -> Assign Business Object to Message Type
6. Engineering Change Management -> Define Change-Relevant Fields
7. Engineering Change Management -> Define Function Module for Evaluation
In all these steps copy the customizing of the original message to your zmessage.
Go to transaction sale:
Modelling and Implementing Business Processes -> Master Data Distribution -> Replication of Modified Data
8. Activate Change Pointers for Message Types (here you need to add your z message)
9. Switch Change Pointer Storage
After that you should be able to run your first test.
Please let me know whether it worked or whether I missed something.
Best of Luck
Andreas

ALE Change Pointers in source system not active

Hi All,
I am trying to load 0COSTELMNT using deltas. The initial load is OK and then i use a delta and it fails and i get the error:
"ALE Change Pointers in source system not active"
I have carried out the following steps in an attempt to resolve the problem - but it didnt. Anyone have any advice??
(1) Checked BD61 to confirm whether the change pointers are active
(2) Checked BDCP to confirm the number range is maintained
(3) Checked SALE (Activate change pointers for message types) to confirm whether the change pointer has been activated for the type we need:
COCOKA Control segment CO object/cost element
COELEM Cost element master data
(4) In transaction snum, Selected number ranges and confirmed the intervals are setup
No. 01
FROM: 0000000001
TO: 0000009999
(5) Activate transfer structure
(6) Replicate Datasources
Thanks,

If you are transferring master data from source system, the BD61 setting on the source system should be checked.
Why it has been unchecked - not sure (likely someone did it by mistake).
It shouldn't have any effect on txnl delta. What will be effected though is that you will have lost delta of the ALE based data sources for the period this setting was unchecked.

Need to createchange pointer with a different Message type

Hii
Existing Scenario :
when i do some changes to the material characteristics through a z- transaction change pointers are created in the tables BDCP and BDCPS with message type ZVCRUMAT
Required Scenarion :
Now when i change the material characteristics i need change pointers to be created with message type ZMATCHG .
Where should i do the changes to get this done .Please help .
Thanks and regards
Ramakanth Akunury

Hello,
First activate change pointers for message type ZMATCHG using BD50. Then identify the fields for creating change pointers using BD52.
Thanks,
Venu

Do we need the change pointers to be set..

do we need the change pointers to be set/activated
if we are to send data via TRFCs

Change Pointers:
-Change documents are working based on change document technique which
tracks changes made to the key documents (Material Master, Customer
Master, Vendor Master ..etc) in SAP.
-Changes made to the keydocuments are recorded in the change document
Header table i.e. CDHDR and Item table CDPOS,   Additional change
pointers are written in the BDCP and BDCPS tables.
-Change pointers technique is used to initiate the outbound process
automatically when master data is created or changed.
-A standard program RBDMIDOC is sechuled to run on periodic basis to
evaluate the change pointers for a message type and starts the ALE
process for distributing the Masterdata to the appropriate destination.
-'Object' is collection of fields of different database tables. T.code
for creating an object is SCDO.
Configuration for Change Pointers:
1. BD61 Active change pointers generally
     - Check the checkbox "Change pointers activated -generally"
     - Save it
2. BD50 Active change pointers for Message Type
     - Message Type           Active
        MATMAS           check the check box
3. SCDO Change Document Objects
     - Check whether the "MATERIAL" is available in the object list.
4. BD52 Maintain Table Views
     - Enter the Message type "MATMAS" and press enter.
     - OBJECT      TABLE NAME     FIELD NAME
   Ex:    MATERIAL      MARA          BISMT
5. BD60 Additional data for message types
        - Message Type           Function Module          Table
   Ex:       MATMAS     MASTERIDOC_CREATE_SMD_MATMAS     MARA
6. WE20 Partner Profile
7. BD64 Distribution Model
8. Create a Material by using T.Code MM01
9. SE38 Run the program RBDMIDOC by passing Message type "MATMAS"
10. WE02 IDOC List
Regards
srikanth

Help With IDOC Change Pointers

Hi guys,
I'm trying an IDOC to file scenario. The scenario is working fine. I have activated change pointers for my IDOC. My understanding was that if there will be any change in my master tables, then because of the activated change pointers, the IDOC will be generated automatically. But in my case, for eg if i'm inserting any new record say Vendor data, no new IDOC is generated. For sending IDOC i have to use bd14 to send my IDOC explicitly.
Is my idea of change pointers wrong???Or am i missing some setting, so that the IDOC should be generated automatically???
Please help me on this guys...
Regards
Varun

Automatic generation of IDOC when we change the MASTER DATA:
Change Pointers:
Change documents are working based on change document technique which
tracks changes made to the key documents (Material Master, Customer Master,
Vendor Master.Etc) in SAP.
Changes made to the keydocuments are recorded in the change document Header
table i.e. CDHDR and Item table CDPOS, Additional change pointers are written
in the BDCP and BDCPS tables.
Change pointers technique is used to initiate the outbound process automatically
when master data is created or changed.
A standard program RBDMIDOC is sechuled to run on periodic basis to evaluate the change pointers for a message type and starts the ALE process for distributing the Masterdata to the appropriate destination.
'Object' is collection of fields of different database tables. T.code for creating an object
is SCDO.
Configuration for Change Pointers:
1. BD61 Active change pointers generally
 - Check the checkbox "Change pointers activated -generally"
 - Save it
2. BD50 Active change pointers for Message Type
Message Type Active
MATMAS Check the check box
3. SCDO Change Document Objects
 - Check whether the "MATERIAL" is available in the object list.
4. BD52 Maintain Table Views
- Enter the Message type "MATMAS" and press enter.
For example
OBJECT TABLE NAME FIELD NAME
MATERIAL MARA BISMT
5. BD60 Additional data for message types:
For example:
Message Type Function Module Table
MATMAS MASTERIDOC_CREATE_SMD_MATMAS MARA
6. WE21 Port
7. WE20 Partner Profile
8. BD64 Distribution Model
as michal said we have to use RBDMIDOC program.for executing this program we need to give message type like
MATMAS or
DEBMAS or
CREMAS
depending on your requirement.
go to SE38 tcode
--- copy RBDMIDOC to zprogram(i'e., ZRBDMIDOC)
---create variant
use this zprogram(ZRBDMIDOC) in BACKGROUND SCHEDULING SM36
STEPS IN BACKGROUND SCHEDULING:
Use tcode SM36
Click Job wizard in the button set
Click Continue
Enter Job name and press continue
Select ABAP program and press Continue
enter Program name and press continue
and again press Continue
set Schedule type immediately and continue
Select periodic job checkbox, press continue
Select none of the above and click on other periods give one-minute and then press create
Press continue and then press complete.
recently i did this requirement
if u have any doubts plz let me know
Best Regards,
Srikanth
Reward the useful answers and you will get one point yourself

Change Pointers -- HRMD_ABA message type

Similar Messages

Maybe you are looking for