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: 

Material Master (MM01/MM02) Field Level Security

Former Member
0 Kudos

I have the Views (M_MATE_STA) segregated per departments in my Roles.

I also have the few fields suppressed & Display-Only for MM01 & MM02 (OMS9). However the 'Field Level Restrictions', as you know, are at the transaction level. Thus, they apply to all the users.

I have a requirement to restrict few fields (MM01 & MM02) to Display Only for 'Complaince Team' & supress few fields for the 'Engineering Team' in the same 'Basic Data' view.

How do I do this ?

Thanks

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Prasanth,

I have a requirement to restrict few fields (MM01 & MM02) to Display Only for 'Complaince Team' & supress few fields for the 'Engineering Team' in the same 'Basic Data' view.

How do I do this ?

In this case you have build two roles, one is for dispaly access for MM01 & MM02 - this goes for complaince team

Second role for supress few fields for the 'Engineering Team' in the same 'Basic Data' view for MM01 & MM02

As you can't restrict both in the same role.

Thanks

Sri

13 REPLIES 13

Former Member
0 Kudos

What you need to do is plan a hierarchial approach to build this role

the conflicts could arise between authoirization object and organizational level values

Create roles if its a value to be populated only at authorization object level

Level 1 highest authorization values let us say 1,2,3,4,5,6,7,8

Level 2 .............................. values let us say 1,2,3,4,5,

Level 3 .......................... values let us say 1,2,

in the above case you will have to build three different roles.

In case you have this value to be filled as Organization level

Then build a parent role and derive three times and insert the required values.

Lastly if you have both authorization object and organization level

build three different role for the same but maintain the hierarchial pattern of values for each role at both authorization object and

organizational levels.

Edited by: Franklin Jayasim on Jul 2, 2010 12:25 AM

Former Member
0 Kudos

Hi Prasanth,

I have a requirement to restrict few fields (MM01 & MM02) to Display Only for 'Complaince Team' & supress few fields for the 'Engineering Team' in the same 'Basic Data' view.

How do I do this ?

In this case you have build two roles, one is for dispaly access for MM01 & MM02 - this goes for complaince team

Second role for supress few fields for the 'Engineering Team' in the same 'Basic Data' view for MM01 & MM02

As you can't restrict both in the same role.

Thanks

Sri

Former Member
0 Kudos

Hi Prashanth,

I suppose your question deserves more thought than of creating a display role and a modify role.

If you have the time and patience try reading earlier posts that could be similar

here is one:[]

0 Kudos

Shekhar,

What are you posting? Here query asked by prasanth is quite different from the post you have mention?

Our goal is to authorize some users to create/modify material master data (MM01/MM02) depending from the combination of views (basic data, purchasing, mrp, ..) and field DIVISION (SPART) in the "General Data" frame of "Basic Data 1" label.

in short : In one role two restriction? Is it possible?

I have a requirement to restrict few fields (MM01 & MM02) to Display Only for 'Complaince Team' & supress few fields for the 'Engineering Team' in the same 'Basic Data' view.

Thanks,

Sri

0 Kudos

>

> Shekhar,

>

> What are you posting? Here query asked by prasanth is quite different from the post you have mention?

>

> Our goal is to authorize some users to create/modify material master data (MM01/MM02) depending from the combination of views (basic data, purchasing, mrp, ..) and field DIVISION (SPART) in the "General Data" frame of "Basic Data 1" label.

>

>

> in short : In one role two restriction? Is it possible?

> I have a requirement to restrict few fields (MM01 & MM02) to Display Only for 'Complaince Team' & supress few fields for the 'Engineering Team' in the same 'Basic Data' view.

>

> Thanks,

> Sri

There is a lot in common with the post provided by Shekar. The poster is asking how to extend the authorisation concept to greater granularity than the material status restriction provides.

Your approach will allow the segregation of views but does not cater for the requirement to restrict specific fields within the views (depending on who is viewing it). For that, it is likely that customisation is required. I agree with your approach to split the views and unless there is a high material risk (no pun intended) if the fields are changed, would put a compensating control in place to identify if and when the fields were inappropriately modified.

Cheers

0 Kudos

>

> Shekhar,

>

> What are you posting? Here query asked by prasanth is quite different from the post you have mention?

>

> Our goal is to authorize some users to create/modify material master data (MM01/MM02) depending from the combination of views (basic data, purchasing, mrp, ..) and field DIVISION (SPART) in the "General Data" frame of "Basic Data 1" label.

>

>

> in short : In one role two restriction? Is it possible?

> I have a requirement to restrict few fields (MM01 & MM02) to Display Only for 'Complaince Team' & supress few fields for the 'Engineering Team' in the same 'Basic Data' view.

>

> Thanks,

> Sri

do read what Alex says in the post above (thanks, Alex)

we need to understand a basic fact, the basic data views in material master are at client level and these are not controlled at Sales organization or Division level by default. Restrictions for particular views is one part of the story, if restrictions to particular fields are to be made based on departments, unless you have specific user groups defined and you make use of transaction/screen variants and some very good ABAP programming you cannot achieve what you set out for, and after doing all this one would inevitably end up in a complex and tight situation pretty quickly

if you find my post irrelevant or ojectionable.......well you have a free choice to make your opinions.....it wouldnt change my thoughts on what can and cannot be done in material master

Edited by: Shekar.J on Jul 2, 2010 1:36 PM

0 Kudos

Hi,

.......Once you got support from Alex,suituation will be different. you can see that

well you have a free choice to make your opinions.

With that document if prasanth query gets solved I will be more happy.

Thanks,

Sri

0 Kudos

This message was moderated.

Former Member
0 Kudos

Hi Prashanth

There are lots of good points flying around on these posts, while you can restrict at field level, you really need to work out if you should go down this route which will likely require development effort.

As I mentioned before, personally I would strongly consider the approach recommended by Sri & Franklin unless there is a concrete business need for further selective restrictions.

Let us know how you get on

0 Kudos

I would re-iterate what i said earlier, Restricting the organizational dependent 'tabs" is one part and trying to make restrcitions on Basic data is another part. I feel all of us are contemplating on what can be done, but I think to get a concrete result someone needs to make a real attempt to try the restricitons on Material Master.........so can someone test what i am talking of and let us know the outcome

0 Kudos

Sorry Shekar, I see what you mean. For some reason I read the other advice was restricting on status / screen only, hence the "use mitigating control" comment.

0 Kudos

Shekar, Sri & Alex, Thanks for all your thoughts and inputs. I agree with you all... I was 'not-for' any customization myself.

Wonder why SAP did not extend its Customer/Vendor Field Grouping functionality here ... anyway... thanks again for your responses.

0 Kudos

Hi All,

we have solution for this with a BADI BADI_MAT_F_SPEC_SEL, you can check OSS Note 746875 for more details with user Authorization group we can control.