Active form hell

[Wim Gielis]

Thank you Mark,

Now I can reproduce it. This is very unfortunate, honestly.

05.png (77.34 KiB) Viewed 3029 times

Input on March, Y2 and March Y1 is visible. Who invented this ?
I should now expect phone calls by customers I guess, since I never paid attention to that "design decision".

[Mark RMBC]

Hi Wim,

All I can say is it wasn't me!

regards, Mark

[tomok]

Input on March, Y2 and March Y1 is visible. Who invented this ?
I should now expect phone calls by customers I guess, since I never paid attention to that "design decision".

AFAIK, it has always worked this way. This is actually one of the drawbacks of using separate year and month dimensions in TM1, that rolling 13 month presentations like this don't zero suppress in the manner you would probably like.

[Wim Gielis]

This is actually one of the drawbacks of using separate year and month dimensions in TM1, that rolling 13 month presentations like this don't zero suppress in the manner you would probably like.

I can understand this for months and periods, but the problem goes much further. Just think about Scenario. Every (financial) report could use some sort of selection of scenario and year/month in the columns: actuals YTD by period, budget next year at total year level, the latest forecast for the coming months at the month level, and so on. I cannot understand this design choice. If I have budget data for January next year, why should that drive my rows in an actuals report (month by month) if it happened to be the case that we didn't have actuals this year (and if scenario is part of the columns area of the active form, and if next year is used in the active form as an element).

Am I right when I say that:
- we can never have too few rows (rows that should have been there in my selection but that drop)
- but what can happen is to have an excess of rows (that are 0 and should be have been suppressed) ?

[Silverik]

This is actually one of the drawbacks of using separate year and month dimensions in TM1, that rolling 13 month presentations like this don't zero suppress in the manner you would probably like.

I can understand this for months and periods, but the problem goes much further. Just think about Scenario. Every (financial) report could use some sort of selection of scenario and year/month in the columns: actuals YTD by period, budget next year at total year level, the latest forecast for the coming months at the month level, and so on. I cannot understand this design choice. If I have budget data for January next year, why should that drive my rows in an actuals report (month by month) if it happened to be the case that we didn't have actuals this year (and if scenario is part of the columns area of the active form, and if next year is used in the active form as an element).

Am I right when I say that:
- we can never have too few rows (rows that should have been there in my selection but that drop)
- but what can happen is to have an excess of rows (that are 0 and should be have been suppressed) ?

Yes that's correct...

For the AF behaviour, it always have been like that.

By having:
- a continuous time dimension,
- and a "Current Forecast" version combining Actuals and Forecast to give you a full year picture,
You avoid most of these traps you mentionned.

i.e. to display Current year 12 Month Actual/Forecast.
Without a combined "current Forecast version" you need: 12 months and 2 versions (Actual, Forecast) = 24 combinations but only 12 displayed ---> you expose yourself to the issue
With a combined "Current Forecast" version you need: 12 months and 1 version = 12 combinations --> No risk there

i.e. to display rolling forecast, next 12 months accross FY
With 2 dimensions ("Year" and "Month") : you need 12 months and 2 Fiscal years = 24 combinations but only 12 displayed ---> you expose yourself to the issue
With a single time dimension ("Year Month") you only need 12 periods = 12 combinations --> No risk there, and actualy an additional benefit of a single time dimension, you can use a simple consolidation in the cube to see your rolling forecast....

You will still probably face some case where this is happening. You'll need to find some workaround, educate users.

But I agree this is a bit anoying but that's the way it is...

[Wim Gielis]

Many thanks Silverik, good information and glad that you joined the forum

Thanks Tomok too.

[Wim Gielis]

A follow up if I may, regarding the continuous time dimension: let's have concatenated year/period elements like 202008, 202009.
Suppose the users input values on months but in a grid: years across rows, periods across columns.

I am not talking about active forms here, but rather PAW or PAFE. In the periods dimension, there are (PA-type) hierarchies for months and years.
So, by crossing the 2 hierarchies, we can have a grid of suppose: 3 years by 12 columns ==> 36 periods/cells.
But, all cells are consolidated by definition, with month elements underneath.

02.png (4.56 KiB) Viewed 2989 times

Does this mean that C-level rules are out of the question ?
Does this mean that data spreading at C-level cannot be blocked ?
Does this mean that security (typically, blocking certain periods for WRITE) should be revisited ?

Or, rather, are we restricted to: 36 months at N-level in the rows rather than 3*12 cells in a grid ?
Or, maybe we need a 2 dimensional input cube and rules/TI ?

A lot of questions. I'm going to explore that but if someone can already share their findings, much appreciated.

[Wim Gielis]

Refer to: viewtopic.php?t=15508

[rbhansen22]

Hi all,

Active forms in Perspectives zero suppress on what would be the the symmetric view created from the elements referenced ... so if you have a stacked column axis ... even if you’ve removed some combinations, the symmetric view will still contain them which is why the view test is helpful.
Note that in PA for Excel that is not the case ... as it’s now calculating with MDX the zero suppression is a true zero suppression of what is in the form. (Also be aware that TM1 web still uses the older mode so you could end up with some differences if publishing).

Regardless, the zero suppression will only happen in the columns identified as part of the active form. If you don’t want the elements included in zero suppression, do not have the 1st parameter of the dbrw point them back to the active form view formula and just add a straight cube reference (or if you have a lot of extra columns in pre PA for Excel or if publishing you will want to create a separate view statement to reference for performance reasons).

Rebecca

[Wim Gielis]

Thank you Rebecca