General application information
You use customer hierarchies in sales order and billing document processing for partner and pricing determination (including rebate determination) and for creating statistics (-> evaluations in profitability analysis (CO-PA) and in the Sales Information System (SIS))
Customizing
In the SAP Reference IMG (Transaction SPRO) you need to maintain the following settings, using path Sales and Distribution -> Master Data -> Business Partners -> Customers -> Customer Hierarchy ... ... Define Hierarchy Types ... Set Partner Determination For Hierarchy Categories ... Assign Account Groups ... Assign Sales Areas ... Assign Hierarchy Type For Pricing By Sales Document Type
General technical information
For customer hierarchy maintenance and display, there exist the following dialog transactions:
Transaction Report
Maintenance: VDH1N (old VDH1) RV_CUSTOMER_HIERARCHY
Display: VDH2N (old VDH2) RVKNVH00
(The old transactions VDH1 and VDH2 are not supported anymore from 4.6B onwards.)
Customer hierarchy data are stored in database table KNVH with the following primary key fields:
Field Short Text
1. MANDT Client
2. HITYP Customer hierarchy type
3. KUNNR Customer
4. VKORG Sales Organization
5. VTWEG Distribution Channel
6. SPART Division
7. DATAB Start of validity period for assignment
In Standard there exists a no-unique database index A (Inverse repr. of customer hierarchy (subordinate nodes)) to improve performance of customer maintaining customer hierarchies.
Database table KNVH has the following technical settings:
Data class = APPL0 (Master data, transparent tables)
Size category = 3 (Data records expected: 150.000 to 620.000)
Buffering not allowed = 'X'
(Buffering of database table KNVH is not possible, because normally it is too large for buffering. Furthermore a buffered access is not necessarily faster.)
Please : The following fields of databse table KNVH are stored redundant in the following database table fields:
Field Short Text DB table field
BOKRE ID: Customer is to receive rebates KNVV-BOKRE
PRFRE Relevant f. price determination ID KNVV-PRFRE
HZUOR Assignment to Hierarchy KNA1-HZUOR
This fact has consequences, which are discussed later (point 4.).
Additional information / Restrictions
If you change one of the three redundant fields in customer master data (Transaction XD02, VD02), you receive I-message F2704 "Update customer hierarchy if change in rebate or price relevance" or W-message F2715 "Customer &1 active in customer hierarchy: Inconsistencies are possible" (both messages have a long text).
Therefore you have to update the customer hierarchy data (KNVH) in transaction VDH1N after such a change in customer master data by using menu path
Hierarchy -> Update programs -> ...... Subhierarchy or... All
This avoids issues due to inconsistencies between tables KNVH, KNVV and KNA1.
Performance
Customer hierarchy maintenance/display (transactions VDH1N / VDH2N) was developed for a limited number of KNVH entries/nodes. But the hierarchy structure is the most important factor regarding performance! This is discussed below.
In Standard there exists no additional room for improvement in the ABAP with regards to performance.
(Recursion is needed to display/adapt the assignments in a hierarchy tree -> inherent performance costs).
The display of a hierarchy tree is limited to 10.000 nodes. But even this significant number of displayed nodes is not desired/reasonable from Standard point of view and therefore can cause performance issues. So for large customer hierarchy trees displaying a complete hierarchy tree - starting from the top level customer - might not be possible.
To improve performance of customer hierarchy maintenance/display in VDH1N / VDH2N, we recommend that you
- use as many selection criteria as possible and
- enter a customer at the lowest possible hierarchy level and
- use flag "Limit display to paths".
a) Assuming a fixed number of customer hierarchy (KNVH) entries, the following aspects regarding hierarchy structure have a positive influence on performance:
- Several hierarchy types (KNVH-HITYP)
- Large number of independent (small) hierarchy trees (-> many top level customers)
- Several independent sales areas
- Mininum number of hierarchy levels
Example: 100.000 Customer hierarchy (KNVH) entries:
Two different hierarchy types -> average hierarchy tree with 100.000 nodes divided by 2 = 50.000 nodes.
5 independent sales areas -> average hierarchy tree with 50.000 nodes divided by 5 = 10.000 nodes.
100 top level customers (= 100 independent hierarchy trees) -> average hierarchy tree with 10.000 divided by 100 = 100 nodes.
--> To maintain a hierarchy tree with 100 nodes is much faster as the maintenance of a hierarchy tree with 100.000 nodes (if the latter is possible at all).
a) To reduce the total number of customer hierarchy entries (KNVH) and therefore improve performance, you can check the following:
- Use/Definition of Common Distribution Channels and Common Divisions for master data: Assign sales areas to each other -> A sales area shares its master data (e. g. customer hierarchies) with another sales area
- Keep validity periods to a minimum for the exact same assignment "Customer <-> Higher level customer" in the same sales area(s)
Example: 1. KUNNR = 1000 in sales area 1000/10/00 assigned to HKUNNR = 1200, valid from 01.01.2011 to 31.12.2011. 2. KUNNR = 1000 in sales area 1000/10/00 assigned to HKUNNR = 1200, valid from 01.01.2012 to 31.12.2012 -> Two KNVH entries. This is the same as KUNNR = 1000 in sales area 1000/10/00 assigned to HKUNNR = 1200, valid from 01.01.2011 to 31.12.2012 -> One KNVH entry. - Change customer hierarchies only if really needed (see above: Keep validity periods to a minimum ...)
- Delete (old) customer hierarchy assignments, if they are definitely not needed anymore. Handle with care and read the online documentation!
Furthermore make sure, that your database accesses the customer hierarchy data (KNVH) in the best way possible (using up-to-date database statistics, etc.).
If customer hierarchy maintenance causes performance issues in dialog transaction anyway, you can try/test to maintain the hierarchy in background using the Standard BAPIs mentioned in FAQ # 548716.
For example to assign a hierarchy sub-tree to another higher level customer please use BAPI_CUSTOMER_HIERARCHIE_INS. This BAPI is less performance intensive (and easier to use) than using BAPI_CUSTOMER_HIERARCHIE_UPD.
Furthermore please , when creating a customer master in transaction XD01 / VD01, you directly can assign this customer to a higher level customer: Sales area data, Tab "Sales". But of course there are checks performed, if the assignment is possible!
(You find the necessary customizing regarding field status in transactions OVT0 and OB20.)
In addition - dependent on the customizing settings - customer hierarchy partners are selected in sales order processing (partner determination -> Function module SD_CUSTOMER_HIERARCHY_PATH).
So large customer hierarchies can cause performance issues in transaction VA01, too!
The largest used customer hierarchy (highest number of KNVH entries) known to SAP Development and Development Support has about 250.000 nodes. But the hierarchy structure (see above) is not known!
Most customers have customer hierarchies with a total number of much less than 100.000 nodes (KNVH entries), but again the hierarchy structure is not known.
In any case we recommend to test customer hierarchy maintenance and hierarchy partner determination(!) before using it productive.