Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
I want to know if there is a way to calculate how many care-episodes that are ongoing for each year month.
A Commitment is ongoin if it starts or ends during the timeperiod or if it starts before the period and the end date is null (i.e has not been ended.)
Each commitment has a start date and an end date.
The following set expression gives the right total and can be used in a KPI visualisation:
={<Year=,
"Year-Month"=,
Date=
>} Count (
{
<
CommitmentStart= {"<=$(=Maxstring(Date))"},
CommitmentEnd={">=$(=minstring(Date)) "}
>
+
<CommitmentStart= {"<=$(=Maxstring(Date))"},
%CommitmentKey = E({<CommitmentStart={"*"}>})
>
}
%CommitmentKey)
I want to put this in a barchart or a line chart and that means that the max date and min date for the period is dependent on the year-month(or time period) in the chart. I have tried to wrapp it in an aggr function but as I understand it, an aggr function is only evalueted once and there for dose not give me the desired result.
If I try to calculate this in the script and assign an "on-going date" to each day the commitment is ongoing I need to create at lot of extra data with uniqe values wich takes up a lot of hard drive and memory. Sure its possble to calculate each commitment as ongoing for each year month but some times the users need to se ongoing per week or day.
What I suspect is needed to be done in order for this to work is to itterate the calculation for each year month(time period in the chart), is this possible? I have looked in to chart scripting but the documentation is quite lean and it is almost like learning a new language.
Antother workaround i have tried is to creat a measure for each time period but that is no really a great option (even thou the performace is really good).
Any one who have had similar issuse and been able to solve this without using the load-script? (chart scripting or something else)
Best regards
@sDahl Explore chart level scripting
It's not solvable with a single set analysis because this is quite the same as a selection - and this selection state is the same against all dimension-values. The mentioned solution of using n specialized expression is IMO not and quite practically because this copy & paste + the few period-adjustments within them is quickly performed.
An alternatively might be to use if-loops to compare the Start/End-values against the period-dimensions. But such if-loops aren't really nice and the performance is rather bad and quite probably significantly slower as n set analysis expressions.
Especially if this kind of view isn't a single one else n ones will need similar methods to match the Start/Ends against the period-selections you should consider the script-solution by resolving the Start/ends to a dedicated date again. It's not mandatory necessary to duplicate all data within it else a small associated link-table may be sufficient. In many scenarios is the growth of the data-set size not significantly because most of the data are redundant and won't need an extra space - only the index-length of the data-table is on top.