Palo Community Forum

Dear Forum Members:

I am desperately looking for a solution for the the following issue:
I am trying to setup a palo based product calculation. There is one major obstacle that seem to become a knock-out criteria for deploying palo:

Other than usual, my product calculation solution requires changing consolidation factors over time.

Example:
Database: DB1
Cube: Cube 1
Dimension 1: Year (2009 ....2015)
Dimension 2: Month (Jan.....Dec)
Dimension 3: Supplier (Supplier1 ....Supplier 3) (Variying consolidation factors...!!!!)

January: Supplier 1 = 60% (Cons.Faktor 0,6), Suppl.2 =20% (C.F 0,2) Suppl. 3=20% (C.F.=0,2) (Sum of Consolidation =1)

February: Suppl1= 35%, Suppl2=40%, Suppl3=25%

Since consolidation factors are to be setup for a dimension on the highest node (the database), I can change them only for all month at time.

It is practically impossible to use rules as a work around because it would mean to setup hundreds of rules that have to be extended and customised for every (dimension-) element to be created in the future.

The only solution I can see at this time is to create an individual database for every single month. This is pretty nasty when it comes to reporting over time spans.

Any help and idea is greatly appreciated.

Thany you!!!

Holger, thank you for your time and hint. Sounds feasible. I will give it a try and get back with feedback asap. Thank you again.

Sorry for the delay but I had to try things out:

Unfortunately the results are less promissing.

Using a second "weight" cube instead of "palo consolidation factor functionality" does not work for the following reasons:

while a consolidation factor works correctly by not just applying the splits to the childs but also to the parent it will assure correct calculation throught all aggregation levels.

deploying a rule that "weights" the childs by the splits setup in the weight cube, will lead to aggregations (meaning parent values) that are only correct if you look at the childs while you are on base element level.

If you for example aggregated 2008 and 2009 to ALL YEARS, the result of All Years will deliver wrong calculation results.

In my special case (which is way way more complex than the above example) I have already setup a huge bag of rules to make it (still not) work. I guess even I won't be able to dig through this mess tomorrow.....:-(

I am still not willing to give up. I am sure there must be a clean solution?
Any idea is welcome! Thanks again