Set analysis с неявным условием

Автор Givashenko, 31 июля 2018, 02:59:20

« назад - далее »

Givashenko

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

Суть такова:

Есть журнал транзакций, в нем интересует 2 колонки (Value и transaction_date).

Есть необходимость отобразить динамику остатка товаров по складу в разрезе артикулов, классов и т.д по полю transaction_date

Журнал транзакций приведен в такой вид, в котором, чтобы получить остаток на конечную дату в журнале достаточно воспользоваться конструкцией Sum(Value).

Но вот вся проблема в том, что когда применяются фильтры по дате (transaction_date), или того проще, строится линейная диаграмма эта самая Sum(Value) - считается только за 1 день (что в целом логично).

Перепробовал все возможные "заплатки":

1. Через доп. таблицу с остатками на начало периода (шило на мыло, арифметически не корректно)
2. Доп. запрос в SQL сервер с DSUM, для формирования стока на ежедневной основе (в целом работает, но вариант не из лучших по причине потери возможности нормально фильтровать по доп. признакам), в общем на случай крайнего отчаяния сойдет.

Вот, нутром чувствую, что можно решить через set analysis, задав условие, при котором будут суммироваться все записи ДО текущей даты (включая ее), что отобразит корректную динамику.

В связи с этим возникла проблема, никак не получается задать условия для set analysis ничем, кроме явного объявления даты, что в моем случае не катит.

Облазил весь мануал по кликсенсу, нашел только примеры с явным объявлением условий.

Удручает,что через Excel, акс и sql сервер это вообще не проблема, а вот через клик прописать вообще никак не получается.

Коллеги, есть у кого опыт решения подобных задач, где надо задать динамическое условие "суммировать все записи, если дата раньше или равна"?

буду очень признателен за какой-нибудь пример синтаксиса.

Заранее спасибо!!

HalLex

Добрый вечер!

sum({$<transaction_date=>} Value )

Что если Вам попробовать такую конструкцию?
Она исключить из выборки transaction_date

Givashenko

Добрый вечер, спасибо большое за подсказку.

Такой вариант навел меня на мысль вообще отказаться от представления динамики стока, а выводить только  текущий запас.

Однако, к сожалению, первостепенный вопрос это не решает, так как там логика иная, что то наподобии:

Sum(выражение, которое проссуммирует Value для каждой более ранней даты) + sum (value) на текущую дату.

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

Под текущей датой понимается не сегодняшний день, а каждая дата с момента точки отсчета. Что то вроде ведения истории данных.

В целом, реализуемо через создания мастер справочника с записями дата-артикул-value, но там теряется возможность исключать из выборки артикульные группы, разные складские помещения и прочее.

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

А вот казалось бы, просто график с накоплением )))

HalLex

Не совсем понял задачу.

"Sum(выражение, которое проссуммирует Value для каждой более ранней даты) + sum (value) на текущую дату."

Если Вам нужен накопительный итог, то можно построить такую конструкцию:

(RangeSum(Above(Sum(value),0,rowno())))

leorock

Добрый день! Одно из решений вашей проблемы - AsOf календарь. Не пробовали?
https://community.qlik.com/message/1346094#1346094

admin

Привет.
Решения два - "as of table" и предварительно рассчитанные остатки.
Можете воспользоваться поиском  по ключу: остатков.
http://qlikview-forum.ru/qvf/index.php/topic,1151.msg2913.html#msg2913
http://qlikview-forum.ru/qvf/index.php/topic,1696.msg4530.html#msg4530
http://qlikview-forum.ru/qvf/index.php/topic,1783.msg4872.html#msg4872

Givashenko

Спасибо всем откликнувшимся на проблему, предварительно подошло пока такое решение:


Цитата: HalLex от 31 июля  2018, 10:05:40  

(RangeSum(Above(Sum(value),0,rowno())))

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

Однако, не могу понять еще один вроде как элементарный момент, так как синтаксис клика идет у меня с большим трудом:
как вообще исключить дату из выборки. Например, если я хочу подсчитывать актуальный остаток на сегодняшний день по каждому артикулу без привязки к истории данных (загнать справочный показатель). То есть просто считать сумму в разрезе артикулов по всем датам, вне зависимости от фильтра дат.

Я же правильно понимаю, что это через set analysis как-то делается?

Еще раз спасибо всем неравнодушным

millik

За весь период работы с кликом, перепробовал кучу разных вариантов.
Самые рабочие - два.
1) Предрасчет остатков с хранением их в qvd. Если у вас есть жесткое закрытие периода хотя бы каждый месяц, то это самый правильный подход. Тогда придется пересчитывать только незакрытый период.
2) Использовать метод AsOfDate - самый простой в плане скрипта. И достаточно шустрый если не нужно считать всякие оборачиваемости и ООСы. Хотя даже они считаются со сносной скоростью.

Givashenko

На самом деле, здесь все гораздо проще, чем кажется.

Сама задача ставилась мне таким образом: просто нужна динамика стока. Этот показатель не будет (я надеюсь) фигурировать в дальнейших расчетах. Заказчик - это склад (операционный уровень). Им надо просто видеть динамику вход-выход-сток. Сам затык возник на уровне визуализации, когда клик не совсем корректно отразил движение стока по той формуле, которую я пытался ему задать. А так да, была мысль формировать на каждый период остатки по стоку через запрос в SQL и гнать его уже оттуда в клик, но есть ощущение, что это и не понадобится под конкретную задачу.

Судя по выгрузкам, через склад в сутки проходит ну максимум 2000 транзакций на 4000 артикулов, из которых в лучшем случае на стоке постоянно находятся в районе 2000. А если фиксировать сток ежедневно по всем артикулам в системе, получится, что за год только по этой таблице набежит в районе 1.5 млн строк, против 700-800 тыс на журнал транзакций. Поэтому и пришел к выводу, что элементарный вариант здесь не так уж и плох.

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

admin

Пожелаю удачи и приятных открытий в этом творческом процессе  :)
С таким подходом все получится,
держите в курсе. ;)

Яндекс.Метрика