Little Challenge --How to give or restrict TRX in derive roles !

[Former Member]

Want to give 10 trx in 2 derive roles and 15 in another 2 derive roles from same Parent role-Any method to do so?One I know is to give additional 5 Trx access through manually Adding TCD in remaning 2 derive roleANY other way to give or restrict so that tabs should not be in manually or changed mode?

[jurjen_heeck]

That's just not the way the parent/derived concept works. To differ in non-organizational values (like S_TCODE) you'll have to create multiple parents.

If you deviate this much from SAP standard you'll have a 100% chance someone will accidentally break your concept in the future......

[Former Member]

Thanks for all for your time:I understand the concept of SAP parent-derive role.

Now the problem in hand is this:

We have a parent role whose various derived rolecountry-wise are already included in multipal composite roles.

we now want to more roles from this parent role which are having same ORG valuse but further down to site wise

Now the problem:

In these site wise derived role we dont want to give some TRX access as those TRX are not desired to use at End user BUT along with this we dont want to remove those from parent as in Middle level those are used.

Please Suggest

[jurjen_heeck]

> In these site wise derived role we dont want to give some TRX access as those TRX are not desired to use at End user BUT along with this we dont want to remove those from parent as in Middle level those are used.

> Please Suggest

Create new parents and new derived roles based on those parents (and possibly new composites) for the users who need them. All tries to find shortcuts will lead you to a situation which is bound to break down and/or cause major headaches in future maintenance.

In every case I've seen so far it turned out to be better to focus on a good consistent role design rather than having as few roles as possible. Some colleagues disagree but hey, we're all human

[Former Member]

What you can do is choose 10 transactions which are compleley org field irrelevant or have a known common set of org fields which do not relate to the additional 5 transactions.

The additional 5 must use objects which have org fields which are mutually exclusive from the org fields from the first 10 transactions.

Then, for 2 of the derived roles which should not be able to use the 5 additional transactions... just give them nonsense org field values which will render the transactions useless even if the user can start it.

Much too complicated - but theoretically possible in Trivial Pursuit...

Cheers,

Julius

[sdipanjan]

>

> so that tabs should not be in manually or changed mode?

Hi,

Excellent answer from Juluis. Also the way you want to do this is conflicting with the Ref-Derive role concept.

I can add/modify some thing to the previous two answers.

One point I want to make clear that you mentioned as quoted above. Do you mean to say that the S_TCode will not be in changed mode (_or_ need not to add S_TCode manually) in Profile generator?

If Yes, then please check the following approach:

1. Create your first parent role and pair of derived roles with 10 Tcodes.

2. Create one role as per the concept of Transaction role - value role. That means, the role will contain those 5 TCodes in the menu but will not contain any authorization (except S_TCODE, all objects should be deactivated).

3. Then create one composite role with these two (one derive role of the pair and the other single role).

if No, then follow this approach:

1. Follow step one of above.

2. Create one generic role without any menue entry. Add TCode manually in authorization tab and then 5 TCodes there.

3. Create another role (value role) [let me know if you need details concept on this] and maintain the authorization of those 5 TCodes here together with org. values.

4. Create composite role by using these three roles (one derive role from the pair, one generic transaction role and one value role).

But please note that the menue entry should not be maintained in the derive role in any circumstances and if you do then you are no longer maintaining SAP Ref-Derive role concept.

Please let me know if these help you to some extent.

Regards,

Dipanjan

[Former Member]

>

> Excellent answer from Juluis. 
> 

Are you sure? Actually, what I want to say is that you will be one of the guilty ones if you do this...

I think the moral of the story here is that derived roles make you inflexible, unless you are willing to make manual entries and deviate from the original concept of the parent or you are very sure that the offspring will be exactly Junior like Senior when they grow up.

It also adds complexity and lures into temptation of building smaller roles, and then using composites to club them, and then having problems with the usr-table limitations and buffers....

Good luck,

Julius

ps: If your search the forum for "inflexible" then you will find other discussions.

[Former Member]

Julius

from experience i can say NEVER allow manualy changes to derived roles as in due time this will fail!

[Former Member]

Thanks for all for your time:I understand the concept of SAP parent-derive role.

Now the problem in hand is this:

We have a parent role whose various derived rolecountry-wise are already included in multipal composite roles.

we now want to more roles from this parent role which are having same ORG valuse but further down to site wise

Now the problem:

In these site wise derived role we dont want to give some TRX access as those TRX are not desired to use at End user BUT along with this we dont want to remove those from parent as in Middle level those are used.

Please Suggest.

[sdipanjan]

Dear ARYENDRA,

This is very easy. Please create two set of Derived roles. One for the middle level users as you mentioned (those who still need these Tcodes) and one for the end user.

No change needed for the Middle level.

But for the end users the following action can be taken to restrict using those particular TCodes.

1. Prepare a list of Authorization Objects associated with Those TCodes.

2. Deactivate all of them in profile gen.

3. Some of the Objects may be used by some other necessary TCodes. In that case after deactivating all the relevant objects, please add only the required objects manually for the necessary Tcodes and assign the value as it was in standard and maintained. (but you should be aware that these values should not contain any activity other than 03).

Note: This approach may become nightmare during future maintenance and you should go for different set of Ref-Der roles for each level where TCode access and usage are different

Regards,

Dipanjan

Edited by: Dipanjan Sanpui on Apr 1, 2009 1:58 PM

[sdipanjan]

Hi ARYENDRA,

Please let us know if you have any query on the discussions done so far (or anything more). We have discussed theoretically / Hypothetically, Practically to make the scenario clear.

Thanks..

Regards,

Dipanjan

[Former Member]

The solution here we always use:

Create BASIC (TEMPLATE) Composite roles and as you cannot have derives of composites you will have to maintain these manually always.

Create singles for the additional transaction (template + only needed derived variants)

Let the Composites be a copy of the template and then add for county or other reasons the additional singles.

This solution allows you to have all your derived roles in line with the template role, but also allows to give specific roles with special transaction (for instance with county specific TAX transactions).

One lesson learned from large number of Multinational SAP implementations:

Although it usually is the wish of central management, no company can force their local affiliates to perform their tasks exactly the same in every affiliate. So it simply is impossible to create a template Functional (positions based) composite that can be used everywhere!

[Former Member]

Dear Auke,

Your solution seems interesting. However, it is not very clear in the following points.

1) is your template role a Composite role?

2) How do you make the Composite be a copy of the template?

3) How do you get your derived roles?

Maybe you can explain as a whole again in detail? We are facing the issue of the inflexibity of the derived role concept.

Thank you in advance

John