Оперативный расчет состояния объекта учета на основе транзакций.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Оперативный расчет состояния объекта учета на основе транзакций.

Mikhail Timoshin
Administrator
Добрый день, Женя.

Задачка твоя оказалась для меня весьма крепким орешком.

> Если у тебя будет время, попробуй решить такую задачку: в QlikView нужно  
> построить сводную таблицу, где по вертикали располагаются товары (или  
> отделы, склады и т. п.), по горизонтали – даты, а на пересечении –  
> остатки (в качестве таблицы фактов у тебя есть товарные операции,  
> например). Причем даты по горизонтали должны соответствовать фильтрам,  
> которые я наложил.

Решить ее я пока не смог. Однако, судя по твоему оставшемуся без ответов  
запросу на форуме "Stock levels best practice"  
<http://community.qlikview.com/forums/p/21619/82779.aspx#82779> решить эту  
"задачку" не так-то просто. Странно, что единственное предлагаемое  
западными коллегами решение повторяет методику, так называемых  
традиционных OLAP систем: создание избыточных данных путем  
предварительного агрегирования (суммирования) детальных транзакций в  
разрезе отдельных измерений (для товаров, например,  
день/неделя/месяц/год-склад) на этапе их загрузки из ERP системы в  
QlikView.

Может в этом и состоит сермяжная правда практиков и не стоит во всех  
случаях уповать на расчеты "на лету"?

Однако вернусь к возможностям QV пригодным для расчета состояния объекта  
учета (товарный запас, баланс по счету и т.д.) "на лету". Предполагается,  
что в таблицу фактов загружены только необработанные детальные транзакции  
по определенному объекту. Например, все типы товарных операций: покупка,  
перемещение, продажа. Все, что нам надо для анализа истории состояния  
объекта (например, ретроспективы уровня товарных запасов) - это:
1. Получить набор записей от самой ранней транзакции до первого указанного  
в горизонтальной шкале сводной таблицы (Pivot Table) временного периода (в  
качестве периода может быть день/неделя/месяц/квартал/год).
2. Просуммировать столбец целевого показателя полученного набора  
(например, количество по товарной операции).
3. Повторить пункты по всей горизонтальной шкале сводной таблицы.

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

Итак, у меня получилась пара формул.

Sum ({$<Posting_Date = {"<=$(=Max(Posting_Date))"}>} total <Item> Quantity)

Эта без фильтрации по времени выдает по всей шкале конечный баланс  
(текущий остаток), а фильтром по дате выдает по всей шкале баланс на дату.

Sum ({<Posting_Date = {"<=$(=Posting_Date)"}>} total <Item> Quantity)

Эта без фильтрации по времени выдает по всей шкале 0 (ноль), а с фильтром  
по дате выдает по всей шкале баланс на дату.

Обе эти формулы не годятся. Всякие там inter-record функции above и иже с  
ними полностью зависят от дизайна сводной таблицы, что мы не приемлем.

Женя, показывай свой вариант.

--
С уважением,
Михаил Тимошин
###############################################
Вы получили это сообщение, потому что подписаны на список рассылки <[hidden email]>.
Архив списка рассылки: <http://n3.nabble.com/QlikView-Users-f182695.html>.
Для отказа от подписки отправьте письмо по адресу: <[hidden email]>.
Для переключения в режим ДАЙДЖЕСТ отправьте письмо по адресу: <[hidden email]>.
Вопросы администратору отправляйте по адресу: <[hidden email]>.

ItemInventory.qvw (169K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Оперативный расчет состояния объекта учета на основе транзакций.

Evgeny Ivanov
См. объект на последнем листе.

С уважением,
Евгений Иванов
Руководитель направления BI/BPM решений
Импакт-Софт


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Михаил Тимошин
Sent: Tuesday, February 02, 2010 5:59 PM
To: [hidden email]
Subject: [qvusers]Оперативный расчет состояния объекта учета на основе транзакций.

Добрый день, Женя.

Задачка твоя оказалась для меня весьма крепким орешком.

> Если у тебя будет время, попробуй решить такую задачку: в QlikView
> нужно построить сводную таблицу, где по вертикали располагаются товары
> (или отделы, склады и т. п.), по горизонтали – даты, а на пересечении
> – остатки (в качестве таблицы фактов у тебя есть товарные операции,
> например). Причем даты по горизонтали должны соответствовать фильтрам,
> которые я наложил.

Решить ее я пока не смог. Однако, судя по твоему оставшемуся без ответов запросу на форуме "Stock levels best practice"
<http://community.qlikview.com/forums/p/21619/82779.aspx#82779> решить эту "задачку" не так-то просто. Странно, что единственное предлагаемое западными коллегами решение повторяет методику, так называемых традиционных OLAP систем: создание избыточных данных путем предварительного агрегирования (суммирования) детальных транзакций в разрезе отдельных измерений (для товаров, например,
день/неделя/месяц/год-склад) на этапе их загрузки из ERP системы в QlikView.

Может в этом и состоит сермяжная правда практиков и не стоит во всех случаях уповать на расчеты "на лету"?

Однако вернусь к возможностям QV пригодным для расчета состояния объекта учета (товарный запас, баланс по счету и т.д.) "на лету". Предполагается, что в таблицу фактов загружены только необработанные детальные транзакции по определенному объекту. Например, все типы товарных операций: покупка, перемещение, продажа. Все, что нам надо для анализа истории состояния объекта (например, ретроспективы уровня товарных запасов) - это:
1. Получить набор записей от самой ранней транзакции до первого указанного в горизонтальной шкале сводной таблицы (Pivot Table) временного периода (в качестве периода может быть день/неделя/месяц/квартал/год).
2. Просуммировать столбец целевого показателя полученного набора (например, количество по товарной операции).
3. Повторить пункты по всей горизонтальной шкале сводной таблицы.

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

Итак, у меня получилась пара формул.

Sum ({$<Posting_Date = {"<=$(=Max(Posting_Date))"}>} total <Item> Quantity)

Эта без фильтрации по времени выдает по всей шкале конечный баланс (текущий остаток), а фильтром по дате выдает по всей шкале баланс на дату.

Sum ({<Posting_Date = {"<=$(=Posting_Date)"}>} total <Item> Quantity)

Эта без фильтрации по времени выдает по всей шкале 0 (ноль), а с фильтром по дате выдает по всей шкале баланс на дату.

Обе эти формулы не годятся. Всякие там inter-record функции above и иже с ними полностью зависят от дизайна сводной таблицы, что мы не приемлем.

Женя, показывай свой вариант.

--
С уважением,
Михаил Тимошин


###############################################
Вы получили это сообщение, потому что подписаны на список рассылки <[hidden email]>.
Архив списка рассылки: <http://n3.nabble.com/QlikView-Users-f182695.html>.
Для отказа от подписки отправьте письмо по адресу: <[hidden email]>.
Для переключения в режим ДАЙДЖЕСТ отправьте письмо по адресу: <[hidden email]>.
Вопросы администратору отправляйте по адресу: <[hidden email]>.

=?utf-8?B?0JDQvdCw0LvQuNC3INGC0L7QstCw0YDQvtC+0LHQvtGA0L7RgtCwICjQsdC1?= =?utf-8?B?0Lcg0LTQsNC90L3Ri9GFKS5xdnc=?= (238K) Download Attachment