topic Re: Authorization Group for MB51 in Application Development and Automation Discussions

Authorization Group for MB51

Former Member — Fri, 15 May 2009 11:36:22 GMT

Hi,

We want to limit users to only seeing movements for a custom material type ZRSA. . There are 5 storage locations currently that we have for Maintenance and that authorization object M_MSEG_LGO is set to those types.

I went in transaction SU24 (maintain the assignments of authorization objects) and set the

check indicator to include object M_MATE_MAR (Material Master: Material

Types ) for MB51 meaning an authorization check will be carred out against this

object in MB51. This was needed to limit users with this role to

seeing only ZRSA material types. How and where do we create the Authorization group for BEGRU to bec checked in auth object M_MATE_MAR? Is this even possible.

Also how can you create an entry into table TMBG (Material Master authorization groups)?

Thank you so much,

Jennie Winn

Re: Authorization Group for MB51

Former Member — Fri, 15 May 2009 13:51:14 GMT


> Hi,
> 
> I went in transaction SU24 (maintain the assignments of authorization objects) and set the
> check indicator to include object M_MATE_MAR (Material Master: Material
> Types ) for MB51 meaning an authorization check will be carred out against this
> object in MB51.

i would be ever so surprised if this object would work with MB51 (whether you add it to SU24 or no. SU24 would work only, if the authority-check was actually coded in the transaction and i have scanned RM07DOCS and it ist not checked), so do not get up your hopes here.


>How and where do we create the Authorization group for BEGRU to bec checked in auth object M_MATE_MAR? Is this even possible.

BEGRU is a field in object M_MATE_MAR and works with a couple of transactions which you can list using SU24. however MB51 is not amongst them. you can maintain BEGRU by maintaining material types in table T134.

 
> Also how can you create an entry into table TMBG (Material Master authorization groups)?
> 
> Thank you so much,
> 
> Jennie Winn

SPRO or SE16N + &sap_edit

Re: Authorization Group for MB51

Former Member — Fri, 15 May 2009 14:30:43 GMT

Mylene,

Thank you so much for your expert response. I have never used SU24 until now. How do you know when adding an authorization object check to a transaction if it will work? Does it have to be coded in the program?

When do you really need to use SU24? I have been reading about it in Authorizations Made Easy, but I guess there is a lot more to it than I understand yet.

Thanks again,

Jennie

Re: Authorization Group for MB51

sdipanjan — Fri, 15 May 2009 18:02:46 GMT

Hi Jen,

Just to give you w brief of the SAP Authorization check infrastructure:

Every Transaction code consists of one or more screens and these screens are basically a Dynpro (Dynamic Program).

When you put some data in a screen of a TCode and try to move forward, then these programs are executed to update or display database / data.

Now you can visualize that where and when these objects are checked and how: Authorization objects are mentioned in the program of such a screen with "AUTHORITY-CHECK" statement. So, the authorization checks for a particular Object is only possible for a TCode if and only if the Object is encoded by a AUTHORITY-CHECK.

AUTHORITY-CHECK OBJECT 'S_CTS_ADMI'

ID 'CTS_ADMFCT'

FIELD IV_ADMINFUNCTION.

SU24 is the documentation (you may say) for these Objects.

1. some of them are checked and take the values hardcoded in the program and will not require to maintain.

These Objects appear with Check indicator = Check and Proposal = No in SU24.

2. some of them are checked and require values to be maintained by later while in use.

These Objects have Check indicator = Check and Proposal = YS in SU24.

2nd categories are pulled into Profile generator for maintaining it's values.

3. there is also one more category : Do Not Check - This is just to reduce unnecessary checks.

Let me know if you have any query. I tried to explain in layman lang fot better understanding.

Regards,

Dipanjan