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.
Key Concept
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 transactions PFCG (security role maintenance) and SU01 (user maintenance). Both have the Personalization tab. Ever wondered when and how to use it?

Typical Scenario

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.”

Jocelyn Dart

Jocelyn Dart is a senior solution consultant at SAP Consulting working in Australia/New Zealand. She currently specializes in workflow and Supplier Relationship Management (SRM). As well as speaking at various SAPPHIREs and at ASUG, Jocelyn is a co-author of the book, Practical Workflow for SAP.

See more by this author


No comments have been submitted on this article. 

Please log in to post a comment.

To learn more about subscription access to premium content, click here.