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

← На главную

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

Метод 1. Использование механизма «Параметры связи выбора»

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

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

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

Теперь платформа автоматически будет передавать текущее значение типа операции в форму выбора справочника «Проекты» в качестве фильтра. Это решение является наиболее «чистым» с точки зрения архитектуры 1С.

Метод 2. Программная установка отбора через событие «НачалоВыбора»

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

Разберем пример кода, который необходимо разместить в модуле формы:


&НаКлиенте
Процедура ПроектНачалоВыбора(Элемент, ДанныеВыбора, СтандартнаяОбработка)
    
    // Отменяем стандартное открытие формы, чтобы настроить параметры самостоятельно
    СтандартнаяОбработка = Ложь;
    
    // Формируем структуру отбора
    ПараметрыОтбора = Новый Структура;
    ПараметрыОтбора.Вставить("ТипПроекта", Объект.ТипОперации);
    ПараметрыОтбора.Вставить("ПометкаУдаления", Ложь); // Дополнительный фильтр
    
    // Формируем параметры открытия формы выбора
    ПараметрыВыбора = Новый Структура;
    ПараметрыВыбора.Вставить("Отбор", ПараметрыОтбора);
    
    // Открываем форму выбора справочника Проекты с нашими параметрами
    ОткрытьФорму("Справочник.Проекты.ФормаВыбора", ПараметрыВыбора, Элемент);
    
КонецПроцедуры

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

Метод 3. Ошибка ручного заполнения списка выбора

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

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

Использовать Элементы.Проект.СписокВыбора.Добавить() стоит только тогда, когда количество вариантов фиксировано и невелико (например, 3-5 статичных значений), которые не хранятся в справочниках.

Важный нюанс: Иерархия (Родитель) vs Владелец

В ходе обсуждения возник вопрос о связи через поле Родитель. Важно понимать разницу:

Родитель — это элемент того же самого справочника. Если вы организуете проекты по папкам «Доходы» и «Расходы», то фильтрация по родителю будет работать только для элементов первого уровня вложенности. Чтобы отбор работал корректно для всей глубины дерева, в параметрах связи выбора нужно использовать вид сравнения ВИерархии.

Владелец — это связь между разными справочниками. Если справочник «Проекты» подчинен справочнику «ТипыОпераций», то установка связи по владельцу — это жесткое ограничение. Один проект сможет принадлежать только одному типу. Если архитектура требует, чтобы проект мог относиться к разным категориям, лучше использовать дополнительные реквизиты или свойства.

Автоматизация: Очистка зависимых полей

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


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

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