Почему регистр сведений не виден в динамическом списке расширения 1С и как это исправить

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

Выясняем причину: пространство имен расширения

Проанализируем архитектуру расширений. Когда мы создаем расширение, оно представляет собой отдельный слой метаданных, который накладывается на основную конфигурацию. Платформа 1С строго разграничивает видимость объектов: внутри расширения "видны" только те объекты, которые в него явно добавлены (заимствованы). Если регистр сведений существует в основной конфигурации, но не добавлен в расширение, конструктор запроса в контексте расширения его не увидит. Это и есть тот самый "кот в мешке", о котором упоминалось в обсуждении на форуме.

Многие разработчики ошибочно полагают, что раз объект есть в "дереве" основной конфигурации, то к нему можно обращаться из любого места. Однако для динамического списка в расширении это правило не работает. Заимствование — это обязательное условие для использования таблиц в произвольных запросах внутри расширения.

Шаг 1: Заимствование регистра в расширение

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

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

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

Шаг 2: Настройка динамического списка

Теперь, когда регистр заимствован, вернемся к форме документа в расширении. Посмотрим на настройку реквизита типа ДинамическийСписок.

Частая ошибка начинающих — попытка установить тип реквизита как "РегистрСведений...". Помните, что ДинамическийСписок — это самостоятельный тип данных. Чтобы он отображал данные регистра, нужно настроить его свойства:

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

Шаг 3: Программная установка запроса (обход ошибок конструктора)

Иногда визуальный конструктор может вести себя некорректно из-за кэша или специфических ошибок платформы. В таком случае проанализируем возможность программной установки текста запроса. Это можно сделать в обработчике ПриСозданииНаСервере. Рассмотрим пример кода:

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

Даже если конструктор в режиме конфигуратора подсвечивает запрос красным, при наличии заимствованного объекта в расширении этот код успешно выполнится в режиме "1С:Предприятие".

Почему не стоит использовать Таблицу Значений (ТЗ)?

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

• Постраничный вывод: Платформа считывает из базы только те записи, которые видны пользователю на экране. Если в регистре тысячи записей, ТЗ "повесит" форму при заполнении, а Динамический список отработает мгновенно.
• Поиск и фильтрация: Стандартные кнопки поиска и расширенный отбор работают "из коробки" без написания кода.
• Условное оформление: Настроить подсветку строк в динамическом списке гораздо проще и производительнее, чем в ТЗ.

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

Работа с правами доступа в расширении

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

Резюме: Решение проблемы "невидимости" регистра сведений в расширении всегда сводится к корректному заимствованию объекта метаданных. Не нужно изобретать велосипед с табличными документами — достаточно один раз правильно настроить состав расширения, и динамический список раскроет весь свой потенциал.