Блеск и нищета сводных таблиц. Часть 10

Павел Сухарев

Описание бюджетной модели

Немного финансовой терминологии

Составляем единый план счетов

Настройка финансовых счетов в MS Analysis

Подготовка аналитического куба к использованию измерения Account

Создание измерения типа Account

Создание правил пересчета

Определение правил форматирования ячеек

Последние штрихи

Заключение

В предыдущих статьях цикла мы довольно подробно рассмотрели основные операторы семейства КУБ(), посредством которых можно управлять выводом данных из многомерного хранилища в клиентское приложение.

В этой статье нам хотелось бы сделать небольшое отступление от основной темы повествования и обсудить вопрос разработки приложений, использующих измерения со встроенной бизнес-логикой. Как показывает практика, большинство OLAP-приложений базируются на применении обычных Regular-измерений и аддитивных мер. Подобные решения обладают рядом безусловных преимуществ. В частности, с их помощью можно оперативно создавать модели для всестороннего анализа многомерных данных. Более того, как мы теперь знаем, в распоряжении бизнес-пользователей есть целый набор инструментов, позволяющих настраивать представления этих данных в среде Microsoft Excel.

Теперь давайте посмотрим на аналитические приложения с позиции пользователя-практика. Без преувеличения можно утверждать, что одно из главных направлений их использования — различные задачи финансового планирования и анализа. Эта сфера деятельности отличается дуализмом. С одной стороны, в OLAP-кубах можно определить предметную область произвольной структуры. Для этого пользователю предоставлена возможность создавать собственные измерения, ориентируясь исключительно на свои потребности. Можно даже составить целый куб, содержащий одни пользовательские измерения, причем подобное встречается повсеместно. С другой стороны, конечная цель любого планирования состоит в формировании нескольких отчетных форм, называемых бюджетами. Структура бюджетов жестко регламентирована нормативными документами. Понятно, что сама по себе задача разработки отчетов с определенной структурой не является проблемой. Действительно, в качестве источника данных для измерения можно взять любую таблицу, в том числе составленную и заполненную по заранее оговоренным правилам. Трудность заключается совсем в другом. Типовой бюджет компании — это совокупность трех бюджетов: «Прибыли и убытки», «Движение денежных средств» (БДДС) и «Баланс». Каждый из них имеет самостоятельную ценность и заполняется по определенным правилам. Если не вдаваться в методические тонкости и технические подробности, то можно считать, что каждый последующий бюджет формируется на базе предыдущих: статьи «Бюджета денежных средств» рассчитываются на основании значений определенных статей из бюджета «Прибыли и убытки», а статьи «Баланса» — на основании статей бюджетов «Прибыли и убытки» и БДДС.

К примеру, значение статьи «Прибыль» бюджета «Баланс» определяется на основании статьи «Чистая прибыль» бюджета «Прибыли и убытки». Но сам бюджет «Баланс», в свою очередь, состоит из двух основных разделов — активов Asset и пассивов Liability & Equity, которые в любой момент должны быть равны друг другу. Поэтому увеличение одной из статей пассивов для сохранения нулевого сальдо должно сопровождаться либо уменьшением другой статьи пассива, либо увеличением какой­либо из статей активов.

Иными словами, статьи различных бюджетов связаны между собой правилами пересчета, которые довольно сложны. Одна базовая статья может влиять на несколько итоговых, и наоборот — значение итоговой статьи может зависеть от нескольких исходных.

В принципе, для организации автоматического пересчета значений статей из различных бюджетов достаточно объединить их в одно большое измерение, а затем преобразовать в измерение типа Parent-Child. Для элементов такого измерения возможно задание произвольных MDX-выражений для агрегирования значений ячеек — дополнительных формул пересчета (Customer member formulas).

Однако при попытке объединения статей из разных бюджетов в единый план счетов мы столкнемся с новой проблемой. Дело в том, что данные бюджеты имеют разную природу. В бюджете «Прибыли и убытки» учитываются обороты по статьям, а в «Балансе» — сальдо (итоговые значения за период).

Набор статей из бюджета «Прибыли и убытки» является обычным Regular-измерением. Смотреть балансовые статьи в отдельности от других бюджетов тоже не составляет труда, достаточно изменить правила агрегации для меры — назначить в качестве функции агрегирования вместо SUM() оператор LastChild. При такой настройке мера станет полуаддитивной — для всех измерений, кроме измерения Time, будет и дальше использоваться функция SUM(), а для измерения Time агрегированным значением станет последний потомок текущего элемента на атрибуте гранулярности.

Но единый план счетов, содержащий элементы как из бюджета «Прибыли и убытки», так и из бюджета «Баланс», приводит на первый взгляд к тупиковой ситуации. В кубе должно присутствовать измерение, у которого для одной части элементов используется стандартная функция агрегации, а для оставшейся части — функция LastChild.

Понятно, что стандартными средствами MS Analysis такую функциональность реализовать не получится. И здесь на помощь приходят измерения со встроенной бизнес-логикой, которые часто называют предопределенными измерениями (Predefined dimensions). В арсенале MS Analysis есть специальный тип измерения — Account. Это измерение предназначено для хранения плана счетов компании, и в нем изначально настроены все операции, которые были описаны выше.

Создатели аналитического сервера прекрасно понимают значение и большую прикладную ценность измерения с типом Account. Достаточно отметить, что это единственный тип измерения, конфигурирование которого осуществляется в специальном меню на уровне аналитической базы данных. К сожалению, на практике измерение данного типа несправедливо обойдено вниманием как разработчиков, так и пользователей. Возможно, это объясняется его двойственной природой. По идее измерение типа Account является инструментом экономистов, но они, как правило, принимают весьма опосредованное участие в проектировании аналитических кубов и часто не располагают полной информацией о возможностях, заложенных в систему. А для ИТ-специалистов, мало знакомых с финансовой спецификой, также неочевидны выгоды от использования этого измерения, которое к тому же требует весьма кропотливой настройки.

В реальности измерение типа Account является той опорой, если угодно — «скелетом», на котором держится всё серьезное финансовое планирование. Практика показывает, что техническим специалистам проще понять базовые постулаты финансового учета, чем работникам экономических специальностей всю совокупность технологий, на которых построен современный OLAP. Поэтому описание работы измерения Account видится уместным именно на страницах журнала компьютерной тематики, хотя и требует начальной экономической подготовки. Если читатели не сочли предыдущие абзацы скучными, то и последующий рассказ будет для них интересным и полезным.

Поиск по сайту: