Как настроить динамический список в 1С с отбором по данным из связанного регистра сведений?

← На главную

В процессе разработки на платформе 1С:Предприятие 8.3 часто возникает задача модификации типовых форм выбора. Типичный пример — форма выбора справочника Партнеры в конфигурации «Управление торговлей 11». Стандартный функционал не всегда позволяет фильтровать данные по условиям из внешних (кастомных) регистров. Рассмотрим ситуацию, когда нам необходимо отобразить в списке только тех партнеров, у которых есть действующее соглашение, зафиксированное в нетиповом регистре сведений АЛП_СтатусыСоглашенийСДизайнерами.

Разбор архитектурной задачи

Проанализируем структуру данных. У нас есть основной справочник Партнеры. С ним связан подчиненный справочник АЛП_СоглашенияСДизайнерами (владельцем которого является партнер). Состояние этого соглашения (действует оно или нет) хранится в периодическом регистре сведений АЛП_СтатусыСоглашенийСДизайнерами. Наша цель — динамически изменять текст запроса списка так, чтобы в него попадали только записи, удовлетворяющие условию: ресурс Действует в срезе последних регистра равен ИСТИНА.

Анализ типичных ошибок при написании запроса

Прежде чем перейти к рабочему решению, разберем, какие ошибки часто допускают разработчики при попытке модифицировать динамический список программно:

Разыменование через несколько точек: Использование конструкций вида Регистр.Соглашение.Владелец.Наименование. В языке запросов 1С каждая точка — это неявное левое соединение. В динамических списках, которые должны работать быстро, это приводит к существенной деградации производительности.
Обращение к табличным частям: Попытка выбрать данные табличных частей (например, ДополнительныеРеквизиты или КонтактнаяИнформация) напрямую в основном запросе списка. Платформа 1С не поддерживает выбор вложенных таблиц в динамических списках. Это либо вызовет ошибку, либо приведет к «размножению» строк (на каждого партнера выведется столько строк, сколько у него реквизитов).
Потеря основной таблицы: Если в свойствах динамического списка не указана «Основная таблица», или запрос стал слишком сложным (например, с использованием ОБЪЕДИНИТЬ или СГРУППИРОВАТЬ), стандартные механизмы поиска и отбора могут перестать работать.

Решение 1: Модификация запроса через левое соединение и РАЗЛИЧНЫЕ

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

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


ТекстЗапроса = 
    "ВЫБРАТЬ РАЗЛИЧНЫЕ
    |    СправочникПартнеры.Ссылка КАК Ссылка,
    |    СправочникПартнеры.ПометкаУдаления КАК ПометкаУдаления,
    |    СправочникПартнеры.Наименование КАК Наименование,
    |    СправочникПартнеры.ИНН КАК ИНН,
    |    ВЫРАЗИТЬ(СправочникПартнеры.Комментарий КАК СТРОКА(100)) КАК Комментарий,
    |    Контрагенты.Ссылка КАК Контрагент,
    |    АЛП_СтатусыСоглашенийСДизайнерамиСрезПоследних.Действует КАК Действует
    |ИЗ
    |    Справочник.Партнеры КАК СправочникПартнеры
    |        {ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты
    |        ПО (Контрагенты.Партнер = СправочникПартнеры.Ссылка)}
    |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.АЛП_СтатусыСоглашенийСДизайнерами.СрезПоследних КАК АЛП_СтатусыСоглашенийСДизайнерамиСрезПоследних
    |        ПО СправочникПартнеры.Ссылка = АЛП_СтатусыСоглашенийСДизайнерамиСрезПоследних.Соглашение.Владелец
    |ГДЕ
    |    СправочникПартнеры.Поставщик = ИСТИНА
    |    И АЛП_СтатусыСоглашенийСДизайнерамиСрезПоследних.Действует = ИСТИНА";

Список.ТекстЗапроса = ТекстЗапроса;

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

Решение 2: Оптимальный метод через условие «В» (подзапрос)

Хотя первый метод является рабочим, использование РАЗЛИЧНЫЕ может замедлять работу формы на больших объемах данных (десятки тысяч партнеров), так как СУБД вынуждена выполнять сортировку для удаления дублей. Рассмотрим более элегантный и производительный подход — использование фильтрации в секции ГДЕ.

Выясним причину эффективности этого метода: мы не расширяем выборку соединениями, а просто ограничиваем ее списком ссылок. Это позволяет платформе эффективнее строить план запроса.


// В тексте запроса динамического списка (с указанной основной таблицей)
// Мы просто добавляем условие связи с регистром
ВЫБРАТЬ
    СправочникПартнеры.Ссылка,
    СправочникПартнеры.Наименование
ИЗ
    Справочник.Партнеры КАК СправочникПартнеры
ГДЕ
    СправочникПартнеры.Ссылка В (
        ВЫБРАТЬ
            Т.Соглашение.Владелец
        ИЗ
            РегистрСведений.АЛП_СтатусыСоглашенийСДизайнерами.СрезПоследних КАК Т
        ГДЕ
            Т.Действует = ИСТИНА
    )

Такой подход гарантирует отсутствие дублей без использования тяжелого оператора DISTINCT.

Решение 3: Гибкая настройка через Компоновщик Настроек

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

Рассмотрим, как это реализовать программно при открытии формы:

Добавим в исходный запрос динамического списка (в конфигураторе) ЛЕВОЕ СОЕДИНЕНИЕ с регистром.
В коде вызова формы установим отбор по полю этого регистра.


// В процедуре ПриСозданииНаСервере или перед открытием
НовыйОтбор = Список.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
НовыйОтбор.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Действует");
НовыйОтбор.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
НовыйОтбор.ПравоеЗначение = Истина;
НовыйОтбор.Использование = Истина;
НовыйОтбор.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный;

Итоги

Подводя итог, можно сказать, что для решения задачи фильтрации списка по данным регистра наиболее стабильным является метод с ЛЕВЫМ СОЕДИНЕНИЕМ и использованием ВЫБРАТЬ РАЗЛИЧНЫЕ, либо (что предпочтительнее для больших баз) использование подзапроса в условии ГДЕ. Всегда следите за тем, чтобы ОсновнаяТаблица динамического списка была заполнена — это залог корректной работы стандартных команд 1С.