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,
CHK

Maybe using program RBDCPCLR to delete change pointers you don't want to use?

Similar Messages

IDOC trigger using Z change pointers for standard SAP table

For IDOC trigger, is using custom change pointers on standard SAP master data tables, a good idea? A seasoned abaper told me "it will mess with the standard" and further told to go with scheduled job.
So, for example, say that my data for table T001K is updated via transports in PRD and I need to transfer this updated data via IDOC to an external system. Since there is no standard message type for this data, I will create a new one. Further, I will create a new change pointer for table T001K (it already has six fields with their data elements activated for Change Documents). Then I link the message type and the new change pointer. And so on an so forth. I have followed the procedure given here:SAP Tips: A to Z of Custom Change Pointer
Now, the question is, will this be a good idea to capture data and trigger IDOC? Or a batch program with calls to standard FM to read CDHRD/CDPOS be a more suitable option.
I need to know if a near instantaneous data transfer (and an effecient one as far as the system performance and reliability is concerned) can be acheived. If there is any other way of doing this, I am not aware of it!
Any one has any input/experience on this?

Hi Viktor,
I think the batch program approach would be a good solution as the by this way you are taking matter into your own hands rather giving control to the SAP framework because you may have to test out the other approach as to how the standard SAP framework is behaving for custom change pointers.
Thanks,
Ravi

Extraction using ALE Change Pointers

Hi,
Can any one pls tell me what is the advatage of extracting r/3 data to bw using ALE Change Pointers. Any document on how to perform ale change pointer extraction will also be helpfull for me. Thanks in Advance
Regards,
Harish.

https://www.sdn.sap.com/irj/sdn/advancedsearch?query=change+pointer&cat=sdn_all

ME23N restrict IDOC creation and keep traffic light yellow

Hi,
I have a requirement in which I need to restrict the EDI IDOC if there are errors in the PO. Also as the IDOC is not created the messages (type NEU) should remain with the yellow traffic light as the IDOC is not processed. What would be the best approach to keep the traffic light yellow , I have identified the point to restrict IDOC creation but the traffic light is set to red.
Thanks,
Esha

Hello Esha,
I have identified the point tojavascript:; restrict IDOC creation but the traffic light is set to red.
Yellow light in Output type shows its Not Processed. If you are talking about exits EXIT_SAPLEINM_002/EXIT_SAPLEINM_011 they come into picture when Output type processing started. So ultimately they will have either Success/Error status.
Even by setting sy-msgty = 'W' in EXIT_SAPLEINM_002 and raising exception will not help.
You can play around with FMs mentioned in group WMCP and can check.

Needs to update Infotype using ALE-Change Pointers-ECC 6.0

HR Experts,
We are using ECC 6.0. There are two SAP-HR systems.. for e.g system A and B.
We would like to send data from system A to B.
If there are any changes in system A for Infotype-0, 1, 2, 6, 8, the IDOC should be generated and it should deliver and update the infotypes in system B.
What message type I have to use?
Do I have to use change pointers?
If there is only change in any one of the above infotypes then it will generate IDOC for all above infotypes or just the changed one?
Thanks in advance for your help..
MP

Hi Frank,
Thanks for your quick reply!
I rewarded you with the points
How I have to choose which infotypes I have to transfer in message type HRMD_A, What tcode I have to use to configure this?
Do you know the BADI or User-Exit for enhancement of custom fields?
How I have to configure to transfer only the changed records OR transfer complete data? Where should I go to do this?
Thanks for your help in advance...
MP

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 .

IDoc creation on save and change of production order

I am looking for a way to create, and send if possible (if not I'll send with a batch job), on the save (creation and change) of production orders. This will be a modified LOIPRO iDoc. Currently we have a customer exit on the save of the production order but because it is before the save we must predict the number of the prod order. This has worked but now we are creating one production order per line item in a sales order (automatically) so this is causing us to predict the same production order number twice. We need a way to automatically create and send an iDoc for all production orders for given plants. Right now the solution we are looking at is creating an output type and running through those output types a few times a day, sending them down to the Shop Floor system (proprietary system).
Is there anything setup in SAP that we can utilize?
Regards,
Davis

Hi Rick,
Follow the below sample steps for changing component quantity:
DATA:
    l_methods TYPE bapi_alm_order_method,
    it_boperations TYPE STANDARD TABLE OF bapi_alm_order_operation_e WITH HEADER LINE,
    it_components TYPE STANDARD TABLE OF bapi_alm_order_component_e WITH HEADER LINE,
    it_components1 TYPE STANDARD TABLE OF bapi_alm_order_component WITH HEADER LINE.
1. Call BAPI :BAPI_ALM_ORDER_GET_DETAIL , it will give existing order component details.
CALL FUNCTION 'BAPI_ALM_ORDER_GET_DETAIL'
    EXPORTING
      number        = <production order number>
    TABLES
      et_operations = it_boperations
      et_components = it_components
      return        = it_bapiret2.
2. Move it_components to components table compatibel to BAPI "BAPI_ALM_ORDER_MAINTAIN".
LOOP AT it_components.
MOVE-CORRESPONDING it_components TO it_components1.
_*"Note here while moving change the component quantity"*_
APPEND it_components1.
CLEAR it_components1.
ENDLOOP.
3. Build the methods table for change production order :
it_methods-refnumber = v_refnumber.
            it_methods-objecttype = 'COMPONENT'.
            it_methods-method = 'CHANGE'.
            it_methods-objectkey = v_objectkey.
            APPEND it_methods.
"Note v_refnumber has 1 to 1 relation ship with the components table, if you want to change First component in it_components1 then you have to enter value '1' here for v_refnumber.
it_methods-method = 'SAVE'.
        APPEND it_methods.
4 . Call
CALL FUNCTION 'BAPI_ALM_ORDER_MAINTAIN'
          TABLES
            it_methods   = it_methods
            it_component = it_components1
            return       = it_bapiret2.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.

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 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

What is the use of change pointer technique in IDOC

hi
could anybody suggest me
what is the use of change pointer technique and how to use it
thank you
kalyan.

Change pointers are used for changes to the master data objects are flagged for distribution by SMD Tool.i.e.shared Master Data.
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
The SMD tool is connected to the change document interface. If the master data changes are to be distributed, the application writes a change document. The contents of this are passed to the SMD tool. The tool writes change pointers, reads the application data and creates the master IDoc.
The master IDoc is then passed to the ALE layer, which sends it to all interested systems.
The change pointer tables (BDCP und BDCPS) should be as small as possible. Use as few change pointers as possible and delete change pointers which you no longer need.
You can increase the rate of processing by using the Analyze Change Pointer and Reorganize Change Pointer functions.

Reprocessing change pointers for MATMAS idoc

Hi
I have a situation where i executed BD21 for changes to materials but no idocs were created due to some issue with the distribution model. Now i have fixed the issue and would like to re process all the materials which were changed. Since i have already executed BD21, now no new idocs are being generated. Is there a way to reprocess the changed materials and generate the idocs again.
Thanks
Nag

Hi Roger
Thanks for your inputs. I am trying to generate idocs through the change pointers and not using output determination.
When i executed BD21 the first time, idocs were not generated due to some config issues. But the job ended successfully saying that idocs were generated and marked all the changed material documents under change pointers (But in WE02, the idocs never showed up actually).
Now i have fixed the issue in config and want to generate the idocs using the change pointers. Is there any way to regenerate the same idocs using BD21 or some alternative.
Thanks
Nag

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
Shai

You 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

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

Problem in Idoc creation in ME22N

Hi All,
We are facing a problem in Idoc creation in transaction ME22N.Our requirement is to trigger an output type and create a idoc everytime a change is made to a particular Purchase Order.
Presently however,for some vendors,when we change the plant at the item level,an Idoc is not created(with a message that the changes are not relevant to create an Idoc).Any other change to the Purchase Order like changes in quantity or price,results in successful Idoc creation.
We have also noticed that this happens only in the case of certain vendors.The Customer Info records and vendor data are all believed to be fine.
Are any other config settings required to be maintained for this?
Thanks in advance!
Regards,
Nejuma Iqbal

Hi Nejuma,
I don't think there is any problem with cofiguration settings.u r getting the idocs for some vendors .
if iam not wrong u r giving LS in the tcode(we20).The method which u r using is change pointers.As u r using standard idoc all the settings will be done.
Only settings u have to do is
1>generate partner profiles(WE20)
2>Distribute model view(BD64).
REGARDS,
Nagaraj

Vendor Master change pointers problem

Hi ,
We have a custom program that will read change pointers for Vendor master .
we use these change pointers to trigger our custom idoc . But we need to select only change pointers of vendors whose changes are confirmed in transaction FK08 or Fk09
Please let me know how we can check the changpointers for particular vendor is confirmed or not
Regards,
Ramesh

Just as a follow up on this. I think that within the setup of the classification system you need to configure the tracking of changes. If you take a look at table TCLA you'll notice that there is a field which indicates if change document are turned on. I belive that this then relates back to the "virtual" change document objects that I refered to in my previous post.
It looks like during update tasks that fucntion CLVF_VB_INSERT_CLASSIFICATION and that this checks the TCLA table and then writes the change documents as part of the updates.
The description of this field in TCLA is:
Change Documents for Classification
Indicator: for this class type, a change document is generated for all changes to classification data.
For technical reasons, this indicator can only be set if the class type is defined for classifying different object types.
looks like there is some more research needed but this should hoepfully get you on the right track.
~Ian
Edited by: Ian Maxwell on Sep 29, 2008 1:37 PM

Restrict IDoc creation by using deactivate change pointers

Similar Messages

Maybe you are looking for