Important Authorization Objects

SAP delivers ECC 6.0 with more than 3000 authorization objects. Remembering even a tiny
fraction of the total number is a daunting task. SAP help provides adequate documentation on the
fields and use of most, if not all, the delivered objects. So instead of repeating existing
information here, I would just mention a few of the existing authorization objects and their
applications.

Tables Security for tables are controlled through three authorization objects,
S_TABU_DIS (based on the table authorization group), S_TABU_CLI (security for
client independent tables) and S_TABU_LIN (row level access to tables).
Reports Reports/Executable programs (Executable programs are just one of many
different types of programs) can be protected through S_PROGRAM. S_PROGRAM
checks if the executing user has access to the program authorization group maintained as
a program attribute.
Background Jobs The basic object is S_BTCH_JOB. To administer jobs created by
other users, users would also need S_BTCH_ADM. To schedule jobs with the access of
another user would require S_BTCH_NAM.
Spools S_ADMI_FCD, S_SPO_ACT, S_SPO_DEVand S_SPO_PAGE.
S_SPO_ACT can be used to give access to spools with specific authorization values.
S_ADMI_FCD in addition to spools controls access to a lot of system
administration/Basis function.
User/Roles A number of authorizations like S_USER_AGR, S_USER_AUT,
S_USER_GRP, S_USER_OBJ, S_USER_PRO, S_USER_SAS. You can segregate the
access for role administration with that of user administration by use of these objects.
BDC Sessions S_BDC_MONI. Batch Sessions are one of the possible ways of loading
data into SAP. Sessions are monitored through the SM35 transaction. S_BDC_MONI
allows security on session names and the possible activities (process, lock, delete) on
sessions.
ABAP Work Bench Access to ABAP development objects is controlled through
S_DEVELOP. Controls are possible on object type, object name, activity, and packages.

You might have noticed that all the above authorization objects begin with S as they deal with
System Administration. I have purposely not included authorization belonging to the individual
application components like MM, FICO, SD or HR as a discussion of these do nt make sense
without discussing the applications themselves. So, we keep these for a later post.
SAP Authorization Objects Tables
Table Name

Description

TOBJ

Authorization Objects

TACT

Activities which can be Protected (Standard activities authorization fields in the

system)

TACTZ

Valid activities for each authorization object

TDDAT

Maintenance Areas for Tables

TSTC

SAP Transaction Codes

TPGP

ABAP/4 Authorization Groups

USOBT

Relation transaction > authorization object

USOBX

Check table for table USOBT

USOBT_C

Relation Transaction > Auth. Object (Customer)

USOBX_C

Check Table for Table USOBT_C

User Tables
Table
USR01
USR02
USR03
USR04
USR05
USR06
USR07
USR08
USR09
USR10
USR11
USR12
USR13
USR14
USR30
USH02
USH04
USH10
USH12
UST04
UST10C
UST10S
UST12

Description
User master record (runtime data)
Logon data
User address data
User master authorizations
User Master Parameter ID
Additional Data per User
Object/values of last authorization check that failed
Table for user menu entries
Entries for user menus (work areas)
User master authorization profiles
User Master Texts for Profiles (USR10)
User master authorization values
Short Texts for Authorizations
Surcharge able Language Versions per User
Additional Information for User Menu
Change history for logon data
Change history for authorizations
Change history for authorization profiles
Change history for authorization values
User masters
User master: Composite profiles
User master: Single profiles
User master: Authorizations

Authorization Objects Checked in Role Administration

The role administration functions (and the Profile Generator) check the following authorization
objects:
Authorization Object

Description
User master maintenance: Authorizations

S_USER_AUT
This authorization object defines which authorizations the administrator can
process. You can use the activities to specify the types of processing (such as
creating, deleting, displaying change documents).
User master maintenance: User groups
S_USER_GRP
The authorization object is used in role administration when assigning users to

roles and during the user master comparison.

You can divide user administration between several administrators with this
authorization object, by assigning only a certain user group to an administrator.
You can use the activities to specify the administrators processing types for
the group (such as creating, deleting, and archiving).
User master maintenance: Authorization profiles
S_USER_PRO
Profiles are protected with this authorization object. You can use the activities
to specify the administrator's processing types for the profile (such as creating,
deleting, and archiving).
Authorization system: Check for roles
S_USER_AGR
This authorization object protects roles. The roles combine users into groups to
assign various properties to them; in particular, transactions and authorization
profiles.
You can use this authorization object together with the authorization objects
S_USER_GRP, S_USER_AUT, S_USER_PRO, S_USER_TCD, and
S_USER_VAL to set up a distributed user administration.
Authorization system: Transactions in roles
S_USER_TCD
This authorization object determines the transactions that an administrator can
assign to a role, and the transactions for which he or she can assign transaction
authorization (object S_TCODE).
Note that a user can only maintain ranges of transactions for the S_TCODE
authorization object in the Profile Generator if he or she has full authorization
for the S_USER_TCD authorization object. Otherwise, he or she can only
maintain individual values for the S_TCODE object.
Authorization system: Field values in roles
S_USER_VAL
This authorization object allows the restriction of values that a system
administrator can insert or change in a role in the Profile Generator.
This authorization object relates to all field values with the exception of the
values for the object S_TCODE.

S_USER_SYS

The authorization to include transactions in a role or to change the transaction

start authorization in a role is linked to the authorization object S_USER_TCD.
Authorization object for system assignment in the Central User Administration
(CUA).
You can distribute users from a central system to various child systems of a
system group. The object S_USER_SYS is used to check the systems to which
the user administrator can assign the users. This authorization object is also
checked when setting up the CUA.
User master maintenance: System-specific assignments

S_USER_SAS
The authorization object S_USER_SAS is checked in transactions SU01,
SU10, PFCG, and PFUD when you assign roles, profiles, and systems to users.
It represents a development of the authorization objects S_USER_GRP,

S_USER_AGR, S_USER_PRO, and S_USER_SYS, which the system

previously checked when users made assignments. If you do not activate the
authorization object S_USER_SAS using the Customizing switch, the
previously-used authorization objects are checked.
To activate authorization object S_USER_SAS, use transaction SM30 to create
the Customizing switch CHECK_S_USER_SAS with the value YES in the
table PRGN_CUST. All authorization checks for the objects S_USER_AGR,
S_USER_PRO, S_USER_GRP, and S_USER_SYS with the activity assign are
replaced by authorization checks for the object S_USER_SAS.
Administration functions for user and authorization administration.
S_USER_ADM
The authorization object S_USER_ADM protects general Customizing and
administration tasks for user and authorization administration. It consists solely
of the authorization field S_ADM_AREA.
Until now, there was only the fixed value CHKSTDPWD, with which special
users (such as SAP*) could be displayed, including their default passwords.
SAP extends additional fixed values as required for other general
administration functions in the area of user and authorization administration,
which are listed in SAP Note 704307.
For more information about the authorization checks, see the system documentation for the
authorization objects. To display this documentation, choose Environment Authorization
Objects Display in role administration (transaction PFCG). Expand the corresponding node
and choose the I button for the relevant authorization object.
Authorization Checks when Adjusting Derived Roles
You are maintaining the authorization data for a role in the Profile Generator (transaction PFCG,
by choosing Change Role on the Authorizations tab page), and want to transfer this data to the
derived roles (Authorizations Adjust Derived Save Derived Roles).
The authorization checks performed here correspond to those that would be performed if you
adjusted the derived roles manually. The following checks are performed, in the order in which
they are listed:

...

1.

Changing a Role

The user requires change authorization for all derived roles (S_USER_AGR, activity 02). To
avoid inconsistencies between the derived roles, the process is terminated, if the authorization
check fails for at least one role. A list of all roles for which change authorization has not been
assigned is displayed first.
2.

Saving the Profile names

The system automatically generates profile names for roles to which no profile name has yet been
assigned (starting with "T-"). The system then checks whether the role administrator is
authorized to save the name (S_USER_PRO, activity 01). The program also only continues in this
case, if all checks are successfully performed, because roles with no profile names cannot be
correctly saved. The profile and role names for all failed checks are displayed.

3.

Removing the Authorizations from the Derived Roles

During the adjustment of derived roles, their authorization data is completely removed and
replaced by the data of the original role. Since the authorizations of the derived roles can be
maintained individually, the system must check whether the administrator has the required
authorizations for S_USER_VAL to be permitted to remove them. If the derived roles also
contain manual authorizations for the object S_TCODE, the corresponding rights for
S_USER_TCD are also required. If the checks are not successful for all derived roles, the process
is terminated after displaying the missing authorizations.
4.

Copying the Authorizations from the Original Role

The administrators authorizations for S_USER_VAL and S_USER_TCD are also checked here.
Note that full authorization is required in the field AUTH_VALUE of S_USER_VAL for
authorization fields that contain ranges of values (see also SAP Note 495282). If the derived role
also contains manual authorizations for the object S_TCODE, the corresponding rights for
S_USER_TCD are also required. These conditions also apply for point 3. In the case of missing
authorizations, a list is again displayed before the process terminates with an error message.
5.

Generating the Profiles

If you have chosen the function Generate Derived Roles, you also require the authorization
S_USER_AGR with activity 64 for the original role and the derived roles. For structural reasons,
it is not possible to adjust derived roles if you do not have authorization to generate the profile of
the original role, since this action is performed before the adjustment process. If this is the case,
the system displays system message 425 (class S#). Derived roles for which the profiles cannot
be generated due to missing authorization are displayed in a list at the end of the adjustment
process. The profiles of all other roles are generated. Termination is not required, since the
authorization data of the derived roles cannot become inconsistent. After confirming the list, the
system displays message 680 (S#) to complete the process. If all profiles have been generated, the
system displays the message "Action performed successfully".
You can also use a background job to adjust derived roles. To do this, schedule a variant of the
report SUPRN_REGENERATE_DEPENDENT, in the selection screen of which you enter the
name of the original role in the field TOP_AGR. To also generate the profile, select the field GEN
with an "X", otherwise leave it empty. If authorization checks fail during the run, these are
recorded in the job log.
You can adjust the data for all derived roles in a single work step. If there are multiple derived
roles for an original role and you want to adjust the authorization data for all derived roles to the
data of the original role, we recommend that you use one of the functions listed under 3 or 4,
instead of adjusting the roles individually with Transfer Data.
Creating Role Menus
You can create the role menu in the following ways on the Menu tab page, which are explained in
more detail below:

Copying Menus

Buttons for menu extension: Copying transactions, reports, other objects, and authorization
default values

Additional activities

Other functions

Copying Menus
With these functions, you copy some or all of the menus of other roles.
You can activate the automatic redundancy avoidance for the following activities to ensure that
there are no repeated entries in the newly created menu:

For single roles, when reading menus from

The SAP menu

Roles

Area menus

A file

For composite roles, when reading menus from single roles

To do this, make the entry CONDENSE_MENU_PFCGin the Customizing table SSM_CUST

with the values "NO" (default value) and "YES". In the role administration tool (transaction
PFCG), choose Utilities Settings on the detail screen for a role. On the dialog window, set the
indicator Menu: Do Not Insert Existing Entries. Standard NO.
You can override these global default settings for specific users. If you select Utilities Settings
and Copy Menu: Do not insert existing entries, Default: NO/YES on the detail screen of any role
(Display or Change Roles), redundancy avoidance is activated. Otherwise, it is not active.
Although this setting applies only for this user, it applies for all of the roles for which he or she is
editing the menus.
The system uses the short texts of the folder hierarchy and the short text, the transaction code, and
the target system of the menu entries o determine redundancies. The system does not investigate
menu entries for other objects. We recommend that you display the "Technical Name" so that you
can see the effect of the redundancy avoidance. If a number of roles are assigned to a user, it can
be useful to continue to use the redundancy avoidance of the Easy Access Menu.
Even if you have removed redundant folder hierarchies in all roles, there can still be redundant
submenus in the Easy Access Menu of a user, if roles with wholly or partly identical menus are
assigned to the user. In this case, it is useful to keep the redundancy avoidance of the Easy Access
Menu active.

From the SAP menu

To copy complete menu branches or parts of menu branches, select these or expand them and
select only the subordinate nodes or individual transactions and repots that you want to copy to
the menu.

You can also copy submenus using an RFC link if you want to use the menu from another
mySAP Workplace component system for example. Specify a target system and choose From
SAP menu. You can specify whether you want to copy the menu locally or the menu of the target
system of the RFC link. If you choose Remote, you are offered the SAP menu of the target
system.
Use the same procedure for the options From other role and From area menu.

From a role

You can use this function to copy a menu structure that is already defined for a role in the same
system or from a role delivered by SAP to the role that you are currently editing.

From an area menu

You can copy area menus (SAP Standard and your own) into a role menu. Choose an area menu
from the list of menus and copy the transactions you want.

Importing from a file

You can copy menu descriptions from external products to the SAP system if the external product
creates a file with the menu definition that can be uploaded into a role. If you want to create this
file yourself, see the procedure in SAP Note 389675.
Buttons for Menu Extension

Transaction

You can extend the user menu by directly entering a transaction code.

Report

You can use this function to add reports, transaction variants, or queries in the user menu. You do
not need to assign a transaction code to the reports, transaction variants, or queries to be included
in advance.

ABAP report
Choose a report and a variant. Set the corresponding indicators to automatically generate
a transaction code and to copy the description of the report.

SAP Query
Enter the name of a user group and of a query. If the query has a variant, you can specify
it. You can also specify a global query. For more information, see Query work areas.

Transactions with variants

The system administrator can create transaction variants in the SAP system personalization.
Transaction variants adjust complex SAP system transactions to customer business processes, by,
for example, hiding superfluous information and adding other information such as pushbuttons,

text or graphics. You can put a transaction variant call in a user menu by entering the transaction
code and variant which you created in the transaction SHD0.

BW report

To include a report from the Business Information Warehouse, enter the ID of the report in the
appropriate input field.

ReportWriter, Search, Report

You can use these functions to include application-specific report types in the user menu.

Other

In this case, a system-specific list is displayed, from which you can insert additional objects.
Depending on the system, the list may contain additional entries as well as those listed below.

URL (Web address or file)

To enter Internet/intranet links, enter a descriptive text and the Web address. You can
enter a file name if the browser can call an application.

Predefined URL from directory

If you want to use some URLs frequently, for example, you can predefine URL objects in
the Object Navigator (SE80). To do this, choose a development class and Create Other
URL objects in the context menu in the Object Navigator.

BW WebReport
You can publish queries which were defined in the Business Explorer Analyzer, in the
Intranet or Internet with Web Reporting. You can insert the queries in any HTML pages
to present them. You can also put various queries in an HTML page and use predefined
navigation buttons or graphics to display the data.
For more information, see the documentation for the Business Information Warehouse
and the SAP Service Marketplace under service.sap.com/bw Documentation
Documentation Enhancements.

WebSource from Drag&Relate Servlet

Enter a name and a URL which you have defined in the Web Source Editor of the
Drag&Relate servlet which is delivered with the mySAP Workplace. URLs that you
define in the Web Source Editor allow Drag&Relate between the mySAP Workplace and
the World Wide Web.
For more information, see the mySAP Workplace Drag&Relate documentation.

External Mail System

You can integrate a call of a mail system.

Knowledge Warehouse link

Choose the information object type with the input help for the Document field. You go to
a selection screen in which you can search for the object in the Knowledge Warehouse.

Authorization Default Value

You can use this function to copy authorization default values for the subsequently listed entries,
without this being visible in the SAP Easy Access user menu. This is useful, for example, if your
users use a Web browser. In this situation, the Web server accesses the backend system using the
relevant user and starts transactions there, for example. Since the users do not access the backend
system themselves, however, they also do not require entries for the corresponding actions in
their user menus, but rather only the undisplayed authorizations, so that the Web server can start
the transaction for them.
You assign, for example, authorization for transaction SE61 with the role that you are editing, but
this is not displayed in the SAP Easy Access menu. On the other hand, for example, transaction
SE63, which you insert using the Transaction button, is displayed in the SAP Easy Access menu.
The entries have different icons so that you can tell them apart while creating the menu.

Transaction
Copies the authorization default values for transactions.

RFC Function
Copies the authorization default values for RFC function modules. Currently, the correct
authorization default values for the authorization object S_RFC are automatically copied.
You must still add the other authorization values required for the relevant function
module.

Service
Copies the authorization default values for services. From a technical point of view, there
are two types of services: Repository services (program ID) and external services. All
services that are managed in the repository in the SAP system and which have an object
catalog entry are combined under repository services. In this case, the input help displays
only the services for which there are authorization default values. External services are
services that were created outside the SAP system, such as a Java program. In this case,
the input help displays only the services for which there are authorization default values
in the current SAP system. The names of the external services, which can be any length,
are abbreviated to 132 characters in the input help, meaning that there can be identical
names.

How to create and assign an Auth Group to a table

Go to SE54, Give the table name and choose authorization group and then click on create/change.
You can create an authorization group.
Example:
You can assign a table to authorization group Z001. (Use transaction SM30 for table TDDAT) A
user that wants to access this table must have authorization object S_TABU_DIS in his or her
profile with the value Z001 in the field DICBERCLS (authorization group for ABAP Dictionary
objects).

Transporting and Distributing Roles

Use
In role administration, you have the following options for transporting roles:

You can download the roles from one system and upload them into another

You can import the role from a remote system using RFC

You can transport the roles with the transport function.

Role upload loads all role data, including authorization data from a file into the SAP system. The
user assignments for the role and the generated profiles for the role are exceptions in this case.
Transporting Roles with the Role Transport Function

Start the role administration function by choosing Tools Administration User

Maintenance Role Administration Roles (transaction PFCG).
1.
2.

Enter the role to be transported and choose Transport Role.

The Mass Transport of Roles screen appears. You can control the default settings for the options
Also transport single roles for composite roles and Also transport generated profiles for roles
using Customizing switches (see Role Administration Functions in the section Functions of the
Utilities Menu).
You should not change the authorizations profiles of the role after you have included the role in a
transport request. If you need to change the profiles or generate them for the first time, transport
the entire role again afterwards.
3.
In the following dialog box, specify whether the user assignment and the personalization
data should also be transported.
If the user assignments are also transported, they will replace the entire user assignment of roles
in the target system. To lock a system so that user assignments of roles cannot be imported, enter
it in the Customizing table PRGN_CUST using transaction SM30. Add the line
USER_REL_IMPORT and the value NO.
If you are using Central User Administration (CUA) with global role assignment, you should not
transport the user assignments of a role together with the role. In this case, you can only create
user assignments in the central system. You can then send these to the system group that you have
defined, if appropriate. If you nevertheless import user assignments for roles into the child
systems of the CUA in these circumstances, the central system is not informed about the changes
to the user master records. This means that data for the users in the child systems that you have
changed in this way is overwritten with the data from the central system during the next
distribution. Therefore, the user assignments created locally in the child systems with the role
import are deleted.
4.

Enter a transport request.

The role is entered in a Customizing request. Use Transaction SE10 to display this.

10

The authorization profiles are transported along with the roles, unless the profile parameter
transport/systemtype is set in this SAP system to value SAP. In this case, only the profiles whose
roles are assigned to customer-relevant delivery classes are transported.
You can also use a Customizing entry to prevent authorization profiles from being transported
with the roles. In the transport source system, add the entry PROFILE_TRANSPORT with the
value NO in table PRGN_CUST. In this case, you must use transaction SUPC (mass generation)
or transaction PFCG (generation of profiles for individual roles) to generate the profiles in the
target system after the transport.
5.

Perform a user master comparison in the target system.

You can create perform a user master comparison in the following ways:

To perform the comparison in the background, schedule the report

PFCG_TIME_DEPENDENCY periodically in the background.

To perform the comparison immediately, start report PFCG_TIME_DEPENDENCY.

To perform the comparison immediately, in transaction PFCG, choose Utilities Mass

Comparison and enter the affected roles in the Role field on the User Master Comparison screen.
Then choose Perform User Master Comparison.
Distributing Roles
In role administration, you can distribute roles on the Menu tab page, as long as the target system
has a release status of at least SAP Basis 4.6A.
Performing a Mass Generation of Profiles
Use
You can use the mass profile generation transaction to determine which roles already have
authorization profiles. You can also perform a mass generation of roles or generate the missing
role authorization profiles for roles in the background.
Prerequisites
You will need the following authorizations to use Transaction SUPC:

User master maintenance: Authorization Profile (S_USER_PRO)

User master maintenance: Authorizations (S_USER_AUT)

Authorization system: Check for roles (S_USER_AGR)

Procedure
1.
In role maintenance (transaction SUPC), choose Utilities Mass Generation in the role
maintenance (transaction SUPC).
2.

Specify the desired selection criteria.

11

To generate all profiles to be generated automatically (last checkbox), you can further
restrict the role selection in the next screen.
Comparing User Master Records
Use
The user master record comparison consists of three types of comparison:

The profile comparison

With this, the profiles of time-dependent role assignments are updated.

You cannot set time limits for authorization profiles and their entry in user master records.

The composite roll area

This updates the role assignments defined in composite roles, that is, added or deleted.

The organizational management comparison

This generates the direct role assignments from the indirect role assignments of the organizational
management model.
You can also choose the Clean-Ups option to delete invalid, generated profiles, and invalid role
assignments.
Procedure
1.

Start transaction PFUD.

2.

Specify the roles that you want to use for the comparison.

3.

Choose one of the following actions:

Schedule or check job for the full comparison

Here you can start report PFCG_TIME_DEPENDENCY by specifying the time when the
job is to start. The overview displays the status of background jobs that have already been
scheduled.
If you schedule the report PFCG_TIME_DEPENDENCY daily before the start of
business as a total comparison and it runs error-free, the authorization profiles in the user
master are up-to-date every morning.
If you choose this action, all four processes types are always included, regardless of your
selection under Processing Type. To execute only certain processing types of the
comparison as a background program (for example, with the aim of improving runtime
behavior), choose Perform User Master Comparison and the desired processing types.
Then choose Save, to schedule a variant of the program RHAUTUPD_NEW.

Performing the User Master Comparison

12

With this action, you start the user master comparison in dialog for individual roles. You
can select the required processing types (see 4.).
4.
If you have selected Perform User Master Comparison, choose one or more of the
following processing types:

Profile Comparison: Start the profile comparison immediately after generating or

importing profiles. If you are using time-dependent role assignments, we recommend that you
schedule this daily as a background job. This compares the authorization profiles with the user
master records; that is, profiles that are no longer current are deleted from the user master records
and the current profiles are entered in the user master records.

Composite role comparison: Start the composite role comparison if you make changes to
a composite role definition (that is, if you add or delete single roles to a composite role) or import
a change. Single-role assignments are compared with the composite role assignments for the user.
If you add single roles to the composite role, the single roles are assigned to those users that are
assigned the composite role. Conversely, if single role assignments are deleted for the users, the
single role is removed from the composite role.

HR comparison: Start the HR comparison, if you make changes to your local

organizational management model that influence the indirect role assignment or transport these to
the system. You can only select this processing type if organizational management is active; that
is, if the switch HR_ORG_ACTIVE is set in the table PRGN_CUST to YES.

Clean-Ups: Perform clean-ups when you generate or import profiles. Generated profiles
that no longer exist are deleted. Regular clean-ups are particularly important if you transport your
roles and profiles frequently, as this helps to solve possible inconsistencies quickly.
You can also select the following options:

Display error messages: All error messages are displayed on the screen in dialog mode.

Replicate local HR assignments in the central system: You can only select this option if
you are in a child system of a CUA group and if organizational management is active. This option
replicates the role assignments that exist in the child system that originate through relationships in
the local organizational management model, for information in the CUA central system. You can
display these relationships in the user maintenance (transaction SU01).
Result
Following the comparison the system displays a log that includes any errors that occurred
(background processing log for a background job).
Comparing and Adjusting Role Menus
Use
You can use this procedure to compare role menus that

Belong to two roles in an SAP System

Belong to two roles in different SAP Systems

13

Belong to a role and its template

Belong to a newly-delivered role and its previous customer version

Prerequisites
To compare two role menus from different systems, their RFC destinations must be maintained.
Procedure
To compare the role menus, use the display mode by choosing the Compare pushbutton . To
adjust the menu of the first role, that is to copy parts of the comparison role menu, choose change
mode by choosing Adjust. The procedure describes change mode.
1.
In the role maintenance (transaction PFCG), choose Utilities Role comparison tool or
call transaction ROLE_CMP.
2.
Enter the name of the role to be adjusted in the Role input field. Then enter the
comparison role in the Comparison role field.
If you specify a single role in the Role field, compare it only to another single role. If you specify
a composite role in the Role field, compare it only to a single or composite role contained within
it.
3.

Choose Adjust.

The Role Comparison screen appears. Until you choose Save or Activate, this screen is the same
as the display mode under Role Comparison.
In this example, we compare the role to be compared Role_Compare_1 with the comparison role
Role_Compare_2. Two menu entries are red in Role_Compare_1. This means that this role has
two extra entries in comparison to the role Role_Compare_2. You can delete these entries by
dragging them to the trashcan.
In the menu of the role Role_Compare_2, the entry Business Add-Ins is blue. That is, this entry is
not contained in the role menu to be adjusted. You can copy it to the appropriate place in the role
menu to be adjusted using Drag&Drop.
You cannot change the black entries.
4.
Save your entries. You have created a maintenance version and the initial screen appears
again.
On the initial screen of the transaction, you can choose Role Delete maintenance vers to
discard the changes.
5.

Choose Activate to create an active version of the compared role menu.

Preparatory Steps

14

When you activate the Profile Generator, you permit specified authorization checks to be
deactivated. The Profile Generator is active in the standard system (the system profile parameter
auth/no_check_in_some_cases is set).
This setting has the following effect:

When a transaction is called, the system always checks to see whether the authorization
checks contained within it are to be suppressed.

The authorization Profile Generator is activated. The system displays Authorizations on the
initial screen for Transaction PFCG (Role Maintenance).
Perform the following steps in the Implementation Guide (IMG):
...
1.

Copy SAP default settings for check indicators and authorization field values

Using Transaction SU25 (step 1), copy the default values delivered by SAP. This is how you
import the SAP check indicator default values for the authorization objects within a transaction,
and the authorization field values for the Profile Generator into the customer tables (tables
USOBX_C and USOBT_C). You can edit these in Transaction SU24.
You can change both configurations to meet your requirements.
To import an upgrade, follow steps 2a to 2d.
It may take a few minutes to copy the SAP defaults into the customer tables.
See the documentation in Transaction SU25.
2.

Schedule Background Job for Time Limits

You can set a time limit on the assignment of users to roles. To ensure that these changes are
reflected in the user master record during the profile assignment, you need to schedule a
background job to make the relevant adjustments daily.
For more information, see Comparing user master record profiles with roles.
To maintain the default check indicator settings, use transaction SU24 (see the following topics).
To do this, you require the authorization ABAP Workbench (S_DEVELOP) with the following
field values:

ACTVT: 03 (Display) or 02 (Change)

DEVCLASS: any

OBJTYPE

SUSK (Assign transaction authorization object in customer systems)

SUSK (Assign transaction authorization object in SAP systems)

15

OBJNAME: Name of the transaction to be edited

P_GROUP: any

You can edit the authorization proposals in the Profile generator.

Transporting Manually-Created Profiles
To transport selected profiles, proceed as follows:
1.
Choose Tools Administration User maintenance Authorizations and Profiles
(Manual Maintenance) Edit Profiles Manually (transaction SU02).
2.

Create a profile list and then choose Profile Transport.

3.

Select the profiles you want to transport or all profiles in the list displayed.

4.

Enter the transport request number for each profile or profile group in the dialog box.

5. The system asks whether you want to transport just the profile, or the authorizations it
contains as well. You can either transport the profile by itself, or include all of its components in
the transport request.
The system also transports the documentation for the profiles and authorizations.
6. When you have finished your selection, you can execute your transport request using the
Workbench Organizer.

Transporting Manually-Created Authorizations

1.
Choose Tools Administration User Maintenance Authorizations and Profiles
(Manual Maintenance) Edit Profiles Manually (transaction SU03).
The Maintain Authorizations: Object Classes screen appears.
2.

Select an object class by double clicking it.

The Object List screen appears.

3.

Select the objects to be transported and choose Transport.

Transporting Authorization Objects and Classes

When you create or change authorization object classes in transaction SU21, the system displays
a dialog box in which you can enter a change request.
Release this request for the desired target system.
Transporting Check Indicators and Field Values
You can use Transaction SU25 (Step 3) to transport all check indicators and field values.

16

Note that the transport overwrites all existing check indicators and field values in the target
system.
You can use transaction SU24 to maintain individual check indicators. You can use the
Workbench Organizer to record your changes. By executing the corresponding transport request,
you distribute your check indicators to other systems.
Transporting Templates
All SAP templates are automatically identical in all systems following an upgrade. You cannot
change SAP templates.
The Workbench Organizer (transaction SE09) records changes to your own templates.
Transport the request. The objects in the transport request have the following syntax: R3TR
SUSV <Name of the template>. The system transports the template name (in all languages) as
well as the maintained data.
Transport User Tables between Clients
Use report RSCLCCOP to transport user master records, profiles and authorizatons between
clients in an R/3 system.
Start RSCLCCOP from the target client which the users and authorizations should be copied.
Do not use this report if the target client contains some users and authorizations you want to
preserve.
First Installation Procedure
To set up user and role administration for your SAP system:
1.

Read the Security in System Groups section.

2.

Get an overview of the various tasks of your staff.

If your company uses various applications, you must liaise with the various departments to decide
which roles to define in each department, and which authorizations the staff is to be given. Each
workplace should be defined (in writing). The authorization administrators need to know in detail
which employees can access which data, call which transactions and programs, and so on.
3.

In transaction SU25, choose menu entry 1: Initial Fill of the Customer Tables.

When initially filling the customer tables, the check indicators and authorization values that are
preset by SAP are copied to the appropriate customer tables.
Users and user groups are assigned roles, possibly predefined, that contain typical transactions for
their work. On the basis of the transactions contained in a role, the role administration tool selects
the authorization objects that are checked in the transactions. If a menu has been created for a
role, the role administration tool searches for the associated authorizations. These can be
supplemented and modified by the administrator.
Depending on how exact the default values are, green (complete authorization), yellow (must be
maintained by the authorization administrator), or red (organizational levels need to be
maintained) lights appear in the display for the maintenance of the individual roles.

17

Default values for authorizations are delivered by SAP in the form of the tables USOBX and
USOBT. The customer tables USOBX_C and USOBT_C are initially filled with the contents of
these tables and can synchronized at each further upgrade.

USOBX

Defines which authorization checks should occur within a transaction and

which authorization checks should be edited in the role administration tool.
You determine the authorization checks that can be edited in the role
administration tool using check indicators. Only the authorization checks
that are assigned the indicator Check with Default Yes (previously PP)
can be edited in the role administration tool.
In these tables, Check with Default Yes (previously PP), which is used in
transaction SU24, corresponds to an X.
Authorization checks can be suppressed despite a programmed authority
check command.

USOBT

4.
tool.

Defines for each transaction and authorization object which default values
should be used in the role administration tool for the transaction codes
entered in a role menu.

If necessary, adjust the extent of authorization checks before using the role administration

You also use check indicators to control which objects are not to be checked, which appear in the
role administration tool and which field values are displayed there for editing before the
authorization profiles are generated automatically.
Adjust the authorization checks to be performed for each transaction according to your wishes. To
do this, call transaction SU25 and choose point 4: Check Indicators in Transactions (SU24).
You can also globally deactivate authorization objects in the transaction SU25 (item 5). See
Reduce extent of authorization checks.
5.
To copy the tables to other systems in your system group, choose point 3: Transport
Customer Tables.
6.

Implement your role administration in accordance with the following model:

18

At the common level, access to commonly used transactions is created for all users of the system.
Examples of contained transactions are: Printing, Online Help, SAP office, and so on. Create one
(or more) roles for general activities in your company. Changes to these roles affect all
employees. If general activities are part of specific job roles, changes in the general
authorizations must be adjusted in all roles.
At the application level, all users of a particular application should be assigned general
transactions for this application. This procedure leads to a time saving, as these general
application-specific roles usually remain stable even after upgrades. If you need to make changes,
you can again make one change for all.
At the job role level, you should assign the transactions and authorizations that are required
especially for one (or a few) work centers. If roles are used at different organizational levels (for
example, in different company codes), you can derive roles and change the appropriate
organizational levels for the derived role in a dialog window.
Since both of the lower levels remain largely stable after the authorization administration has
been implemented, the work of the authorization administrator will mainly be related to roles at
the job role level after the implementation.

Security in System Groups

The development system
When the development system is first installed, the users are mainly the project team members,
including developers and system administrators. Most users of a newly-installed SAP system
initially have the authorization profile SAP_ALL in their user master record, which allows them
to perform all tasks in the system. As the project progresses it is necessary to restrict user access.
Development system users usually have greater access rights as quality assurance or production
system users.
Authorization administrators should make themselves acquainted with the SAP authorization
concept in this phase. We recommend that you use SAP_ALL as a template and first define the
role or profile <company>_ALL without the superuser authorizations. To do this, proceed as
follows:
1.

Create a role with Tools Administration User maintenance Roles.

2.
Do not enter any transactions, choose the Authorizations tab page and then Change
authorization data.
3.

Do not copy any templates, but choose Edit Add authorization. Full authorization.

4.

Expand theBasis administration object class.

Here you find the authorizations that are generally regarded as critical.
5.
Deactivate all authorizations which begin with User master maintenance or have
S_USER_* in the object name, and any others which you regard as critical.
6.

Using the role administration tool, generate a new profile and save it under a new name.

19

You can assign the role that you have just created to the relevant users in user maintenance. See
Assigning roles .
This control ensures the integrity and stability of the system.
The Basis authorization objects are documented in the transaction AUTH_DISPLAY_OBJECTS.
The authorization objects in the object class Basis - Administration are called S_USER_*. Place
the cursor on an authorization object and choose Information.
For more information about Basis system and SAP work area authorizations, see Tools
AcceleratedSAP Customizing Edit project and choose the SAP Reference IMG button.
Search for the entries User or Authorization to call the authorization sections.
The authorization administrator creates the roles for end users in the development system. These
roles are transported to the final test in the quality assurance system before being put in the
production system. The user master records are usually created in the production system shortly
before it goes live. The roles are assigned to the end users in the production system together with
the transported authorization data, as required.
The authorization administrator must know which clients are to be created in the customer
systems. Roles are not automatically copied when new clients are created. Since users, roles,
authorization profiles and authorizations are client-specific, the client copy administrator must
also know which user master records are to be copied.
The quality assurance system
The authorization administrator can start to transport the roles from the development system into
the quality assurance system when it has been setup.
For example a member of the FI project team can check the following in the accounts payable
accounting with a model user ID:

Whether the user has access to the transactions in the roles assigned to him or her

Whether these transactions correspond to the role defined by the company for the accounts
payable accounting
Whether the model user ID has access authorization for certain transactions without
permission
The end users can logon in a test environment and simulate production processing to test the user
authorizations.
A training client is usually created in the quality assurance system because it contains the newest
configuration. Larger installations have a separate training system.
The production system
When the roles and authorization profiles have been completely tested in the quality assurance
system and approved by the end users or project team, the roles can be transported into the
production system. The user IDs can then be created.

20

You should never make changes to a production SAP system. You should therefore not assign
following authorizations to users in a production system:
Authorizations for the ABAP Workbench (authorization objects ABAP Workbench
(S_DEVELOP) and Transport Organizer (S_TRANSPRT))

SAP system operating system command execution authorizations (transaction SM52)

(System Authorizations (S_ADMI_FCD) value UNIX).
Authorizations to deactivate authorization checks (transaction
AUTH_SWITCH_OBJECTS) with the authorization object S_USER_OBJ.
Setting Up User and Authorization Administrators
Use
If you have organized your user administration in a decentralized manner, in which you have
distributed the user administration tasks among multiple administrators, you must create these
administrators as normal SAP users or assign these tasks to existing users.
The table below shows the tasks that you should assign to individual administrators, tasks that
you should not assign, and the templates and roles that we have predefined for these tasks. A role
is only available for the user administrator. This has the advantage over a template that the
administrator receives a menu that contains all of the important functions for his or her work.
Organization of the User Administrators when using the Role Administration Tool

Administrator

Permitted Tasks

Impermissible Tasks

User Administrator

Creating and
changing user master
records

Changing role data

Assigning roles to
users

Changing or
generating profiles

Templates and Roles

Template
SAP_ADM_US
Role
SAP_BC_USER_ADMI

Assigning profiles
beginning with "T" to
users
Displaying
authorizations and
profiles
Using the User
Information System
Authorization Data
Administrator

Creating and
changing roles

Changing users

21

SAP_ADM_AU

Changing
authorization data
and transaction
selection in roles

Generating profiles

Using the User

Information System
Authorization Profile
Administrator

Displaying roles and

the associated data

Changing users

Using transaction
PFCG or SUPC to
generate the
authorizations and
profiles that begin
with T for roles
that have
authorization data

Changing role data

Checking roles for

the existence of
authorization data
(transaction SUPC)

Generating
authorization profiles
with authorization
objects that begin
with S_USER

SAP_ADM_PR

Performing a user
master comparison
(transaction PFUD,
Performing a profile
comparison of the
user master
comparison)
Using the User
Information System
Prerequisites
You are an administrator with the predefined profile S_A.SYSTEM, with which you can edit
users of the group SUPER.
Procedure
1.

Create a role for each administrator.

1.

a.
Enter a name in the Role field in role administration
(transaction PFCG) and choose Create Role.
2.
b.
Do not assign any transactions; instead, choose Change
authorization data on the Authorizations tab page.
A dialog box appears asking you to choose a template.

22

3.

c.
Choose one of the following templates:
Administrator
Authorization profile
administrator
SAP_ADM_AU Authorization data
administrator
SAP_ADM_US User administrator
4.
d.
Generate an authorization profile in each case.
Use a profile name that does not begin with T, so that the authorization data
administrator cannot change his or her own authorizations.
Template
SAP_ADM_PR

2.

On the User tab page, assign the role to the relevant user, that is, to the administrator.

3.

Save your entries.

4.
So that the user administrators cannot change their own user master records, or those of
other administrators, assign them to the group SUPER. This applies if you are using the
predefined user administration authorizations.
a.
To do this, choose the Logon Data tab page in user administration (transaction SU01).
b.
In the User Group for Authorization Check field, enter the value SUPER.
c.
Save your entries.
5.

If appropriate, restrict the authorizations of the administrators further:

You can use authorization objects S_USER_AGR, S_USER_TCD and S_USER_VAL to

further differentiate the roles of the administrators.

For the user administrator, you can restrict the authorization to particular user groups.

For the profile administrator, you can exclude additional authorization objects, for
example, for HR data. If you want your generated authorization profiles to begin with a letter
other than T, you should inform your profile administrator.
Setting Up the Role Administration Tool
To use the role administration tool, perform the following steps:
...
1.
The role administration tool is activated when delivered; that is, the profile parameter
auth/no_check_in_some_cases is preset to the value Y. Do not change this setting.
2.

Execute transaction SU25.

This copies the SAP check indicator defaults and field values into the customer tables so that you
can change them.
You can then use the role administration tool to edit the authorization information for your users.
Password Rules

23

The following table describes the specifications that are to be followed for passwords. It also
shows whether these guidelines are predefined in the system or whether you can change them
using profile parameters.

Rule

Notes

The password must be at least 3 characters long

You can change this with profile

parameter login/min_password_lng.

The password cannot be more than 40 characters long

Until SAP NetWeaver 6.40 (inclusive), passwords could
not be more than 8 characters long.
Until SAP NetWeaver 6.40 (inclusive), all characters of
the syntactic character set can be used, that is, all letters
and digits, and some special characters. The system does
not differentiate between upper- and lower-case.

Predefined in SAP system

After SAP NetWeaver 6.40, any Unicode characters can

be used, and the system does differentiate between upperand lower-case.

You can change this with profile

parameters
login/min_password_letters,
login/min_password_digits, and
login/min_password_specials.
See also: login/password_charset.

As of SAP Web AS 6.10, the administrator can define

how many digits, letters, and special characters must be
contained in new passwords (see profile parameter).
The first character may not be an exclamation point (!) or
a question mark (?).
The first three characters may not appear in the same
order in the user ID

Predefined in SAP system

Predefined in SAP system

This rule applies only in systems up to SAP R/3 4.6D.

The first three characters cannot all be the same.
None of the first three characters can be a space

Predefined in SAP system

Predefined in SAP system

This rule applies only in systems up to SAP R/3 4.6D.

The password may not be in a list of impermissible
passwords (table USR40) The list contains character
combinations or terms, where the asterisk (*) and
question mark (?) can be used as placeholders. Asterisk
(*) stands for a character sequence, and the question mark
(?) for a single character.

Can be changed. The default value is

that all passwords, except PASS and
SAP* are allowed.

The administrator receives only a warning, if he or she

breaks this password rule when assigning passwords in
user maintenance.
The password cannot be PASS or SAP*.

Predefined in SAP system

24

The password may not be changed to any of a users last

x passwords, if the user changes the password himself or
herself.

You can change this with the profile

parameter
login/password_history_size.

Until SAP NetWeaver 6.40 (inclusive), the password

history was fixed to the value 5.
After SAP NetWeaver 6.40, the administrator can set the
size of the password history (up to 100 passwords
selected by the user).
The administrator can reset a users password to any
initial password, therefore also to one of the last x
passwords for this user. This is necessary, since the
administrator should not know the passwords of the
users. The user is prompted to change the initial password
at the first interactive logon.
The password can only be changed after the old password
has been entered correctly.

Predefined in SAP system

Up to SAP Web AS 6.10, the user can only change the

password during the logon procedure. As of SAP Web AS
6.20, the user can also change the password by choosing
System User Profile Own Data (transaction SU3)

Users can only change their passwords again after a wait

period.
Until SAP NetWeaver 6.40 (inclusive), the wait period
was one day. A password changed by a user could only be
changed again by that user on the next day.

You can change this with the profile

parameter
login/password_change_waittime.

The system can now reject all password changes during

the wait period (unit: days). If the administrator changes
the users password, the user must change this initial
password the next time he or she logs on, regardless of
when he or she last changed his or her password.
System administrators can still change passwords as often
as necessary.
The password must contain at least x lower-case letters.
Until SAP NetWeaver 6.40 (inclusive), the system did not
differentiate between upper- and lower-case.
The password must contain at least x upper-case letters.
Until SAP NetWeaver 6.40 (inclusive), the system did not
differentiate between upper- and lower-case.

25

You can change this with profile

parameter
login/min_password_lowercase.
You can change this with profile
parameter
login/min_password_uppercase.

At least one character in the new password must be

different from the old password.
As of SAP Web AS 6.10, the administrator can specify
the minimum number of characters that must be different
in the old and new passwords in a profile parameter.
The password must comply with the current password
rules and must be changed if it does not.
Until SAP NetWeaver 6.40 (inclusive), changed password
rules did not apply to old password, but were only
evaluated when passwords were changed.
A productive password (chosen by the user) is valid for a
maximum of x days, if it is not used.
Available after SAP NetWeaver 6.40.
An initial password (set by the user administrator) is
valid for a maximum of x days, if it is not used. After this
period has expired, the password can no longer be used
for authentication. The user administrator can reactivate
password-based logon by assigning a new initial
password.

You can change this with profile

parameter login/min_password_diff.

You can activate this with the profile

parameter
login/password_compliance_to_curre
nt_policy.

You can change this with the profile

parameter
login/password_max_idle_productive
.
You can change this with the profile
parameter
login/password_max_idle_initial.

Available after SAP NetWeaver 6.40.

As of SAP Web AS 6.10, the function module PASSWORD_FORMAL_CHECK can determine
whether a string meets the current password rules. The following rules are not evaluated here:

Password may not be changed to any of a users last five passwords

The password can only be changed after the old password has been entered correctly.

A user can change his or her password only once a day.

At least x characters in the new password must be different from the old password.

For an exact description of the sequence and the scope of the check, see the documentation for the
function module. You can display this documentation with transaction SE37.

Protecting Special Users

Clients 000, 001 and 066 are created when your SAP System is installed. Two special users are
defined in clients 000 and 001. Since these users have standard names and standard passwords,
you must secure them against unauthorized use by outsiders who know of their existence.
Note that no special user is created in client 066.
The two special users in the SAP System are as follows:

26

The SAP System superuser, SAP*

SAP* is the only user in the SAP System that does not require a user master record, but
that is instead defined in the system code itself. SAP* has by default the password PASS,
as well as unlimited system access authorizations.
When you install your SAP System, a user master record is defined for SAP* with the
initial password 06071992 in Clients 000 and 001. The presence of a SAP* user master
record deactivates the special properties of SAP*. It has only the password and the
authorizations that are specified for it in the user master record.
To secure SAP* against misuse, you should at least change its password from the
standard PASS. For security reasons, SAP recommends that you deactivate SAP* and
define your own superuser.

The maintenance user for the ABAP Dictionary and software logistics, user DDIC.
The user master record for user DDIC is automatically created in clients 000 and 001
when you install your SAP System. The default password for this user is 19920706. The
system code allows user DDIC special privileges for certain operations. For example,
DDIC is the only user that is allowed to log on to the SAP System during an upgrade.
To secure DDIC against unauthorized use, you must change the initial password for the
user in clients 000 and 001 in your R/3 System.

The user EarlyWatch is delivered in client 066 and is protected using the password
SUPPORT. The SAP EarlyWatch experts use this user which should not be deleted.
Change the password. This user should only be used for EarlyWatch functions
(monitoring and performance).

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:
1.
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.

27

If you use transaction SU25 (option 6) to convert profiles into roles, which you then want to
derive, ensure that you choose the optimized option to copy the status of the organizational level
fields contained in the profiles correctly to the role. You may then have to maintain the values in
the organizational level fields, since transaction SU25 collects the field values from all
authorization objects including the affected organizational levels. This means that after the
migration, every authorization object contains the total of all field values in the profile for this
organizational level. This ensures that the uniform status of the organizational levels in all
authorization objects is maintained. This is the prerequisite for maintaining the organizational
levels using the dialog box Determine Organiz. Levels.
If you are migrating the profiles using the option Identical to Profile, although only the values for
the organizational level fields contained in the profile are copied to the role, it is no longer
possible to maintain organization levels using the dialog box Determine Organiz. Levels.
2.
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 Information System (transaction SUIM). You
can download the Information System 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

28

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.

29