Advice on inserting data at parent level

Question

Hi experts,
I would need some advice on how can I enter data at parent level. As we cannot enter data at parent level I am figuring out different strategies to do so. The one I seem to like the most is to create members representing the parents where we can input the data. For example:
- 2008.Total (Parent)
    + 2008.Generic (Leaf)
    + 2008.Jan (Leaf)
    + 2008.Feb (Leaf)
    + etc....
I would need to do this in different dimensions in my application. So here are the questions:
1) Is there anything wrong about doing this?
2) Is there a better option? (what is the Best Practice in this case?)
3) In the case of doing this for the TIME dimension, there are some properties which value is not easy to set for those members (TIMEID, YEAR and LEVEL). I don't really know where and how those properties are used and the help doesn't help me much (what is the "time format required for Analysis Services"?). So what values have you used in these properties for such members?
Thank you very much,
Rafael

Answer 1

Hi Rafael,
What purpose is your application designed for? In a legal consol application, would never mess with the standard time dimension setup, in particular the time dimension. The setup of the Time.Level and Time.Year properties are very sensitive in the operation of some of the business rules, particularly the opening balances & account transformation rules (where there's a time-period offset functionality). I always try to retain the standard time dimension setup there.
This means, for example, using a seperate datasrc member (or members) if the customer insists on having "13th period" for year-end adjustments. If they don't go into December along with the standard December values, then the carry-forward opening balances for the following year can be very tricky to calculate.
If your application is purely analytics, or for planning, then you should still understand what business rules features you want to use before deciding the time dimension design. When I've had year-total input data, I either
1.) use a standard 12-month time dimension, and by practice always put total-year data in December. Set up input schedules appropriately, and train people appropriately. Use Dec not Jan, or else the year-total and periodic/YTD computations in the cube won't work correctly. And consider your Account.Acctype carefully.
2.) If the data is for annual values that aren't directly part of the P&L or B/S, and are things like allocation drivers, tax rates, inflation rates, stuff like that -- which doesn't get added up along with the monthly values to come to a total-year "full picture" -- then I follow the structure from the old Outlooksoft demo. Create each of your years with the standard 12 months. Then create
Input.Year
xxxx Input.Quarter
xxxxxxxx 2008.Input
xxxxxxxx 2009.Input
xxxxxxxx 2010.Input
etc.
Then set your YEAR = 2008,LEVEL=MONTH for 2008.Input, etc.
This approach works well in logic *LOOKUPs and also keeps the dimension structure clean & intuitive for end users. If you put your 2008.Input under 2008.Q1 or 2008.Q4, then every time someone lays out or drills down in a report, they will curse the designer, since they now need to remove that extra column of the 2008.Input member.
With the datasrc approach for the "13th month" you can control whether the year-end adjustments are there or not, for those few reports where you'll want to see them. And 99% of the time, your time dimension "looks" normal.
I'm sure there are other approaches beyond what I've discussed, but I've never gotten into trouble using one or both of these two.
Regards,
Tim