Change pointers and Idoc creation

Hello,
I would like to create change pointers for any changes regarding one of our customer infotypes: 9002 (hrp9002)
I was able to do that, however, I'm struggeling with the details.
The problem is that I do not want to send any data related to infotype 9002. I just need this change pointer to trigger idoc creation for the related objects.
Example: Let's assume that infotype 9002 gets created for position S 40001234. Once a night a customer report is executed via a job which reads all unprocessed change pointers (including the one mentioned above) and sends the corresponding object. In this case, an Idoc for the holder of position 40001234 should be created WITHOUT data for infotype 9002.
The message type is HRMD_A.
What do I need to do?
Thank you for your input.

Hi,
For Info type 9002 we need to implement Badi HRALE00CHANGE_PTRS using below code.
   LOOP AT  t_changed_objects  INTO   wa_changed_objects .
    CASE  wa_changed_objects-infty.
      WHEN '9002'.
        wa_cp_data-tabname = 'HROBJINFTY'.
        wa_changed_objects-plvar = '01' .
        wa_cp_data-tabkey  = wa_changed_objects .
        wa_cp_data-cdchgid = 'U'.
*  wa_cp_data-CDOBJCL = 'HRMD_A'.
        APPEND wa_cp_data TO t_cp_data1 .
    ENDCASE.
  ENDLOOP.
  IF t_cp_data1 IS NOT INITIAL .
    CALL FUNCTION 'CHANGE_POINTERS_CREATE_DIRECT'
      EXPORTING
        message_type          = 'HRMD_A'
      TABLES
        t_cp_data             = t_cp_data1
      EXCEPTIONS
        number_range_problems = 1
        OTHERS                = 2.
    IF sy-subrc <> 0.
* Implement suitable error handling here
    ENDIF.
  ENDIF.
This code will create entry in BDCP2 table.
After thsi populating segemnet you need to code for below exit as .
EXIT_SAPLRHAL_003
   IF PNNNN_NAME = 'P9002' .
*FIELD-SYMBOLS: <FS_plog> TYPE ANY.   "Field Symbol for dynamic filling of data based on the structure
*Clearing the SUBRC
CLEAR SUBRC.
* fill workarea for infotype with infotype-data
ASSIGN pnnnn_data TO <FS_plog> CASTING TYPE P9002.
LS_9002 = <FS_plog>.
* move fields
MOVE-CORRESPONDING LS_9002 TO LS_p9002.
* fill IDoc-data with workarea for segmenttype
ASSIGN sdata_data TO <FS_plog> CASTING TYPE Z1P9002.
<FS_plog> = LS_P9002.
CONVERTED = ZCDP_IF_CONSTANTS_DTIRIS=>GC_CROSS .
ENDIF.
It will work fine.
Thanks
Anju

Similar Messages

  • Idoc Conversion rule, Change pointers and Filters

    Hi Experts,
        Please any one can help me out, i need material or clear picture about Idoc Conversion rule, Change pointers and Filters where we can use these concepts what is the befit for these concepts.
    Thanks in advance,
    Ramesh.

    Hi,
    Check this link. It has got some of the tutorials you are looking for.
    http://www.****************/Tutorials/ALE/ALEMainPage.htm
    Cheers
    VJ

  • Change pointers and RFC

    Hi All,
    Is it possible to implement change pointers without creating idocs, but with only RFC's.
    Actaully i am goign through aproject document which says the interfaces are implemented using change pointers and BADI's.I was in a understandign that there would be idocs created to communicate the master data changes to other systems.
    But one of the person who involved in the interface development said that there are no idocs related involved related to the interfaces, its all RFC's enabled.
    Can anyone please let me know if change pointers can also be implemented using RFC.
    Thanks in advcane.

    Hi,
    this is described sufficiently in SAPHELP - in a nutshell:
    Changepointers - as the name says - point at changes (change documents). Therefore the creation is together with change documents (at the end of FM CHANGEDOCUMENT_CLOSE.
    Chane pointers are created for ALE message types (tcode WE81). This does not mean, that any ALE message has to follow - there might be another subsequent action.
    Writing of CP must be enabled with BD50. With BD52 the tables/fields are customized. Precondition is, that the data element of the table field is enabled for change documents and that change documents are created. BADI
    BDCP_BEFORE_WRITE allows further refinement (or any other action triggerd by the change). Note that both - change documents and CP - are created in update task - so you have to activate update debugging to see it in debug.
    Storage of CP is in table BDCP2 (since release 7.00 former releases use BDCP and BDCPS). Read pointers with FM CHANGE_POINTERS_READ and set them to processed with CHANGE_POINTERS_STATUS_WRITE. If more than aprox. 1 Mio. pointers are read an overflow may occur - use CHANGE_POINTERS_READ_MODE_SET to set an appropriate block size and CHANGE_POINTERS_READ_INFO_GET to stirr the further processing. All FM are documented sufficiently.
    Have fun!
    hp
    Edited by: Holger Pakirnus on Sep 14, 2011 3:58 PM

  • Regd. change pointers and notifications

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

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

  • Change Pointers and Recovery Index

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

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

  • Change pointers in idoc

    This is to send the data from SAP to third party system . For data mapping, we have used the exit 'EXIT_SAPLRHA0_003' in the enhancement 'RHALE001' . Iam using the message type 'HRMD_A' and the basic type 'HRMD_A07' . I have activated the change pointers. How to test this?

    Hi,
    Please goto we02 and check whether the idoc is generated or not , when you change master data and executed RBDMIDOC.
    If yes Check the segment to which you have made changes to populate the data using EXIT.
    Thanks and Regards,
    P.Bharadwaj

  • Change pointers of IDoc

    Please conduct a simple question. T-code BD52 is Maintain change-relevant fields for message type,the first column is 'Object', the contents of this column can be maintained in where?
    Thanks a lot.

    >
    Hao Zhang wrote:
    > Please conduct a simple question. T-code BD52 is Maintain change-relevant fields for message type,the first column is 'Object', the contents of this column can be maintained in where?
    > Thanks a lot.
    Hi,
    CDHDR,CDPOS,BDCP,BDCP2 and BDCPV are the tables related to change pointers. These change Document objects are stored in CDHDR and CDPOS. CDHDR contains header level information and CDPOS contains item level information
    Regrds
    Vinod

  • Deleting change pointers in IDOC

    Is there any other way to delete change pointers other than using transaction code BD22?

    Hi,
    u can activate/deactivate change pointer using Transaction code BD50. Guess this will be helpful.

  • ABAP Extension Module and IDOC Creation

    Dear Gurus,
    I would like to send master data from SAP to IBM Websphere with the help of ABAP Extension module and populating idoc data using ABAP Event handler. Could you please let me know the flow of it. 
    Thanks in advance.
    Thanks
    Shanthi

    Hi,
       After calling MASTER_IDOC_DISTRIBUTE, you need to COMMIT. (COMMIT WORK).
       Please go through these links.
      http://help.sap.com/saphelp_erp2005vp/helpdata/en/78/21783151ce11d189570000e829fbbd/content.htm
    http://www.erpgenie.com/sapedi/idoc_abap.htm
    Regards,
    Vivek LR
    Edited by: Vivek LR on Jun 20, 2008 9:22 AM

  • IS-U and IDoc creation

    Hello everybody,
    I need that the IS-U payment run creates a PAYEXT or DIRDEB Idoc with BaseType PEXR2002 ( I need this for in-house cash).
    Anybody here who knows how to do this?
    Thx
    Thorsten

    Thersten,
    I understand that after you send the IDoc info to SAP-Inhouse Cash, the entry/entries wud/cud be
    DR: Subsidiary Bank
    CR : Inhouse Cash Center
    (OR) &
    DR: Inhouse Cash Center
    CR : House Bank
    Another combination can be
    DR: Subsidiary Bank
    CR : Inhouse Cash Center
    (OR) &
    DR: Inhouse Cash Center
    CR : Clearing Partner.
    So while sending the IDocs to SAP Inhouse bank, you need to consider above entries &  design the program accordingly.
    But do remember that FYP1 entries usually wud be:
    DR: Bank Clearing Account
    CR: Contract Account
    Below URL may be helpful to you
    https://help.sap.com/saphelp_erp60_sp/helpdata/en/20/8ad8fa96494f16a8db9110234c855b/frameset.htm
    Hope this helps
    Rgds
    Rajendra

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

  • Triggering Idoc creation based on following Sales Order changes

    Hi,
    I am trying to find the best way to trigger an outbound Idoc to a customer for the following cases:
      1. Delivery date change
      2. Partial Shipment
      3. Complete Shipment
      4. Backorder
      5. Cancellation from Vendor
    Any help is appreciated. SAP does not provide a clean way to do this. Thanks in advance.

    Hi,
        Use change pointers concept as follows
    Activating Change Pointers
    Change pointer generation has to be activated at both the
    general level and message type.
    1) Goto BD61, check the checkbox Change pointers activated - generally.
    2) Save
    3) Goto BD50, Choose the row for message type MATMAS, and check mark the corresponding field
    4) Save
    Converting change pointers to IDOCs
    • Create, change or mark for deletion materials using
    transaction MM01, MM02, or MM06.
    • Execute transaction BD21
    • Enter Message type MATMAS
    • Execute
    Regards
    Amole

  • 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

  • Help With IDOC Change Pointers

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

    <b>Automatic generation of IDOC when we change the MASTER DATA:</b>
    <b>Change Pointers:</b>
    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.
    <b><u>Configuration for Change Pointers:</u></b>
    1. BD61 Active change pointers generally
         - Check the checkbox "Change pointers activated -generally"
         - Save it
    2. BD50 Active change pointers for Message Type
    Message Type     Active
    MATMAS              Check the check box
    3. SCDO Change Document Objects
         - Check whether the "MATERIAL" is available in the object list.      
    4. BD52 Maintain Table Views
    -     Enter the Message type "MATMAS" and press enter.
    For example
    OBJECT     TABLE NAME     FIELD NAME
    MATERIAL     MARA     BISMT
    5. BD60 Additional data for message types:
    For example:
    Message Type                Function Module                         Table
    MATMAS                 MASTERIDOC_CREATE_SMD_MATMAS        MARA
    6. WE21 Port
    7. WE20 Partner Profile
    8.  BD64 Distribution Model
    as michal said we have to use RBDMIDOC program.for executing this program we need to give message type like
    MATMAS or
    DEBMAS or
    CREMAS
    depending on your requirement.
    go to SE38 tcode
    --- copy RBDMIDOC to zprogram(i'e., ZRBDMIDOC)
    ---create variant
    use this zprogram(ZRBDMIDOC) in BACKGROUND SCHEDULING SM36
    <u>STEPS IN BACKGROUND SCHEDULING:</u>
    Use tcode SM36
    Click Job wizard in the button set
    Click Continue
    Enter Job name and press continue
    Select ABAP program and press Continue
    enter Program name and press continue
    and again press Continue
    set Schedule type immediately and continue
    Select periodic job checkbox, press continue
    Select none of the above and click on other periods – give one-minute and then press create
    Press continue and then press complete.
    recently i did this requirement
    if u have any doubts plz let me know
    Best Regards,
    Srikanth     
    Reward the useful answers and you will get one point yourself

Maybe you are looking for