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

Типа фиктивное ФИФО нужно придумать? реальных данных нет, какая партия продана?

что то вроде "остатки-партия1>0, значит еще не продана, и следующая остатки-партия1-партия2<0 значит партия 2 продана уже. на бумаге формула есть, как в клик преобразовать правильно не знаю

да, есть данные по количеству произведенного товара, и дата производства

если я правильно вас понял, смлтрите в сторону rangesum(above))

про накопления знаю, таким образом посчитал остатки по всем товарам, но партии производились в разные дни, как мне создать признак, что партия продана или еще продается?

Можете почитать про функцию peek в скрипте, с помощью нее вы сможете навесить флаг продан товар или нет

предполагаю что если кумулятивная сумма проданных больше чем произведено кумулятивно, значит текущая(для строки) партия продана

ну тут еще играет фактор того, что может быть из предыдущей партии продано не все, а уже есть новая партия, тогда какая то часть товара будет с одним сроком, какая то с другим...

Смотря какой вопрос будет задаваться к данным. Если вопрос - "какая сумма остатка по партии на день", то это можно посчитать в формуле если все движение товаров в разрезе партий уже загружено. А вот если вопрос - "Какая оборачиваемость товара по поставщику?" или "Какой средневзвешенный остаток по договору?" а договор или поставщик это признак партии, то лучше вне Qlik посчитать витрину на каждый день с остатками по партиям и использовать ее. Иначе в Qlik будут здоровенные формулы, очень сложные и долгие в расчетах.
Вообще второй вопрос на большом объеме данных очень непростой с точки зрения производительности.

Поддерживаю, это в учетной системе нужно предусмотреть, а не в клике. Как сверяться будете?

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

Если в Qlik загружена таблица с остатками товара и там есть поля - Дата остатка, Дата производства, Срок годности в днях, КоличествоОстатка, партия и товар. То можно сделать так

Измерение: Партия
Мера: SUM(if([Дата производства] + [Срок годности в днях] < [Дата остатка], КоличествоОстатка, 0))
написал через if чтобы логика понятна была, можно через set анализ

Я несколько раз разрабатывал отчеты для учетных систем которые вычисляли FIFO от таблиц-документов. Это задача не для Qlik, там очень много нюансов.... Например в какую партию добавлять товар при возврате, как быть с товарами на разных условиях типа комиссия и тд. Чтобы эти все вещи обходить приходится чаще всего мыслить процедурными запросами - то есть перебором построчным данных. А Qlik для этого слабо годится поскольку там подход чаще всего декларативный как в SQL.

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

А главное, после всех этих процедур результат может не биться с реальностью)

Он точно не будет биться ! )))

пробовал я считать FIFO в Qlik, но если я считаю "процедурно" как в учетных системах в алгоритме - 1. выбрать все по товару, 2. Составить очередь 3. Рассчитать для каждого документа расхода документ прихода и поделить документ расхода по ссылкам на приход. То в Qlik это работает только на мелких объемах данных. Как только речь заходит о реальных боевых данных это все считается очень долго. То есть на пуле данных "сеть магазинов DIY" где 20000 товаров и 10 магазинов надо считать за последние 2 года и примерно 500 разных поставщиков алгоритм сдувался сразу же

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

Это не клик задача имхо, это задача систем контроля спроса, ценообразования, эластичности и тп. То есть чисто биай системой не обойтись, как раз из-за объемов данных и большого кол-ва вывода инструкций магазинам, менеджерам и тп. Как какой-то отчет, что-то можно собрать внятное, если скажем все же агрегировать покатегориям. По сути, нужен именно модуль управления остатками, запасами, закупками, в связке с биай системой. В последней снимаем стату о том, как работает первая.