Как настроить отчет План-Заявки-Факт и почему не работает расшифровка по заявкам в бюджетировании 1С:ERP?

Бизнес-аналитик 1С v8.3 (Управляемые формы) 1С:ERP Управление предприятием Управленческий учет IT и автоматизация бизнеса
← На главную

При построении комплексной бюджетной отчетности в 1С:ERP часто возникает потребность сопоставить в едином отчете три ключевых показателя: утвержденный План, зарезервированные Заявки (на расходование денежных средств) и фактически совершенные платежи — Факт. На практике пользователи нередко сталкиваются с ситуацией, когда по статье настраивается несколько источников, но стандартная расшифровка до первичных документов по колонке заявок отказывается работать.

Разберем по шагам, можно ли использовать несколько правил получения факта для одной статьи, выясним архитектурные причины сбоя расшифровки по сценарию «Исполнение бюджета» и рассмотрим корректные варианты решения этой задачи.

Возможность использования нескольких правил для одной статьи бюджета

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

Рассмотрим особенности работы этого механизма:

  1. Автоматическое суммирование данных: если для статьи задано несколько активных правил, система вычисляет их значения независимо и затем складывает. Это удобно, когда факт собирается из разнородных хозяйственных операций или разных учетных регистров.
  2. Корректирующие коэффициенты: в правилах доступно указание коэффициента (например, -1), что позволяет автоматически вычитать определенные обороты, например, внутренние перемещения или внутригрупповые расчеты.
  3. Контроль количественного учета: важно помнить об ограничении — если статья предусматривает учет количества, все связанные с ней правила сбора факта обязаны транслировать значения в строго одинаковых единицах измерения, иначе агрегированные показатели окажутся некорректными.

Почему не работает расшифровка по заявкам и сценарию «Исполнение бюджета»

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

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

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

  1. В регистре Обороты бюджетов — если колонка построена по плановым сценариям;
  2. В регистре Фактические данные бюджетирования — если колонка отображает фактические данные.

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

Вариант 1. Использование штатных отчетов казначейства (рекомендуемый способ)

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

Рассмотрим, какие типовые отчеты решают эту задачу:

  1. Контроль лимитов расхода ДС: формирует полную картину по выбранной периодичности, показывая установленный лимит, сумму согласованных и находящихся на согласовании заявок, сумму фактической оплаты и доступный остаток.
  2. Лимиты расхода денежных средств: отображает аналитический срез расходования лимитов в разрезе подразделений, статей Движения денежных средств и аналитик.

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

Вариант 2. Настройка вида бюджета через «Сложную таблицу»

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

  1. Создадим новый вид бюджета и разместим элемент Таблица со сложной структурой.
  2. В колонке План укажем показатель статьи бюджета с отбором по вашему плановому сценарию.
  3. В колонке Факт укажем ту же статью с источником данных по сценарию фактических данных.
  4. Для колонки Заявки создадим отдельную ячейку, значение которой будет заполняться операндом по источнику Произвольные данные (запрос к регистру казначейства по заявкам).

При настройке схемы компоновки данных (СКД) для произвольного источника крайне важно соблюдать жесткие требования структуры выборки. В наборе данных обязательно должны присутствовать поля:

  1. Период;
  2. Регистратор (ссылка на документ-источник);
  3. Ресурсные поля валют: СуммаРегл, СуммаУпр или СуммаВВалюте;
  4. Для аналитик с составными типами данных (на базе планов видов характеристик) необходимо явно декларировать типы, иначе при попытке построения расшифровки связь с первичными объектами будет утеряна.

Вариант 3. Использование отдельного пользовательского сценария

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

  1. Создаем в справочнике Сценарии бюджетирования отдельный пользовательский сценарий, например, Резервы по заявкам.
  2. Настраиваем трансляцию данных из заявок в этот сценарий с помощью документа Экземпляр бюджета, формируемого автоматически по правилам на основании оперативных документов казначейства.
  3. Поскольку документ Экземпляр бюджета делает полноценные записи в регистр Обороты бюджетов с фиксацией регистратора, в бюджетном отчете колонка с этим сценарием будет полностью функциональной: все цифры расшифруются стандартной оборотной ведомостью до исходных документов.
← На главную