Feederless rules and zero suppression

[Steve Rowe]

Hi,
Working on 10.1.1 and attempting to rebuild a too large cube using the feederless C level rules technique and getting pretty impressive results so far, though it does feel like I'm tip-toeing around the edge of sending the system (and me!) into total melt down.

So I have everything working (nearly) as I expect and all the numbers are calculating and consolidating exactly as I want but they are zero-supressing, i.e. disappearing.

I'm wondering if this is normal? On the one hand I can see why they would fail the suppression since the ruled values are not fed, on the other hand if the ruled values weren't fed then they wouldn't consolidate properly. So the values appear to be both fed and not fed at the same time......

Also using ConsolidateChildren, not sure if this is interfering with it or not...

It would appear that the populated flag from a populated N level in a consolidation is different to the populated flag from a feeder firing and that zero suppression works off feeder flag not the consolidation flag. (Made up guess at what is going on under the hood).

Anyone been down this road?

Cheers,

[lotsaram]

Anyone been down this road?

Many times.

I use this all the time but try to limit it to KPI calculations which are multiplications, divisions or lookups. Wherever consolidation is required of a value that has been calculated by feederless C rule you need ConsolidateChildren and then you are in distinctly dicy territory. A real danger is that once consolidation is required you need rules everywhere to lots of other intersections that you just wouldn't need or think about with normal N rules that consolidate like data because any undefined C intersection is effectively treated as a STET and you will return the underlying consolidation unless explicitly handled with another C rule.

The zero suppression issue is an annoyance, hard to say whether a bug or a "feature" but I lean to bug. If you have a view with ONLY consolidated feederless calculations from the measure dimension and zero suppress then often you get no data (even though were there no rules the natural consolidation would return data!) but yet if just a single N element that sits behind the feederless measures is exposed in the view then hey presto, like magic there are all your feederless measures again with zero suppression behaving like it should. This is the workaround I use, just include the "base measure" in the view to ensure the null suppression works properly.

[jim wood]

As long as the consolidated value has children with static values then the consolidation should stay with supress zeros selected, rule or no rule. If it isn't working like this then it's a bug rather than a feature. Have you tested this in lower versions? I know in version 7 consolidations were designed to work this way. (I only worked at Applix after version 7 had just come out so not sure about 6 or below) I can't however say for certain that this particaular "feature" was tested that well.

[Steve Rowe]

Thanks guys, it kind of feels like a bug to me so nice to get some confirmation that the behaviour I see is experienced by others. I'll see if I can persuade support team to raise a defect. I see the same behaviour if I include the N level in a view.

For KPI type stuff it is easy and by far the best way of building something that has to be recalc'd at all levels in the hierarchy. Trying to extend it to N level calcs is a proper challenge though but that's good it has been a while since I had one of those...

Also thanks to lotsaram for making the first post covering this technique.

Cheers,

[qml]

One thing you need to be aware of with this technique is that if any of the weights between your N level and the C level that you are looking at are set to 0 then the faux feeding will not work and numbers will disappear from zero-suppressed views. You need to use any non-zero weight (the actual value doesn't really matter as you're overriding natural consolidation with your C-level rules anyway). If in some dimensions you have 0 weights on purpose (e.g. only the last day in each month rolls into the full month etc.) then you might want to consider setting the weight to something very tiny instead.

I have recently built a similar solution in 10.1.1 and only saw the behaviour you described when 0 weightings were being used. Other than that when the C element has any fed/populated children it should not disappear from zero-suppressed views, end of story.

[Steve Rowe]

Thanks Kamil, I'm pretty sure that there are not any in the space I'm looking at but will check. It is sounding increasingly like a bug, trying to get the time to package something up for IBM.
Cheers,

[deepakjain2020]

Hi Steve,

I think the issue is when we are applying suppress zero the records are disappearing in a cube view. Correct me if I am wrong in understanding.

One of the developer has written feeders statement in a way were he was bluffing with feeders.
We were getting appropriate data when Zero-Suppression was disabled, but when we calculated the same with enabling Zero-Suppression the records were disappearing.

So we changed the feeders statement and later we got appropriate results.
Bluffing with feeders is a good idea, but not at the time when we are having zero-suppression.

Hope your feederless rules doesn't include skipcheck.
Can you please check and let us know what it is showing in check feeders?

Regards,
Deepak Jain

[qml]

Deepak, I hate to patronise you here, but I assure you Steve is not having issues grasping the concept of skipcheck and feeders. This thread is in fact about a somewhat advanced technique of using skipcheck without feeder statements, instead feeding your calculations through other means. Nice try, though.

Out of curiosity, what exactly do you mean when you say 'bluffing with feeders'?

[deepakjain2020]

Hi Kamil,

I do understand there are few persons in a forum who are having a very good experience and good knowledge.
I rate myself as a beginner and can't even imagine at a place where the Steve and many people are. But I am curious to understand and learn.
My curiousity is to know what it might be showing when we view "Check Feeders".

Bluffing with feeders
example:

A is a consolidated element having B and C which are leaf level elements.
Consider D and X as some elements.
X having a value as 5.

Skipcheck;
D = A * X;
Feeder;
B => D

Now suppose we are having a value "Zero" for element B and there is some value '10' for element C.
We will get an appropriate result when Zero Suppression is disabled i.e. 50.
Row will disappear when we have zero-suppression as data is not fed properly.

For above example, if we right click and view 'Check Feeders' it will show as Not Fed.

I came to know about Bluffing feeders from this forum.

I am learning alot of new things on forum and credit goes to every person who is sharing knowledge over here.

Regards,
Deepak Jain

[tomok]

if we right click and view 'Check Feeders' it will show as Not Fed.

A feeder statement basically tells TM1 to feed the right hand side of the feeder whenever there is data in the left hand side. Just including the statement B => D does not guarantee that D will be fed. B has to actually have a value in it in order to feed D. There's no "bluffing" anything when it comes to feeders.

[Steve Rowe]

Kamil, Thanks a heap for the tip on the zero-weighted consolidations, that was the exact issue I was facing.... As ever obvious when you know the answer.

I owe some massive pints next time we meet!

Cheers,

[Steve Rowe]

Just to give some pointers on the approach, it is well worth experimenting with but it is a challenge and you may have to re-design your cube so that you can use it.

For the typical calculation C=A*B where A is the input value.
Put skipcheck on
Make A a child of C, this feeds C a "consolidation feeder" rather than rule feeder.
Write your rule at the C level C=C:A*B
Design your cube so that for any given rule you only need to involve one dimension, this is key as it limits the use of ConsolidateChildren to just the single dimension.

I _think_ this is key.
If you can get to point where there are no rules in place at the N level then you can deliver big performance benefits since the engine will consolidate the N level inputs before executing the rule, rather than applying the rule to the N levels and then consolidating.

You are trying to just calculate on the edges of the cube and leave the centre to consolidate the base values very quickly.

Just a large warning this is v challenging and can be impossible for some models, experimentation and practice is key, it is unlikely that I'm going to be able to provide any help on a specific models using this approach.

[jim wood]

Another point Steve is that security and communication are both very important. once users start to use and understand TM1 they will start to ask why is A a child of C. Especially if they are say accounts.

[qml]

Another point Steve is that security and communication are both very important. once users start to use and understand TM1 they will start to ask why is A a child of C. Especially if they are say accounts.

That can be largely addressed through security (as I think you tried to hint) i.e. introducing another level between element C and A and hiding it with element security therefore 'breaking' the potentially confusing hierarchy and masking it for the users. I think lotsa actually suggested it in his post a while back where he outlined the technique.

[Steve Rowe]

Thanks for the pointers on security, at this point the cube will be serving data for BI and not user facing so probably not a consideration.

I've been trying to cross link to lotsarams original post on this approach but can't find it....but full credit to him for raising it initially.

[qml]

Here is lotsa's post. I think this is a very powerful way of setting up your cube, but it's obviously not without its problems and challenges. As always, one needs to be able to figure out if this design ticks all the boxes in their particular case.

BTW, Steve - are you not giving users any self service via BI? If it's only pre-built standard reports then you probably don't need to consider the intuitiveness and security as you are saying. I think, however, that the TM1/BI combo really shines when you give users self service (e.g. Workspace Advanced is a good and easy front end for that). It is admittedly more challenging as you need to make sure your cube is as foolproof as possible and performs well, but it really opens up possibilities.

[iansdigby]

Although not terribly clearly expressed, this post of mine records a similar effect (zero-suppressed calculated C values disappearing) where weightings are not zero but are 1 and -1.

http://www.tm1forum.com/viewtopic.php?f=3&t=11233