A hierachy with several characteristics in Integrated Planning

[Former Member]

Hi gurus!

Have you been able to implement an input-ready query with a hierarchy for several characteristics in row area?

I have two characteristics, 0SEM_POSIT and 0ACCOUNT and the requirement is that plan figures should be posted to 0SEM_POSIT but history data should be read from different 0ACCOUNT values for different companies even if they use the same template to plan their values. I have added 0SEM_POSIT as an external hierarchy characteristic to 0ACCOUNT info-object and created a hierarchy for 0ACCOUNT in which hierarchy nodes are defined as 0SEM_POSIT values.

However, if I use an aggregation level in my query, which has characteristic 0SEM_POSIT, hierarchy nodes are not input-ready (unless I use disaggregation, which is not possible if I want to post to 0SEM_POSIT).

Am I missing something or is it simply impossible to configure such a multidimensional query with a hierarchy? I didn't find any solution for this in SAP documentation.

Greatful for your answers, points guaranteed for helpful messages!

Sari

[Former Member]

Thank you Gregor for you reply!

I tested 0ACCOUNT hierarchy with different kind of aggregation levels and 0SEM_POSIT as external hierarchy nodes and noticed that it was not possible to make nodes postable in a way that the values would have posted to 0SEM_POSIT. Finally i found also sap documentation telling me the same, so I decided to change my course with this:)

I have used disaggregation in many layouts, but it didn't fit here, because of several reasons. The main reason is, that several 'companies' (they all have their own comp_code in sap) use this layout. They all have different characteristic relationships between 0ACCOUNT and 0SEM_POSIT even if they use same 0ACCOUNT values. If I had used 0ACCOUNT hierarchy in my layout (different hierarchy for different 0COMP_CODE), I could have defined different accounts for each company to a hierarchy node in their own 0ACCOUNT hierarchy. The users should not have been able to see 0ACCOUNT-level though, which would have meant that the analysis item could not have been activated for navigation (only hierachy nodes would have been visible and 0ACCOUNT level would have been hided). Even if there would have been disaggregation, the users would not have known about it. The problem is, that disaggregation takes time and I think the users would not have been pleased to wait for refresh especially when they would not have known a disaggregation takes place.

Another problem would have been, that there is only one way to define the disaggregation in a query column. My requirement is that user is able to choose between two different ways to disaggregate planned values to lower organisation level (according to last year budget or actual data). That means that I have to have two planning functions in my layout for the user to choose for.

I desided to create characteristic relationship based on user exit. I will use 0SEM_POSIT as row characteristic in higher organisational levels to plan for. To derive the right 0SEM_POSIT to each 0ACCOUNT value in profit center level, characteristic relationship source characteristics are profit_ctr (which I can use for determining what the company is) and 0ACCOUNT and target characteristic is 0SEM_POSIT. I created a DSO to load different 0SEM_POSIT values for each account for different companies. I read the values from dso table when deriving 0SEM_POSIT.

Points assigned to your kind answer, Gregor!

Sari

[gregor_dieckmann]

Hi Sari,

a BW hierarchy for 0ACCOUNT using 0SEM_POSIT as an external characteristic is not a multidimensional objects. The nodes using 0SEM_POSIT are in fact like text nodes, the only difference is that the node descriptions come 0SEM_POSIT master data values. So BW hierarchies are 1 dimensional.

Why is disaggregation not an option? Then you plan on 0ACCOUNT, but you may still use 0SEM_POSIT in the InfoCube (but not in the aggregation level). E.g. when 0ACCOUNT is the finer granlar characteristic whith your hierarchy on 0ACCOUNT you can derive the 0SEM_POSIT values when 0ACCOUNT is filled. To do this create a characteristic relationship of type derivation that derives 0SEM_POSIT from 0ACCOUNT using the BW hierarchy.

Then planning on 0ACCOUNT in fact also fills 0SEM_POSIT in the InfoCube. So you can use 0SEM_POSIT in other queries.

Another option is to copy the historic data, derive from 0ACCOUNT the 0SEM_POSIT values as above and then only include 0SEM_POSIT in the aggregation level, maybe to create an additional hierarchy for 0SEM_POSIT if you what to have a hierarchical display for 0SEM_POSIT. You may also use both characteristics in planning with disaggregation in the query and dispay the group change as a hierarchy. This works well, if the 0SEM_POSIT, 0ACCOUNT hierarchy is balanced (exact one levle per characteristic).

Regards,

Gregor