Why does this happen?
Moderators: Snowy, thx4allthefish, YuriT, Gothmog
Why does this happen?
Hi.
Put some code in user exit RV60AFZZ, form USEREXIT_NUMBER_RANGE. The code basically takes data from XKOMV and updates a custom field on VBRP and another on VBRK. This is accomplished by updating the working tables XVBRP and XVBRK. When an invoice is created via VF01, these fields are updated correctly and all is well.
The problem is when that invoice is cancelled (VF11), no actual cancellation takes place. There is a cancellation doc number created, but no actual cancellation.
Could anyone tell me why this happens? Thanks, I am fairly new to SAP/ABAP, so any help is welcome.
Thanks!
Crocker.
Put some code in user exit RV60AFZZ, form USEREXIT_NUMBER_RANGE. The code basically takes data from XKOMV and updates a custom field on VBRP and another on VBRK. This is accomplished by updating the working tables XVBRP and XVBRK. When an invoice is created via VF01, these fields are updated correctly and all is well.
The problem is when that invoice is cancelled (VF11), no actual cancellation takes place. There is a cancellation doc number created, but no actual cancellation.
Could anyone tell me why this happens? Thanks, I am fairly new to SAP/ABAP, so any help is welcome.
Thanks!
Crocker.
Re: Why does this happen?
What do you men, precisely, by 'no actual cancellation takes place'?crocker wrote: The problem is when that invoice is cancelled (VF11), no actual cancellation takes place. There is a cancellation doc number created, but no actual cancellation.
.
Sorry for the confusion....When VF11 is run with my logic, a new document number for the cancel is displayed at the bottom of the screen, but when you go to look up that number in VBRK, VBRP it does not exist. When I comment out my code and run the same scenario, the cancel works as it suppossed to.
It seems like by updating the XVBRK, XVBRP tables I am causing problems.
It seems like by updating the XVBRK, XVBRP tables I am causing problems.
-
- Posts: 1398
- Joined: Thu Dec 04, 2003 8:16 am
- Location: Stuck in a pagoda with Tricia Toyoda
any old userexit will do...
I just reread your post. USEREXIT_NUMBER_RANGE is for changing the number range used (often to have number ranges per company code or sales org, rather than per doc type). Seems you're using it for something other than what it was intended for.crocker wrote: It seems like by updating the XVBRK, XVBRP tables I am causing problems.
First he pinches my sig, Now he's cribbing my posts too!
Thanks for your reply. Where it works great for the creation of an invoice and not for the credit is what has me a bit puzzled. But I agree that perhaps I need to find another userexit.
This exit showed promise due to the fact that XKOMV, XVBRP and XVBRK were all available. I needed to get tax fields from XKOMV moved to my new custom fields within VBRP and VBRK.....all the others I debugged and checked did not provide these tables at the same time....
Thanks again for your response!
This exit showed promise due to the fact that XKOMV, XVBRP and XVBRK were all available. I needed to get tax fields from XKOMV moved to my new custom fields within VBRP and VBRK.....all the others I debugged and checked did not provide these tables at the same time....
Thanks again for your response!
Take a look at this note: 415716
It is for User exits in delivery processing. Not exactly your specific, but it has a lot of interesting and useful info. Especially for how to correctly update xvbak, etc.. tables.
If you look there should also be a specific note for your needs.
Have not found it myself.
If you do let us know...
Phillip
It is for User exits in delivery processing. Not exactly your specific, but it has a lot of interesting and useful info. Especially for how to correctly update xvbak, etc.. tables.
If you look there should also be a specific note for your needs.
Have not found it myself.
If you do let us know...
Phillip
I have abbused this exit too. XVBRK(P) is an internal table with header line. For each temporary document the user exit is called (vbeln = $....). If you change the body of the internal table make sure you change the header line accordingly. Actually, it is the header line that is being processed, not the body.
Oscar.