Почему в динамическом списке не отображается реквизит из расширения и как исправить ошибку «Поле не найдено»?

При разработке в среде 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда добавленные через расширение реквизиты или справочники корректно работают под полными правами, но вызывают критическую ошибку у обычных пользователей. Рассмотрим типовой сценарий на примере конфигурации УТ 11.4: в расширении создан справочник Автомобили, а в документ РеализацияТоваровУслуг добавлен реквизит, ссылающийся на этот справочник. При попытке вывести данные в динамический список журнала продаж система выдает ошибку: «Поле не найдено...». Разберем детально, почему это происходит и как правильно настроить систему.

Проанализируем причину возникновения ошибки

Первым делом проанализируем текст ошибки. Система сообщает, что поле РеализацияТоваровУслуг.СТО_Автомобиль.ГосНомер не найдено. На первый взгляд, запрос составлен верно, и в конфигураторе поле отображается. Однако для платформы 1С видимость данных в динамическом списке напрямую зависит от прав доступа текущего пользователя. Если у пользователя нет прав на чтение хотя бы одного элемента в цепочке обращения, платформа «скрывает» это поле из метаданных для этого сеанса, что и приводит к ошибке выполнения запроса.

Рассмотрим цепочку обращения в запросе автора:

РеализацияТоваровУслуг.СТО_Автомобиль.ГосНомер КАК СТО_АвтомобильГосНомер

Чтобы этот фрагмент кода работал, у пользователя должны быть права одновременно на:

1. Чтение самого документа РеализацияТоваровУслуг.
2. Просмотр нового реквизита СТО_Автомобиль, добавленного в этот документ через расширение.
3. Чтение и просмотр нового справочника Автомобили.
4. Просмотр реквизита ГосНомер внутри нового справочника.

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

Решение 1: Создание и настройка ролей в расширении

Выясним, как правильно добавить права в расширении. В 1С права, заданные в основной конфигурации, не распространяются автоматически на новые объекты расширения (если не включены специальные опции). Рассмотрим по шагам процесс создания роли:

1. В дереве объектов расширения перейдем в ветку Роли и создадим новую роль (например, СТО_РаботаСАвтомобилями).
2. В окне редактирования роли найдем наши новые объекты: справочник Автомобили и заимствованный документ РеализацияТоваровУслуг.
3. Для справочника Автомобили установим права: Чтение и Просмотр.
4. Для документа РеализацияТоваровУслуг перейдем к списку реквизитов и найдем добавленный нами реквизит СТО_Автомобиль. Установим для него право Просмотр.
5. Сохраним расширение и обновим конфигурацию базы данных.
6. Важный момент: созданную роль необходимо добавить в профили групп доступа соответствующих пользователей в пользовательском режиме (1С:Предприятие).

После этого система начнет «видеть» поле в запросе динамического списка, и ошибка исчезнет.

Решение 2: Использование свойства «Устанавливать права для новых объектов»

Посмотрим на настройки самого расширения. В корне дерева объектов расширения (самый верхний элемент) есть палитра свойств. Там находится флаг «Устанавливать права для новых объектов».

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

Решение 3: Проверка функциональных опций

Иногда причина кроется не в ролях, а в функциональных опциях. Проанализируем ситуацию: если ваш новый справочник или реквизит привязан к какой-либо Функциональной опции, и эта опция в текущей базе выключена, поле также будет недоступно в метаданных запроса. Убедитесь, что для новых объектов не заданы лишние функциональные опции, или что они включены в константах системы.

Оптимизация: Архитектурно правильный подход в УТ 11

Разберем, как сделать работу журнала документов более быстрой. В типовых решениях, таких как УТ 11.4 или ERP, журналы документов (например, журнал продаж) строятся не на таблицах документов, а на специальном регистре сведений РеестрДокументов. Автор вопроса добавил ЛЕВОЕ СОЕДИНЕНИЕ с таблицей Документ.РеализацияТоваровУслуг прямо в динамический список:

ЛЕВОЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ПО РеестрДокументовПереопределяемый.Ссылка = РеализацияТоваровУслуг.Ссылка

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

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

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

Дополнительные рекомендации

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

• Очистка кэша: Иногда платформа хранит старую структуру метаданных в локальном кэше пользователя. Очистите кэш или запустите базу с параметром /ClearCache.
• Стандартные настройки: В режиме 1С:Предприятие в форме списка зайдите в Еще — Установить стандартные настройки. Это заставит динамический список перечитать структуру колонок и полей запроса.
• Основная роль расширения: Проверьте, нет ли в расширении роли с установленным флагом «Основная роль». Если она есть и в ней не прописаны права на ваши объекты, это также может блокировать доступ.

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