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

← На главную

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

Причина потери интерактивности списка

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

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

Шаг 1: Подготовка запроса

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

Рассмотрим пример запроса, который позволяет выводить итоги по табличной части документа (например, Реализация товаров и услуг):


ВЫБРАТЬ
    ДокументРеализация.Ссылка КАК Ссылка,
    ДокументРеализация.Номер КАК Номер,
    ДокументРеализация.Дата КАК Дата,
    ДокументРеализация.Контрагент КАК Контрагент,
    ЕСТЬNULL(ВложенныйЗапрос.СуммаИтог, 0) КАК СуммаПоДокументу
ИЗ
    Документ.РеализацияТоваровУслуг КАК ДокументРеализация
        ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
            РеализацияТовары.Ссылка КАК Ссылка,
            СУММА(РеализацияТовары.Сумма) КАК СуммаИтог
        ИЗ
            Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТовары
        СГРУППИРОВАТЬ ПО
            РеализацияТовары.Ссылка) КАК ВложенныйЗапрос
        ПО ДокументРеализация.Ссылка = ВложенныйЗапрос.Ссылка

В данном примере поле Ссылка выбрано в основном пакете запроса. Это критически важно для следующего шага.

Шаг 2: Установка основной таблицы

После написания запроса в окне редактирования динамического списка выполним следующие действия:

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

Важный момент: Установка основной таблицы не только возвращает стандартные команды, но и включает механизм RLS (Record Level Security). Без основной таблицы ограничения прав доступа на уровне записей могут не сработать корректно, и пользователь увидит данные, к которым у него нет прав.

Использование временных таблиц в динамических списках

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

До версии платформы 8.3.14 использование временных таблиц в динамических списках было ограничено или приводило к ошибкам. В современных версиях это допустимо, но с определенными оговорками. Рассмотрим ситуацию, когда основная таблица становится недоступной для выбора из-за использования пакета запросов.

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

Однако стоит помнить о производительности. Динамический список с временными таблицами работает медленнее, так как системе сложнее оптимизировать порционную выборку данных (считывание только видимых строк). Проанализируем влияние: СУБД может потребоваться сформировать всю временную таблицу целиком, прежде чем отдать первые 20 строк пользователю, что вызовет задержки при открытии формы и прокрутке.

Архитектурный подход: когда произвольный запрос — зло

Вернемся к задаче автора: вывод итога суммы табличной части. Использование соединений или вложенных запросов для подсчета сумм "на лету" в динамическом списке — это ресурсоемкая операция. Рассмотрим более правильный с точки зрения стандартов "1С" подход.

Для обеспечения максимального быстродействия интерфейса рекомендуется:

Добавить в документ реальный реквизит СуммаДокумента.
Настроить его заполнение в процедуре ПередЗаписью или ПриЗаписи на стороне сервера.
Проиндексировать этот реквизит.
В динамическом списке использовать обычный режим (без произвольного запроса) или простой запрос к основной таблице документа.

Такой подход позволяет системе считывать данные из одной физической таблицы без выполнения математических вычислений и группировок при каждом движении мышки пользователя. Это особенно критично для баз с большим объемом данных (десятки и сотни тысяч документов).

Резюме по настройке

Подведем итоги наших действий при работе с динамическим списком:

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

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