declanr wrote: ↑Sun Jul 14, 2024 9:16 pm
If this wasn't a control dimension; you could add a consolidation to the }clients dimension and feed that - feeding a consolidation is essentially just shorthand for feeding every N-level element under the consolidation. However, I would not recommend it with a control dimension (you can add consolidations to control dimensions but it could cause unforeseen issues.)
In this particular instance; it looks like other than the measure dimension (rates) you only have a year and period dimension; so it could be quite a small cube dependent on how many other measures there are.
If it is a small cube AND there are not any/many other rule calculations in it; then you could probably get away with turning off Skipcheck altogether... I would recommend fine-tuning the rule to only work on future/forecast rates and use a TI to populate historic/actual periods (assuming they don't need live "real-time" updates.)
Alternatively; create your own duplicate of the }clients dimension (with an "All Users" consolidation) which you would use in the cube instead of the }clients dimension and feed that consilidation.
Other alternative is - does it really need to be fed?
If you construct the views in a sensible way you can normally get away without feeding some cells; for example in another scenario you populate a rate for all products. But you only need to see the product if it has a volume in that period; so you make sure that the volume is also shown alongside the rate and then the suppression will work on the rows because of the volume cell being fed.
In YOUR particular scenario; you are wanting to feed the rate for EVERY single client anyway - so you don't need to suppress to hide clients. That leaves only year/period combinations - you can probably define those combinations via subsets (or an MDX view on the tuples) and leave suppression turned off altogether.
Welcome to the world of TM1 - (until feederless rules make their way into the product) understanding feeders is one of the primary concepts that everyone should focus on early.
Something that often gets overlooked for a long time into people's careers is the step of at least asking the question of "do I really need to feed it?"
In this case maybe you do; but maybe you could save yourself a headache by realising it's actually not necessary.
Thanks for the detailed answer.
If this wasn't a control dimension; you could add a consolidation to the }clients dimension and feed that - feeding a consolidation is essentially just shorthand for feeding every N-level element under the consolidation. However, I would not recommend it with a control dimension (you can add consolidations to control dimensions but it could cause unforeseen issues.)
It seems to me that this option is technically impossible, because IBM cant consolidate string elements (}Cllients elements of string type).
In this particular instance; it looks like other than the measure dimension (rates) you only have a year and period dimension; so it could be quite a small cube dependent on how many other measures there are.
If it is a small cube AND there are not any/many other rule calculations in it; then you could probably get away with turning off Skipcheck altogether...
In this question I gave an example of a minimal cube that demonstrates my problem. Of course, this problem involves a cube with a large number of dimensions and elements.
I would recommend fine-tuning the rule to only work on future/forecast rates and use a TI to populate historic/actual periods (assuming they don't need live "real-time" updates.)
This is a good approach, I use it in other cubes of my IBM model (for me TI is easier than Rules). But this problem requires real-time calculations.
Alternatively; create your own duplicate of the }clients dimension (with an "All Users" consolidation) which you would use in the cube instead of the }clients dimension and feed that consilidation.
Oh, I didn't think about that. Maybe this is a good idea, I will suggest it to my team. We are used to using the }Clients dimension in the cubes of our IBM model - this can become a problem.
Other alternative is - does it really need to be fed?
If you construct the views in a sensible way you can normally get away without feeding some cells; for example in another scenario you populate a rate for all products. But you only need to see the product if it has a volume in that period; so you make sure that the volume is also shown alongside the rate and then the suppression will work on the rows because of the volume cell being fed.
In YOUR particular scenario; you are wanting to feed the rate for EVERY single client anyway - so you don't need to suppress to hide clients. That leaves only year/period combinations - you can probably define those combinations via subsets (or an MDX view on the tuples) and leave suppression turned off altogether.
Sounds good, but I need time to test this.
What can you say about this idea:
Pass values only for the Admin element and then, inside the 01_Approval cube, distribute the values in the }Clients:Admin slice to all other elements (except Admin). I tried this and it seems to work, but there are problems with the feeders inside the cube 01_Approval...
Anyway, your answer is very useful, especially when there is little information about IBM (official documentation, this forum, Cubewise topics).
If you don’t mind, I’ll add one more message to this topic; I need to experiment with feeders and skipchecks for some time.