Deactivate change pointers check from a program
Hi,
I am using hr_inoftype_operation and the change pointers are turned on,whenever I am creating a infotype the idocs are getting updated with the changes. Is there a way where I can turnoff the change pointers from my program.
Thanks
vick
This is a duplicate thread
Hello Vivk , Go to Transaction SALE and follow the path
Modelling & Implementing BP --> Master Data Distribution --> Replication Of MasterData -->Activate Change Pointers for Message Type .
Uncheck the Box Active for ur Message Type. Hope this helps.
Subhash .
Similar Messages
-
Implications of changing credit check from sales order level to delivery
Currently the credit check is availbale at the sales order level in the system and if I want to change the credit management settings so that credit check will be available at the delivery level.
What are the implications of changing credit check from sales order level to delivery>
Mangesh Desai wrote:
> Currently the credit check is availbale at the sales order level in the system and if I want to change the credit management settings so that credit check will be available at the delivery level.
>
>
> What are the implications of changing credit check from sales order level to delivery
Hi,
No Implications simple credit check will not happen order level it will happen delivery level .
*system will not conceded at order level open order will not be calculated
Best Regards,
venkataswamy. -
Restrict IDoc creation by using deactivate change pointers
Hi Experts,
I am trying to restrict the creation of IDOCS by deactivate the change pointers from a ztable. if the record in ztable and BDCP table match then i should deactivate the change pointer. And restrict the creation of Idocs.
pls, suggest me soon... its urgernt.......
Regards,
CHKMaybe using program RBDCPCLR to delete change pointers you don't want to use?
-
Printing checks from payment program F110 with smartforms
Hi! I am working in ECC 5.0 and I want to print checks from the payment program with a smartform, I created a non standard smartform but when I try to link the smartform with the program by transaction FBZP the available options are SAPScripts only. Is possible to do it?
Thanks in advanceHi! Even I am working in ECC 5.0 and I want to print checks from the payment program with a SAP SCRIPT Form, but the issue is that we hav the standard print program for printing the form and this form is being used by some other custom program....I want to customize the standard print program in the transaction F110 so that It successfully calls that form which is now called by some other program. I've the option of customizing the standard print program as per the program which is calling that Form but I'm not able to understand the flow of either of the print programs. Can anybody guide me here on how to understand the flow of the print and go for the customizing of the standard print program for the payment process?
Also, the current print program and Form which is being used by some other custom print program is already customized in the transaction FBZP.
Thanks in advance
Shamim -
Screen does not seem to reflect changes when called from main program.....
Hi all,
here's an issue that i've been trying to solve for a few days now,
i had created a screen in the screen painter, inside which i've included a table control (screen number 100: ).
i, then created a second screen pointing to the same program as screen 100 and assigned screen number 200 to it. so both scrn 100 and scrn 200 has got table controls and the validations occur in modules from the same program.
the issue i face is that, while any changes i make in screen 100 works fine when i call screen 100 from the main program; it does not work when i try to modify the table control in screen 200. for example, if i were to add a new column, it messes up the allignment of the other columns in screen 200, i can't seem to assign fixed colums, etc....
has anyone come across similar issues? if so how can i solve it? could it be an error with the SAP GUI?
any response will be appreciated. points will be rewarded as well... if that's how things work here.
Thanks,
David.
Edited by: david joseph on Aug 14, 2008 2:33 AM>
david joseph wrote:
> Hi all,
> here's an issue that i've been trying to solve for a few days now,
> i had created a screen in the screen painter, inside which i've included a table control (screen number 100: ).
> i, then created a second screen pointing to the same program as screen 100 and assigned screen number 200 to it. so both scrn 100 and scrn 200 has got table controls and the validations occur in modules from the same program.
>
> the issue i face is that, while any changes i make in screen 100 works fine when i call screen 100 from the main program; it does not work when i try to modify the table control in screen 200. for example, if i were to add a new column, it messes up the allignment of the other columns in screen 200, i can't seem to assign fixed colums, etc....
>
> has anyone come across similar issues? if so how can i solve it? could it be an error with the SAP GUI?
>
> Thanks,
> David.
>
> Edited by: david joseph on Aug 14, 2008 2:33 AM
Hi David,
The description of the problem is not so clear.
Let me know where I'm wrong, you have 2 screens and 2 different tablecontrols ? When you do any changes from the sapgui to the screen 100 there is no problem. But when you do that to the screen 200 is messes up ?
My logic with table controls
if you want 2 screens to share the same control then add the control to a subscreen
when you want to have 2 screens with 2 differents controls :
in main program
CONTROLS : tc_100 type TABLEVIEW USING SCREEN 100.
CONTROLS : tc_200 type TABLEVIEW USING SCREEN 200.
In screen 100 / 200 assure the name of the controls are tc_100 / tc_200....
Using this method I never have any problem.... -
Change availability check group to 02 from 01 in scheduling agreement
Hi All,
I have created a Scheduling agreement for a material which is having an availability check of 01(Daily requirement), because of that my order number is not reflecting in MDO4. Now i have changed the availability check for that material to 02(individual requirement). Could you please suggest me how to get the order number in MD04 now? Finally we have to update availability check group as 02 in scheduling agreement also.
Do we have any program or SAP note which will help us to resolve this issue?
Warm Regards
LakshmikanthHi
Any corrections made in masters after a document is created will not update the already created documents (99 %in SAP)
It will apply for new documents only
You have made the changes in material master only changing availability check from 01 to 02
You need to create a fresh order and see
Regards
Raja -
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,
vinayChange 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 -
Track change pointers creation
Hello
We currently face a problem of mass of change pointers for 1 message type ( MATMAS ) and would like to deactivate change pointers for the other unused message types in the system. How can I track which message types are not used in the last week?
thanks
ShaiYou should check the program RBDCPCLR (t-code BD22). This program is also available in SALE menu.
Read the SAP documentation for details:
[http://help.sap.com/saphelp_nw70/helpdata/EN/12/83e03c19758e71e10000000a114084/content.htm]
[http://help.sap.com/saphelp_nw04/helpdata/en/ab/27bde462848440ba70cf8eb348c86f/content.htm]
BR,
Suhas -
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 RajHi,
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 suggestChange 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 -
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 -
Avoiding change pointers for data with status planned
Hi,
we have to distribute HCM-data, standard infotypes and customer infotypes, into other SAP sytems. One of the receiving systems must not get data with the status planned (istat = 2).
Which would be the best way to avoid planned data in the receiving system? Is it possible to avoid creating change pointers for planned data in the delivering system or have I to delete the planned data in the receiving system while processing the idocs via user-exit?
Best regards
StefanDear Stefan,
You can create the change pointers manually from the IDOC data (e.g.with FM CHANGE_POINTERS_CREATE) during the inbound processing within of the customer-exits of enhancement RHALE001 or within an own BAdI implementation of BAdI HRALE00INBOUND_IDOC.
Or else you can use method IDOC_DATA_FOR_RECEIVER_MODIFY of BAdI HRALE00OUTBOUND_IDOC. In this case please make sure that note 1292241 is implemented.
Hope it helps,
Christine -
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 FerreiraIf 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. -
Creating IDoc Type from Change Pointers using RBDMIDOC
Hi All,
we are executing program RBDMIDOC(Creating IDoc Type from Change Pointers) evrey 15 minuts in background.
Issue : if some jobs are taking more than 15 minuts then next jobs are failed,
is next job will pick up any idocs that were missed?
there is no extesion's and ther is no Z-fields are used in that message type , we are used OILMAT as mesage type.
Regards,
DSK
Edited by: suresh dameruppula on Aug 5, 2008 2:04 PMHi,
Include a step in your job and have a program which checks if a job is already running. If yes do not start the next instance of the same job.
in the custom program just call function module
CALL FUNCTION 'ZBC_JOB_ALREADY_RUNNING'
EXPORTING
JOBNAME = p_job
IMPORTING
JOB_RUNNING = w_count
EXCEPTIONS
JOB_NOT_SPECIFIED = 1
OTHERS = 2.
Code within FM ->
select count(*)
into job_running
from tbtco
where jobname = jobname
and status = 'R'.
where p_job is the job name.
w_count is current running job count. If its greater than 1, then stop the 2nd with an error message.
Rgds,
Hema -
RBDMIDOC creates duplicateIDocs from the change pointers
Hi,
SAP program RBDMIDOC creates IDocs from the change pointers for a
specified message type(ZHRMDA06_PREHIRE, an extension of standard
HRMD_A06 ) and then marks the change pointer as processed.
HCM has an instance of this program that runs for PreHire employees,
creating 1 Idoc per employee. When this job runs in background via
production batch, a single change pointer for a single employee creates
3 or 4 identical IDocs in that one run of the program. This results in
duplicate records in the resulting interface file to Hewitt.
Please suggest solution for that.
Thanks and Best Regards,
Binod K singh.hi, try to check the distribution model: BD64, find whether there are mutiple receiving system for your message type...just a suggestion
Maybe you are looking for
-
HT3228 How can an email notication from my account appear on another mac?
I was sitting with a supplier, and as we were working an email notification from my email account appeared on her desktop. We have set her up with an email address with our business, but she is a supplier, and totally unconnected - even on a differen
-
Error in ios 6 installation on iphone 4, the iphone doesn't boot
error in ios 6 installation on iphone 4, the iphone doesn't boot
-
HOW CAN I FIND OUT HOW MANY SONGS I HAVE ON ITUNES?
How can I find the total number of songs my itunes
-
Source table has an xml column that I need to query before splitting into 2 tables.
Hi I have a source table with an xml column that I need to query on the nodes and then depending on what data is in the node then to split it into 2 different tables. I don't think I can use conditional split so I am looking at just a straight Execut
-
I am looking for a way to autocomplete login forms(In a web browser, IE) with a Java program. Does anyone know of a method, or if this is possible with Java? What about JNI?