NurglРедко тут пишу, т.к. во всем сам разбираюсь, а сегодня встрял на элементарной вещи.

Есть такая калькуляха считает средние отгрузки за год. CurrentMember выбран год.
avg(DESCENDANTS([Дата].[Дата].CurrentMember, [Дата].[Дата].[Месяц]), [Measures].[Отгрузки шт])
по сути считает среднее арифметическое по месяцам в разрезе года.
Но она не совсем верная, т.к. с точки зрения бизнес логики надо считать среднее по закрытый месяц. Т.е. надо использовать что-то вроде LAG или PrevMember, но в DESCENDANTS это не работает в данном разрезе....

Вопрос как сместить период на -1 месяц (на -1 мембер)
А потом будет еще вот какая проблема. Вы развернете копию OLAP базы, чтобы работать с ней как со срезом. Но вот эти "закрытые" месяцы будут смещаться.
Вывод - сделать группу мер со счетчиком "Счетчик закрытых месяцев", суммирование строк с 1, привязка к "Дата"."Месяц" неключевому атрибуту.

Сделать набор выбранных месяцев как DynamicMonthsSet as existing [Дата].[Месяц].[Месяц];
А формулу "Средние отгрузки шт" считать как AVG(existing [DynamicMonthsSet], iif(Measures.[Счетчик закрытых месяцев] = 1, [Measures].[Отгрузки шт], null) )

На уровень года останутся только его месяцы, из них будут выбраны закрытые. Группу мер при пересчете ежедневно обновлять, создайте view, куда формулой прописывайте 1 для нужных месяцев. Как только копия OLAP базы разворачивается для архивной работы - перестаете пересчитывать закрытые месяцы.

И вот эти закрытые с точки зрения бизнеса месяцы всегда используйте из одного места и из одного dynamic set набора.

КритикNurgl,

проще будет порекомендовать пользователям самим снимать галку с незакрытого месяца

у вас сейчас незакрытый месяц с точки зрения одного заказчика (пусть это подрезделение "склад"),
потом будет незакрытый месяц с точки зрения бухгалтерии,
потом у третьего подразделения будет свой незакрытый месяц,

и все они будут разными...
Таки да. И можно сделать измерение "ТипыЗакрытыхПериодов" - для бухгалтерии один элемент измерения и набор 1 для месяцев, для склада второй элемент измерения и набор 2 для месяцев, и все эти наборы в одну view и одну отдельную группу мер. Вместо того, чтобы пытаться с NOW() работать.
Потому что бывает ситуация, когда нужно взять OLAP базу и заморозить ее копию. Например, классификатор для номенклатуры поменяли, а планы продаж идут по веткам старого классификатора. Для нового не будут заново распределять планы, а факты в прошлом разъедутся. И получится LFL анализ выполнения план-фактов продаж кривым. Выход - оставить навсегда копию OLAP базы со старым классификатором и не менять никогда больше измерение номенклатуры. Как и набор закрытых месяцев. Не заставлять пользователей каждый раз галочками ставить перечень месяцев. Они ведь забудут, какие были тогда закрытые, какие открытые.

Если можно логику от бизнеса формализовать и зафиксировать в виде физических measures вместо набора непонятных формул, которые "извне" куба не видны - тогда нужно фиксировать. И не пользоваться NOW(). Я так думаю.