Loading Data to a Consolidation

[ParisHilton]

Hi all,
I know I can't load data at a consolidated level, but I'm trying to explain to the pointy haired boss why not. To me it 'feels' wrong (possibly I've been using TM1 too long), but I can't come up with a concrete example of why it would be 'wrong' to do so. I sort of sense that it would mean trying to consolidate across a different direction wouldn't work but I just can't write it down. Maybe one of the TM1 guru's here has a concrete example of why it would be foolish of TM1 to allow us to load at consolidated level?

For what it's worth, when I have data at consolidated level, I've created a leaf member that replicates the consolidations name but with a suffix and loaded the data there. *(the suffix I've got is horrible, and I'm trying to come up with a good name at the moment!)

P

[rmackenzie]

I know I can't load data at a consolidated level, but I'm trying to explain to the pointy haired boss why not.

Just say it is fundamental to the way the technology works and please could (s)he stop asking so many silly questions? You can of course, explain that you can spread into consolidated intersections.

To me it 'feels' wrong (possibly I've been using TM1 too long), but I can't come up with a concrete example of why it would be 'wrong' to do so. I sort of sense that it would mean trying to consolidate across a different direction wouldn't work but I just can't write it down. Maybe one of the TM1 guru's here has a concrete example of why it would be foolish of TM1 to allow us to load at consolidated level?

If you could load into a consolidated level then what would happen to the sum of all the children beneath the consolidation? ... Perhaps the number to be loaded should just acutally add in to that existing total? Then just create a leaf element and load to that instead - which is what you've done and is a common solution.

For what it's worth, when I have data at consolidated level, I've created a leaf member that replicates the consolidations name but with a suffix and loaded the data there. *(the suffix I've got is horrible, and I'm trying to come up with a good name at the moment!)

The other thing that people do is create a summary hierarchy that is 'cloned' from the detail hierarchy. In the summary hierarchy you strip out the granularity you don't need and create n-levels that correspond to consolidations in the detail hierarchy - you can then input data to a cube with that dimension and it will still 'join' to a cube with the detail hierarchy. People often do this for forecasting where they don't want to forecast at the level of the actuals. The downside is you have actual versus forecast in two different cubes. YMMV.

[Alan Kirk]

I know I can't load data at a consolidated level, but I'm trying to explain to the pointy haired boss why not. To me it 'feels' wrong (possibly I've been using TM1 too long), but I can't come up with a concrete example of why it would be 'wrong' to do so.

I agree with Robin's assessment but I can give you a more boss-friendly reason in one word... transparency.

A consolidation is supposed to be a defined aggregation of values. Granted, the members of the consolidation can be weighted, but the definition is clear within the hierarchy structure. It may not be so obvious within a websheet or Excel file generated from that structure, but that's a different issue. The fact remains that anyone with the relevant access looking at a consolidation in Cube Viewer / Subset Editor can see exactly where the number came from, and exactly how it's defined. (Unless overriden by rules, obviously, but even those are traceable.)

if you load to a "dummy" N level element, as you do, that's fine too; again the composition of the consolidation is completely transparent.

But now imagine if you could enter directly to a consolidation other than by spreading to the leaves. There would no longer be any transparency. Did that number come from a calculation? Did someone just make it up and punch it in? Who knows.

Personally I'm a big fan of transparency. I'm also a big fan of the principle of "what it is is what it is", meaning that if a number is wrong it should be fixed in the source system. I am rather less a fan of the expressions "off balance sheet" and "below the line", but in the TM1 admin aspect of my work, that's not my call.

In the other part it is my call, and anyone supplying me with non-transparent numbers knows that I know how to query the system for myself, that though I am but a mere private company director and not a not a public company one I can actually tell the difference between a billion bucks of short term debt and a billion bucks of long term debt, that I can add, and that I am armed.

Consequently, it is my preference that the source and calculation of numbers not be obscured by non-obvious inputs, which is what something like entering to a consolidation would allow.

[Michel Zijlema]

I know I can't load data at a consolidated level, but I'm trying to explain to the pointy haired boss why not.

The pointy haired boss is quite aware these days...

Michel

[Alan Kirk]

I know I can't load data at a consolidated level, but I'm trying to explain to the pointy haired boss why not.

The pointy haired boss is quite aware these days...

Michel

Heh, I saw that one just yesterday, but I'm glad you found a link to it so that everyone can share. It didn't take but a moment for my thoughts to turn to Our Favourite Software when I reached the third frame.

[ParisHilton]

Thanks again for taking the time to reply people. Clear concise and boss friendly answers. Brownie points heading my way