Как вариант, наш гуру Роб выложил простой пример по остаткам: https://community.qlik.com/t5/QlikView-App-Dev/Is-it-possible-FIFO-in-QlikView/td-p/169332

Конечно, все зависит от объема данных, но задача будет очень ресурсоемкой, потому что вам нужно будет для КАЖДОЙ транзакии делать слепок остатков, чтобы аллоцировать списания на соотетствующую партию

Вы спросите своих пользователей как они будут данные qlik проверять или "на слово поверят".
Я сделала на одном проекте, задолбалась показывать, что qlik считает правильно, пользователи сверялись с Excel и были варианты.
На втором проекте, где просто себестоимость считали управленческую  сами задолбались через Excel корректировать и пошли правильным путем.
Но в моих случаях изначально начиналось вполне невинно, давайте чуть-чуть данные поправим через Excel, а выливалось в нормальную такую задачу после всех правок

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

ну это не честный фифо уже)

Не, все честно было, началось все с построчной теории, и после выяснили, что объемы можно уменьшить агрегацией, и восстановить обратно джоином цены поставки назад к транзакции. Все честно)

ну ладно)

Спасибо, я увидел приблизительное решение. Если коротко про задачу - нужна оборачиваемость и сроки хранения текущих остатков по складу в разрезе документов поступления при том, что остатки в разрезе документов поступления в системе не хранятся - только движения. Решение временное, и только на части складов, просто нужно разгрести очень большой завал.

В посмотрите в сторону банально abc/xyz анализа

Там как раз дату возьмёте по приходам, движения перед этим нарезать на транзакции, вывести все таблицей и графиком. Вполне себе норм. Делал так как раз для оборачиваемости складов.

Коллеги, вопрос по QS, есть ли способ перестать выдавать лицензии по правилу (prof allocation rule или analyzer allocation rule) при достижении определенного числа выданных лицензий? Пример, есть группа А и группа B, если пользователи из группа А уже получили 100 лицензий, то больше им не выдается. Если пользователи из группы B уже получили 50 лицензий, то больше им не выдается. При этом, скажем, общий запас лицензий на сервере равен 500.

Правила безопасности не могут считать числа типа количества объектов. Но! Можно сделать CustomProperty , которое заполнять цифрой бэкэндовым сервисом, который будет через QSR API считать кол-во выданных и заполнять запись Property. Как тебе?
:-D

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

Спасибо, буду мучать QRS

Мне круто, костыли наше все:)))) спасибо ещё раз, буду ковырять)

Ааааааааааааааааааааааа

хотя примерно так я это и представлял

Да вот да)))

Данных сколько?
Если не сильно много то AsOfCalendar и налету считайте остатки и все остальное производное от них, и всякие скользящие

не не не)