Skip to Content
avatar image
Former Member

Does anyone have an idea if we can obtain the IDOC number from change pointer number?

Hi Experts! Does anyone have an idea if we can obtain the IDOC number from change pointer number?

eg. My case is that I have a running interface of MATMAS message type. I can see a change pointer entry created for a particular material change in BDCP2 table and also it is showing processed field as 'X'. However I'm not able to locate the particular IDOC in which this data is being transferred. Any tip how can I relate this?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    avatar image
    Former Member
    Mar 15 at 09:11 AM

    Hi! Thanks for your help.

    I realized that this data was being generated in a custom code!

    It was picking data based on Change pointer ID and the corresponding table name.

    This code was written with case syntax on Table name and my data change was getting stored in ''DMARM" table, for which there was no case written at all!! Therefore this data was not getting picked.

    Add comment
    10|10000 characters needed characters exceeded

  • Feb 02 at 11:00 AM

    Hi, Danish,

    I'm not sure if there is any *direct* link between IDOC and change pointer, but they both are linked to some business object (in your case, material). Thus you can do it in two steps:

    1. get material key from change pointer

    2. find IDOC(s), transporting this material by the material key <-- use WE09 to do this

    Add comment
    10|10000 characters needed characters exceeded

    • Hi, Danish,

      AFAIK full\delta load work independently: whether delta set up or not, you can run 'full load' and it will process all records, no way checking presence of change pointers.

      As for the initial problem: it is really unusual that the change pointer is marked as processed and no data for the corresponding material is present in the outgoing IDOC. Do you have this problem reproduced in a DEV or QA system? If so, you could actually debug the program rbdmidoc and see what happens. One of these FMs is in charge for writing change pointers: CHANGE_POINTERS_CREATE_LONG, CHANGE_POINTERS_CREATE, CHANGE_POINTERS_DIRECT