Архитектурно-управленческая задача. К 8 марта

Немного вводных данных. Заказчик - проектная организация. Т.е. весь учет ведет в разрезе проектов, у каждого проекта от нескольких до сотен этапов. По каждому этапу планируется и анализируется финансовый результат. К анализируемым показателям относятся: производственная себестоимость (с детализацией до десятка статей), полная себестоимость, накладные расходы, выручка и взаиморасчеты. Весь анализ, по-сути, сведен  к безумному количеству отчетных форм, которые в тех или иных комбинациях показателей отображают информацию о план-фактном состоянии выполнения этапов проектов.

А теперь представьте себе задачу: собрать все эти показатели в одном запросе и масштабировать этот запрос на десятки форм.

Во-первых, давайте будем честны, аналитиков, способных такую постановку написать, "днем с огнем не сыщешь".

Во-вторых, трудозатраты на разработку и сопровождение такой формы "зашкалят".

Ну и, в-третьих, у нас в ERP на все контуры учета (если исключить организацию) одна единственная сквозная аналитика - это направление деятельности (ее, кстати, и задействуем под этап проекта). В каких-то регистрах быстрая выборка данных по направлению деятельности поддержана за счет индексов, но в части регистров этой возможности нет.  А нам все показатели нужно собрать в 4-5 аналитических разрезах.

Дополнительно ко всем вводным у нас, естественно, дефицит разработчиков и большая часть из них недавние стажеры.

Безвыходных ситуаций нет - давайте выкручиваться. Поможет нам в этом подсистема бюджетирования. Честно признаюсь, блок бюджетирования в ERP мне не нравится.

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

Покритиковать - покритиковали (нужно же интригу создать?). А теперь похвалим и рассмотрим то, что в подсистеме бюджетирования реализовано реально удобно - это сбор факта.

Во-первых, правила получения фактических данных позволяют собрать показатели практически по всем контурам учета с гибкими настройками в разрезе 6 аналитик в суммовом и количественном эквиваленте. Причем, по-умолчанию, доступно большое количество предопределенных настроек-схем, для сбора этих показателей.

Во-вторых - возможность хранения просчитанных фактических показателей с детализацией до регистратора.

В-третьих - механизм заданий на переотражение факта в бюджетировании, автоматически вызываемый при изменении данных в учетном документе или при изменении правил получения факта.

Зафиксируем мысль:

Каждый типовой документ (существенный для решения нашей задачи) может вписать информацию о себе в разрезе 6 аналитических измерений в оборотный регистр накопления. При изменении данных в документе выполняется автоматический пересчет данных в этом регистре.

Идем дальше. С помощью правил получения фактических данных мы можем сделать настройки для получения требуемых показателей. Можем организовать хранение просчитанной информации в регистре с фактическими данными.

Можем ли мы реализовать выборку данных для отчетов из этого регистра?

Конечно же, нет! Во-первых, предсказать, что еще будет храниться в данной таблице (и объем этого самого чего-то), со 100% гарантией мы не можем. Блок бюджетирования может использоваться не только для решения нашей задачи. Ну, например, как ни парадоксально, для реального бюджетирования. Хотя, конечно, использовать подсистему бюджетирования для бюджетирования  - это совсем не дело, это тренд прошлого сезона. А в этом сезоне в моде искусственный интеллект! Программировать за программистов уже научили. Пора бы уже и бюджетировать за пользователей обучить.

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

Плюс, к тому же, нужно разбираться с разграничением прав на доступ к этой таблице.

Вывод? - этот регистр не подходит для наших нужд. Что будем делать? Ну, конечно же, создадим свой! Ведь если в БД в таблицу пишется порция данных, привязанная к конкретному учетному документу, что мешает вписать сразу эту порцию данных в другую таблицу? А в первую вообще не писать - зачем нам там эти данные?

Что нам для этого потребуется? Для начала, вероятно, новый регистр. Накопления и оборотный, естественно. С измерениями, соответствующими 1-6 аналитикам. Назовем его "Фактические показатели исполнения проектов".

Что еще полезного у нас есть в исходном регистре? - статья бюджетов.  Что такое "статья бюджетов"? Это оборотный суммовой (и, опционально, количественный) показатель с 6 аналитическими разрезами. Где мы храним "суммовые оборотные" показатели? Конечно же, в ресурсах оборотного регистра накопления. Как "круто загнула" - аж самой понравилось! Мысль уловили?

Заведем на каждый требуемый показатель ресурс в нашем новом регистре и статью бюджета, в которой сделаем настройки правил получения фактических данных. Осталось только инструкцию оставить, данные какой статьи в какой ресурс писать. Ну как-нибудь так:

Что-то забыли? Точно  - у каждого регистра накопления должен быть регистратор. У исходного, "Фактические данные бюджетирования", документов-регистраторов несколько десятков. Связь между регистратором и регистром, напомню, устанавливается в свойствах самого документа. Нам не подходит - не будем же мы такое количество типовых документов "портить"? Да и лениво, честно признаюсь.

Что будем делать? Регистратор для нашего нового регистра все-таки нужен. Ну так давайте его и заведем. Поименуем гордо - Регистратор фактических показателей бюджетирования! А связку с первоначальным документом организуем с помощью реквизита "Документ-основание". Главное не забыть проиндексировать.

Кстати, и индекс отличный получится, содержать будет ссылку на исходный документ и на наш документ-"пустышку". Тот редкий случай, когда вся информация есть в дополнительном индексе и "подчитка" из кластерного не потребуется.

Ой! Ну до чего же хорошенький, славненький регистр получился!

• И данные в нем все необходимые есть.
• Даже стажер эти данные в запросе собрать сможет.
• И индекс у таблицы оборотов подходящий.
• Мы еще первые два измерения проиндексируем - совсем красивый станет!
• Еще и на расшифровку до регистратора в запросах по таблице движений выйти можно.
• В него и накопленные показатели при переходе с УПП по незакрытым проектам перенесем, чтобы отчеты корректно формировались.
• А правила получения факта у нас что? - Настройка системы. А за настройки кто в системе отвечает? Конечно, аналитики. Вот, пусть, сидят и настраивают! Как же мне эта мысль нравится!

Ну не прелесть ли? Красивый, удобный, практичный! Еще и дешево стоит! Берем! Однозначно, берем этот шедевр архитектурной мысли!

Осталось только данными нашего красавца наполнить. Ну, это совсем просто! Что нам стоит найти, где в коде осуществляется запись в регистр "Фактические данные бюджетирования"?

Задача вроде решена. Теперь, как учили в школе, нужно сделать проверку:

• Решение позволяет собрать отчеты с минимальными трудозатратами на разработку. Скорость выборки данных ожидается хорошая.
• Из типового функционала затронут только один метод в общем модуле. И может быть форма справочника "Статьи бюджетов". Все остальное "прикручено" сбоку. Сопровождение не должно вызвать проблемы.
• Расчет данных будет выполняться регламентным заданием в ночное время, когда пользователи не работают, после выполнения операций по закрытию месяца. Все равно без закрытия месяца никаких сумм в ERP нет. То, что сбор данных и запись в БД по сути "запросы в цикле", - ну так "несложными" запросами мы, при отсутствии пользователей в базе, критичную нагрузку не создадим. Тем более, что это типовое архитектурное решение (мы только таблицы, куда данные пишутся подменили), прошедшее тестирование Фирмой 1С. Отец наш, кормилец, плохому же нас не научит?

Теперь точно решили. )))

Резюмируем (обещала же техническое решение в конце статьи):

1. Создаем новый регистр накопления. В измерениях будут ключевые аналитики, по которым пользователи анализируют данные. Не более шести. В ресурсах будут анализируемые показатели: выручка, с/с и т.д.

2. Регистратором у нового регистра будет документ-"пустышка" с единственным реквизитом "Документ-основание" (тип - ссылка на любой документ, проиндексировать).

3. Настраиваем статьи бюджетов на каждый требуемый показатель. Т.е. каждому ресурсу нового регистра будет соответствовать элемент справочника. Аналитики в статьях строго должны соответствовать измерениям нового регистра.

4. Создаем настройку, позволяющую определить, данные какой статьи в какой ресурс нового регистра нужно вписать.

5. Реализуем запись в новый регистр. В типовой конфигурации реализована запись движений по исходному учетному-документу регистратору в оборотный регистр "Фактические данные бюджетирования". Набор движений просчитывается штатными средствами при выполнении регламентного задания "Отражение документов в бюджетировании". Нам достаточно забрать данные этого набора, обработать и вписать в наш новый регистр. Для каждого исходного регистратора создаем документ-"пустышку", который будет вписывать эти данные в новый регистр. Связь  между документами - один к одному.

6. Сажаем аналитика настраивать правила получения фактических данных в статьях бюджета.

7. Живем и радуемся)))

Отдаю идею "абсолютно безвозмездно, т.е. даром". Пользуйтесь.

P.S. Девчонки-коллеги, с праздником! Мы с Вами - самое прекрасное, что есть в разработке на 1С!