КА 2.6: не сохраняется факт бюджетирования при включённом хранении результата правила. Два варианта исправления

КА 2.6 не сохраняется факт бюджетирования при включённом хранении результата правила. Два варианта исправления

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

Стоит включить хранение, записать правило и выполнить отражение документов, как результат перестаёт попадать в регистр ФактическиеДанныеБюджетирования.

При этом исходные документы проведены, необходимые движения существуют, а без хранения правило продолжает возвращать правильные суммы.

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

Покажу диагностику и два варианта реализации расширением:

1. &Вместо с ПродолжитьВызов() и корректировкой готового запроса.

2. &ИзменениеИКонтроль с добавлением недостающего поля при формировании группировки СКД.

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

1. На каком релизе обнаружили проблему

Конфигурация: 1С:Комплексная автоматизация 2.6.2.59.

Подсистема: бюджетирование.

Объект метаданных:

Справочник.ПравилаПолученияФактаПоСтатьямБюджетов

Проблемная функция модуля менеджера:

ПолучитьЗапросПоНастройкамПравила()

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

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

Нужно было разобраться, почему типовой механизм работает в одном режиме и не работает в другом.

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

Наш конкретный пример:

• Статья бюджетов: Премия.

• Раздел источника: Произвольные данные.

• Источник: ОтражениеЗарплатыВФинУчете.

• Отбор: Статья Равно "Премия".

Эти наименования не являются обязательными для воспроизведения проблемы. Они относятся к настройкам конкретной информационной базы.

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

2. Как проявляется ошибка

Проверяем одно и то же правило в двух режимах.

Вариант 1. Хранение выключено.

Снимаем флажок «Хранить результат выполнения правила» и формируем отчёт «Результат работы правил по статье бюджетов».

Данные рассчитываются корректно.

В нашем случае за март 2026 года получено 2 000 000 руб.

Проверили исходные движения. Сумма соответствует данным источника.

Вариант 2. Хранение включено.

Устанавливаем флажок хранения, записываем правило и выполняем отражение документов.

Однако новых движений в регистре накопления:

РегистрНакопления.ФактическиеДанныеБюджетирования

не появляется.

На первый взгляд кажется, что неправильно настроено правило или отсутствуют исходные данные.

Но это не так: без хранения тот же источник и тот же отбор продолжают работать.

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

3. Почему два режима работают по-разному

При выключенном хранении система рассчитывает показатели на основании настроенного источника при формировании отчёта.

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

Он должен получить данные из источника и сформировать движения регистра ФактическиеДанныеБюджетирования.

Для этого система формирует отдельный запрос на основании настроек правила.

Одна из функций, участвующих в подготовке этого запроса:

ПолучитьЗапросПоНастройкамПравила()

Она находится в модуле менеджера справочника ПравилаПолученияФактаПоСтатьямБюджетов.

Внутри используются настройки СКД, перечни полей, группировки, отборы и вспомогательные запросы.

Поэтому успешно рассчитанный отчёт ещё не гарантирует, что запрос для хранения результата сформируется правильно.

Именно в этой части обнаружили проблему.

4. Как нашли причину

Начали с отладки формирования запроса.

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

Затем посмотрели сформированный текст запроса.

В нашем источнике исходное поле статьи называется:

КорСтатья

А в настройках СКД оно используется под именем:

Статья

При анализе запроса обнаружили, что в последующей части используется обращение:

ПсевдонимТаблицыИсточника.Статья

Но соответствующее поле отсутствовало в промежуточном наборе данных.

То есть запрос обращался к полю, которое не было выведено в нужную временную таблицу.

Это происходило при подготовке хранимого факта, тогда как непосредственный расчёт по источнику выполнялся корректно.

Далее посмотрели, откуда формируется список полей группировки.

В функции ПолучитьЗапросПоНастройкамПравила() обнаружили следующий участок:

Группировка = ФинансоваяОтчетностьСервер.НоваяГруппировка(
    НастройкиКД.Структура);

ИменаПолейГруппировки = СтрРазделить(
    "Организация,Подразделение,ПериодДень,Регистратор", ",");

В исходном списке отсутствует Статья.

Проверили гипотезу прямо в отладчике: добавили поле к списку группировки.

ИменаПолейГруппировки = СтрРазделить(
    "Организация,Подразделение,ПериодДень,Регистратор,Статья", ",");

После пересоздания запроса и отражения документов факт сформировался.

За март получили пять документов с общей суммой 2 000 000 руб.

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

Важное уточнение: это не универсальная ошибка каждого правила, у которого есть отбор по статье.

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

Поэтому нельзя просто добавить Статья во все правила без анализа их схем СКД.

5. Решение № 1. Расширение через &Вместо

Первым реализовали адресное исправление через &Вместо и ПродолжитьВызов().

Это позволяет сохранить выполнение типовой функции, получить её результат и скорректировать только сформированный текст запроса.

Не требуется переносить весь типовой алгоритм в расширение.

Объект расширения:

Справочник.ПравилаПолученияФактаПоСтатьямБюджетов.МодульМенеджера

Ниже код, использованный именно для нашего источника.

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

&Вместо("ПолучитьЗапросПоНастройкамПравила")
Функция БЮД_ПолучитьЗапросПоНастройкамПравила(Правило) Экспорт

    Результат = ПродолжитьВызов(Правило);

    Если ТипЗнч(Результат) <> Тип("Структура") Тогда
        Возврат Результат;
    КонецЕсли;

    // Источник из нашего конкретного примера.
    Если Правило.РазделИсточникаДанных <>
        Перечисления.РазделыИсточниковДанныхБюджетирования.ПроизвольныеДанные
        Или Правило.ИсточникДанных <> "ОтражениеЗарплатыВФинУчете" Тогда

        Возврат Результат;

    КонецЕсли;

    ТекстЗапроса = "";

    Если Не Результат.Свойство("ТекстЗапроса", ТекстЗапроса)
        Или ТипЗнч(ТекстЗапроса) <> Тип("Строка") Тогда

        Возврат Результат;

    КонецЕсли;

    Маркер = "ПОМЕСТИТЬ ФактическиеДанные";
    Позиция = СтрНайти(ТекстЗапроса, Маркер);

    Если Позиция = 0 Тогда
        Возврат Результат;
    КонецЕсли;

    ПерваяВыборка = Лев(ТекстЗапроса, Позиция - 1);
    ОстальнаяЧасть = Сред(ТекстЗапроса, Позиция);

    Если СтрНайти(
        ОстальнаяЧасть,
        "ПсевдонимТаблицыИсточника.Статья") = 0
        Или СтрНайти(ПерваяВыборка, " КАК Статья") > 0 Тогда

        Возврат Результат;

    КонецЕсли;

    // Фрагмент сформированного запроса нашего источника.
    ПолеДляВставки =
        "ТаблицаДанных.СуммаРеглОборот КАК СуммаВВалюте";

    Если СтрНайти(ПерваяВыборка, ПолеДляВставки) = 0
        Или СтрНайти(ПерваяВыборка, "СГРУППИРОВАТЬ ПО") > 0 Тогда

        Возврат Результат;

    КонецЕсли;

    ПерваяВыборка = СтрЗаменить(
        ПерваяВыборка,
        ПолеДляВставки,
        ПолеДляВставки + "," + Символы.ПС
        + "    ТаблицаДанных.КорСтатья КАК Статья");

    Результат.ТекстЗапроса =
        ПерваяВыборка + ОстальнаяЧасть;

    Возврат Результат;

КонецФункции

Почему здесь жёсткий отбор по источнику

Обрати внимание на условие:

Правило.ИсточникДанных <> "ОтражениеЗарплатыВФинУчете"

Оно сделано намеренно.

В нашей базе именно этот источник использовал проблемную структуру запроса.

Причём текст запроса содержал конкретное поле:

ТаблицаДанных.СуммаРеглОборот КАК СуммаВВалюте

Рядом с которым мы добавляли:

ТаблицаДанных.КорСтатья КАК Статья

Для другого источника такие поля могут отсутствовать.

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

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

Это адресное исправление одной подтверждённой проблемы.

Результаты проверки первого варианта

Расширение проверили на копии КА 2.6.2.68.

За март сформировались пять документов.

За апрель получили шесть документов, 89 строк фактических данных.

Суммы совпали с проверенными исходными данными.

Это подтвердило работоспособность исправления на двух периодах нашего источника.

Недостаток подхода

Мы изменяем готовый текст запроса, ориентируясь на конкретные строковые фрагменты.

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

Тогда исправление может просто перестать находить нужный участок.

Именно поэтому такой вариант требует проверки после обновлений.

6. Решение № 2. Расширение через &ИзменениеИКонтроль

Второй подход заключается в исправлении непосредственно списка группировки СКД.

Для этого можно использовать аннотацию:

&ИзменениеИКонтроль("ПолучитьЗапросПоНастройкамПравила")
Функция БЮД_ПолучитьЗапросПоНастройкамПравила(Правило) Экспорт

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

Наша задача не переписывать весь алгоритм, а изменить один участок.

После исходной строки:

ИменаПолейГруппировки = СтрРазделить(
    "Организация,Подразделение,ПериодДень,Регистратор", ",");

добавляем:

#Вставка

Если ОписаниеПравила.РазделИсточникаДанных =
    Перечисления.РазделыИсточниковДанныхБюджетирования.ПроизвольныеДанные
    И ОписаниеПравила.ИсточникДанных = "ОтражениеЗарплатыВФинУчете"
    И ПоляНабора.Найти("Статья") <> Неопределено Тогда

    ИменаПолейГруппировки.Добавить("Статья");

КонецЕсли;

#КонецВставки

И здесь названия относятся к нашему примеру.

ОтражениеЗарплатыВФинУчете является именем проверенного источника, а Статья представляет поле его СКД.

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

Нельзя определять нужное поле только по названию отбора, которое пользователь видит в форме правила.

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

Почему этот вариант интереснее

Мы не ищем строку SQL и не вставляем в неё дополнительное выражение.

Изменяется список полей группировки, который затем обрабатывается самой типовой функцией.

Преимущества такого подхода:

• Исправление находится ближе к причине обнаруженной ошибки.

• Не требуется искать конкретный фрагмент СуммаРеглОборот КАК СуммаВВалюте.

• Изменение типовой функции контролируется механизмом платформы.

• Основной алгоритм остаётся типовым, за исключением явно обозначенной вставки.

Но есть и особенности.

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

В нашем первом варианте такого расширения проверка возможности применения проходила, но при записи правила возникали ошибки компиляции.

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

Это отдельная проблема корректного переноса и компиляции метода в расширении, а не подтверждение ошибочности самой вставки ИменаПолейГруппировки.Добавить("Статья").

Поэтому второй вариант приведён как альтернативный способ реализации.

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

7. Почему не нужно добавлять поле всем правилам

Самый очевидный вариант после обнаружения проблемы:

ИменаПолейГруппировки.Добавить("Статья");

без каких-либо условий.

Но применять его сразу ко всем правилам не стоит.

Разные правила могут использовать:

• Различные разделы источников данных.

• Разные схемы компоновки данных.

• Другие наименования полей.

• Разные аналитики и уровни детализации.

• Поля, которые вообще отсутствуют в конкретном источнике.

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

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

Это не обязательно ошибка, но влияние такой детализации на результат необходимо проверить.

В нашем случае отдельно тестировался другой произвольный источник:

ДанныеПоПрочимРасходам

При включённом хранении он сформировал факт без нашего исправления.

Следовательно, проблема не сводится к наличию условия Статья Равно ....

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

8. Как диагностировать аналогичную проблему в другой базе

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

Сначала нужно установить, что именно перестало работать.

Рекомендую следующий порядок:

1. Найти правило, для которого расчёт без хранения возвращает данные, а отражение с хранением не создаёт ожидаемые движения.

2. Зафиксировать его раздел источника, наименование источника и настройки отбора.

3. Убедиться, что за проверяемый период имеются подходящие исходные документы.

4. В отладчике проверить результат функции ПолучитьЗапросПоНастройкамПравила().

5. Посмотреть сформированный ТекстЗапроса и состав промежуточных таблиц.

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

7. Найти, на каком этапе формирования СКД теряется нужное поле.

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

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

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

9. Запрос для проверки результата

Для контроля фактических движений можно использовать консоль запросов.

В отличие от нашего первоначального тестового запроса, здесь не зашито название конкретной статьи.

Параметры СтатьяБюджетов и Правило нужно заполнить ссылками из своей базы.

ВЫБРАТЬ
    Факт.Правило КАК Правило,
    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Факт.Регистратор)
        КАК Документов,
    КОЛИЧЕСТВО(*) КАК СтрокФакта,
    СУММА(Факт.СуммаУпр) КАК СуммаУпр,
    СУММА(Факт.СуммаРегл) КАК СуммаРегл
ИЗ
    РегистрНакопления.ФактическиеДанныеБюджетирования
        КАК Факт
ГДЕ
    Факт.Период МЕЖДУ &НачалоПериода И &КонецПериода
    И Факт.СтатьяБюджетов = &СтатьяБюджетов
    И Факт.Правило = &Правило

СГРУППИРОВАТЬ ПО
    Факт.Правило

Параметры:

• НачалоПериода: начало проверяемого периода.

• КонецПериода: конец проверяемого периода.

• СтатьяБюджетов: ссылка на нужную статью бюджетов.

• Правило: ссылка на проверяемое правило.

Такой запрос позволяет проверить движения конкретного правила, не предполагая, что в базе существует статья с названием «Премия».

Для сравнения суммы необходимо получать и из непосредственного расчёта, и из регистра за одинаковый период и с одинаковыми условиями отбора.

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

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

10. Что в итоге выбрать

Оба подхода решают задачу на разных уровнях.

В нашем случае первый и второй вариант успешно прошёл испытания КА 2.6.2.59.

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

Заключение

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

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

После добавления этого поля удалось восстановить формирование хранимого факта и проверить результат на двух периодах.

Адресное исправление выполнили расширением через &Вместо и ПродолжитьВызов() без изменения основной конфигурации.

Дополнительно рассмотрели способ через &ИзменениеИКонтроль, при котором исправляется список полей группировки СКД, а не готовый текст запроса.

Основной вывод: когда без хранения правило работает, а с хранением нет, имеет смысл проверить не только исходные данные и отборы, но и запрос, который система формирует для сохранения результата.

При этом не следует автоматически переносить исправление на все правила со схожими отборами. Состав полей, схема СКД и сам механизм формирования запроса могут отличаться.

В статье показан конкретный проверенный сценарий на релизе КА 2.6.2.59, а не утверждается наличие одинакового дефекта у всех пользователей этой конфигурации.