11-13-2009 7:27 AM
Hi,
We have an issue of authorization missing for tcode ME22N.
The user was able to go to display/change purchase order from tcode vl10b (indirect cll of tcode me22n from tcode vl10b) without the assignment of tcode me22n.after support package application the user missed with the authorization and is not able to do the activity.
The su53 report says missing authorization for me22n but he was doing the same activity before without me22n.I want to know how the indirect call transction works and how can we enable it.
Any hints will help.
Regards
Ashok Dalai
11-13-2009 8:34 AM
These "Enjoy" transactions have a very strict tcode check in them. You can try to maintain the CALL TRANSACTION relationship in SE97 such that ME22N trusts VL10B and you might even be able to access the first screen, but you won't be able to actually use it.
The difference is because previously the system assumed that if you are in ME22N then you must have been authorized for it, so did not check it's own tcode for authorization again. Now, the system assumes that being in ME22N is no reason to believe that you must have been authorized to get there, so it checks it's own tcode for authorization again.
This means that you cannot create variant transactions for them either... at least not without making it known that they can in fact access the core transaction, which was the problem.
Cheers,
Julius
11-13-2009 8:09 AM
Hi Ashok,
Please check with SAP about the patch you have installed. Even we faced same type of issue after installing some patch, not able to recollate the same.
Raise a message with SAP.
Cheers
Deepanshu
11-13-2009 8:23 AM
look in OSS there are a lot of authorisation issues with follow on transactions in MM. This one might have been coorected in this suuport package.
Actually no follow on transaction should be called without the real transaction being called so it was an eror.
11-13-2009 8:34 AM
These "Enjoy" transactions have a very strict tcode check in them. You can try to maintain the CALL TRANSACTION relationship in SE97 such that ME22N trusts VL10B and you might even be able to access the first screen, but you won't be able to actually use it.
The difference is because previously the system assumed that if you are in ME22N then you must have been authorized for it, so did not check it's own tcode for authorization again. Now, the system assumes that being in ME22N is no reason to believe that you must have been authorized to get there, so it checks it's own tcode for authorization again.
This means that you cannot create variant transactions for them either... at least not without making it known that they can in fact access the core transaction, which was the problem.
Cheers,
Julius