Как добавить поле «Договор» в журнал операций БГУ 2.0 и исправить ошибку несоответствия типов в критериях отбора

← На главную

При кастомизации типовых решений на базе 1С, таких как Бухгалтерия государственного учреждения 2.0 (БГУ 2), разработчики часто сталкиваются с необходимостью вывода дополнительных данных в стандартные журналы документов. Одной из самых востребованных задач является вывод информации о договоре контрагента в «Журнале операций». Однако простое изменение запроса динамического списка может привести к неожиданным ошибкам, в частности к сбою при переходе к списку документов из карточки договора через механизм Критериев отбора.

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

Постановка проблемы и анализ ошибки

Рассмотрим ситуацию: программист вносит изменения в запрос динамического списка ЖурналДокументов.ЖурналОпераций. Цель — вывести колонку «Договор». В запросе используется массивная конструкция ВЫБОР... КОГДА... ТОГДА, которая проверяет тип ссылки документа и через оператор ВЫРАЗИТЬ пытается получить реквизит Договор. Пример такого кода выглядит следующим образом:


ВЫБОР
    КОГДА ЖурналДокументовЖурналОпераций.Ссылка ССЫЛКА Документ.СчетФактураВыданный
        ТОГДА ЕСТЬNULL(ВЫРАЗИТЬ(ЖурналДокументовЖурналОпераций.Ссылка КАК Документ.СчетФактураВыданный).Договор, "")
    КОГДА ЖурналДокументовЖурналОпераций.Ссылка ССЫЛКА Документ.КассовоеВыбытие
        ТОГДА ЕСТЬNULL(ВЫРАЗИТЬ(ЖурналДокументовЖурналОпераций.Ссылка КАК Документ.КассовоеВыбытие).Договор, "")
    // ... и так далее для всех типов документов
КОНЕЦ КАК Договор

После внесения таких правок сам журнал открывается корректно, и данные отображаются. Но при попытке открыть список документов непосредственно из элемента справочника «Договоры» (используя стандартную команду «Документы»), система выдает критическую ошибку: «ошибка обработки представления критерий отбора.документы по договору: несоответствие типов (параметр номер 1)». Выясним причину этого поведения.

Проблема кроется в механизме Критериев отбора. Когда платформа 1С выполняет переход по ссылке, она пытается наложить фильтр на динамический список журнала, используя встроенные условия. Если в запросе списка имя поля совпадает с именем параметра или если структура запроса мешает платформе корректно сопоставить типы данных (так как ВЫБОР создает анонимный составной тип), возникает конфликт. Система не может «прокинуть» ссылку на конкретный договор в параметр критерия отбора, так как ожидает жестко определенный тип данных, а получает результат сложного вычисления.

Разберем по шагам: почему запрос «на лету» — это плохо?

Прежде чем перейти к правильному решению, проанализируем ситуацию с точки зрения производительности и архитектуры. Когда мы пишем конструкцию ВЫРАЗИТЬ(... КАК Документ.ИмяДокумента) внутри общего журнала, СУБД вынуждена выполнять левое соединение (LEFT JOIN) с таблицей каждого указанного документа при прорисовке каждой строки списка. Если в журнале десятки тысяч документов, это приведет к значительным задержкам (фризам) при прокрутке списка.

Для решения подобных задач в платформе 1С предусмотрен специальный объект — Графы журнала. Посмотрим на них подробнее.

Правильное решение: использование Граф журнала

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

Рассмотрим алгоритм правильной настройки:

Откройте конфигуратор и найдите объект ЖурналДокументов.ЖурналОпераций.
Перейдите на вкладку «Данные».
В списке «Графы» добавьте новую графу, например, с именем VID_ДоговорКонтрагента (или используйте существующую, если она подходит по смыслу).
В свойствах графы укажите тип данных — СправочникСсылка.Договоры (или составной тип, если это необходимо).
Ниже, в списке документов, входящих в журнал, расставьте флажки напротив реквизитов Договор для каждого вида документа. Этим вы сообщаете платформе: «Возьми значение из этого поля документа и положи его в общую колонку журнала».

После того как графа создана и заполнена, запрос динамического списка значительно упрощается. Нам больше не нужны сложные условия ВЫБОР.

Обновление запроса динамического списка

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

Пример оптимизированного кода запроса:


ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ЖурналДокументовЖурналОпераций.Ссылка КАК Ссылка,
    ЖурналДокументовЖурналОпераций.Дата КАК Дата,
    ЖурналДокументовЖурналОпераций.Номер КАК Номер,
    // Используем созданную графу вместо сложной логики
    ЕСТЬNULL(ЖурналДокументовЖурналОпераций.VID_ДоговорКонтрагента, ЗНАЧЕНИЕ(Справочник.Договоры.ПустаяСсылка)) КАК Договор,
    // Остальные поля...
    ОперацииДокументов.Состояние КАК СостояниеОперации
ИЗ
    ЖурналДокументов.ЖурналОпераций КАК ЖурналДокументовЖурналОпераций
    {ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ОперацииДокументов КАК ОперацииДокументов
    ПО ЖурналДокументовЖурналОпераций.Ссылка = ОперацииДокументов.Документ}

Важный нюанс: В блоке {ГДЕ ...} динамического списка платформа автоматически управляет фильтрами. Использование граф позволяет платформе беспрепятственно накладывать условие ГДЕ Договор = &Параметр, так как поле VID_ДоговорКонтрагента теперь имеет четкий тип ссылки справочника, совпадающий с типом параметра критерия отбора.

Особенности БГУ 2.0 и регистр «Операции документов»

В конфигурации БГУ 2.0 многие сведения о состоянии проводок и суммах документов хранятся в вспомогательном регистре сведений ОперацииДокументов. Это сделано для ускорения работы интерфейса. При кастомизации журнала операций полезно помнить:

Если вам нужно вывести специфические данные, которых нет в графах журнала, проверьте, нет ли их в регистре ОперацииДокументов.
При использовании соединений с регистрами в динамическом списке всегда оборачивайте их в фигурные скобки {}. Это позволит платформе оптимизировать запрос и не выполнять соединение, если поля из регистра не выведены в текущем пользовательском представлении списка.
Для БГУ 2.0 крайне рекомендуется выполнять подобные изменения через Расширения конфигурации. Это позволит сохранить возможность типового обновления программы, что критически важно для государственных учреждений из-за частого изменения законодательства.

Итоги

Рассмотренная проблема «несоответствия типов» является классическим примером того, как попытка решить задачу «в лоб» через код запроса вступает в конфликт с системными механизмами платформы 1С. Подведем итог нашим действиям:

Во-первых, мы выяснили, что сложные конструкции ВЫБОР и ВЫРАЗИТЬ в журналах документов вредны для производительности и ломают работу критериев отбора.

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

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

Следуя этой методике, вы сможете добавлять любые дополнительные поля (Контрагенты, КФО, Источники финансирования) в любые журналы документов, сохраняя при этом высокую скорость работы системы и полную совместимость со всеми встроенными функциями поиска и навигации 1С.