I've difficulty to have corrects results for a table chart aggreagate by end of months date and the max date of the current month. In comparaison the KPI chart display the correct result for one date selected.
The application have 'Always one selected value' on the date field.
Your datamodel may be correct but I'm not sure if it's specially suitable for your data and requirements.
Recommended - especially by larger datasets - is to develop a datamodel in the direction of a star-scheme. Means to have a single fact-table and n dimension-tables. And this in regard to the development efforts, logically easiness, maintainability as well as the UI performance. Link-table approaches are usually rather the worst case.
In regard to my suggestion to apply one or multiple intervalmatch logigs I must be a bit more preciser. I really meant the logic behind an intervalmatch but not to apply them within the classical and inbuilt way - which creates rather large link-tables with additionally synthetic keys. Personally I don't use it in this way else I apply appropriate while loops, like:
t: load date(from + iterno() - 1) as DATE from source while from + iterno() - 1 <= to;
which is IMO much more flexible and enables me to associate the data without link-tables.
Transferred to your case I would try to resolve all from + to fields to real dates - at least for all matching/linking tasks and avoiding the link-tables. Like above mentioned the final logics within the UI should be as simple as possible so that simple user-selections are enough to control the used subset of data. To have all the from + to and loading + displaying them within the UI doesn't mean that they must be used to make all matchings with them else it would be better to flag, (pre-)calculate and associate the data already within the datamodel.
Beside this your intended set analysis logic within the table isn't possible in this way. The reason for it is that the measure is identically for all rows - the variable has always one value and won't change within the row to apply :
ValidFrom={"<=31.01.2021"}, ValidTo={">=31.01.2021"} for January and ValidFrom={"<=28.02.2021"}, ValidTo={">=28.02.2021"} for February and so on ...
To evaluate something in this way you would need a logic like:
whereby such an approach couldn't be recommended - neither form the efforts to develop the logic nor from the performance point of view.
Therefore I must repeat my suggestion to review the whole datamodel and to develop a real Qlik datamodel instead like it looked of transferring a sql-scheme with more or less adjustments to Qlik.
