The concept of parent and derived roles was introduced by SAP to simplify role administration tasks. It's especially helpful while mapping security for large enterprises spread across multiple geographies or divisions. A child's role derived from a parent's role will have all the attributes similar to the parent except the Organizational Level field values. Therefore, maintenance is simplified at the derived role level. This also makes sure that no mistake is made during the authorization of derived roles and even lessens the testing effort.
Creating a parent role follows the same process as creating any other single role. In the example below, we create a global role “Z_CREATE_SO_GLOBAL” which allows the creation of Sales Orders (transaction VA01) for all company codes, sales org.
The menu for a derived role cannot be individually maintained as all entries are inherited from the parent.
Now we maintain the values of the org levels relevant to the child role. In the example below, we have used a dummy value of @ but in a production system, the correct value for org levels should be used. The other need not be maintained at this stage. Now we save the authorization entry for the derived role.
To populate the rest of the authorization values for the child role, we go into the authorization maintenance screen for the parent and click the button “push from gl”. This option pushes the non-org level values from the parent to the child's role and generates the profiles for both.
The most critical success factor for a parent-derived role concept is how well, the different business processes mapped by SAP roles are mirrored across the different divisions in an enterprise. In other words, a parent-derived role concept will not be very beneficial in case an enterprise follows a different business process in its different subsidiaries.
A single role is an integration of t codes and authorization objects. However, SAP also designs composite roles that contain one or a few single roles. Let us explore the technical and business reasons for exploring composite roles.
In the course of creating a role, the PFCG initial screen enables one to select either a single or composite role. Once designed, there is no chance of altering a single role to a composite or vice versa.
The below screen displays the role definition of the SAP_AUDITOR composite role that employs the Audit Information System (AIS). One shall notice that the individual tabs differ from those of a single role. Instead, we have the Roles tab and a menu tab.
Although transactions cannot be added directly to a composite role, however, it can have its own menu structure that is displayed through the SAP Auditor role.
| Want to acquire industry skills and gain complete knowledge of SAP BASIS? Enrol in Instructor-Led live SAP BASIS Training to get Job Ready! |
The transaction and value/controller role concept deals with the design of individual transaction roles and authorization objects. Authorization objects deal with the final transaction access. The transactional role also handles the authorization objects. Authorization objects are manually added to the value roles.
During the assignment, both transaction and value roles need to be assigned to a user. In a typical scenario, a transaction role might be created to map various jobs of an enterprise. After a transaction role is set up, few broad value roles are designed with authorization objects. The number of value roles are usually much lesser than the transaction roles and possess authorization objects.
Organizational management is meant to be a launchpad to our discussion on structural authorizations a unique and indispensable part of HR security. We already have had a brief idea on Org Mgmt or OM when talking about the PLOG authorization object. Let's take the discussion forward to the next level. OM deals with the representation of the personnel organizational structure within an enterprise within SAP HCM. OM uses the same data model as used by Personnel Planning.
The data model uses object-oriented design and uses the concepts of
Object Types: Objects that are used to create an organizational plan in Organizational Management. The following object types are available:
An organizational object comprises:
Relationships among objects create a hierarchy that mirrors organizational structure.
Use: In Detail Maintenance, you create relationships between objects by entering information in the Relationshipinfotype (1001). In Simple Maintenance, it is more straightforward. When you create a new object, the system creates that object’s relationships.
You use the network of relationships between objects to model the reporting structures of your organization.
Structure: There are many different types of relationships between objects in the component Organizational Management. It is the relationships between objects that give information its value. It is important to understand the syntax used to identify relationships and the structure of relationships.
Syntax Used to Identify Relationships: The standard syntax used to identify a relationship is A/B 000. A/B refers to the two different sides of a relationship, which you create when you link two objects. The system calls these sides passive (A) and active (B). They form the reciprocal relationship and are vital in holding the relationship together. The three-digit numerical code identifies the relationship.
You assign a position to an organizational unit, to identify where the position is allocated. The system creates a relationship infotype record between the organizational unit and the position. You can check the relationship in the Relationship infotype screen in Detail Maintenance. This relationship is called 003. This means the position belongs to the organizational unit, which in turn incorporates the position. The organizational unit’s relationship record is B 003 and the positions are A 003.
Structure of Relationships: A relationship between two objects can be structured:
For example, the relationship between a senior position in an organizational unit and another position in that same unit is hierarchical. The senior position (B 002) is the line supervisor to the lower placed position (A 002) which reports to the position above.
A lateral or flat relationship, for example, relationship 041, is made with two jobs equivalent, which can also be replaced. One side of the relationship is A 041, the other is B 041, but the two sides have equal standing. A relationship between a job and a position is also a lateral relationship.
A relationship can be one-sided. For example, a relationship between an object (such as a position) and an external object type (a cost center in Controlling, perhaps), has only one direction and so is one-sided.
| Read these latest SAP Security Interview Questions that help you grab high-paying jobs! |
Inheritance is one of the most powerful aspects of component Organizational Management. Inheritance is when an object automatically receives attributes assigned to another object. It occurs when:
The object concerned shares a special type of relationship with another object
For example, positions always inherit the attributes of the job to which they are related. This concept is fundamental.
Objects are placed below other objects in a hierarchical structure
The lower-level objects inherit the attributes of the higher-level objects unless you specifically provide other attributes. (The Simple Maintenance tree structure, which illustrates this hierarchy, can help you visualize how inheritance takes place.)
Inheritance is particularly useful as a time-saver. In setting up your organizational plan, you create numerous objects with individual attributes. However, many objects share the same attributes. Entering the same attributes for each object takes a lot of time. Instead, inheritance does this for you.
Two Methods can be used in Maintaining Infotypes
Expert Mode.: Expert Mode handles details. Object Manager chooses the Individual objects. Infotypes for each object can then be upheld.
PP01 handles all of the object types. Due to certain authorization restrictions, PP01, might not have access. Instead, the below transactions are used to restrict access:
Plan Version: Correct Plan Version ensures effective working, each time.
Object Information: Each object information is displayed at each end so that the user is aware of the object being edited.
Status: Tab pages are utilized in selecting the status of the info type.
Infotype: Select the desired info type.
Validity Period: Beginning and ending dates specifies the period of object existence.
Organizational plans can also include organizational objects that come from components other than Organizational Management (cost center or person (employee or user), for example) or objects defined in customizing.
The data model can be represented by the following graphic. Note that object types, Person, and cost center are shown as orange boxes instead of blue ones. These are external objects and not created in the OM component.
A typical org structure when represented by the same data model might look something like the graphic(transaction PPOC).
While the relationship between two objects is stored in the IT 1001 (table HRP1001).
HRP1001- Relationships for a position
Finally, the org structure composed through these two tables is displayed through the PPOSE transaction.
You liked the article?
Like: 0
Vote for difficulty
Current difficulty (Avg): Medium
TekSlate is the best online training provider in delivering world-class IT skills to individuals and corporates from all parts of the globe. We are proven experts in accumulating every need of an IT skills upgrade aspirant and have delivered excellent services. We aim to bring you all the essentials to learn and master new technologies in the market with our articles, blogs, and videos. Build your career success with us, enhancing most in-demand skills in the market.
