Master role inherits everything to derived role. Can I change that?

[d_laber]

Dear Gurus,

I am new to SAP and very thankful for every help I can get. I hope you can understand my problem!

I have defined a master role where I did not fill out every authorization object (yellow triangle), because I have different authorities for every derived role. Now my Problem.

If I change sth. in my master role now. Everytime I generate it I have to re-define the particular authorities in my derived role. Is there any way to avoid that?

Can I somehow give authorities to derived roles which are not changed by the master role everytime?

Thank you very much for your help!

D.

[koehntopp]

That's the way it's supposed to work

Derived roles should usually only differ in organizational levels, not in other authorizations.

Frank.

[Former Member]

Those fields you are looking for are called Org. Levels.

If you hang on for a while, then someone called Shekar might turn up and show you a controvercial trick. Whether that is bad luck or good luck is debatable... but for sure an interesting flamewar will break out...

Generally I should also use the search if you suspect that you are not the first person to face a certain doubt.

Cheers,

Julius

[Former Member]

>

> If you hang on for a while, then someone called Shekar might turn up and show you a controvercial trick. Whether that is bad luck or good luck is debatable... but for sure an interesting flamewar will break out... 
> Generally I should also use the search if you suspect that you are not the first person to face a certain doubt.
> 
> Cheers,
> Julius

Julius and his subtle ways.........

Thanks for the nice introduction, Julius

I dont know if this is what is called link farming but have a go

[]. make sure you read the attached link and also the post i have in it & click the link without fail

Edited by: Shekar.J on Jan 21, 2011 12:03 PM

@ Julius: Thnx4allthefish

[Former Member]

I was reading that thread from the last post back up to the first one and then almost fell off my chair...

Cheers,

Julius

[Former Member]

C'mon....it wasnt that bad

never ending perenial struggle between idealism vs Reality........everyone would love to be an idealist, if their day today is taken care of - aint it?

By the way, unless there is a better option with the inheritance concept reality does'nt change.....or does it?

generic question @ALL: If one has inter-company sales/purchases - How does someone manage vendor customer authorization groups via the inheritance concept? surprising to note that no one ever questioned on that

[Former Member]

I have run into that a few times...

Plan A: drop the word "key user" into a conversation and wait to see which anti-key and non-key requirements respond.

Plan B: move the respondents over to the transactions based on logistical events and remove as much FI access as possible.

Plan C: if anyone is still left standing, make them a real key user and give them a concept to make selective use of the priviledge during interesting times...

Personally I prefer the concept of logistical events such as orders, requests, movements... creating their own indirect financial postings, and not the other way around...

Cheers,

Julius

Edited by: Julius Bussche on Jan 23, 2011 9:27 AM

[Former Member]

>

> 
> Personally I prefer the concept of logistical events such as orders, requests, movements... creating their own indirect financial postings, and not the other way around... 
> 
> Cheers,
> Julius
> 
> Edited by: Julius Bussche on Jan 23, 2011 9:27 AM

That exactly is what we are striving for. I can make my case with the right examples, but my position as a consultant forbids me to discuss my client's business situation....._Excuse me, i withdraw from the discussion._

Not that i want to have the last say, But i still say the same thing.......for my view, promoting a field to an org value is as sinister as duplicating an object with a pre-defined value. I remember that one of our co-forum members suggested that having a org value as a pre-defined value is a "rule-break" - but when you fill the org values in a role in the first instance are'nt we pre-defining the value for which the role should work? or when we pre-define values for the RESPAREA field aren't we pre-defining values?

@OP: I know i don't have the greatest solution, and i am sure no one would come up with one unless something drastically changes with the way SAP works with authorizations for commonly shared objects/values........ Good luck in your quest and do follow the advice from Julius and others

[Former Member]

RESPAREA is a very hot potatoe, and classic example where roles as building blocks have a chance to survive as "derived" roles or "value" roles.

Promoting it to an org. level is not without controversy and pain-ponits. The "activity / action" type fields of the objects which use it have a hearty mix of functions and you need to rely on naming conventions to get it right.

Much like batch input session names...

Demoting a field when you reach it's technical limits is still the ultimate D'oh moment

Cheers,

Julius

[Former Member]

the ultimate D'oh moment 
> 
> Cheers,
> Julius

I thought it should be a Dúh moment (relating the expression to Big Moose from Archies) and not a Dóh moment

by the way there are two things to infer out here

1. The limitations you would have to live with in the inheritance concept

2. We were primarily discsussing about a work-around and not about Idealism and Reality?

Now that we have ended having such a lenghty conversation in someone else's post, Firstly i would like to apologise to the OP and then i would be glad to hear, why is it wrong to have a duplicate object in a role with a value. As you mentioned in the other post, Is it just because the role reaches the maximum limit of the number of org values it can hold? or is it like becaue of hard-coding of values? ( personally i am ruling out a discussion on the hard-coding part as the statement doesnt hold ground)

Over to you, dear julius

[arpan_paik]

Master derived always do have some limitations and the real fact is that it do not have any good solution to overcome with. After a analysis in our last client system it was found that there are 21 non-org level field which has different value from master depending on market to market.

Out of this 21, 19 field was uniform accross the role. So getting them to org level was the best way but actual heat felt when in a running system those get converted and lot of manuall work performed.

For the rest 2 (I do not remember their name) the value was not uniform through out a role so promoting was not possible. And their I go with solution for managing extra role with manuall object.

It lead to create some extra roles it's true. But If I look at business I will say it was good to have. Controll is still there over rest of the object, role menu etc. Having it single role, after 2-3 years there definately will be some dissimilarity accross the market. From business control that is not good in my view.

I hope one day SAP will come up with some better solution on this. Like profile generator once?

Regards,

Arpan Paik

[Former Member]

Hi,

There is a workaround which we follow in our organization for a few handful of sensitive objects for a few roles.

In the master role, the sensitive object is made "INACTIVE". For various child roles an "exception" role is created with just the sensitive object with desired value. A Composite role is created with combination of the child role + "exception role" and is assigned to users.

This will work for a few sensitive objects for a few roles.

Regards,

Partha.

[arpan_paik]

Try add object in derived role only manually.

Regards,

Arpan paik

[Former Member]

Hello D.

Please could you give a few examples of the values that you wish to exclude from the 'adjust-derived' e.g. are they cost centres?

Regards

David

[d_laber]

Hi David,

I want to maintain things like displaying, changing and deleting rights in the master role. In the derived role I will have things like cost centers.

Thanks for any further help and the great response so far!

regards.

D.

[Former Member]

Well, you can use ABAP program PFCG_ORGFIELD_CREATE to move cost center field to org level and maintain values in each derived role individually.

[arpan_paik]

Promoting non-org level field to org level should be done before role designing that is planning phase. Please look into documentation before applying the same. In a running system you may face many problem with that. End up with manually role correction.

Also take a note that for cost center (an example for non-org level field), is the value uniform in a role? If so then only promoting to org level will worth. Else a new problemm will come in way.

Regards,

Arpan Paik

[d_laber]

Thanks for the hints,

we are just trying if it its worth the effort to make an org_lev for every single role . We have a lot of roles and are more or less in the planning phase. By tomorrow I will know if we can solve it like that. But this was very useful!

Thanks again!

regards.

D.