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

Similar Messages

  • Creation of Idocs from the change pointers by the program RBDMIDOC

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

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

  • How to find out what are all the change pointers assoicated for an idoc ??

    Hi ,
    How to find out what are all the change pointers activated for an idoc ??
    Thanks,
    Varma

    Verma,
    You can check what are the active Change Pointers for the message type in tcode <b>BD50</b>
    Use tcode <b>BD61</b> to check whether change pointers are active or not??
    Hope this helps..

  • 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

  • Need help ion change pointers.

    Hi,
    I am Using Change pointer for a change/create of material master data.
    At regular intervals (currently proposed hourly) i need to execute the function module MASTERIDOC_CREATE_SMD_MATMAS to create an output message and send it to PI Middleware. The Middleware examines the changed fields contained in the MATMAS IDOC.
    The following things to be perfomed.
    1. If the change pointer is for a material with its client level deletion flag set then an output message is not generated for that material.
    2. If the change pointer is for a plant specific field then it can be ignored.
    Could you please guide me as to hw can i achieve ths?
    ans also Hw can i make the FM MASTERIDOC_CREATE_SMD_MATMAS to execute on regular intervals.
    PLease do reply.
    Thanks
    Sahil

    Hi,
    1. You need to execute BD21 for your message type to send the IDOCs for the change pointers created in DB. This is nothing but executing your FM "MASTERIDOC_CREATE_SMD_MATMAS". You need to schedule a back ground job for this.
    2. Implement "FILTER_BDCPV_BEFORE_WRITE" method of the BADI "BDCP_BEFORE_WRITE" to filter your requirements. This methos has Message Type name as import parameter (FLT_VAL). You can find out information related to type of change using the import parameters CHANGE_DOCUMENT_HEADER and CHANGE_DOCUMENT_POSITIONS. If any change need to be filtered, just use the changing parameter "CHANGE_POINTERS" of this method.
    Hope this helps you!!!
    Regards,
    Ganga

  • Change Pointers for the fields PERNR, GBDAT and PERID

    Hi,
         I want to know, how we can delete/de-activate and then add/activate Change Pointers for these fields. Is my Question a valid one? Please guide me if I'm wrong and help me in this issue.
    Thanks in advance,
    Exertive.
    Message was edited by:
            Exertive

    Hi Suresh,
                   I didn't get your point exactly. With this report, we can only Log the Changes that has been performed on a Particular Pernr or an Infotype. Actually, if see go through my Previous Post, you will get Clear Idea. Actually, I'm looking for the Concept below:
    Actually, I'm using the Standard ALE Process for Masking Master Data fields (PERID and GBDAT) with default values from one system to another using the Message Type, HRMD_A (which will be used as a Standard Message Type for HR Personnel Administration and Organizational Management). For this, I' have used two Conversion Rules in the above Message Type. To make this ALE trigger, I have to Run the Report, RBDMIDOC. But, before trigerring the ALE for all the Employees in the System, I want to test the ALE for few Employees, whether it is working properly or not. For this, I think, I need to delete the Change Pointers for all the Employees except for the few Employees whom I want to Test. But, I don't have any idea, how to delete those Change Pointers. Please guide me some solution or provide me some document where I can find exact procedure for doing this. Guide me, If I'm going in wrong procedure.
    Thanks in advance,
    Exertive.

  • 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 field’s 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

  • 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 field’s 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 &#8209; Generally.
    2. Set the activation status Activate Change Pointers &#8209; 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,

  • How do we control what fields you need in the change log?

    Gurus,
    Some time ago in an unrelated problem solving activity I came across the configuration screens that controlled what (and if) you could log when changed.
    I can not find the place now.
    There should be a place in SPRO which allows me to configure that I do not want log of the change in sales orders. It also allows me to choose which fields within the sales orders should be logged. So I could choose (say) to have the logging of quantity changes to be turned off.
    Was I dreaming? ... Can someone point me in the right direction?
    Thank you all for contributing
    Regards
    Raju

    I have a direction now:
    1) Check in the SE11 to ensure that the field that I need the change log for is marked "Change Document" in the Data Element of the field.
    2) Check the document object VERKBELEG (Sales Document) to ensure that the table is included in the configuration. Transaction SCDO.
    I will experiment with this to find out if this can be done.
    Regards
    Raju

  • Change Pointers - adding a new field to existing Change Document

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

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

  • Change pointers in case of purcahse order

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

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

  • Change Pointers are not getting populated in BDCPV table.

    Hi All,
             I am trying to create IDOC for Activity type master - KL02 through change pointers. For that I have done following things.
    Message type - COAMAS
    1. Created Custom message type - WE81 - ZIN_COAMAS_TCSMOBILE
    2. WE82 - Config for Mess Type and Idoc type combination
    3. SCDO - Checked object type LSTAR and have required tables in that object.
    4. BD61 - Activated Change pointers - Generally.
    5. BD50 - Checked Active for ZIN_COAMAS_TCSMOBILE
    6. BD52 - Added fields for I want to create Change pointers
    7. BD60 - Message type and ref Mesage Type and function module config.
    8. BD64 - Created distribution model for my Message type
    After doing all this settings the change pointers are not getting created in BDCP and BDCPV tables.
    Note - The entries are going in CDHDR and CDPOS table for activity which i change through KL02 for class LSTAR
    Can anybody figure out what need to be done in this case?
    Regards,
    Gautam Joshi.

    Hi All,
              Solved the problem myself.
              In BD52 I have given
              LSTAR               CSLA         KOARS
              LSTAR               CSLA         LSTAR
              LSTAR               CSLT          KTEXT
              Here the data of activity are stored in TCLA and TCLT tables. So intially while doing config in BD52 I have given TCLA and TCLT table names.
              But I debugged the KL02 and found that change pointers are not created for TCLA and TCLT table. further looking into CDHDr and CDPOS table I found that for COAMAS message type in these two tables table name was CSLAB.
    CDPOS entry
    LSTAR                        
    3166442                      
    119512890                    
    *CSLAB*                        
    2003166442   2400123120000101
    KTEXT                        
    U                            
    --> BUT CSLAB is structure.
    After putting these entry in BD52 the problem solved.
    LSTAR     CSLAB     KOKRS
    LSTAR     CSLAB     KTEXT
    LSTAR     CSLAB     LSTAR
    Regards,
    Gautam Joshi.

  • 0CML_DELTA : Change pointers are not active

    Hi All,
    I have successfully did the delta init without data transfer for datasource 0CML_DELTA and 0CML_DELTA_CAP. Now, While trying to load delta, I am getting an error "Change pointers are not active" for both the datasource 0CML_DELTA and 0CML_DELTA_CAP.
    The position datasources are fecthing 0 records.
    I have activated the change pointers in BD61, even though I am getting the same error.
    Anyone faced the similar issue or have any clue about the problem.
    Thanks in advance,
    Pravender
    Edited by: Pravender on Sep 30, 2010 11:09 AM

    I resolved it. I was activating change pointers in BD61. But fot CML we need to activate in SPRO--> SAP Banking --> Loans Management --> Basic settings --> Installation parameters ---> Define general installation parameters.
    Then it will work.
    Pravender

  • Regarding change pointers for HRMD_A

    Hi Abapers,
    I need to distribute changes to HR master data to a middleware system. hence i have activated the change pointers for the message type: HRMD_A. now my idoc is populating the infotype segments whenever it is changed with all fields.
    But a particular change (on an infotype) should be sent individually in two different runs of RBDMIDOC run to the middleware. Ex: Vendor A needs changes to be sent to it on a weekly basis whereas Vendor B needs changes to be sent to it on a biweekly basis. When an employee X has a change on infotype 2, this change should be sent to middleware in both instances separately in different IDOCS at different times when RBDMIDOC program is run (by capturing change pointers pertinent to the message type of the particular vendor).
    What are the changes required for ALE config.? Do i need to create a new message type for vendor B and  configure. Please help.
    Thanks.

    Hi sudarshan,
    Yuo need to create Z program to trigger IDOC.
    As you need to set read status of change pointer as X after yuo send it to both system.
    So you need to create Z table to keep track of this whether you have send to sys a or Sys  B..
    If you willl not update read status in will cause performance prob.
    Hope this helps.
    Dhiraj.

Maybe you are looking for