Hyperion Planning : calculated column on data form

В Hyperion Planning версии 11.1.2.х появилась очень интересная функциональность – возможность создавать в формах данных рассчитываемые объекты, как в строчках так и в столбцах.

Какие задачи данный функционал позволяет решить

  1. Расчет вспомогательных показателей
  2. Переименование показателя в соответствии с особыми требованиями текущего владельца бюджета
  3. Уменьшение размера модели, за счет удаление «справочных» показателей.

Пример формулы

 

Дополнительная информация в Oracle Hyperion Documentation

 

 

Planning: Calculate Data Form

Данный функционал призван для расчета формы данных.Поговорим о том как это работает в деталях.

Автоматически создается бизнес правило, которое имеет вид : в FIX отправляются все что в форме определено как PoV ( срез данных), в тело вставляется значение аналитик , которые определены в строках. Измерения , определенные в столбцах остаются за скобками.

Например

FIX (“BUD”,”VR_Work”,”ICFO_NA”,”FY13,iLE_NA,”CFO_0AAA”,”LE_10AA”)
“Account_FRG_15”;
“Account _FRG_13”;
“Sparce_Total”;
ENDFIX

Соответственно данные элементы рассчитываются либо согласно иерархии, либо от наличия на нем формулы.
Для лучшего контроля над данными лучше данный функционал отключать из всех форм.

CalcScript : казнить нельзя помиловать (,)

“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп

Несколько слов в эпистолярном жанре о судьбе программирования для Essbase на CalcScipt. По мотивам статьи «Десять вещей, которые я терпеть не могу в ООП».

 
 

CalcScript, как следует из его названия, это язык расчетов данных в многомерной модели, которому чужды такие парадигмы программирования как «процедурность»( данные + алгоритмы, ), «объектность»( объекты + сообщения. ) и «функциональность» (функции + функции). Итого: CalcScript – это работа с данными, которые функционально разложены в многомерной модели или «CalcScript – это расчет данных»

Что данное определение означает с точки зрения прикладного использования: программа расчетов функциональных показателей опирается на значения справочников (метаданных) модели и жестко с ней связана. К чему это приводит , если следовать данному определению буквально : первые реализации программы на CalcScript адекватны только текущему состоянию восприятия задачи программистом, т.е. реализованный расчет находится в состоянии «мертворожденного дитя», так как не может в полной мере адаптироваться к изменению бизнес – требований (из-за умышленного ограничения требуемой «картины мира» ).

К счастью, такая ситуация не является новостью, и эти все проблемы выявляются на этапе «опытно-промышленной» эксплуатации. И при выполнении нескольких условий, есть возможность вдохнуть жизнь в этот «трупик сознания»: в последующих реализациях модели расчетов все больше опираться на признаки метаданных (атрибуты, место в иерархии, составное имя элемента) . Т.е. уйти от модели разработки «CalcScript – это расчет данных» в сторону «процедурности»( данные + алгоритмы) или «CalcScript – это получение данных и расчет ». Т.е. предлагается в существующую алгоритмическую область расчетов искусственно внести сущность управления данными.

Как подход к разработке «CalcScript – получение данных и расчет » выглядит в реальной жизни:

  • На уровне описания функциональных требований и документации: Для каждого алгоритма описывается часть «Источник данных(получение данных)» и «Часть расчет» . Например
    • Шаг 1. Получить данные по оборотам (Форма 0101 Движение расходных материалов.))
    • …..
    • Шаг N. Рассчитать Остаток на конец = Остаток на начало + Движение материалов
    • ….
  • На уровне модели отдельно выделяется срез исходных данных и срез расчетов и корректировок. Для этого выделяется аналитика с соответствующими элементами (ближайший аналог направление «Value» в Hyperion Financial Management).
  • Для каждого алгоритма выделяют отдельное графическое правило (которое состоит из множества скриптов) , в котором часть «источник данных» описана как получение среза данных через функции отношения элементов в иерархии с определенным набором признаков
    • Т.е. для выборки определенного элемента в справочнике используется не его семантическое значение («А1», «A2» .. ), а его функциональная часть (все элементы, помеченные как центр расходов и относящиеся к региону «Восток»)
    • Часть «расчет» представляет собой отдельный скрипт, который инкапсулируется в нужных местах общего правила. Его реализация должна описывать алгоритм расчета, а не расположение элементов в модели.

 
 

Описанный подход требует особой дисциплины разработки, так как ничто не мешает программисту «упасть» в хардкод.

З.Ы. Перенос расчета из Essbase в PL-SQL физически разделяет слои «Получение данных» и «Расчет»

 
 

 
 

  

Вы все еще используете XREF ? – Тогда мы идем к Вам !

К несчастью я обнаружил, что даже в проектах прошлого года, некоторые интеграторы использовали XREF как основной транспорт обмена данными. 2 года назад, Михаил Легкий описал способы отказа от такого простого , но ресурса емкого XREF.

Если Вы далеки от выгрузок, партиций и XMLA – то лучшей альтернативой на данный момент является – XWRITE.

Так как

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

 

Удачи, и да, я очень сильно надеюсь, что больше не услышу вопросов о том, чем заменить XREF.

ER