Link Defaults, Limits, and Other Values Directly to Security Roles
- by Jocelyn Dart, Senior Solution Consultant, SAP Consulting
- May 1, 2006
Personalization data functionality introduced with SAP R/3 Release 4.6C enables you to link and maintain default settings, values, limits, and other data directly against security roles and user masters.
Even with all the customizing options available in SAP systems, every so often you need to store a little extra data to default settings for users or link limits and values to security roles. In the “old days” you might have had to use custom tables or GET/SET parameters in the user master or even put special naming conventions on security roles, none of which have ever fully solved the problem of storing sensitive data with security in a way that’s easy to maintain and monitor. In Release 4.6C, SAP introduced a better option, personalization data functionality, and quietly started using it in a lot of standard applications.
How do you hold complex data that isn’t an
SAP authorization but is directly related to the
users’ security roles or the user master? Data
that includes defaults, limits, and other values
that relate to the jobs they do? Companies have tried
all sorts of approaches. However, in R/3 Release
4.6C, a new and better option silently appeared in
maintenance) and SU01
Both have the Personalization
Ever wondered when and how to use it?
Late Thursday afternoon at the security administration
desk: It’s half an hour after the financial
delegations meeting and Chris is mulling over
how best to meet the new requirements. He has
until tomorrow morning to come up with suggestions. “So
they want a financial delegations limit by account
assignment category… hmmm… and
some managers in remote sites have special authority,
and some people have authority for cost center
but not project and vice versa. We also need
to allow for the limits changing because the
financial department rethinks those limits about
every six months.”
“Can’t they just use purchase requisition
release strategy classification?” asks
Jaime from the other side of the desk.
“No — that only relates to purchase
requisitions — we need something that handles
financial delegations for Supplier Relationship
Management (SRM) shopping carts, purchasing documents,
financial journal entries, workflow, and everything.
We need something we can read from any user exit,
workflow, or custom program that needs to know
financial limits. Besides, purchase requisition
release strategy is really about working out
the requisition’s release requirements
and not really about working out a particular
person’s financial delegation authority.
We want to link their financial limit to their
security role, so that if, say, John Smith has
the Level 1 Manager security role, he has financial
delegation authority of 0 to $5,000 for cost
centers and 0 to $10,000 for projects, and if
David Jones has both Level 1 Manager and Remote
Manager security roles he gets the cost center
and project limits just like John Smith but we
also increase his cost center limit to $15,000
because he is a remote manager.”
Would you like to see this full item?