В предыдущей статье мы рассмотрели проблемы, связанные с колонками отчета, в данной статье мы рассмотрим особенности архитектуры решения, которые связанны со строками.
В нашем примере в качестве входных данных мы получаем Список статей в Экселе, и наша задача заключается в том, чтобы из данной таблицы сформировать связку «Вид Отчета+ Бланк отчета», которая бы удовлетворяла определенным требованиям.
Данные требования могут включать в себя
· Требования к вводу информации (например, форма должна позволять ввод и корректировку данных),
· Ограничения на доступ к справочникам в зависимости от организационного и другого контекста пользователя,
· Требования к формату отчета (например, корпоративный формат и цветовая гамма),
· Требования к выводу информации (например, вывести за прошлые периоды, сценарии, вывести показатели из других отчетов),
· Требования к расчету и анализу информации (структура данных должна быть удобной в качестве источника информации для других форм и отчетов),
· Структура данных должна быть нормализована (например, исключен двойной ввод или расчет одних и тех же данных),
· Скорость обработки (расчета и сохранения) информации (могут быть очень большие расчетные формы, которые долго сохраняются),
· Общее удобство работы пользователя с формой (например, вводить данные вручную в форму, в которой более 100 строк, неудобно),
Мы рассмотрим три основных подхода к решению данной задачи:
Первое решение
1. Сформировать Вид отчета на основании файла Эксель. Строки вида отчета будут совпадать со строками файла Эксель. Вид отчета выглядит следующим образом.
Бланк можно выбрать стандартный и раскрасить под требования Пользователя.
В данном случае мы используем Вид отчета (или базу данных для хранения показателей) "как Эксель", соответственно данное решение включает в себя плюсы и минусы использования электронных таблиц.
Плюсами этого подхода является простота реализации и интуитивное соответствие Вида отчета экселевской форме, что упрощает восприятие архитектуры Пользователем. Мы не зависим от наполнения справочника БДДС, а фактически создаем «свои» статьи БДДС в блоке Бюджетирование для данной формы. Справочник БДДС обычно широко используется в других системах, например Казначействе и БУ, и если вы не хотите с ними согласовывать «свои» статьи, то можно использовать данный подход.
Но мы знаем, что у Экселя есть недостатки по сравнению с реляционной базой данных, соответственно эти недостатки будут являться недостатками данного подхода.
Например
· добавление нового вида оплат, приводит к изменению Вида отчета, а это означает переработку бюджетной модели
· для суммирования (агрегирования) могут потребоваться громоздкие формулы, в которых должны быть прямые обращения к строкам формы
· при ссылке на данные строки как на источник данных из других форм, также могут потребоваться громоздкие формулы с перебором строк.
Данные проблемы решаются с помощью добавления аналитик к строкам отчета, что будет продемонстрировано в следующих примерах решений.
Работа аналитика с исходным списком строк также должна включать в себя классификацию строк (или разбиение на группы) в соответствии с определенными принципами. В нашем примере мы говорим про строки, связанные с БДДС, поэтому рекомендуется взять за основу классификацию статей БДДС из какого-нибудь авторитетного источника (например, ПБУ) и применить ее к текущей бизнес ситуации.
Применим данный список к нашей ситуации и мы получим следующую группировку
Тогда архитектура решения может выглядеть следующим образом
Второе решение
Кардинальное решение с использованием аналитик представляет из себя следующий вид отчета с одной строкой.
Преимуществом данного подхода является формирование «единого куба данных», к которому можно обратиться стандартными запросам (СКД, сводными таблицами). При этом различные срезы данных можно получить в пользовательском режиме посредством отборов.
Бланк отчета при этом может иметь несколько реализаций
1. Обыкновенный бланк, в котором можно включать и выключать иерархию
Данный подход рекомендуется, если иерархия справочника соответствует целям бюджетирования. Например она имеет такой вид.
2. Обыкновенные бланк с фиксированной иерархией. Аналитики справочника подвязываются к строкам Бланка через отборы.
Такой подход можно использовать, если иерархия справочника не соответствует иерархии статей бюджетирования. В этом случае Пользователь будет находится в своей среде, в своем контексте названий строк, но использовать аналитики из справочника ДДС.
Третье решение
Вид отчет имеет строки на уровне иерархии с аналитикой БДДС в строке. Т.е. мы прорабатываем форму Эксель, выделяем основные неизменяемые строки, а остальные строки переводим в аналитику (в данном случае БДДС). Это рекомендуемое решение.
Бланк отчета не имеет дополнительных особенностей. При необходимости его можно отформатировать по требованиям Пользователя, используя вышеописанные возможности.
Плюсами данного подхода являются
· Мы фиксируем основные строки в структуре вида отчета. Далее на эти строки можно ссылаться из других форм.
· Агрегирование данных производится автоматически на уровне синтетического значения. Дополнительных формул не требуется
· Сохраняются необходимые расшифровки до уровня аналитики.
Обычно на практике используется этот смешанный вариант. Он требует методической проработки взаимосвязей между формами, разделения аналитик и строк бюджета, надлежащую классификацию строк. Соответственно от качества решения зависит эффективность бюджетной модели, ее гибкость и масштабируемость.
