Did you think it all the way through? Did you? Mostly.
In the last thrilling, brilliant, and not the least bit possibly misleading blog post on C#Aggregated, Yr. Obt. Svt. stated, “Who, amongst planning implementors, thinks about C#Local? Let us embrace C#Aggregated in all things planning.” Yeah. No. Mostly.
Calculations
Yes
All of the above is true, but it doesn’t go far enough. Yes, you can input in C#Aggregated and yes you can consolidate (aggregation, not consolidation takes place once the Cons member is swapped from C#Local) in C#Aggregated, and yes can view aggregated parent level Entities in C#Aggregated and not in C#Local with an aggregation-not-consolidation, and yes level 0 data is in both C#Local and C#Aggregated (the one acts as pointer to the other) but what about calculations? A Custom Calculate Data Management Step does specify the Consolidation dimension member. We only care about data in C#Aggregated – that is sort of the whole point – so surely calculating there makes sense.
No, or a foolish consistency is the hobgoblin of little minds
Level 0 is the place
Let’s have a looky-loo at data in our beloved GolfStream running 7.4.1 in C#Aggregated:
Is it also there in C#Local?
Yes, Indeed! Empirical observation, i.e., I looked at it and this is the only thing that makes sense, suggests that C#Local is a pointer to C#Aggregated and vice versa for data can be entered into either and then show up in the other. Where it’s actually stored doesn’t matter, does it? Maybe?
Just about the world’s simplest Finance Business Rule
I am calculating a * b:
To review, that’s the dollar value in A#2000_100 (inexplicably, GolfStream does not provide aliases for its accounts) multiplied by the FICA % (equally inexplicably, GolfStream uses special characters in its driver names) to calculate A#2000_200. That use case, hopefully, is not inexplicable.
This is a level 0 calculation, data is in an indicated C#Aggregated, so surely all I need to do is set up a Custom Calculate Data Management Step:
Run the rule and…
Great Googly Moogly
Nothing. That’s a bit of a bother. What if I change the Cons member to C#Local in the Data Management Step?
Success!
As all of this is at level 0, data is in both C#Local and C#Aggregated. Just as if it was input or loaded:
Shall we review?
This is a bit complicated, but not overmuch.
C#Aggregated can be used for inputting level 0 data. It cannot be used when (and OMG, this confuses me because calculations are supposed to be bound by the Data Unit definition, but there it is) defining the Data Unit for a Custom Calculate. It must be used in a Data Unit definition when performing a Data Management Step aggregation:
And here it is. Note that as expected (and remarked upon in the last post on this subject), parent level Entities are not consolidated in C#Local:
As always, whew.
It doesn’t matter, not one jot
Data input in a Quick View or Cube View can be in C#Local or C#Aggregate. What about a data load?
Interestingly (yes, it is, sorta), there is no place that I can see to indicate what Consolidation member an Import Data goes to. It’s just….C#Local/C#Aggregated. I’m no accountant (this is being incredibly charitable, let us plough on regardless), but it seems to me that the point of Consolidate is to either perform currency conversion (planners get this) and/or perform accounting-thingy bits like eliminations (I await the tortured cries of CPAs as they note that I’ve wildly undersold what consolidations do). Given that, and given that data has to start somewhere, that somewhere might as well be C#Local.
I really and truly am looking for my OneStream comrades in arms to correct the above; I think it’s mostly right.
Don’t believe me? Show me where in a Data Source one defines a Cons dimension member:
If it’s not in the Data Source, it can’t be transformed:
And there’s no place that I can find to define it in Workflow. It just is.
It’s not all bad
The rule of eschewing C#Local is almost completely correct, just not for Custom Calculate Data Management Steps. That’s it.
Be seeing you.
