Planning on aggregated level (parent hierachy level)

[Former Member]

Hey all,

I was wondering if there is any feasible solution if you want to implement a planning sceneario where you

don't want to plan on basemember level. Let's assume you have a very detailed structure for your profit

margin but time by time you don't wan't to plan on detailed cost element but on a more aggregated level.

Do i really have to change my hierarchy for the profit margin or is there any workaround how i can plan on

aggregated level ?

another aspect why i don't want to change the profit margin hierarchy is that actual data comes on detailed

level so that it would be great when if i could use same hierachy in planning and reporting without performing

a top down allocation of my aggregated planning data.

Best regards,

Moritz

[Former Member · Accepted solution]

Hi Moritz,

Yes you can do this via the WRITE BACK BADI, I am currently doing this at a customer. You need to "CATCH" the data before it is written to the database and disaggregate the data from the parent level down to base level members. You need to come up with an algorithm (based on your requirements) of how you plan to do this; weighted, even spread, etc.

This is possible though. Hopefully this helps.

Cheers, Scott

[Former Member]

Hi Moritz.

Method introduced by Scott described in "[How To... Use the Write Back PreProcess BAdI|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f0309226-814f-2d10-61a6-ef8da29e3727?quicklink=index&overridelayout=true]". It works pretty fine.

[Former Member]

Hey all,

thanks a lot for your support ! So far i already knew they about the existance of the write-back BADI. As of now i just don't know if this is the right solution. But as far as i understood this is the only way to handle data planned on an aggregated level. My only problem ist that in my use case disaggregation is excluded because we don't want to see (disaggregated) data on basemember level due to that fact that no planner i really responsible for du to disaggregation. So i'm searching for a solution where i can save data on aggregated level. At the moment i'm thinking about a solution like Gersh mentioned where i create 'shadowbasemembers' for each parent node and save data on this level.

But i'm still thinking about an easier way to solve this issue.

Thanks so far for your input,

Moritz

[Former Member]

Hey all,

thanks a lot for your support ! So far i already knew they about the existance of the write-back BADI. As of now i just don't know if this is the right solution. But as far as i understood this is the only way to handle data planned on an aggregated level. My only problem ist that in my use case disaggregation is excluded because we don't want to see (disaggregated) data on basemember level due to that fact that no planner i really responsible for du to disaggregation. So i'm searching for a solution where i can save data on aggregated level. At the moment i'm thinking about a solution like Gersh mentioned where i create 'shadowbasemembers' for each parent node and save data on this level.

But i'm still thinking about an easier way to solve this issue.

Thanks so far for your input,

Moritz

[Former Member]

> because we don't want to see (disaggregated) data on basemember level due to that fact that no planner i really responsible for du to disaggregation.
> Moritz

I don't fully understand the reason why not to use BADI, but if you don't want to display records on base level to end user, you simply can display only members with HLevel < BaseLevel. Simply speaking, you hide the last level of hierarchy and user enter plan data as if he actually planes on aggregated level.

[Former Member]

Hey Anton,

the reason is that ur process defines that the user can choose on wich level he would like to enter the data. that coul look like that user is planning some mempers on parent level and some on basemember level. for this issue i'm looking for a solution.

Any ideas ?

[former_member200327]

Hi Moritz,

This sounds like very vague requirement. What if one user assigns an amount to a node and another user assigns a value to a child of that node? And this is just one example; with such requirements it's possible to get many scenarios which are hard to interpret or have multiple interpretations.

I'd suggest you clarify with the users what they really need (not want). Allowing each user to plan at arbitrary level can not be a Planning requirement, sorry.

Regards,

Gersh

[former_member200327]

Hi Moritz,

There are multiple ways on how can work around the restriction that BPC doesn't store data at node level. One option is what Scott described above.

Another could be something similar to what IP is doing behind the scenes: create a "shadow" base member for each hierarchy node that could be inputted. You can even give that shadow member same description as the node has. I'd recommend keep tat shadow member input at different DataSource from all other base members. This way you can either include shadow member in a report or exclude it.

Please let us know if you need farther clarification.

Regards,

Gersh