Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I need a static KPI that doesn't change when any filters are used throughout my app,
reading around it looks like the key is using {1} but I'm evidently not getting it in the right place as it's not working!
Current format is as below which returns a null when a filter is selected:
1-
((Sum({1}{$<TdateYear={"(=$(vCurrentYear))"},NPD_Other={'Overhead'}>} Nmhrs))+ (Sum({1}{$<TdateYear={"(=$(vCurrentYear))"},NPD_Other={'Overhead'}>} OThrs)))/
((Sum({1}{$<TdateYear={"(=$(vCurrentYear))"}>} Nmhrs))+ (Sum({1}{$<TdateYear={"(=$(vCurrentYear))"}>} OThrs)))
Hi, try using the 1 to replace the $... so instead of this :
Sum({1}{$<TdateYear=...
You have this:
Sum({1<TdateYear=...
There is some more information in the 'modifiers' section of this page: Set analysis and set expressions | QlikView Help
You may try:
Sum({1 $<TdateYear={"(=$(vCurrentYear))"},NPD_Other={'Overhead'}>} rangesum(Nmhrs, OThrs)) /
Sum({1 $<TdateYear={"(=$(vCurrentYear))"}>} rangesum(Nmhrs, OThrs))
Thanks both - I've tried to simplify by adding the calculations to variables - would this be a better way to do it and if so where does the 1 go?
1-
sum(
v_Overhead_LastYear/ v_AllTime_LastYear)
Thanks Marcus - does there need to be a closing } for the {1 ?
The 1 is a set identifier, so goes at the beginning of the set analysis, after a {
The closing } comes at the end of the set analysis expression.
I can't get the range sum to work? it seem s to want an extra }
Also, your example where you have used variables... you can apply an outer set analysis expression at the start of the formula, so it then applies to the whole thing. Note this will depend on how your variables are defined, i.e. you need to make sure they aren't pre-evaluated; they need to evaluate as part of your final combined formula.
Inner and outer set expressions | Qlik Sense on Windows Help
I think there were not all causes fetched - therefore try it with:
Sum({1 <TdateYear={$(vCurrentYear)},NPD_Other={'Overhead'}>} rangesum(Nmhrs, OThrs)) /
Sum({1 <TdateYear={$(vCurrentYear)}>} rangesum(Nmhrs, OThrs))
Variables are a very powerful feature - but they are adding complexity because there are extra dependencies to how a variable is created + where they is called again + which kind of content is included.
What ever - variables shouldn't be the starting point else the end. Means if there is a working expression/logic which is either very large and/or quite redundant it might be worth to outsource into a variable - because of the fact that the working were already proofed the sometimes challenging syntax-stuff isn't so hard - but the opposite way could be quite painful.