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.” Figure 1 illustrates that scenario.

Figure 1

Security settings requested by the example company

After some discussion, Chris and Jaime also eliminated these three options:

• GET/SET parameters, which are only for defaulting values. Because the user can change them themselves, they aren’t meant for secure data.
  
  
• Custom tables, which you have to keep in sync with the roles. You have to make sure they are transported again every time you change the roles and that they have the same sort of security protection as transaction PFCG.
  
  
• Special naming conventions (e.g., Cost_Ctr_10000 role, Project_20000 role). The developer reads the user’s roles in the program code and works out limits from the name of the role. However, every time the limit changes you have to create new roles. At the company in this example, all users already have roles based on their jobs. The company wants to link limits to their current roles rather than create many new roles.

They then settled on using the Personalization tab in transaction PFCG. Using the tab, you can link the data to the security role and maintain and transport it with the security role transaction PFCG. You just have to add the financial delegation limits per account assignment category (Figure 2). I’ll show you how to implement it.

Figure 2

Use the Personalization tab to delegate financial limits

Set Up Personalization Data Functionality

A personalization key equals an entry in the Personalization tab on which you can drill down to view or enter the personalization data. In my example, you set up a personalization key that allows users to enter limits by account assignment category.

Before you define your personalization key, define a dictionary type that formally describes the format of the data to be maintained via the personalization key, such as whether it is a single field or multiple fields or a table, whether fields are numeric or character, the length, and any search helps that can help the user enter correct values. Do this in transaction SE11.

To create limits per account assignment category, you need to define a dictionary type that describes a table in which each line contains the account assignment category and its associated limit. A quick way to do this would be to create a Structure (e.g., ZACC_CAT_LIMIT). Define the format of each line as having two fields (i.e., Account assignment category and Limit) as shown in Figure 3. Then create a Table Type (e.g., ZACC_CAT_LIMIT_TABLE) in which your structure describes each line of the table (Figure 4).

Figure 3

A dictionary type (structure) containing account assignment category and associated limit

Figure 4

A dictionary type (table type) representing a table in which each line has the format of ZACC_CAT_LIMIT

Use transaction PERSREG to create the personalization key itself. It takes just one screen to define it. Give it a technical name (e.g., ZACC_CAT_LIMIT), give it a description, and enter your dictionary type against it (Figure 5). It is OK to use the same name as the dictionary type because these are different objects.

Figure 5

Create the personalization key ZACC_CAT_LIMIT in transaction PERSREG

Indicate the use of the default storage area by checking the generic repository check box. The generic repository is a special table (SPERS_OBJ) that can hold many different data formats. If you use the generic repository, you don’t have to create your own custom table or file to store the personalization data.

You also need to indicate whether the personalization data is relevant to the security role (transaction PFCG) Personalization tab or the user (transaction SU01) Personalization tab, or both, by selecting the relevant check boxes on the PERSREG screen. For a security role you would check Take into account in role changes and Copy with Role. If you want the personalization data to be transported along with your security roles, also select the check box Transport with roles. If you want to maintain them via the Personalization tab in transaction PFCG select the check box Visible in role maintenance.

If you have some ABAP skills or access to a developer, you can use the fields Dialog function module or Access class to provide your own routines to cope with more complicated scenarios, such as:

• Create your own screen with special formatting
  
  
• Store the data somewhere other than the generic repository
  
  
• Include extra functions such as starting a workflow event or creating an audit trail of changes to the personalization data

The system uses routines to override the default maintenance screen and data storage in table SPERS_OBJ. If you want to know how to code your own routines, just look at any of the many examples of SAP-provided personalization keys in transaction PERSREG. For example, if you look at the personalization key RESOURCE and the ABAP code in its dialog function module SUSR_RESOURCE_DIALOG, you can see that the main requirements are:

• Use the required function module interface. That is, you must use the parameters appropriate to personalization data maintenance — just copy them from any other dialog function module. There’s a similar interface to use if you are using an Access Class instead of the dialog function module.
  
  
• Read the existing data using the GET_DATA method of class CL_PERS_OBJECT_DATA.
  
  
• Present a view/maintenance screen to the user. The RESOURCE key uses a standard pop-up dialog STC1_POPUP_ WITH_TABLE_CONTROL, but you could use your own screen if you wish.
  
  
• Save the existing data using the SET_DATA method of class CL_PERS_OBJECT_DATA.

If you want to protect your personalization data even more, or want to have, say, a financials expert maintain the data without any risk of changing the security role, you can use transaction SPERS_MAINT. On the SPERS_MAINT entry screen, you can enter a user ID and find all the roles currently attached to the user to make sure you are maintaining the correct role (Figure 6).

Figure 6

SPERS_MAINT initial and maintenance screen

PERSREG lets you define a personalization key. Once you have defined it, you can then maintain the data in either transaction PFCG (SU01 if you are using user personalization) or transaction SPERS_ MAINT. However, you still need to read the data in user exits, workflow, and programs so you have to calculate the user’s financial delegation authority and apply it to the particular business case, such as approving SRM shopping carts. The data is stored in a special multi-format-handling generic repository table called SPERS_OBJ (Figure 7).

A quick look at the format of the generic repository table SPERS_OBJ shows you could create a report easily on this table SPERS_OBJ if you want to find out what roles have the ZACC_CAT_LIMIT personalization key maintained. You look at the fields Pers. level (A = role, U = user), Pers. obj. (role name or user ID), and Key (technical name of my personalization key).

It’s obviously not so easy to read back the limits programmatically by account assignment category as a table in the same way you entered it. This is because the generic repository has to handle many formats. The correct way to read your personalization data is to use the special routines provided as part of the personalization data technique.

To read the data attached to the role, use the method GET_DATA_ROLE in the ABAP class CL_PERS_ADMIN. All you have to do is provide the personalization key and the name of the security role, and the system returns the limits by account assignment category as a table using your predefined dictionary table type. Figure 8 shows an example of the ABAP code you would include in your user exit, workflow, or other program that needs to find the financial limits.

REPORT  ztest_persdata.
DATA:  acc_cat_limits_tab TYPE zacc_cat_limit_table,
       acc_cat_limits_line TYPE zacc_cat_limit.

CALL METHOD cl_pers_admin=>get_data_role
  EXPORTING
    p_pers_key          = ‘ZACC_CAT_LIMIT’
    p_role_name         = ‘ZTEST’
    p_refresh_buffer    = ‘’
  IMPORTING
    p_pers_data         = acc_cat_limits_tab
  EXCEPTIONS
    pers_key_not_found  = 1
    data_type_error     = 2
    no_data_found       = 3
    role_does_not_exist = 4
    not_set_to_default  = 5
    OTHERS              = 6.

LOOP AT acc_cat_limits_tab INTO acc_cat_limits_line.
  WRITE: / acc_cat_limits_line-acc_cat, acc_cat_limits_line-limit.
ENDLOOP

Of course, if you are in a program that is looking at a user ID, you still need to find out which security roles are assigned to that user so that you can calculate all of their limits across all of their roles. Class CL_PERS_ADMIN has a method GET_DATA that you can use to read all the personalization data assigned to a user regardless of whether it was assigned in the role or the user personalization tab.

Say you have a program that knows the security role and its financial limits, but you want to find all users assigned to that security role. Simply use function module PRGN_READ_USERS.

Now you know how to define, maintain, and use personalization data. The only thing left to do is to look at how you transport data from a development environment to a test environment to a production environment. You’ll need to do this because security roles are usually created in your development environment, tested in the test environment, and then transported through to production, where they are assigned to users. It usually makes sense, as it provides extra protection against unauthorized changes, to transport sensitive data such as limits in the same way, although if you are using personalization data to hold non-sensitive data such as defaults, it’s fine to just maintain the personalization data directly in your production environment.

Transporting personalization data is a simple extra step in the normal role transport process. As usual, you go to transaction PFCG and select the menu option Role>Transport. Enter the role to be transported on the transport selection screen, and click on the execute icon. A pop-up shown in Figure 9 then asks if you want to transport the personalization data with the role, and you just check the Personalization check box (it defaults to checked) to confirm this. Provided you checked the Transport with roles check box when you defined the personalization key in transaction PERSREG, your personalization data is transported along with the security role.

Figure 9

Pop-up window to confirm transport of personalization data with security role

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.

You may contact the author at jocelyn.dart@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.