10-20-2008 7:57 AM
We have a requirement to update a VBAK field (created for our own use as an extension to VBAK) based on a change to VBAK-LIFSK.
Our check statement for the change is as follows:
"IF YVBAK-LIFSK EQ 'ZZ' AND XVBAK-LIFSK IS INITIAL."
So if LIFSK was 'ZZ' and has now been changed to INITIAL we wish to update this other VBAK field. The check takes place in Form USEREXIT_SAVE_DOCUMENT_PREPARE.
This check functions correctly when we execute the change to LIFSK in dialogue. However, we have another background process that makes the change through BDC with 'Call transaction' in synchronous mode. In this case we are not detecting the change. Also, we are not able to interrupt this processing in debug mode so cannot check the values concerned.
Interestingly, we did have other problems in which field to update as a result of the above. We now move the value to both the VBAK and XVBAK occurrences of our new field.
I feel the probem is either due to a misunderstanding of the usage of the XVBAK//YVBAK/VBAK fields or that there is some difference in their handling when VA02 is run through BDC.
As ever, would much appreciate your assistance.
10-20-2008 11:09 AM
XVBAK <-- New data if any change/else it will be same as old
YVBAK <---Old value
VBAK <---work area
when you deal with Items it will be some thing like this..
XVBAP <-- New data if any change/else it will be same as old
YVBAP <---Old data if any change(considers item) /else it is blank
10-20-2008 1:32 PM
That was our understanding too. We wonder when XVBAK is overwritten with the VBAK values.
10-20-2008 1:42 PM
Hi
U should post all code of your user-exit, perhaps are checking the transaction code before checking VBAK-LISK
Max
10-20-2008 1:49 PM
Why are you not able to debug that? You can use debug for save_document_prepare exit.
10-20-2008 2:05 PM
Thank you for your interest. What really puzzles us is why the code works when we make the update through VA02 in dialogue but not when we execute VA02 within BDC. We have put soft break-points in the code without success. It's as though the execution of the BDC takes it out of our control.
Our code is fairly simple:
IF yvbak-lifsk EQ '01' AND xvbak-lifsk IS INITIAL.
MOVE sy-datum TO vbak-zzrdate1.
MOVE sy-datum TO xvbak-zzrdate1.
ENDIF.
The reason we update both fields (VBAK and XVBAK) is because we did have some issues in early testing where we weren't sure which was the field that would be used to update actual VBAK.
10-20-2008 2:33 PM
Hi
Try to insert an cycle DO/ENDDO in the user-exit in order to debug it while it's working in background mode:
DATA: _STOP(1).
DO.
IF _STOP = 'X'.
EXIT.
ENDIF.
ENDDO.
...................................................................
F yvbak-lifsk EQ '01' AND xvbak-lifsk IS INITIAL.
MOVE sy-datum TO vbak-zzrdate1.
MOVE sy-datum TO xvbak-zzrdate1.
ENDIF.
This is cycle without end, in this way you should have enough time to catch the background process by trx SM50.
So after running trx VA02, run trx SM50, find and select your process and go to
Program/Session->Program->Debugging
The program should be in the cycle DO/ENDO, so change the value of _STOP in order to go out form the cycle and go on the debug.
Max
10-20-2008 2:40 PM
Thanks for that Max. A break-point is the only way to understand what is happening.
12-25-2008 1:54 AM
Why not use hard coded break point?
ex.
BREAK your_user_name.
Edited by: Chih-Chieh Chan on Dec 25, 2008 9:54 AM
02-10-2009 11:45 AM
We have finally managed to replicate this problem. One way is to go into order change, double click on an order item, go to tab Sales B, change the sales district value (VBKD-BZIRK) and save. My conclusion is that if you only modify a non-VBAK field then XVBAK does not get populated.