Can you provide me with details on Derived Roles? Pros? Cons? How are they used in 4.6C?
I will avoid all the gory details around table structures, although it would be worth your time to review some of them. Derived Roles make a lot of sense if you have a very disciplined business process in which every business unit (plant, company code) uses the exact same functional (transactions and Reports) roles with only organization differences (cost center, plant, PC, company code...) and minimal authorization differences (sales types, material types, material views). If so... best practice (my own, you asked for advice:) )would stipulate that you modify table USOBT (SU24) to include the appropriate standardized authorization values for each transaction code. You would then create your model roles (although some of the USOBT activity will occur concurrently) and begin deriving roles for organizational differences.
- New transactions added to say a GL Clerk Role for 80 different plants (ie. 80 plant specific GL roles) is painless. Since adding the t-code to the model, imports it into the derived.
- Roles are kept very consistent from the model role to the derived.. typically if you fix a transaction related problem in the model (and do the USOBT trick) you fix it in all the derived.
- Have to be disciplined
- Have to be consistent
- Can be a lot of upfront work
- Not always very flexible