Уже не первый раз сталкиваюсь с тем, что внедренцы реализуют бизнес-логику на уровне правил фактических данных. Что это значит, рассмотрим на примере схемы:
Из всех данных выбираются части данных с разными фильтрами. Например, для первой статьи бюджета выбираются все данные по одной статье ДДС, по второй статье бюджета выбираются данные с фильтром по статье и контрагенту, по третьей статье бюджета выбираются данные только по контрагенту. При большом количестве статьей бюджета очень сложно настроить так, чтобы сумма всех статей бюджета была равна сумме исходных данных.
Последствия
Такая модель приводит к следующим проблемам:
- Пользователю сложно определить, правильно ли настроены правила. Приходится сверяться путем вычислений. Хорошо, если при этом в системе есть подходящий отчет, в котором можно взять данные для таких вычислений
- При большом объеме таких правил сопоставление результатов работы правил с исходными данными становится практически невозможной из-за высокой трудоемкости
- Вследствие причин, указанных выше, управленцы теряют веру в данные бюджетирования, так как быстро и однозначно ответить, почему именно такое значение показывает система, сложно даже профессиональному автоматизатору. И расшифровка до регистратора, к сожалению, мало помогает
- Увеличивается время формирования бюджетных отчетов. Связано это с тем, что при сохранении бюджета определяются источники фактических данных для данного бюджета. Чем больше правил с уникальными отборами, тем больше запросов будет выполнено для получения фактических данных
Решение
В общем, модель трансформации данных при подготовке бюджетных отчетов может быть представлена следующим образом:
На уровне бюджетных отчетов данные могут быть проверены с помощью расшифровок бюджетных отчетов.
На уровне правил получения фактических данных есть отчеты, которые позволяют проанализировать результат работы правил, например: «Результат работы правил», «Оборотная ведомость по статьям бюджетов». Чтобы убедиться в корректности работы правил получения факта, нужно, чтобы данные были легко сопоставимы. Например, таким образом:
Правила получения фактических данных настраиваются так, чтобы транслировались все фактические данные в подсистему "Бюджетирование", распределение по статьям бюджетов в свою очередь выполняется по укрупненным критериям, например - по группам статей ДДС. Т.е фильтры выполняют роль разделителя фактических данных по статьям бюджетов.
В этой модели, относительно первоначальной настройки, не хватает фильтров по контрагенту, но их легко можно реализовать на уровне бюджетных отчетов.
Преимущества
Выгоды такой модели:
- Результаты правил фактических данных легко проверяемы.
- Исключается ситуация, когда одна и та же операция подпадет под фильтры разных правил.
- Бюджетные отчеты работают быстрее, так как меньше правил получения фактических данных.
- Всегда можно понять, откуда появилась та или иная цифра в бюджетном отчете.
