Objects are linked to each other using relationships. You create relationships between the individual elements in your organizational plan. Several linked objects form a structure.
Different types of relationships are used because there are different types of connections between elements. The relationships used between standard object types are predefined in the SAP standard system. You must be careful if you change a relationship that is delivered with the standard system, because it can impact the evaluation results. You are advised to copy the standard delivered relationship as well as workflows, authorization and security access and create a new relationship when required.
Relationship ID
Each standard relationship has a 3-digit numeric key.
You can define your own relationships. The namespace AAA to ZZZ is reserved for customer-specific relationships. Relationships between objects are reciprocal. If a job describes a position, then the position, in turn, is described by the job. The direction of these relationships is distinguished by using the identifiers A or B in the relationship name.
You need to create a relationship only for one direction. The inverse relationship is created automatically by the system.
A relationship can also be one sided, in that it exists in only one direction. Relationships to objects of an external object type (for example, a cost center in Controlling) are often one sided.
Organizational Units
By creating relationships between organizational units, you create an organizational structure.
An organizational unit can have many subordinate organizational units, but only one higher-level organizational unit.
The following table shows some examples of standard relationships between organizational units:
| Org. Unit Relationship Type | Standard Relationship |
| A 002 | An organizational unit reports to another organizational unit. |
| B 002 | An organizational unit is line supervisor of another organizational unit. |
A/B003 (belongs to/incorporates) is one of the relationship types that can be used to map a matrix structure. A/B003 is also used to map organizational units and positions.
Organizational Units and Positions
Positions are linked to organizational units in the organizational plan. They inherit certain characteristics of the organizational unit, such as cost center assignment or working time.
The following table shows the relationships between a position and an organizational unit:
| Organizational Unit Type | Standard Relationship |
|---|---|
| A 003 | A position belongs to an organizational unit. |
| B 003 | An organizational unit incorporates a position. |
Jobs and Positions
When a position is created based on a job, it inherits the characteristics of the job, such as associated tasks or qualifications.
Jobs can describe many positions; however, a position can be described by only one job.
The following table shows the relationships between a job and a position:
| Organizational Unit Type | Standard Relationship |
| A 007 | A job describes a position. |
| B 007 | A position is described by a job. |
Positions and Persons

The position is the object that links persons or users to the organizational plan.
A position can be held by more than one person or user and a person can hold more than one position. However, a one-to-one ratio is the ideal scenario.
The following table shows the standard relationship between a person and a position:
| Organizational Unit Type | Standard Relationship |
|---|---|
| A 008 | A person is assigned as the holder of a position. |
| B 008 | A person is the holder of a position. |
Other relationships between persons and positions are as follows:
- A/B009: Successor
- A/B010: Substitute
Cost Centers
An organizational unit or a position is assigned to a cost center by using relationship A 011.
Chief Position

The table shows the relationships that exist when a position manages an organizational unit in a standard system:
| Organizational Unit Type | Standard Relationship |
|---|---|
| A 012 | A position manages an organizational unit. |
| B 012 | An organizational unit is managed by a position. |
This relationship is also created for A/B003 between the chief position and its higher-level organizational unit. A position which will be designated as the chief must first belong to the organizational unit with the 003 relationship.
Positions
The relationships between positions form the reporting hierarchy that can be evaluated independently of the organizational structure.
In some organizations, the reporting structure, that is, the specialist or disciplinary relationship of one position to another, is based on the simple assignment of positions to organizational units. In this case, you do not need an additional reporting structure.
If, however, the actual reporting structure of your enterprise differs from the reporting structure determined by the organizational structure, you can model it with the relationships.
The table shows the standard relationship:
| Organizational Unit Type | Relationship |
| A 002 | A position reports to another position. Example: The position Payroll Administrator position reports to the position Payroll Manager. |
| B 002 | A position is line supervisor of another position. Example: The Payroll Manager position is the line supervisor of the Payroll Specialist positions. |
Other relationships between positions are shown in the table:
| Organizational Unit Type | Relationship |
| A/B 004 | Is subordinate to (disc.) / is disc. supervisor of |
| A/B 210 | Substitutes with profile / Substitutes with profile |
Maintaining Relationships

The Relationships infotype (IT1001) can include multiple relationships.
Relationship properties allow you to control how the system responds to the criteria defined in Customizing for a relationship. The possible responses include error messages, warnings, or information. For example, if the 100% mark is exceeded in the case of weighted relationships, the system outputs either an error message, a warning, or an informational message.
Relationship properties include the following:
- Additional relationship information
You can determine whether additional relationship information can be maintained and whether the weighting percentage of a relationship needs to be shown or hidden. Additional information that is customer-specific can only be entered for customer-specific relationships, and then only by agreement with SAP.
- Allowed relationships
You can define the object types that are allowed for each relationship type.
- External relationships
External relationships are the relationships that are not stored in the HRP1001 database.
- Time constraints
You must assign a time constraint to each relationship, depending on the object type. If you want the time constraint to also be dependent on the target object type, you must maintain this setting in the step Define Time Constraint Depending on Target Object Type.
Simple Structures
You can view relationships as table entries. Relationships between organizational objects exist only as table entries in the database. You can display the table entries as such in the relevant transactions.
In the example shown in the figure Simple Structures, two entries exist with the relationship key B002 for the higher-level organizational unit 50001111.
All relationships between internal objects are stored for each object in the logical database PCH. External objects such as cost centers or users do not store data in the database.