SAP Basis Notes: SAP Upgrade Procedure

After an upgrade, you must make adjustments to the user and role administration. What these are depends on whether you were already using the profile generator in the source release.

In the following, it is assumed that you have not yet used the profile generator, and that you are not upgrading from SAP R/3 3.0F.

If you were already using the profile generator in the last release, read Source Release with the Profile Generator (> SAP R/3 3.0F).

First of all, choose one of the following options:

Convert the profiles that you manually created to roles. To do this, choose step 6 in transaction SU25.

This has the advantage that the administrator can assign all of the existing, thoroughly checked profiles to the corresponding roles. You can, however, only create a user menu for the role if the corresponding authorizations for the authorization object S_TCODE are contained in the profile. Additionally, you cannot use the configuration tables (USOBX_C, USOBT_C) in which the predefined authorization values are contained.

Carry out a new implementation of the authorization administration using the profile generator.

This has the following advantages:

Customers’ experiences have made it clear that the time invested in the new implementation of the authorization administration pays off with a large time saving during other maintenance of the user and authorization data.

Your employees can take advantage of user-friendly user menus.

We recommend the second option. In addition to the advantages already mentioned, you can use the three level model for the implementation of roles, as shown in the section First Installation Procedure. A redesign of the authorization administration using the three-level model makes sense in the long term, in that the work time that an authorization administrator must expend for the maintenance of the roles can be significantly reduced.

If you have decided to use the second option (Redesigning the Authorization Administration), read the First Installation Procedure, and the following advice:

Plan the conversion of profiles to roles. Produce a list of transactions and associated profiles for which you want to set up roles. Use the Infosystem (transaction SUIM). You can download the Infosystem lists to a Microsoft Excel sheet and use it as the basis for the migration to be performed. Contact the departments and discuss which roles should be provided for which departments.

During the conversion to roles, you can decide if the naming conventions that you used have proved to be useful. If necessary, you can define a different naming convention.

Create the new roles in the development system.

The following procedure may be useful when copying the authorization values from the old profiles:

Open three sessions in the SAP system.

In the first session, start transaction SU02 and choose a profile that you want to convert to a role

In the second session, call transaction PFCG and create the new role there.

In the third session, start the transaction SUIM as a utility for maintaining the authorizations. Choose Authorization Objects ® Authorization Objects by Complex Selection Criteria. Enter the name of an authorization object. You want to know, for example, in which profile the object S_TABU_DIS is used. Choose Where-Used List. Choose the profile for which you want to create a role. Select the profile and choose Expand Subtree.
You can now search for the desired authorization object (in this case S_TABU_DIS) and enter the authorization values in the role.

When you have finished the conversion of profiles to roles, call step 2C of transaction SU25.

All roles that are affected by newly added authorization checks and must be correspondingly supplemented. Edit and regenerate their authorization profiles. The system assigns the status Profile comparison required to the affected roles. Step 2C uses a traffic light system to display which roles must be checked after an upgrade. For revised roles, the traffic light is green. For roles that have not yet been revised, the traffic light is red. You can call the report repeatedly without overwriting adjustments that you have already made.

Transaction SU25 would have produced no output for profiles. It makes sense to create the roles beforehand, in order to find out which roles authorization checks have been added for.

Call step 2D to find out if transaction codes have been changed in the new release. You can also download this list to a Microsoft Excel sheet and then remove the old transaction codes during the test phase once the testers are satisfied with the new transactions.

Step 2D uses a traffic light system to display which roles have already been revised after the upgrade. For revised roles, the traffic light is green. For roles that have not yet been revised, the traffic light is red. You can switch the traffic light from red to green by double clicking it. You can call the report repeatedly without overwriting adjustments that you have already made.

In Step 2D, you can use the following pushbuttons to add new transactions to roles or to replace old transactions with new ones:

Manually adjust menu

You can manually replace or add transactions.

Automatically adjust menu

Old transactions are automatically replaced by new ones.

Automatically add menu

You can use this function to add the new transactions to each role. The system checks whether the role already contains each individual transaction. It is only added to the role if this is not the case. In this way, the users can continue using the old transactions until they have had time to learn how to use the new ones.