Skip to Content
0

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

Feb 02 at 09:05 AM

32

avatar image
Former Member

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?

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

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

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.

Share
10 |10000 characters needed characters left characters exceeded
Egor Malov Feb 02 at 11:00 AM
0

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

Show 2 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Hi Egor,

Thanks for the help, I tried doing this already, but could not find the data.

However, when the full load interface ran, I could find this data successfully.

My question is when a change pointer entry is generated, is it necessary that the data should flow in delta load interface?

Or can it also flow through full load only?

When the change pointer was created, the next delta idoc that was triggered, did not carry this data, however on the weekend when full load job triggered the idoc, this data was present in it.

0
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

0