Ошибка №1 внедрения "Бюджетирования" в 1С:ERP2 и 1С:КА2: настройка статей бюджетов и статей ДДС 1-в-1

Управление - Пользователю системы

30
В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2. Сегодня поговорим и о самой распространенной ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС».

Коллеги, я являюсь счастливым автоматизатором: сначала я разрабатывал бюджетирование в 1С:ERP2 и 1С:КА2, а теперь его внедряю. В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2.

Сегодня поговорим и о самой распространенной на мой взгляд ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС». В базе это выглядит так:

 

 

 

Т.е каждому элементу справочника «статьи ДДС» мы прямо сопоставляем статью бюджета движения денежных средств:

 

 

 

 

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

 

 

 

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

В данной модели при добавлении статьи ДДС нужно вводить новую статью бюджетов, настраивать отбор и модифицировать виды бюджетов. Т.е невозможно добавить статью ДДС в бюджеты без специалиста по автоматизации.

Теперь немного технических подробностей: разберем как получаются фактические данные в подсистеме «Бюджетирование».  В зависимости от версии конфигурации и применяемого решения (КА или ERP) могут сработать следующие схемы:

1. Получение факта для каждой статьи отдельной компоновкой и выгрузка в сводную таблицу значений. Тут всем очевидно, что выполнение СКД в цикле – ничего хорошего не сулит. Особенно с ростом базы данных и количества статей бюджетов

2. Компоновка всех необходимы правил в одну СКД. При этом на основании уникальных отборов будут сформированы однотипные запросы, но с разными параметрами отборов, и объединены в рамках набор с типом «Объединение» одной СКД. Получится большая компоновка с кучей наборов в «Объединении». На практике так же выполняться будет неприятно.

Если вы указываете отбор для статьи бюджетов – то такая статья создаст новый источник, т.е новый набор в рамках набора «объединения», либо выполнится отдельной компоновки в зависимости от версии применяемого решения. При этом, если несколько статей бюджетов имеют одинаковый отбор в правилах фактических данных – то запрос скорее всего будет объединен. Для оптимального получения фактических данных лучше делать статьи бюджетов максимально укрупненными. Для приведенного выше примера оптимальная настройка выглядит так:

 

 

 

Таким образом, для этого примера, мы более чем в 2 раза сократили количество запросов для получения фактических данных, а соответственно более чем в 2 раза оптимизировали формирование бюджетных отчетов.

В такой модели, при правильной настройке фактических данных, мы получим систему бюджетирования, в которой пользователи самостоятельно могут добавлять «Статьи ДДС» в бюджетах. И в план-фактных отчетах такие добавленные статьи будут отображаться без изменения видов бюджетов, т.е автоматически. Как правильно настроить фактические данные для статей бюджетов мы рассмотрим в следующей статье.

Также пишите в комментариях, какие темы по подсистеме «Бюджетирование» ERP 2 интересны Вам, с какими непонятными ситуациями сталкивались – рассмотрим, а самые интересные проблемы разберем подробно в последующих статьях.

30

См. также

Комментарии
Сортировка: Древо
1. Nikola23 379 18.06.18 09:49 Сейчас в теме
ИМХО - главная сложность в перенавороченном механизме получения данных, строго последовательно.

Для этого механизма, где как ни старайся будут тяжелые запросы в цикле, приходится дорабатывать и оптимизировать код.
Не сложно же было написать параллельные вычисления! В моем примере один из отчетов собирал данные 8-12 часов, пока не провели оптимизацию кода. Ускорили до 10 минут.

Ну а добавить статью в бюджет можно и без автоматизаторов, не велика сложность. Наши пользователи освоили с первой попытки.

"Не знаешь как - спроси меня" (С)
2. SergeyN 111 18.06.18 13:22 Сейчас в теме
(1) можете пример такого бюджет привести? С замером производительности.
3. Nikola23 379 18.06.18 15:00 Сейчас в теме
(2)
) можете пример такого бюджет привести? С замером производительности.
1
В заголовке статьи указано, что Вы являлись разработчиком, а теперь внедряете. Я готов поработать совместно, если это окажет влияние на подсистему в будущих релизах и принесет бонусы заказчику.
Ради спортивного интереса - не готов.

Замеры могу предоставить только по ускоренной версии. Полагаю, что выгрузит в xml настройки тоже получится договориться.
4. SergeyN 111 18.06.18 19:57 Сейчас в теме
(3) я писал в статье, что могу разобрать интересные случаи в последующих статьях для сообщества. Учтет это вендор или нет я прогнозировать не берусь.

Что касается формирования 12 часов - то я полагаю что скорее дело в неверной настройке, а не в коде. Перенастроить виды бюджетов как правило быстрее чем переписывать код подсистемы. Если вид бюджета не переписывался - то могу посмотреть на типовой как его можно было бы ускорить.
5. Nikola23 379 18.06.18 20:39 Сейчас в теме
(4) Полагаю, не имеет смысла. Конкретная задача решена.

Расскажите, зачем там 2 алгоритма формирования "РассчитатьФактПоВидуБюджетаАльтернативный" и "РассчитатьФактПоВидуБюджета"? В моем случае результат в данных одинаковый, а у альтернативного варианта - производительность на порядок ниже. Да и в релизе только этот вариант используется.

Технические различия понятны по комментариям. На практике - зачем?
8. SergeyN 111 20.06.18 21:43 Сейчас в теме
(5) Альтернативный механизм разрабатывался после моего ухода в апреле 2016 из 1С. В официальных публикациях нововведений на partners я не нашел связанных материалов. Посмотрел код и мой вывод: в альтернативном механизме все запросы к факту объединены в 1 СКД, что теоретически должно дать выигрыш в производительности. Однако применяется механизм СхемаЗапроса - по моим замерам далеко не быстрый механизм. Что в свою очередь ставит под вопрос выигрыш в производительности.
11. Nikola23 379 20.06.18 21:56 Сейчас в теме
(8) Там с этим механизмом дополнительная куча колонок в результирующей таблице получается. Этот алгоритм в несколько раз увеличивает длительность выполнения запроса.
12. SergeyN 111 20.06.18 23:21 Сейчас в теме
(11) дополнительные колонки могут существенно увеличить время выполнения только в случае если эти колонки включены в индекс таблицы значений и исть массовое добавление/удаление строк, либо на старой платформе - изменение значений этих колонок. Индексации таблицы факта я не нашел. Поэтому склоняюсь к варианту что заседление дает СхемаЗапроса.
6. grabarenko 20.06.18 10:56 Сейчас в теме
9. SergeyN 111 20.06.18 21:44 Сейчас в теме
(6) Я с вами! :) Много работы по текущим проектам - поэтому отвечаю не оперативно. Но отвечу обязательно!
7. user711894_ninburg_v 20.06.18 11:47 Сейчас в теме
Добрый день.
Я в отличии от Вас являюсь не автоматизатором, а пользователем 1С:ERP2, в связи с этим вопрос.
Мне тоже показалось подход 1-в-1 используемый моим коллегой очень трудоемким, и я ввел другой вид бюджета
с укрупненными статьями, и подробной разбивкой по аналитике. Вопрос в том, влечет-ли это какие-нибудь ограничения
при использовании бюджета для лимитирования в казначействе? Контроль суммы возможен только по статье бюджета,
или по аналитике тоже?
10. SergeyN 111 20.06.18 21:54 Сейчас в теме
Контроль суммы возможен до аналитики. Уровень контроля настраивается в правилах лимита. Например, на статье бюджета 2 уровня аналитики: статья ДДС и доп.аналитика. Можно настроить что бы контроль был только до уровня статьи ДДС, а доп.аналитика использовалась только участниками процесса бюджетирования для план-факт анализа. Во вложении - пример настройки лимитов ДС, где выделено как установить нужный уровень аналитики. Лимиты ДС настраиваются в модели бюджетирования. Модели бюджетирования находятся в пункте меню "Бюджетирование и планирование" -> "Настройки и справочники" -> "Модели бюджетирования".
Прикрепленные файлы:
13. user711894_ninburg_v 21.06.18 10:29 Сейчас в теме
14. edeez 11.07.18 22:35 Сейчас в теме
+ Полезная статья. Уважаемые, не мог бы кто-нибудь скинуть рабочую СКД на получения факта из статьи бюджета, почему-то не взлетает никак, спасибо.
15. SergeyN 111 12.07.18 02:24 Сейчас в теме
(14) Уточните: правила факта или правила исполнения бюджета? Какая именно ошибка?
16. edeez 12.07.18 21:02 Сейчас в теме
(15) (15) Сценарий - Фактические данные, В СКД простейший запрос в собственный регистр сведений на получение данных:
СКД

В результате работы правил результат выдает:
Скрин

Но вот в самом отчете бюджета пустота...
17. edeez 12.07.18 21:06 Сейчас в теме
(15) Сценарий Фактические данные, запрос простейший:
СКД

В результатах работы правил результат есть, но в самом ничего не показывает
Прикрепленные файлы:
18. SergeyN 111 13.07.18 01:46 Сейчас в теме
На первый взгляд в СКД все верно. Единственное - проверьте, указаны ли типы для полей СКД для организации и подразделения.
Пришлите скрин настройки вида бюджета и настроек отчета при формировании. Может ошибка не в СКД.
19. edeez 13.07.18 11:48 Сейчас в теме
(18) Я так же пробовал схемы входящие в состав конфигурации, тоже не взлетело. Не могу понять этот феномен.
Прикрепленные файлы:
20. edeez 19.07.18 20:07 Сейчас в теме
В настройках бюджета "месяц" был лишним, завелось!
21. SergeyN 111 19.07.18 20:24 Сейчас в теме
(20) А если убрать флаг ограничения на условие "Период" - с периодом "месяц" заработает?
Оставьте свое сообщение