How to load data at non-leaf levels directly?

Question

Hi,
We have a requirement where by Fact data for different scenarios gets loaded at different levels of ragged/recursive hierarchies.
For example, the Actual sales are loaded at Product Leaf level but the Budgets data is available for loading only at Product Group level (which is one level above Product Leaf in Product Hierarchy).
Please let me know if this is possible in Essbase.
This is rater urgent.
Thanks & Regards,
Gurudatta

Answer 1

Yes, as Gary said, performance is one factor.
There are other less prominent reasons to keep agg missing on, but the overall reason for me is that it just makes more sense, especially when you consider the user operations involved in zooming in on data. When you do a zoom to bottom level, it's going to show you that the sum of the parts is equal to the whole in a well designed cube with agg missing on. With agg missing off, this may or may not be the case, and would NOT be the case if you load at non-leaf members. In that scenario, you end up with a "where did the data go?" issue that adds time to any hunt for answers as well as the likelyhood that more questions will be brought up that ultimately need answering. It's not obvious, but one scenario can be described as follows:
(For convenience, I will use a standard time dimension hierarchy of YEAR|QUARTER|MONTH|DAY to illustrate the issue)
2008 = 12000
    2008Q1 = 3000
        Jan 2008 = 1000 (input)
            1/1/2008 = #Missing
            1/2/2008...
        Feb 2008 = 1000 (input)
        Mar 2008 = 1000 (input)
    2008Q2 = 3000
      ... and so onIn the above example, there are two ways that confusion and errors can occur, the first is that somebody decides to upload some data to the days (level 0) instead of the month, and it doesn't add up to the total for the month. The second is that somebody decides to upload to the quarter, and thus the months no longer add up to the quarter amount. I treat these two conditions separately because in the first, the total is still represented by the amounts loaded to the monthly values, whereas the second case changes the grand total. If you were troubleshooting, you have to go level by level to see where the "breakdown" occurs by comparing each and every parent value to the sum of the children. It's a valid condition that is almost impossible to find quickly. There is no quick "show me all the inputs" approach, and no easy way to enforce an "input only at these levels" condition (there is, but there isn't as it's only practical in a perfect environment and trust me here you won't have it for long even if you could create it to begin with).
So, long story short, data consistency goes out the window in a "load at upper level" cube, and the simple answer of providing an input member for the required generation(s) is much easier and reliable in the long run.
Of course, there will always be exceptions, I just like to avoid them at all cost on this issue.