Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

CHANGE POINTERS DEBI XD06

Former Member
0 Kudos

Dear Experts,

BDCP table is getting updated with object class 'DEBI' when I create or change the customer using XD01 and XD02 transaction. How to make this table updated when transaction XD06 (mark a customer for delete) is exectued? I have checked on SE11 , that KNA1-LOEVM is marked for change document.

Note: The tables CDHDR and CDPOS are updated with object class 'DEBI' for XD01, XD02 and XD06.

Thank you!

Grace

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Grace,

Have you checked table TBD62 (trans BD52) for your message type?

In case you did not know then the way change pointers normally get written is:

- FM CHANGEDOCUMENT_CLOSE get called (this get called for every change doucment)

- Towards the end of this FM it writes out change pointers (via FM CHANGE_POINTERS_CREATE_LONG in my system)

- Within this it performs the following checks:

- Check ALE active (table TBDA1)

- Read all messages that are flagged as active (table TBDA2)

- Read all fields for messages active (table TBD62)

- Evaluate match against CDPOS changes and prepare for writing to table BDCP

Normally table TBD62 is already delivered with KNA1-LOEVM so the changes should be written (i.e. confirmed as CDPOS is updated - therefore it is going through CHANGEDOCUMENT_CLOSE for trans XD06).

I would place an update debugging breakpoint around the code in form tbd62_getrelevantentries(LSCP1F01) to check what is happening.

Cheers,

Pete

7 REPLIES 7

Former Member
0 Kudos

Hi Grace,

Have you checked table TBD62 (trans BD52) for your message type?

In case you did not know then the way change pointers normally get written is:

- FM CHANGEDOCUMENT_CLOSE get called (this get called for every change doucment)

- Towards the end of this FM it writes out change pointers (via FM CHANGE_POINTERS_CREATE_LONG in my system)

- Within this it performs the following checks:

- Check ALE active (table TBDA1)

- Read all messages that are flagged as active (table TBDA2)

- Read all fields for messages active (table TBD62)

- Evaluate match against CDPOS changes and prepare for writing to table BDCP

Normally table TBD62 is already delivered with KNA1-LOEVM so the changes should be written (i.e. confirmed as CDPOS is updated - therefore it is going through CHANGEDOCUMENT_CLOSE for trans XD06).

I would place an update debugging breakpoint around the code in form tbd62_getrelevantentries(LSCP1F01) to check what is happening.

Cheers,

Pete

0 Kudos

Hi Pete,

Thank you very much for your through answer!

I have made tha change TBDA2-ACTIVE = 'X' to message type FRE_LOC_SITE and the change to field LOEVM has been captured in BDCP.

Details:

According to BD62 table on my system, Field KNA1-LOEVM is part of the following Message Types:

FRE_LOC_SITE

DEBMAS

DEBCOR

I have checked for these Message Types in TBDA2 table:

FRE_LOC_SITE - shows (TBDA2-ACTIVE = space) and I can change to TBDA2-ACTIVE = 'X'.

DEBMAS u2013 does not exist

DEBCOR u2013 does not exist.

So, I concluded the field LOEVM was Not marked for Change Pointers.

However, the table CDHDR and CDPOS was capturing the change (via Xd06) of this field, while BDCP did not.

Best Regards,

Grace

0 Kudos

Hi Pete,

Thank you very much for your through answer!

I have made tha change TBDA2-ACTIVE = 'X' to message type FRE_LOC_SITE and the change to field LOEVM has been captured in BDCP.

Details:

According to BD62 table on my system, Field KNA1-LOEVM is part of the following Message Types:

FRE_LOC_SITE

DEBMAS

DEBCOR

I have checked for these Message Types in TBDA2 table:

FRE_LOC_SITE - shows (TBDA2-ACTIVE = space) and I can change to TBDA2-ACTIVE = 'X'.

DEBMAS u2013 does not exist

DEBCOR u2013 does not exist.

So, I concluded the field LOEVM was Not marked for Change Pointers.

However, the table CDHDR and CDPOS was capturing the change (via Xd06) of this field, while BDCP did not.

Best Regards,

Grace

0 Kudos

Hi Grace,

Glad you got it sorted. Just to clarify - the entries in CDHDR/CDPOS as part of change document processing (using the flag on the data element) is a separate process to that of change pointers. ALE change pointers therefore 'piggy back' on change documents and are user configurable via tables above -i.e. you could create your own Z/Y message type and just add the fields that you want to watch for changes.

Cheers,

Pete

0 Kudos

HI Pete,

Thanks for the additional info regarding CDHDR/POS tables, ALE and Z/Y message type.

This will allow me to capture changes on my Z* tables.

I very greatful and hope that by marking your answer has solved my problem, your are rewareded with the 'points'. It is the first time on SDN that I got a really good anwer.

Best Regards,

Grace

0 Kudos

Hello Pete,

i think u have analyzed lot in CDHDR table and related FM's.

i am using FM: BAPI_MATERIAL_SAVEDATA for chang material plant status in basic data 2. but after save the data , if i go MM03, environment->display changes, here change number field is blank.

i debug this FM , this FM is calling MATERIAL_MAINTAIN_DARK and then MATERIAL_UPDATE_ALL and then CHANGEDOCUMENT_OPEN , here PLANNED_CHANGE_NUMBER field is blank.

could you please guide me how to solve this problem.

thanks in advance.

srinivas

Former Member
0 Kudos

Hi Srinivas,

Not sure on what you are trying to achieve but planned future changes to materials are made in the GUI via transaction MM12. I am guessing you are changing the material immediately via the BAPI call so I would not expect anything in parameter PLANNED_CHANGE_NUMBER of FM CHANGEDOCUMENT_OPEN.

Are you able to confirm entries for CDHDR are created if you change the same material data via the GUI in MM02? I would initially concentrate on FM MATERIAL_WRITE_DOCUMENT as this is specific to the material master (see generation info in trans SCDO for object MATERIAL).

Let me know how this goes.

Pete