Scenario
Business users wanted to see the balance sheets and income statements based on some specific hierarchy which was not coming from ECC system. So, they decided that they will maintain 2 hierarchies out of which one will be loaded from ECC system and other will be custom maintained in BPC dimension administration. While creating the custom members in hierarchy, users faced several issues and error whose resolutions will be explained in this document.
Why multiple hierarchies
In most of the implementations, hierarchies for profit center, accounts, cost center usually come from ECC system. For example: In ECC, accounts are groups by their type and accordingly assets accounts fall under asset node, liabilities fall under liabilities node.
However, this will be used to create balance sheets and income statements very well. But let us say business is planning and they would like to see all the accounts in one group that are related to revenue/expenses generated/incurred in fleet. It could be on product basis, region basis or any other business function relate criteria. This way it becomes easier for business users to group accounts according to their convenience, which is different than the standard hierarchy.
Implementation of multiply hierarchy
Create a new hierarchy in structure of account dimension from BPC web administration page. For help on creating the alternate hierarchy please refer:
http://scn.sap.com/docs/DOC-56122
1. Unhandled Error: unmarshal.invalid.xml
Error detail:
This error is encountered when you try to delete the members in the hierarchy or sometimes when you try to change the members existing in the dimension.
Reason of this error: There is a dynamic table from which BPC pulls data whenever we request. In addition to this there are BW tables where actual BPC dimension data is stored in BW server. Whenever we delete the data from a dimension it sometimes reflects the data in BW table but the dynamic table is not refreshed. In this case we need to sync the BW table and dynamic BPC table.
Solution: Solution for this error is a program: “UJA_REFRESH_DIM_CACHE”. This program will sync the dynamic table with the BW tables. After executing this program, reprocess the dimension and the error will be resolved.
2. Base member ‘XXXX’ cannot be a parent of ‘XXXX’ in PARENTHH1
In this case user was trying to create a H2 hierarchy members by suffixing ‘_H2’ to the members assigned in H2. However, user made a mistake in which he assigned the _H2 members to H1 hierarchy. This was a rule violation.
This error occurs when we break the rules of creating multiple hierarchy.
Rule says: If for example: Account “300000” rolls into “Q_50_H2” in H2 hierarchy then while creating “Q_50_H2” as a member, its parent should also be populated in H2 column and not in H1. If it’s in the H1 column then it will likely fail and throw this error.
ACCOUNTP | H1 | H2 |
300000 | Q_50 | Q_50_H2 |
300001 | Q_50 | Q_50_H2 |
300002 | Q_50 | Q_50_H2 |
Q_50 | Q_30 | |
Q_30 | L_6 | |
L_6 | L_8 | |
L_8 | GL | |
Q_50_H2 | | Q_30_H2 |
Q_30_H2 | | L_6_H2 |
L_6_H2 | | L_8_H2 |
L_8_H2 | | GL_H2 |
GL_H2 | | |
This way if you create your hierarchy then it won’t fail.
Conclusion
Alternate/multiple hierarchies are very useful for finance users in order to see the reports according to their custom build hierarchies which are easily understood and closely relate to their day to day work. While creating these multiple hierarchies we just need to take care of the rule mentioned above and can be really beneficial for any customer.
