Hierarchy
BBPCRM (Software Component) BBPCRM⤷
CRM (Application Component) Customer Relationship Management⤷
CRM_APPLICATION (Package) All CRM Components Without Special Structure Packages⤷
KBAS (Package) Overhead Cost Controlling
Basic Data
| Data Element | AUTH_USE_NO_STD |
| Short Description | Do Not Use Standard Hierarchy for Authorizations |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | CHAR1 | |
| Data Type | CHAR | Character String |
| Length | 1 | |
| Decimal Places | 0 | |
| Output Length | 1 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | No StdHier |
| Medium | 15 | No StdHier |
| Long | 22 | Do Not Use Std Hier. |
| Heading | 10 | No StdHier |
Documentation
Definition
Since the introduction of the new authorization concept in Overhead Cost Controlling in Release 4.0, you can inherit authorizations within a hierarchy. The authorization objects K_CCA, K_PCA, K_ABC and K_ORDER enable you to enter standard hierarchy groups. If a user is authorized for one of these groups then he/she is also authorized for all objects in this group (for more information, see note no. 370082).
This inheritance logic previously only applied to the standard hierarchy . You can now use the settings in the controlling area to name up to two more alternative hierarchies (according to fiscal year) that are used in the authorization checks in the same way as the standard hierarchy (with the inheritance logic). You can also deactivate the standard hierarchy as the authorization hierarchy, and use only the alternative hierarchies.
This logic has been implemented for cost centers (K_CCA and K_ORDER) and profit centers (K_PCA).
When you maintain the authorizations, you can use an F4-help, which is influenced by customizing. All hierarchies that were entered with a date five years in the past and the future in the customizing for the controlling area can be used in the authorization maintenance.
Authorizations are always checked with the current calendar year and the valid hierarchies, in the order in which they were entered. This means that the standard hierarchy is checked first, followed by the first alternative hierarchy and then the second one. You cannot specify the year using the transaction.
Note that the more alternative hierarchies you use, the longer the runtime.
History
| Last changed by/on | SAP | 20010607 |
| SAP Release Created in | 470 |
