How to view recently used transactions by users

There are various ways to do that, two of the quickest ones are
1) Turn the audit log on by using SM19 and SM20 and analyze the audit logs.Put filters while setting up these logs so that you can see the specific data.

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…

SAP System Administration: Authorization Concepts

Access control in SAP is composed of several concepts:

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.

SAP System Administration: Authorization Concepts

Access control in SAP is composed of several concepts:

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.

SAP Derived Roles

As the name indications are derived from already existing roles.
There are two scenarios when we derive roles.

* 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

SAP Composite Roles

Composite Roles :
Suppose there is position in your organization in which activites of two positions need to be performs the roles is called composite role.
Take an example. There are two positions like a clerk and auditor. If there is a position in your organization where the individual has to act both as a clerk and an auditor the the role is a composite roles which needs him/her to work both as a clerk and auditor. This is quite common scenario in organizations or companies.
A composite role has many single roles. No authorization data can be maintained in a composite role.  You can eneter some menu entries like links to websites, reports only. Tcodes cannot be added. The authorization data has to be maintained only in the single roles.
When you attach a composite roles to an user all the single roles gets attached to him. In the change documents it shows the single profiles that belongs to single roles gets attached to them. Suppose a composite role has 3 single roles. when you attach this composite role to a user then 3 authorizations profiles will get attached to him. The change count  in SUIM will be 3.

What is a authorization Role in SAP?

Role is the way how authorizations are granted in SAP or the activities which are performed by and individual are restricted. A role consists of all the duties performed by an individual in the organization. For e.g., the clerk or the manager or buyer or dispatcher etc.. Two managers of same cader has same type of duties. Technically a roles contains all the items(transactions or tcodes, reports, links) which are needed by an individual in particular position. In a  roles-based authorization system the lattice structure of organization is well defined and the activities performed by each individual is defined clearly. In a role-based authorization system the users are assigned to generiuc roles (technical)  which contains tcodes necessary for peforming the job. The above description is a single role.

There are three types of roles.

o Single roles
o Composite roles
o Derived roles