Trigger CREMAS change pointer for vendor classification change in XK02/FK02

Question

Hi,
I have a business case where I need to trigger a change pointer of type CREMAS whenever a client modifies vendor classification in transactions FK02/XK02.  I realize classificatiion/characteristics have their own change pointer types (CLFMAS, CHRMAS, etc.), but I was wondering if there was a user exit/BADI available for this scenario where I can manually create a change pointer.  I need the characteristic data to be part of a custom IDoc type (based off of CREMAS03), and it's no problem to include this data in the custom IDoc, but I need a way to trigger the change pointer if the clients changes vendor characteristic data, and nothing else. 
I also went into transaction BD52 for type CREMAS to see if there's another row for classification (CLASSIFY), but couldn't figure out the right object type.
There's a BADI called CACL_VALUE_CHANGE that triggers when vendor classification is changed, where I can generate my change pointer, but it's triggered before the client saves which means I would have a useless change pointer. 
Does anyone have any ideas on what my options are?  I hope I've elaborated enough
Thanks,
Chris

Answer 1

I figured out a way to do this which was to implement the BDCP_BEFORE_WRITE BADI which allows you to interrogate a change pointer based on an IDoc message type before it's saved to the database.  For starters, change pointers for message type CLFMAS must be activated in order for this to work, even though I'm not interested in those eventual IDocs. 
In the IF_EX_BDCP_BEFORE_WRITE~FILTER_BDCPV_BEFORE_WRITE method of the BADI implementation, I was able to loop through all of the change pointers about to be created and this is where I was able to obtain the vendor number the classification is being applied to.  I actually added another line to the internal table that's changeable in the method for CREMAS and it worked out well.
The only thing that was difficult was to debug this baby.  No matter how you set the breakpoint, it just never hits it until I discovered it's called using an UPDATE TASK.  I found an unorthodox method to debug this situation on the web which is to force an endless loop before your custom code such as.........
while sy-subrc <> 98.
endwhile.
<custom code here>
Once your process runs, it will be sitting in an endless loop in an update task which you can view in transaction SM50.  From here, you can highlight this line then you can click on "Program Session > Program > Debugging" to debug your code.  It's not something I was used to, but it allowed me to debug in the end.  I would hope there's better ways, but this worked for now.
I hope this helps someone else!
Cheers,
Chris