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: 

Creating Debit Memo Request and changing mvgr1 field in vbap

Former Member
0 Kudos

I'm trying to create a Debit Memo Request when there is a contract. During this process, I want to change the vbap-mvgr1 field if it's a certain project type. I've tried almost all of the userexits in Include MV45AFZZ using xvbap. I've mostly tried userexit_move_field_to_vbap, userexit_save_document and userexit_save_document_prepare. In debug mode I see it change, but it doesn't change in VBAP. I was able to create code using the enhancement framework and it update the screen in va02, but it still didn't update VBAP. I'm not sure what else to try. It appears to be material driven and we're not changing the actual mvgr1 field in the material master, but we want to change it based on project type on the Debit Memo Request.

Here is sample code:

data: zzvbak like vbak.

data: zzprps like prps.

if vbak-auart = 'ZDRU'.

case xvbap-mvgr1.

when '006'.

select single * into zzvbak from vbak

where vbeln = xvbap-vgbel

and auart = 'ZPC'.

if sy-subrc = 0.

select single * into zzprps from prps

where pspnr = xvbap-ps_psp_pnr.

if zzprps-prart = 'AM' or zzprps-prart = 'ME'.

xvbap-mvgr1 = '102'.

elseif zzprps-prart = 'AD' or zzprps-prart = 'ND'.

xvbap-mvgr1 = '302'.

endif.

endif.

when '104'.

select single * into zzvbak from vbak

where vbeln = xvbap-vgbel

and auart = 'ZPC'.

if sy-subrc = 0.

select single * into zzprps from prps

where pspnr = xvbap-ps_psp_pnr.

if zzprps-prart = 'AM' or zzprps-prart = 'ME'.

xvbap-mvgr1 = '101'.

elseif zzprps-prart = 'AD' or zzprps-prart = 'ND'.

xvbap-mvgr1 = '301'.

endif.

endif.

endcase.

endif.

1 ACCEPTED SOLUTION

tamas_hoznek
Product and Topic Expert
Product and Topic Expert
0 Kudos

Instead of changing xvbap-mvgr1, try to change VBAP-MVGR1 in USEREXIT_MOVE_FIELD_TO_VBAP.

11 REPLIES 11

tamas_hoznek
Product and Topic Expert
Product and Topic Expert
0 Kudos

Instead of changing xvbap-mvgr1, try to change VBAP-MVGR1 in USEREXIT_MOVE_FIELD_TO_VBAP.

0 Kudos

Thank you for your quick response. I did try userexit_move_field_to_vbap and it didn't work either. I was able to create an implicit enhancement using the enhancement framework, but all that did was put it on the screen when you call va02. It did not update VBAP. I don't understand why this isn't working because everything I read on help and about the userexits, it should work. Please let me know if you have any other suggestions I may try.

tamas_hoznek
Product and Topic Expert
Product and Topic Expert
0 Kudos

I just tried the solution I suggested to you and it worked flawlessly.

0 Kudos

Trust me, I believe you. I just tried it again and it's not working for me. Can you put in the code showing how you did it? That would be helpful. I thought it was my hardcoding so I picked the right one from the tvm1 table and it still didn't update.

thanks so much.

0 Kudos

Also, what tcode did you use to test this. Keep in mind I'm creating this using tcode DP90(resource related billing) on contracts only. I'm not using VA01 to create the DMR.

tamas_hoznek
Product and Topic Expert
Product and Topic Expert
0 Kudos

All you need to do is insert this line in subroutine USEREXIT_MOVE_FIELD_TO_VBAP:

VBAP-MVGR1 = 'xxx'.

where xxx is a valid material pricing group.

Make sure you change VBAP, not XVBAP.

tamas_hoznek
Product and Topic Expert
Product and Topic Expert
0 Kudos

Ah, I didn't realize you are using tcode DP90. I tried it in VA01 / VA02. That flow may be different and it is possible that there is some code later updating this field.

Does the processing even stop at USEREXIT_MOVE_FIELD_TO_VBAP if you set a break-point there?

0 Kudos

Thank you so much for your quick responses. It's well appreciated and I will award points. I did insert exactly what you said to do using VBAP and it still doesn't work. Yes the debugger does stop there and believe me I've been in this debugger for a week trying to figure this out. This is a tough one. It does change vbap and right before it commits to database in function module VPKI_RRB_SM_COMPLETE. I just can't capiture it there, but you get there through VPKO_CREATE_SALES_DOCUMENT which will take you to VPKSD_CREATE_SALES_DOCUMENT and that creates the DMR number but isn't in VBAP yet.

As you can see, I've really been in this debugger a lot.

Thanks. I'll keep plugging away and if you have any other suggestions, please let me know.

tamas_hoznek
Product and Topic Expert
Product and Topic Expert
0 Kudos

After a quick glance at the function modules you mentioned, I'm not certain that the field MVGR1 is even updated with any value when the FM creates your sales document. It is possible that this value is ignored so that this item field is not updated at all by this FM. This would explain why the value is not in the document after you see MVGR1 changed by the userexit.

If that's the case, you may have a hard time to change this behavior... there are enhancement points but it doesn't mean you'll be able to persuade this FM to populate MVGR1 in the item.

But it certainly requires some more digging to see if any of these enhancements can help. Even then, if the FM interface doesn't contain this field, it may not work... so it doesn't look good unless I have missed MVGR1 as an available item field in the posting FM.

0 Kudos

Thanks again. You've been very helpful. You confirmed exactly what I've been seeing. I'll dig a little further, but I've been in here for about a week. I was thinking about letting it create the DMR and then do a BDC to change that field before it creates the Debit Memo to see if the Debit Memo will have that item goes back to the original mvgr1 for that material. We may have to create materials for these new mvgr1 groups.

0 Kudos

Thanks again for your response. We've decided to write a BDC and run the job before we do billing. I just tested it and that works. I would dig further, but time does not permit me to do that.