Если создать островную таблицу для связи значений фильтров

Допустим решения нет, делаем две таблицы, где у нас есть отгрузки по складам и по авансам… сумма аванса оценивается по сумме всех заказов в общей таблице. Т.е есть рейтинг. Если у нас данные разведены в модели, как мы посчитаем сумму всех заказов и внесённых предоплат

Я ж говорю, считать сумму на складах и суммировать ее с суммой внесённых авансов, которые ещё не относятся к складам

Я это к тому, что есть свои нюансы, при которых выбранная модель можете не оптимальна, но верная в контексте задачи

Это нужно делать на этапе создания модели

Что бы была группировка

Вот тут вариант описан.
Вы не меняете текущую модель, только расширяете ее.
И там где надо суммируете ещё и нераспределенные авансы.

Не вижу проблем

Посчитайте все. А в конце разнесите на разные таблицы

Я может немного запутался в синтаксисе, но надеюсь Никита сможет найти и понять что ему нужно из кучи этих вариантов, которые тут предложили.

Синтаксис анализа множеств порой вырвиглазный

Особенно, если встраивать формулы, поиск значений и р(), е()

Посмотрите здесь может найдёте что то полезное https://community.qlik.com/t5/Qlik-Design-Blog/Fact-Table-with-Mixed-Granularity/ba-p/1468238

Спасибо , гляну :) но я вчера решил свой кейс

Создал обычный справочник из общей таблицы с данными, взяв поля Склад, Заказчик. В одном таблице данные с учётом пустых ячеек по полю склад, в другом только склад с наличием наименования в поле . Соединил  таблицы и прописал на этапе загрузки: если склад пусто , то берём значение скал из таблице без пустых полей склад, если склад из одной таблицы равен складу из другой, то оставляю значение по складу ю, если склад из одной не равен складу в другой, то поле в where отсеивается

Потом ключ и цепляю к основной таблице

И все ок

Но странно что нет подходящей функции

Ее не может быть, т.к. невозможно в пользовательском режиме выбрать отсутствие значения - противоречит идее самих данных

Там можно по идее было посчитать авансы так как вам надо через сумму двух сумм, но это плохой вариант, такие вещи надо делать моделью