Application Development and Automation 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: 
Read only

CHANGEDOCUMENT_READ

Former Member
0 Likes
1,059

Req:

While creating condition records through VK11, if we maintain scale prices as well, the entries that get stored in CDHDR and CDPOS are wrt to new entry only and not reflecting KONM table with scale prices.

However, when we change scale prices in condition records through VK12, the changes are captured as old value and new value in CDPOS table.

Now the requirement is that user wants to report scale prices data even when they are creating the new condition records. And using FM u2018CHANGEDOCUMENT_READu2019

Or u2018CHANGEDOCUMENT_READ_HEADERSu2019 is not capturing the scale prices data as explained above.

Any pointers for this are appreciated.

Probable Solution:

Do the coding after CHANGEDOCUMENT_READ and read the table (structure CDRED) with tcode VK11 and read the data from KONM table.

Modify internal table accordingly and let the rest of processing go on.

If you find any solution better than this usual brute-force method, please advise.

Thanks in advance !

3 REPLIES 3
Read only

Former Member
0 Likes
599

Hi,

if we maintain scale prices as well, the entries that get stored in CDHDR and CDPOS are wrt to new entry only and not reflecting KONM table with scale prices.

is it the new condition records maintained are not getting updated in KONM table

Can u specify which condition type u r using ..

if u r able to retreive the new records maintained from KONM ,thn the probable solution u specified wud work..

Regards,

Mdi.Deeba

Read only

0 Likes
599

Yea it is the new condition record scale prices that are not reflected in Cdhdr and cdpos tables.

This is not condition type dependent. It is occuring for any condition.

Regards,

Shreya

Read only

0 Likes
599

There was no work around possible for this issue.

So the only solution is to add the required entries programmatically in desired internal table of type CDRED.

This only has solved the problem.

Thanks,

Shreya