LastFilledValue?

Modeling
1

Is there something like LastFilledValue() ?

I have a repeatable group with a date and some other properties. I would like the newest entry filtered on some properties.
But currently, our computation

FirstFilledValue(../ZerlB*/RtKStZB 
    Having [../ZerlB/Status] == "offen" 
    and [../ZerlB/Storno] == False 
    and [../ZerlB/RtKStZB] == MaxValue(../ZerlB*/RtKStZB)
)

returns either the latest entry if it also matches the other 2 filter conditions, or nothing because all filter-conditions-
matching entries are not the latest.

See attached POC:
POC_Having.json (5.9 KB)
In this example:
image
entries 1 and 4 are matching the filter conditions “status == offen and storno == false”, so I would like to get entry 4 as the latest.

How can I achieve this?

2

Hi @marieestelle-firm-summit

It looks like you’re trying to find the maximum value of RtKStZB which is “offen” and Storno == False. If this is correct, what about:

MaxValue(../ZerlB*/RtKStZB 
    Having [../ZerlB/Status] == "offen" 
    and [../ZerlB/Storno] == False
)

AYm6JLS5yX
AYm6JLS5yX1920Ă—1200 166 KB

3

Such an easy solution!! :smiling_face:
Yes, I think it’s what I want. I’ll give it a try, and check all concerned places! thanks a lot!

4

Well, I have a follow-up question. Now I still want to identify the latest entry satisfying the criteria, but I want to return some other field from that group. So the “MaxValue” doesn’t work anymore.
I tried

FirstFilledValue(../ZerlB*/SomeValue
    Having [../ZerlB/RtKStZB] == 
    MaxValue(../ZerlB*/RtKStZB 
        Having [../ZerlB/Status] == "offen" 
        and [../ZerlB/Storno] == False
    )
)

but of course, two nested Havings is not allowed.

I tried introducing a helper field to compute the inner Having, so that I just need to return

FirstFilledValue(../ZerlB*/SomeValue
    Having [../ZerlB/helperLatestFiltered] == True
)

but the helper field doesn’t get a value. I guess I should watch the MMH about Indexing again…
meanwhile, are you able to spot any obvious mistake? :thinking:
POC_Having.json (9.6 KB)
With the same example data

image
image772Ă—450 15.9 KB

I still target entry 4, so I would like to get the value “444” in the POC2 field… and I would expect exactly one “true” in the last column, and 4 Falses.

5

Hi,

you’re right, we’ve got an open ticket looking into nesting of Kernel Language operations, A12-14972

But back to your models and your question. When I enter the data, the “helperLatestFiltered” is calculated correctly and the target entry 4 is identified. What you might be seeing is that the data is not recomputed until you interact with this. A Computation of a Field is triggered if you update a field value used in the computation. I don’t see a problem in the Computation Rules that you’ve modeled.

Given that the “helperLatestFiltered” Field is purely there to represent 2-value logic, I’d recommend modeling this as a Confirm and simplifying the computation. You can see this in the attached model. This would also reduce the amount of data you are saving but you still have the issue that this calculation is processed for every row in the repeat.

To solve this issue, you can reference the date that we calculated for “POC: date of latest entry satisfying the filter”

FirstFilledValue(../ZerlB*/SomeValue Having [../ZerlB/RtKStZB] == [POC])

You could make the POC field transient so that the value is not saved and then you only have one computation for the repeat instead of one computation for every row of the repeat. This has been done for the POC4 field in the attached model.

POC_Having_v3.json (10.8 KB)

6

Hi Malcolm,
Thanks for your answer! Indeed, when I loaded my test data into the 2nd version of my model this morning, I could see the proper calculation. Some Friday-Afternoon-Effect… :grin:
Yes, I’ll turn my first helper field into a Confirm, that’s enough. Why is it an issue that it is computed for each row? Ow, I just got it: I compute the POC field once (and use it) instead of the helper in each repeat! Yes, good point. I’ll check how it fits in my real model (which of course is much more complex than the POC).
Thanks again! I feel I just became a better modeler :smiling_face: