Question:
Hello,
What is the simplest possibility to create one role for a couple of clerks in a way that they only can work in their own sales org?
thanks Martin
Answer:
Hi
I don't think it is poss. to let two clerks work only in their own sales org. by assigning just one role.
But however u can create one role as a parent role and then create another role as a child role which inherits the transactions from the parent role.
Then u can change the org. data and assign diff. sales orgs.
But in this case, separate profiles will be generated but u can assign these roles to diff. users.
Regards
suril2031
Answer:
Just create a role for the users as individual roles. You may not be a able to limit to just their sales org, it will depend on the tcodes you assign.
In any case DO NOT use Derived roles on an on-going basis!!! THere are too may problems and too much maintenance long run. ou can use derived role to create role ( but why not just copy?) and then have the "child" grow up by severing the relationship.
Answer:
What is with structural authorizations, is there a way to bind a sales org. to a HR-Org.unit and let the users only access their own org.unit?
Answer:
In any case DO NOT use Derived roles on an on-going basis!!! THere are too may problems and too much maintenance long run.
john, why not used "inheritence" relationships? I find it very useful and much easier to maintain in the long run than seperate roles, especially when one role serves several different users that the only difference between them is the "org data". I remember that you also said not to use coposite roles... why?
Answer:
What is with structural authorizations, is there a way to bind a sales org. to a HR-Org.unit and let the users only access their own org.unit? Structural authorization is a separte control on the HR org structure. It takes the authorized HR records that are allowed by a person's P_ORGIN (must be turned on) and only allows the records associated to the user as dictated by the HR structure. You have to turn on Structural authorization ( also called PD Profiles). By default everyone gets what SAP* has, which is everything and yes it will control SD if the config is on correct.
john, why not used "inheritence" relationships? I find it very useful and much easier to maintain in the long run than seperate roles, especially when one role serves several different users that the only difference between them is the "org data". I remember that you also said not to use coposite roles... why? SAP securiy is Risk based not "I do not want" based. If the roels are only different by org levels then why have separate ones? Has the risk analysis been done? what is the loss ( risk) to the company? What is the potential of occurance? and what is the cost? Answers in the case are: Almost no loss, Very low possibility, and high cost. So do not do it. All roles have an inherent cost to maintian so the more you have the more the cost.
Also there is a nasty little button inthe parent that will wipe out any differences ( other than orgs) in the children. If you only maintain the org, parent-child leads to more roles as you will eventually need one-offs.
Security is not intended to prevent training, abdicate someone's stewardship responsibilities of implement I WANTS or Need to know. It is to prevent substantial loss to the company.
Composite - Major increase in maintenance in just finding which piece to change. Then having to negative test EVERY comosite the singel is attached to. Increased chances of SoD. Poor auditability... and the list goes on.