Did you know that it is now possible to set up authorization profiles for users in a more flexible and simple way? New developments since 4.0 enable you to do just that.

Further developments in R/3 Enterprise 4.7 provide you with extra flexibility to meet more complex requirements. The interface has not changed much with Release 4.7 as far as the end user is concerned. Thanks to the changes made at the administration level, however, the process for setting up CO authorizations has been enormously improved.

This article is for administrators, and it explains how they can set up authorizations without the need to assign authorization objects to every single CO object or application in the standard hierarchy of your company. This saves a significant amount of time.

Since Release 4.0

The authorization concept that was developed in Release 4.0 was all about having a responsibility area, whereby the following applies:

• The multiple authorization objects have been replaced by single objects for each application: K_CCA, K_ORDER, K_PCA, K_ABC.

• Reporting, planning, and master data maintenance have the same logic. You can enter a specific numeric key for the business transaction (e.g., for master data maintenance) followed by a numeric key for the system transaction (e.g., for displaying data). These keys mean that you can assign authorization for a user to execute the related business and system transactions in the required combination.

• The same logic is used in more than one application (also applies to cost centers, orders, processes, and profit centers).

This enables the quick and easy maintenance of authorization with the use of inheritance logic. Using inheritance logic, you apply authorization to a node in an authorization hierarchy, which then applies to or is "inherited" by the nodes below. This enables you to plan data on all the cost centers in the hierarchy, making life a lot simpler. You give users authorization for all the objects beneath a node in their authorization profile. In Release 4.5, the maintenance for group master data was added.

Since R/3 Enterprise Release 4.7

Now the advantages of the inheritance logic can be applied to hierarchies other than the standard one. You can configure more than one view for your authorization concept—for example, reporting or planning views—rather than just an organizational point of view such as controlling areas and company codes. These additional authorization hierarchies can be activated in the maintenance for the controlling area by entering your alternative hierarchy in the fields circled in Figure 1. You can find this screen by following the IMG menu path Controlling>General Controlling> Organization>Maintain Controlling Area>Maintain Controlling Area, and then selecting the relevant controlling area from the right side of the screen and clicking on Activate components/control indicators on the left side of the screen.

The additional hierarchies are a great advantage because if you change the hierarchy view and have, for example, a reporting or planning hierarchy, your cost centers will not appear in the same order as they would in the standard hierarchy. This new development means that you do not have to spend time finding where each cost center appears in order to provide authorization for that cost center.

You also can more easily create authorization profiles for users in different departments. For instance, a clerk who makes postings on cost centers might have different authorization than a clerk who enters planning data. The cost center clerk would be assigned different object groups for authorization than the planning clerk, and neither would be able to access the other’s object groups. The two sets of object groups, therefore, cannot be assigned to the same hierarchy, and so additional hierarchies to represent these authorizations play an important role. This avoids the need for the administrator to assign separate authorization to the objects.

Another advantage is that you could create a planning hierarchy for the year 2003, for example, and a reporting hierarchy for the year 2002. It is possible to copy the hierarchy by making it year-dependent. This means that you can edit a hierarchy without losing the original, by naming the copy H1.2003, for example. The major advantage of this is that it is easy to change the authorization concept to reflect organizational changes. You could easily have a plan hierarchy and an actual hierarchy for a particular year. Checks would then always have to be carried out using the current date to ensure that the right hierarchy version is chosen.

Figure 1

Maintenance of additional hierarchies (since R/3 Enterprise Release 4.7)

How the System Checks for Authorization

The system carries out the authorization check starting from the bottom and working its way up to the top of the first hierarchy (if still activated, the standard hierarchy is the first hierarchy). If this is unsuccessful, the system moves on to the second hierarchy. If this is also unsuccessful, it repeats the process of searching for authorization in the next hierarchy until it finds the authorization. Figure 2 illustrates this process.

If authorization is only provided in the third hierarchy, the runtime is longer because the first two hierarchies are checked first. Therefore, it is a good idea to deactivate the standard hierarchy if it is not needed so that the system does not check through it. Figure 3 shows the settings to deactivate the standard hierarchy. To call up this screen, follow the IMG menu path Controlling> General Controlling>Organization> Maintain Controlling Area> Maintain Controlling Area, and then double-click on the relevant controlling area.

Note that when you maintain authorization, the standard hierarchy tab page has been renamed Authoriz. Hier., as shown in Figure 4. It does not matter if you assign authorization more than once, because the system will stop at the first authorization that it finds during the authorization check.

Figure 2

Authorization checks for the standard and alternative hierarchies

Figure 3

Deactivation of the standard hierarchy in the maintenance of additional hierarchies

Figure 4

Maintenance of the authorization hierarchy. Call up the F4 help from this view to show all hierarchy nodes defined in the CO area in Customizing.