User exit to restrict in VA02

[Former Member]

Hi all,

i wants to provide only some user to change the reason for rejection field

in VA02 transaction. please tell me which user-exit i have to use.

The scenario is that, if a sales order is changed, then only few user can

change the reason for rejection field in VA02.

So please tell me in which user exit i have to code my logic.

[former_member187748]

Hi Srikant,

you have to code your logic in

FORM USEREXIT_FIELD_MODIFICATION.

Go to the transaction SE38, put the program name as MV45AFZZ

and inside this you will find the above mentioned exit, write your code

logic there.

[Former Member]

Hi Sanjeev,

if you don't mind can you please provide some sample code,

how to achieve this, because i am not getting, how can i restricts other users

to restrict other than some whom i wants to provide that facility.

[former_member187748]

Hi Srikant,

here is the sample code, please change it according to your use. In place of id put all the id's

you wants to provide change facility, the id other than specified here will not able to change the

reason for rejection field.

DATA : p_abgru TYPE vbap-abgru.

DATA: BEGIN OF WA_KNA1 OCCURS 0.

         INCLUDE STRUCTURE KNA1.

DATA: END OF WA_KNA1.

IF ( SY-UNAME NE 'id' AND SY-UNAME NE 'id' AND SY-UNAME NE 'id' ) .

     IF SY-TCODE EQ 'VA02'.

       IF VBAK-VBELN IS NOT INITIAL AND  VBAK-KUNNR IS NOT INITIAL.

         CLEAR: P_ABGRU.

         SELECT SINGLE * FROM KNA1 INTO  WA_KNA1 WHERE KUNNR = VBAK-KUNNR.

         SELECT SINGLE * FROM KNVV INTO KNVV WHERE KUNNR = VBAK-KUNNR.

         SELECT SINGLE ABGRU FROM VBAP INTO P_ABGRU WHERE VBELN = VBAK-VBELN.

         IF P_ABGRU IS NOT INITIAL.

           CLEAR: VBAK, VBAP, VBKD.

           MESSAGE 'You are not authorized to edit cancelled or Rejected Sales Orders ' TYPE 'E'.

         ENDIF.

       ENDIF.

     ENDIF.

   ENDIF.

[Former Member]

Hi,

Create a ztable and maintain user id in the table who are authorised to change reason for rejection in

sales order. if any other user changes the reason raise error in user exit

USEREXIT_SAVE_DOCUMENT_PREPARE to stop the system from saving document

Thanks & Regards,

Akshay Ruia

[former_member221891]

In the mentioned user exit, please create a include with a Z name.

Z<name> if found.

Create a TVARVC variant with th elist of user ID s who have authorization as per your need.

TVARVC is a SAP standard table.

You can save variants in SM30 , TVARV.

Save your variant with a name of your choice (parameter) and store user ids in it as you need.

Then within the include, before your code logic, include a select query on TVARVC table with name as variant name you have just created and then only for the user ids that are retrieved , compare the sy-uname and proceed if it exists in the list.

[Former Member]

Hi Sriknath,

As Akashya was correctly mentioned!  better to use the USEREXIT_SAVE_DOCUMENT_PREPARE.

because the reason for reject is item level! You can validate your code

* it will trigger when the sales order is changed

loop at xvbap where updkz eq 'U'.

if xvbap-abgru is not initial.

check xbvak-ernam = ' user name'.

message error.

endif.

endloop.

dont hard code the user names inside the user-exit. Better to maintain the table to restrict to set the reason for rejection.

[Former Member]

Hi Kiran,

why are you opting to use USEREXIT_SAVE_DOCUMENT_PREPARE

it is triggering at

FORM USEREXIT_FIELD_MODIFICATION.

as sujjested by sanjeev kumar

i have to check only that if a sales order has been cancelled, then only 4 persons

should be able to change reason for rejection.

, so what is the problem if i will put my code there

and i have to provide only 4 users this facility, so for the same reason

can i create a ztable and maintain it, is it justificable.

[former_member187748]

Hi Kiran,

i have worked on the same topic , and for the same purpose some months ago,

and i put my code as i have shown above in the

FORM USEREXIT_FIELD_MODIFICATION.

and it is working fine, i didn't get any issue till now, can i know the reason for your support

in SAVE_DOCUMENT_PREPARE.

[nabheetscn]

Hi Sanjeev

Kiran is proposing the right thing. If you read the documentation of both the methods it is recommended to use FIELD_MODIFICATION for modifying the field attributes and PREPARE to be used for for checks before saving.

No doubt it has worked for you but sometime in your screen you navigate to such a place where this field modification wont trigger. But Prepare will trigger for sure

Hope it clarifies

Nabheet

[former_member187748]

Ok Nabheet,

thanks a lot for your information.

Got it.

[Former Member]

Hi Srikant,

Please check the explanation from Nabheet!

Reason for rejection is nothing but stopping the sales order for further processing! If you have 1000 line items in the sales order. If user sets the reason for rejection for 150, 800 item only. the user exit  USEREXIT_FIELD_MODIFICATION will trigger each and every item and your checks has to perfrom each and every time.

so instead of that I proposed! just check before saving in a single stretch ( see my code above)!

- today you have the 4 users , if user left from the organization and new user joined. definitely you have to modify the code again. may be in future you will have 20 users.. do you want to hard code 20 users again????

so better to use the table/control table ( tabe maintained ) - compare the table with your VBAK-ERNAM ....this is the right option...

Hope you understand my proposal!

[Former Member]

Hi Kiran,

thanks for your reply, but i have only one line items with each sales order no,

not having many, because for me scenario, i have to check only one sales order

per instance.

When it comes to having more user id, i have to give this to selected senior level

persons, which will always 4 (might 1 or 2 more added, and the id are as per post, no no need

to change it always).

So please tell me, i have written my code under MODIFICATION

and its working as per as requirement, should i change it.

[Former Member]

Hi Srikant,

Its entirely your call, if you are satisfied and the requirement is working fine you can code in modification.

But keep in mind that if the line item number increases it may create performance issue. If the same validation needs to be done at header level, again the same code needs to be rewritten in some other exit.

thanks & Regards,

akshay ruia

[Former Member]

Hi Kiran,

While I agree with you on having a custom table to maintain users or rather have a authorization object for this purpose, I dont agree with you on the performance concern. As you have mentioned, MODIFICATION is triggered for each and every record depending on the screen which you are navigating. But it does not mean that we should trigger our logic to check authorization all the time. We can just trigger it once, and set a flag and use it through out. There are many ways that we can avoid triggering our logic each time MODIFCATION is called.

( And just FYI, even standard code select an entry from the table J_3AFMGRP within the screen loop.)

[Former Member]

Ideal place is FORM USEREXIT_FIELD_MODIFICATION which is in MV45AFZZ. This is triggered in the PBO of most of the screens ( surely in item overview scree and size level screen where you find rejection reason) within the SCREEN Loop. So you dont need to raise an error message.

Just change SCREEN-INPUT to make the field input enabled/disabled based on your requirement. I would do something like below for your requirement.

IF T180-TRTYP <> 'V'. "V means change mode.(VA02)

RETURN.

ENDIF.

DATA: lv_authorized TYPE as4flag.

Have your logic to determine the authorization here. I would recommend you to create a custom authorization object rather than creating a Z table which gives more controlability.

Based on your logic, set the LV_AUTHORIZED flag to 'X' if the user is authorized to change the rejection reason.

And below is all what you need to do to control the field property.

CASE SCREEN-NAME.

  WHEN 'J_3ASZDI-ABGRU'. "This is the item level rejection reason

  IF lv_authorized = 'X'.

   SCREEN-INPUT = '1'.

  ELSE.

   SCREEN-INPUT = '0'.

  ENDIF.

  WHEN 'J_3ASZDI-J_3AABGRU'. This is the size level reason rejection.

  IF lv_authorized = 'X'.

   SCREEN-INPUT = '1'.

  ELSE.

   SCREEN-INPUT = '0'.

  ENDIF.

ENDCASE.

[Former Member]

Hi,

As you mentioned it will trigger in most of the case, which means it will fail in some of the cases. This should never happen. it should be successful in all the cases.

Thanks & Regards,

Akshay Ruia

[Former Member]

According to Srikanth's requirement, his case is Rejection Reason. There is no field in Sales Order processing which is used in each and every screen. So USEREXIT_FIELD_MODIFICATION is the ideal place to control a field properly.

You can achieve the same via SAVE_DOCUMENT_PREPARE. But if you think from the user's perspective, he will get to know that he cant play with rejection reason only at the time of saving the order.

But if you do this in the USEREXIT_FIELD_MODIFICATION, you can make the field un-editable so that user knows he cant mess with the field when he goes to the screen.