А не приведете для наглядности пример Ваших иерархий?

Что касается Excel + MS AS, то я думаю, что у этих продуктов более тесная интеграция, чем у любого другого OLAP-клиента с MS AS. У меня даже есть такое подозрение, что Excel, Access, MS SQL Server и MS AS - это продукты, имеющие много общих внутренних компонентов...

измельчал форум, одни лишь круглые сэйлзы остались, на вопрос про mdx ответа уже и не дождешься

Круглые сэйлзы - это Вы про себя говорите? Ваш смайлик выглядит достаточно кругло :)

Что касается MDX - то это лишь инструмент, не все задачи он может решить. Ваш вопрос довольно непростой, люди на форуме Вам пытаются помочь - пытаются понять, в чем же состоит Ваша задача (возможно она решается и без функции ParallelPeriod). А Вы с ними играете в игру "Что, Где, Когда?"...

2. Сравнение показателей с плановыми значениями

Фиктивные дни - это Ваше изобретение, или это стандартный подход Microsoft?
Уж больно кривоват этот метод...

Я замечал, что те задачи (включая План/Факт с разной детализацией), которые в Cognos PowerPlay входят в стандартную функциональность и решаются визуальными средствами, иногда могут быть решены и в MS AS подобным образом. В PowerPlay нужно для консолидации Плана и Факта в модели куба использовать 2 таблицы фактов, а в MS AS - создать виртуальный куб на основе кубов с Планом и с Фактом. Я думаю, эксперты по MS AS консолидируют План и Факт именно с помощью виртуального куба.

P.S.: Вы спросите, почему я привожу пример, как задача решается в Cognos PowerPlay, зная, что Вы используете MS AS? Все просто - Cognos один раз "изобрел велосипед", предложил эффективную архитектуру для решения классических задач, и вполне логично, что стоит перенять этот опыт.

В том-то и дело что я далеко не эксперт, и никак не могу взять в толк, как слить 2 куба с разными измерениями времени (в Факте это ВремяДоДней а в плане это ВремяДоМесяцев) в один виртуальный.

Планирование, бюждетирование, анализ отклонений - это серьезные задачи, и Вам либо придется стать экспертом по MS AS, либо перейти на более дружественный Cognos PowerPlay.

Вам важно сначала разобраться в методологии. С моей точки зрения, если сейчас у Вас планы - помесячные, то отдельного плана на Год у Вас быть не должно! - он должен вычисляться автоматом (агрегироваться) на основе месячных планов. Когда Вы перейдете на подневное планирование - пропадет надобность в помесячном планировании.
С другой стороны, возможна ситуация, когда годовой/месячный/ежедневный планы создаются разными отделами и не согласуются - тогда можно закачать 3 разных плана.
Что касается отображения помесячного плана в отчете, когда задана детализация до недель или дней: в Cognos PowerPlay этим можно управлять - либо показывать NULL для плана на детальных категориях времени, отображая его лишь на уровне месяцев, кварталов и лет; либо распределять план пропорционально какой-то базе, либо показывать одно и то же общее число плана для каждого детального элемента.

Если захотите не мучаться с постановкой задачи - советую поиграться с ознакомительной версией Cognos PowerPlay.

Что тут такого серьезного в анализе отклонений, если нужно всего лишь два числа друг на друга поделить? :)

Я бы сказал, что не два числа - а миллион чисел друг на друга в многомерном пространстве куба, и чтобы в зависимости от контекста отчета экономисты, финансисты и др. конечные пользователи видели то, что они хотят. Это не так просто...

Разная детализация планов во времени это лишь одна сторона проблемы. Есть еще разная детализация планов по группам товара (план на конкретную модель/подгруппу моделей/группу моделей + еще десяток разных классификаторов), по торговым точкам (план на группу магазинов / на конкретный магазин ).
Интересно как с этим справляется Cognos?

В том то и кайф, что для Cognos не принципиально, по скольким измерениям куба сравнивать План и Факт. В PowerPlay самое простое - объединить 2 или несколько таблиц фактов (планы и факт) по оси времени (месяцы с днями или любая другая комбинация). Далее можно усложнять пример - дробить план, например, по группам товаров, добавив соответствующее поле/поля в таблицу плана - и связь между планом и фактом будет происходить не только по полю типа Дата, но и по другим полям. В кубах с Планом и Фактом всегда есть измерения (их верхние уровни иерархии), для которых в явном виде задан и план, и факт (Год-месяц, если план помесячный, Группы товаров). А вот для торговых представителей, для подгрупп товаров, для самих товаров, для клиентов план может быть пока не задан - и для них в PowerPlay используется 1 из 3 основых режимов распределения Плана (для каждого измерения можно задать свое правило).
Что касается ситуации, когда план задается одновременно на товар и на группу товара (узлы разных уровней иерархии измерения товаров) - то глубоко я это не копал. Думаю лучше избегать таких ситуаций, например сделать фиктивную группу для товара, по которому хочется в явном виде задать план (по аналогии с тем, что когда хочется для одного человека дать уникальный набор прав - создается группа пользователей, состоящая из одного человека).

Так это как раз и есть моя изначальная придумка с фиктивными элементами измерения.
А раз это решение универсально можно применить его и для времени.

Группы товаров/Товары и время - это разные вещи. Со временем шутки плохи :) Как бы объяснить попроще эту разницу...
Конечные пользователи привыкли видеть отчеты, в которых товары либо по группам, либо по подгруппам, либо до артикулов. То есть в традиционном отчете по товарам нет несбалансированных иерархий (хотя для анализа в кубах Cognos PowerPlay я часто делаю несбалансированные иерархии). Ответственность по продажам товаров обычно делится между менеджерами аналогичным образом - один менеджер отвечает за одну группу, другой - за другую. Поэтому и классические системы планирования предусматривает наиболее удобный для плановика подход - работа со сбалансированной иерархией.
А время - оно и в Африке - время :) Есть год, месяц, день (не считая кварталов и недель). Если добавить фиктивный день - то это может привести к проблемам - типа ошибки в подсчете числа дней. Кроме этого, хороший вопрос - если добавить фиктивные дни - это измерение останется измерением времени (Date, Time), или превлатится в текстовое измерение?

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

Не знаю как в MS AS, но если в Cognos PowerPlay измерение времени делать на основе текстовых полей (а не полей типа Дата) - потеряется некоторая функциональность - поддержка справочника валют в модели куба, прогнозирование, нельзя будет с легкостью вычислить показатели типа YTD, MTD (и то же самое для предыдущих лет), и т.п.

В MS AS любому измерению можно присвоить тип "Time", а уровням этого измерения типы "Years", "Months", "Weeks" и так далее. На основе этих свойств включается соответствующая функциональность, тип полей при этом не учитывается.

Главное чтобы MS AS не проверял, что в поле типа Month могут быть только числа от 1 до 12, дней не может быть больше 31 и т.п. :)

Владимир,

И сколько не долбал разработчиков Юра, все равно они к Microsoft убегают. :)
Не верят что-то в Cognos=Super коллеги из это тренда

У меня нет цели переманить кого-то с MS AS на Cognos. Не у всех на это хватит мужества, кто-то наваял какие-то модели в MS AS - и теперь для него это самое дорогое в жизни, для кого-то это гарантия стабильности в плане карьеры...
Другое дело, что хочется быть уверенным, что пользователи MS AS (видимо не эксперты), которые мучаются, работая с этим продуктом по крайней мере осведомлены, что есть более удобные OLAP-сервера, а есть менее удобные.
Кроме этого, дискуссии на форуме хранятся долго, и их читают не только фанаты MS AS, но и более объективные люди.
Эти дискуссии полезны и лично для меня - я узнаю много нового о MS AS - о его сильных и слабых сторонах :)
Можно будет как-нибудь опубликовать книжку Cognos vs MS AS - и каждая дискуссия будет представлять из себя отдельную главу.