I’M WILLING TO C#AGGREGATE, I’M WANTING TO C#AGGREGATE, I’M WAITING TO C#AGGREGATE

Not Alfred P. Doolittle, but maybe Alfred E. Neuman

How long, oh how long we (or at least Yr. Obt. Svt.) have waited for this, to wit, inputting in C#Aggregated?

In Alfred P. Doolittle’s poorly quoted immortal words, I’m willing to C#Aggregated, I’m wanting to C#Aggregated, I’m waiting to C#Aggregated, i.e., we can now (as of 7.4) input directly into C#Aggregated. No more oh-so-painful input into C#Local and then aggregating into, totes obvs, C#Aggregated. C#Aggregated by itself was a step in the right direction, as all good planning types care not a whit for the rigors and features of accountingland C#Local consolidation, especially since planning is all play accounting. The speed of C#Aggregated (eight-ish or more times as fast as C#Local) is what We Happy Few need; devil take the hindmost to planners who cannot see this need for speed.

And yet…and yet…

This is what we get. That doesn’t look overmuch like direct input to C#Aggregated. Observe the cruelty of input directly to C#Local. Is it so? Must we be tortured still with unfulfilled promise? As the Great Schnozzola said, that’s the conditions that prevail:

Bugger, it’s as before. Oh sure, when I enter data in C#Local, I can see the level 0 data in C#Aggregated, but direct input is not possible:

And of course I can aggregate and see totals in C#Aggregated but not C#Local:

This means that forms (Cube Views) must be input in C#Local and, if Entity is in the rows, flipped to C#Aggregated to see totals. Ugh.

Great googly, moogly, the 7.4 documentation supports this:

Are you kidding? Are you? Is OneStream? Maybe, ‘cos here it is in the 7.4 Release Notes:

Keep searching, and it’s there for all to see:

Read the instructions, Cameron

Well, the right instructions:

It really is that easy:

Here we are:

Note the data in C#Local. Can we get rid of this?

Alas and alack, no. Cleared out data and then input into C#Aggregated:

It’s just like input into C#Local:

Fear not

Just ignore C#Local. Who, amongst planning implementors, thinks about C#Local? Let us embrace C#Aggregated in all things planning. Why? Simple Cube/Quick Views, fast aggregation, no redundant/potentially consolidated C#Local (if C#Local is in play, it may inadvertently get consolidated – stay away from C#Local) data (although it is there in level 0 members). Win, win, and win.

Be seeing you.

Share This: