Коллеги. Возникло вот пару вопросов по стандартным временным переменным. Поиском таких вопросов не нашел.
Первый и самый важный:
Ситуация в том, что делаю в BEx Analyzer запрос, предназначенный для запуска в режиме изменения (для планирования). При этом планировалось сделать так, что пользователь выбирает значение переменной, которая ограничивает 0calyear, а потом заполняет набор показателей (для выбранного года). Но тут я столкнулся с некоторым непониманием ситуации - ведение основных данных для этого признака не осуществляется, при этом, на моем пустом кубе, он дает выбрать до 2012 года (видимо такие даты есть в каких-то других провайдерах в системе), а уже на 2013-й и более пишет, что выбрано недопустимое значение признака. И, собственно, что же делать, если пользователю понадобится запланировать 2015-й год, например?
Правильно ли я предположил, что ограничение по 2012 год связано с тем, что в каких-то провайдерах есть данные с этим годом?
Есть ли какой-то стандартный и логичный мехнизм для ведения мастерданных временных признаков?
Может есть какая-то настройка, которая позволит в фильтре ввести новое значение признака (значение, которого нет ни в кубе, ни в мастерданных)?
В голову пока приходят только следующие мысли:
1. Сделать какой-то инфопровайдер, в котором только даты и стандартные признаки и грузить его нужными значениями.
2. Заполнить свой инфопровайдер какими-то записями, где указан, например, только год\квартал\месяц, а остальное или пусто или ноль (а потом это станет проблемой, если нужно будет посчитать количество записей на какую-то дату)
3. Переделать запрос так, чтобы можно было добавлять строки (получается неудобно и некрасиво). Кстати сейчас вспомнил, что когда я ставил 0calyear в строки запроса, чтобы можно было добавить новую строку, то запрос мне новую строку для ввода предоставлял, а вот при попытке ввести туда (и по всем показателям) значение (2020) - выдавал ошибку "Нет свойства признака 2020 для признака Календарный год".
4. Использовать просто свой признак, который сделать как надо и который можно вести, при необходимости.

И по 4-му пункту вариантов первого вопроса, вопрос второй:
В чем реальные преимущества (если они есть) использования стандартных временных признаков? Может стоит просто сделать свои нужного типа? А то вот я придерживаюсь правила, что надо стараться с использованием по максимуму стандартных объектов, но при этом кажется, что проще было бы использовать свои.

З.Ы. Задам еще и третий вопрос на всякий случай - правильно ли я понял, что если я в запросе (изменяемом) использую структуру с набранными и ограниченными вручную признаками, то я уже не смогу добавить новую строку в отчете? Вот я пробую сейчас - ставлю еще один признак, в нем - "только проведенные значения". И вот, если второй признак также просто помещен в запрос, то показывается строка для новых значений. А если второй признак представлен структурой, то все - новой строки нет уже. Это так и должно быть? А как поступить в этом случае? Вот мне надо, чтобы в столбцах были все кварталы выбранного года, безотносительно того, есть или нет они в проведенных значениях или мастерданных признака... или в этом случае надо просто вести в системе мастерданные признаков? А тогда возвращаемся к первому вопросу - как это делать для стандартных календарных признаков?

З.З.Ы. Правильно ли я понимаю, что один из плюсов стандартных признаков в том, что если у меня в кубе 0calyear, 0calquarter и 0calquart1 (который без года), то я смогу на уровень агрегации вытащить только 0calyear и 0calquart1 и запонять их, а 0calquarter система заполнит сама при записи в куб?

Возможно, Вам надо расширить временной интервал.
Транзакция spro.
Sap NetWeaver\Sap Business Information Warehouse\Релевантные для отчетов параметры\Общие параметры для отчетов в Business Explorer\Справка F4 и иерархии для настройки временных признаков/параметров OLAP

Огромное Вам спасибо!
Я сначала порыл в СПРо, но она как-то не нарылось, поиском, видимо, просто не попал в ключевое слово. А так и правда - время у меня там до 01.07.2012.
Правда путь немного другой, но без Вашего бы совета наверно я бы не нашел его:
SAP NetWeaver/Business Intelligence/Параметры настройки для системы отчетов и анализа/"Справка F4 и иерархии для настройки временных признаков / параметров OLAP"

В 3.5

Это в смысле указания, что не получится использовать свои? Так никто и не создавал бы, я думаю, "настоящие" временные признаки. Создали бы year char(4), month char(2), quart char(1) и т.д.
Конечно - их бы не получилось засунуть в настоящее временное измерение куба - туда бы лег какой-нибудь 0calday = # и все. Но чем это чревато?

Первая морока, которую удалось представить, - это стыковка в отчетах "псевдовременного" плана с традиционным фактом.

Вот еще - поменял куб (добавил в измерение времени 0calmonth2 и 0calquart1). Активировал его, система его проактивировала без ошибок, но предупредила, что уровни агрегации теперь не активны. Зашел в rsplan, поменял уровни (убрал оттуда 0calquarter и 0calmonth, а вставил 0calquart1 и 0calmonth2), проактивировал (без ошибок). Поменял и пересохранил запрос. Так теперь на запросах, где используются новые признаки оно сначала показывает запрос (причем можно увидеть, что вроде бы как и правильно даже, ячейки для ввода подсвечены синим), после чего появляется окно, где написано, что произошла ошибка чтения данных из провайдера такого-то и что навигация возможна, после чего (после нажатия на "ок") закрывает всю книгу.

Так у всех? Как с этим бороться? Неужели для IP любое изменение куба влечет за собой необходимость пересоздания всех уровней?

З.Ы. У меня такое уже было, но я тогда не спросил, так как тогда я новое измерение даже добавил и подумал, что оно справедливо ругается. Но признаки-то порой приходится добавлять в существующие измерения.

Ну так в этом случае и факт загружается в кубы с такими же "псевдовременными" признаками, конечно же. Даже если использовать стандартные экстракторы, то преобразовывать можно в правилах обновления. Все равно ведь стандартные кубы довольно редко используются просто потому, что довольно часто не обеспечивают разрезов, нужных заказчикам нашим. Или я ошибаюсь?

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

Кроме настроенной деривации еще плюс, насколько я понял, в том, что можно использовать стандартные виртуальные иерархии. В общем, стало понятнее, спасибо. Да и проблема с ограничением года решилась. Единственное, что немного смущает - у меня признак 0calquart1 в списке значений (когда, например, разворачиваю пункт "Значения" в бексе) предлагает варианты #, 1, 2, 3, 4 и, почему-то, 6.