Почему новый реквизит справочника не отображается в отладчике при формировании печатных форм в 1С?

При доработке конфигураций, разработанных на базе Библиотеки стандартных подсистем (БСП), разработчики часто сталкиваются с ситуацией: в справочник (например, Организации) добавлен новый реквизит (допустим, КодПоОКТМО), он выведен на форму, конфигурация базы данных успешно обновлена, однако при вызове процедур печати новый реквизит отсутствует в структуре данных и не виден в отладчике. Разберем причины такого поведения платформы и типовых механизмов БСП, а также пошагово устраним проблему.

Причина 1. Особенности формирования данных печати в подсистемах БСП

Проанализируем архитектуру подсистемы печати БСП. В типовых конфигурациях алгоритмы формирования печатных форм практически никогда не обращаются к реквизитам объектов через точку от ссылки (например, СсылкаНаОрганизацию.КодПоОКТМО), так как это приводит к неоптимальным запросам к базе данных («чтение через точку»).

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

1. В обработчик печати передается не ссылка СправочникСсылка.Организации, а объект типа Структура, СтрокаТаблицыЗначений или ВыборкаИзРезультатаЗапроса.
2. Если новый реквизит не был явно добавлен в текст запроса функции сбора сведений в модуле менеджера, он не попадет в результирующую структуру, даже если поле физически существует в метаданных и заполнено в базе.
3. При попытке посмотреть состав реквизитов структуры через отладчик программист видит только те поля, которые были запрошены изначально (например, ИНН, КПП, ОКАТО).

Решение: Добавление реквизита в модуль менеджера

Разберем по шагам, как добавить новый реквизит в механизм печати:

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

// Пример доработки текста запроса сбора сведений
ТекстЗапроса = 
"ВЫБРАТЬ
|	Организации.Ссылка КАК Организация,
|	Организации.ИНН КАК ИНН,
|	Организации.КПП КАК КПП,
|	Организации.КодПоОКАТО КАК КодПоОКАТО,
|	Организации.КодПоОКТМО КАК КодПоОКТМО
|ИЗ
|	Справочник.Организации КАК Организации
|ГДЕ
|	Организации.Ссылка = &Организация";

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

Причина 2. Кэширование модулей с повторным использованием значений

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

Для сброса кэша выполним следующие действия:

1. Перезапустим сеанс «1С:Предприятия».
2. При разработке на сервере приложений можно использовать метод ОчиститьКэшПовторногоИспользования().

Причина 3. Динамическое обновление («демоническое обновление»)

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

Проверим и исправим эту ситуацию:

1. Завершим все сеансы пользователей и сеанс отладки.
2. Выполним полноценное сохранение и обновление конфигурации базы данных (клавиша F7 в конфигураторе).
3. При сохранении проблем на серверной базе перезапустим службу 1C:Enterprise Server Agent и очистим локальный кэш конфигурации на клиентском ПК.

Причина 4. Права доступа и Привилегированный режим

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

Убедимся, что:

1. Новый реквизит включен в соответствующие роли пользователей для чтения.
2. В служебных модулях печати считывание данных выполняется в привилегированном режиме с использованием инструкции УстановитьПривилегированныйРежим(Истина).