Рассмотрим упрощенно такой пример. Происходит поступление/выбытие материала:

Д/К Дата_проводки Кол-во(кумулятив)
S 01.01.2010 5
S 01.01.2011 5
H 01.01.2012 -5

Если построить отчет на некумулятивном показателе, выводящем остаток на 01.01.2013, то получим

Кол-во(некумулятив)
5

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

В отчете, приведенном выше, некумулятив используется, чтобы максимально быстро получить результат, и ограничение в фильтре задано как "=01.01.2013". Новый отчет при этом должен выглядеть так

Кол-во(некумулятив) Дата_последнего_поступления
5 01.01.2011

при этом дата последнего поступления 01.01.2011 не должна искаться по условию "<=01.01.2013", то есть нет такой роскоши, как просмотр и анализ всех записей вплоть до 01.01.2013. Поэтому возникла идея как-то извернуться и попробовать создать еще и некумулятивный показатель для даты последнего поступления, чтобы оставить ограничение "=01.01.2013" и при этом получить

Кол-во(некумулятив) Дата_последнего_поступления(некумулятив)
5 01.01.2011

Но при создании некумулятивных показателей они могут иметь агрегацию только "SUM", а нужен, по идее, "MAX". Может есть у кого идеи, как выйти из неприятного положения?!

А если создать кумулятивный показатель с агрегацией "MAX", а в отчете дополнительно его ограничить по Д/К ?

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

К тому же, если еще добавить реалистичности, то требуется также рассчитать срок хранения (в днях или месяцах) с момента последнего поступления, то есть

Кол-во Дата_последнего_поступления Срок_хранения
5 01.01.2011 ...сколько-то там дней (месяцев)

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

С кумулятивными показателями все работает и считается, но чем дальше уходим по времени вправо, тем печальнее... Возможно, у кого-то подобная задача была. Интересуют любые идеи и способы выхода из ситуации (кроме самых радикальных)

Приветствую!

Быть может посмотреть в сторону использования некумулятива только для данных остатков, а для дат использовать другой провайдер (DSO, куб)? Тем самым логику со сторно (для дат) можно обрабатывать на этапе загрузки, и количество показателей в некумулятивном кубе подсократить.

А можно поконкретнее по поводу другого провайдера: какой должна быть логика обработки сторно, при которой бы не пришлось просматривать все данные?!

Чтобы не создавать отдельную тему задам вопрос здесь (так как все в рамках одной задачи)...

Как известно, при сжатии некумулятивного куба, в область 0recordtp = 1 E-таблицы попадают записи с остатками на дату 31.12.9999. Вопрос - почему в этой области не удаляются записи со всеми нулевыми показателями (кумулятивными и некумулятивными)?

Пример куба до сжатия (F-таблица):
0recordtp kf_in kf_out
0 10 0
0 0 10

Пример куба после сжатия (E-таблица) с удаление строк с нулевыми показателями:
0recordtp kf_in kf_out
0 10 10
1 0 0

То есть строки с нулевыми показателями для 0recordtp=1 не удаляются. Это баг и надо искать ноту (пока не нашел) или нулевые остатки для некумулятивов должны всегда храниться? Но такое хранение приводит к тому, что область 0recordtp=1 распухает, особенно, если остатки приходится хранить на достаточно детальном уровне