Techniques to not over feed with virtual dimensions

[PlanningDev]

I may already know the answer to this but if you have an input cube where you simply enter a numeric amount and then pick a couple of dropdowns. An then you want to report on those picklists as actual dimensions, what techniques are there to not overfeed?

Currently I believe you are stuck to a conditional feeder or using a TI. I would be interested to know if anyone has any slick techniques other than these?

[Gabor]

I think, you are talking about a disadvantage, which was built into TM1 from the very first. As long as you do traditional consolidations, feeding works fine.
If one intend the usage of extra dims as a kind of dropdown to display variations of original data, then conventional feeding is very restricted, as you blow up your feeding volume.

The best way I know, to keep a smart (rule based) TM1, is the introduction of feeder dummy elements in the extra dims and move your N-level elements one level up, means make every N-element a C-element with having the dummy leaf as child.

There are a couple of tricks to get back the usual TM1 cube behaviour (zero suppression etc.), however the creation of rules is more sophisticated of course, because you cannot write N: business rules anymore. The biggest step ahead was, when 8.2.2 introduced the ConsolidateChildren function, so I could get rid of external compilations into a TM1 server.

Best Regards
Gabor

[whitej_d]

I may not be fully understanding the scenario here, but can't you just reference the picklist cells in your feeder.

ie

Cube 1 - input cube

Dim 1 - sku (sku A, sku B, ....)
Dim 2 - SKU Info (Category, Department, etc as picklists, quantity,revenue, as numbers)


Cube 2 - reporting cube

Dim 1 - sku
Dim 2 - 'measures' (quantity, revenue etc)
Dim 3 - Category
Dim 4 - Department
.....
....


Then the rule in Cube 2 would read:

Code: Select all

[{'quantity', 'revenue'}] = N: IF(
    !Category @= DB('Cube 1', !sku, !Category)
 & !Department @= DB('Cube 1', !sku, !Department),
    DB('Cube 1', !sku, !Measures),
    CONTINUE
); 

The feeder in Cube 1 reads:

Code: Select all

[{'Quantity'. 'Revenue'}] => 
  DB('Cube 2', !Sku, !SKU Info, 
        DB('Cube 2', !SKU, 'Category'),
        DB('Cube 2', !Sku, 'Department'), .....
  );

Again, I'm not sure this is the sort of situation you're looking for, but this would introduce no overfeeding at all. The If statements in the rule aren't too slow, even with huge cubes. The feeders would also need to be reprocessed whenever a picklist value is changed, but if you play around with settings, and the feeder source, you can do it so that feeders are re-fired whenever a picklist is changed.

[George Regateiro]

I have used Whitej_d's method with a little variation to get around the refiring issue. I use an accompanying string feeder. For the numerical values on the input template I have a corresponding DBSS that will populate a string value if the numeric is not zero or blank it out if the numeric entry is zero. That way if the picklist value changes then the corresponding numeric in the reporting cube is fed automatically.

Using the string feeder might not be the most efficient way to handle it but for our instance it was a good compromise around the refiring, but it is efficient enough that we have not run into any issues using this method.