2) In ST03N / ST03, you can analyze the transactions run by users by selecting the “User Profile” under the “Analysis Views” section.

Note: ST03N keeps limited data

You can use STAD too, more on that later…

Program code that calls an authorization check using the authority-check statement. This will look something like:
authority-check object id field

Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:

ACTIVITY: defines the type of activity the user is doing with the data. Possible values are
‘DISPLAY’, ‘MODIFY’, ‘DELETE’, etc.

COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as ‘0438′ and ‘0600′ thru ‘1100′)

Authorization objects that define a group of fields. For example, an authorization object called ‘CO_MDATA’, containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.

Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object ‘CO_MDATA’, called ‘CO_MDATA_ALL’, that grants all access to all company master data. Then ‘CO_MDATA_ALL’ would have the following values:

FIELD VALUE
ACTIVITY *
COMPANY_CODE *

Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]

Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.
Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user’s system authorizations. It sounds complicated, but once you start working with authorizations, it’s pretty easy.

* The role menus are identical but the authorizations for the menu actions are different in the derived role.
* The menu and authorizations of the derived role are identical, but the organizational levels are different in the derived role.

The derived roles inherit the menu structure and functions (including transactions etc…) of the referred role.

The default authorization values of the derived role are that of the inherited role. The organizational values are to be maintained in the derived role.
The organization level data is only copied the first time the authorization data is adjusted for the derived role. If organization level data is maintained in the derived role, it is not overwritten by subsequent adjustments.

Roles derived from another cannot have any additional menu entries. The menu is maintained in the referred role which take effect immediately in all derived roles.

To change the menu of the derived role without changing the menu of referred role you have to break the inheritance relationship. Once the relationship breaks, the derived role is dealt as a normal role and the inheritance relation ship cannot be re established

There are three types of roles.

o Single roles
o Composite roles
o Derived roles

This is the vast list of USR,USH & AGR tables