Добрый день!

AS2k sp3

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


Дальше получился куб, с мерами Сумма отгрузки и Сумма опаты и измерением Дата (упрощенно).
Нужно посчитать сумму просроки на конец периода. Это сумма разности мер
(Сумма отгрузки - Сумма опаты) за выбранный период. Сумма считается только по строкам, у которых поле "Оплатить до" меньше поля "Дата".

Простите за неточность. Не меньше поля "Дата" конечно, а меньше последнего дня выбранного члена измерения "Время", т.е. меньше конца выбранного периода.

Выскажу свои соображения. Поскольку строки агрегируются, вытащить их поле "Оплатить до", чтобы сравнить с концом периода в первозданном виде невозможно. Агрегировать его тоже нельзя :)
Мне поможет измерение, которое сможет "достать" каждую строку по отдельности. Именно поэтому было введено поле "Ид" - уникальный идентификатор записи. По нему было построено виртуальное измерение RecId, в качестве листьев соержащее все идентификаторы строк.
Дальше нужно было перебрать с помощью этого измерения все строки, сравнить даты и получить сумму разностей. Для перебора строк воспользовался функцией Generate, в надежде на конструкцию Current, но видимо я что-то пишу не так, СМ выдает ошибку на выходе.


38807 - это я пока для простоты, еще не думал как буду вытаскивать конец периода. Значения поля "Оплатить до" хранятся как int - число дней от 01.01.1900. Это поле я тоже внес в куб как меру.

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

ну плохо я знаю mdx, плохо.. все приходится пробовать методом тыка. а как надо?
при тестировании конечно все равно бы понял, что не считает разность, написал бы как-нибудь по другому, благодоря вам сделаю это раньше :) Задачу это не решает в любом случае

можно вдаваться, передизайн так передизайн, куб все равно еще не эксплуатируется, а в стадии разработки так сказать, так что я могу себе это позволить :)

хм.. похоже уже и не придется никуда влазить, т.к. предложенный код дал то, что было нужно. За что мерси =)

2 ShIgor
а вот еще какой вопрос, вы большой спец по мультиселекту, скажите, можно ли получить последнюю дату в интервале (тот самый конец периода) при мультиселекте?

Я написал такой запросик:

isEmpty почему-то не сработал, хотя данных там нет. А в целом запрос дает то, что нужно, но только при условии, что на протяжении всего выбранного периода будет мера [Measures].[Сумма отгрузки]. А в суровой действительности, меры по всему периоду может и не быть, т.е. факты к примеру могут закончиться 15-го мая, а пользователь выберет март, май. И хотелось бы получить именно 31 мая, а не 15.

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

К сожалению должен вновь вернуться к данной проблеме. СМ, предложенный ShIgor работает, но при порядке 60-80 тыс. записей за месяц (а в целом их около 1млн и дальше будет больше) клиент просто умирает при обновлении =( Очень долго обрабатывается.. Дело усугубляется еще и тем, что эту же формулу я применил еще к двум другим СМ. В общем караул, давайте придумаем что-нибудь побыстрее плз =)

Решение от OldNov не подходит, т.к. нельзя заранее вычислить разницу между Оплатить до и концом периода (как это требовалось в условиях задачи), т.к. конец периода задает пользователь, а значит, он динамический. В целом картина такая: Дата - это дата когда клиент забирает у нас товар. Сумма отгрузки - сумма, на которую товар забрали. Оплатить до - дата, не позднее которой от клиента должны поступить деньги, Сумма оплаты - платеж клиента за товар.
Пользователь хочет видеть, есть ли по клиенту просрочка за этот период, т.е. для тех строк, где Оплатить до < конца периода вычисляется разность Сумма отгрузки - Сумма оплаты. Если разность > 0, то это прсрочка.