Hierarchical Accesses 
Hierarchical Accesses
Use
Hierarchy accesses are used to optimize pricing for hierarchical data constellations such as a product hierarchy. When using hierarchies of this kind, it may be necessary to use any number of partial quantities (taken from the specified quantity of characteristics) to define the keys of the condition tables. A simple example of this would be a price that is fixed for sales organization and distribution channel but otherwise depends upon either customer, material or both.
Without hierarchy accesses, you would need to create a condition table for every combination and assign all accesses to this table in a hierarchy within an access sequence. This would not only take a great deal of time, but it would also reduce system performance and force the system to use a rigidly fixed sequence of accesses.
This represents a major drawback, especially for hierarchical data such as that representing a product hierarchy or a customer hierarchy.
Using the hierarchy access function, the system can find variants of this kind with a single access to a condition table containing all the necessary fields in the variable key. It can then determine the required condition record according to the relevant criteria.
Prerequisites
When creating an access sequence in a condition table for the fields of an access, the user has the option of defining which part of the key remains fixed and which part can vary (these are the free fields and the optional fields in condition maintenance). During access sequence maintenance, you assign priorities to the fields in the variable part of the key. These priorities are used to evaluate the relevance of the condition records determined using the fixed part of the key.
In Customizing for Pricing, you need to make the following settings in the access at field level:
The records with the highest priorities are then made available in pricing.
The quick entry screen for the condition records is not used. Mandatory entry is not used for the optional fields.
When using hierarchical accesses, you should always use physical deletion and not the deletion indicator. This is because condition records are determined using the priority for hierarchical conditions before Pricing takes place. However the deletion indicator is not checked until Pricing has begun. This can lead to the following:
A condition record may have top priority for the hierarchical accesses and be transferred to Pricing. Using one of the deletion indicators however, the condition record is then sent out of Pricing without a replacement.
You can find more information on deletion in the unit
Example of Pricing with Free Fields
You want to set up Pricing for materials that are assigned to a product hierarchy. You mark the hierarchy levels as free fields and enter a priority. As a rule, the priority should increase as you move from general to more specific criteria:
Field |
Processing type in access |
Evaluation |
Sales organization |
||
Material group |
A |
5 |
Main group |
A |
4 |
Group |
A |
3 |
Sub-group |
A |
2 |
Material |
A |
1 |
The advantage of this is that only one access needs to be created in the access sequence during master data maintenance. This is because the free fields represent optional fields during condition record maintenance, allowing any number of combinations of characteristics for an access.
You also get a much better overview of master data maintenance, because the different condition records can be created for a condition type in the condition maintenance quick entry screen.
Example Data in the Standard System
You can use condition type K148 with access sequence PRHI to test hierarchy accesses.