Как настроить зависимый выбор значений и фильтрацию выпадающих списков в 1С

При разработке прикладных решений часто возникает задача создания зависимых полей, когда значение одного реквизита определяет доступный список значений в другом. Классический пример — поля «Производитель» и «Модель». Пользователю необходимо предоставить удобный интерфейс, в котором при выборе модели учитывается уже указанный производитель: как при открытии формы выбора, так и при вводе текста или раскрытии списка ранее выбранных значений.

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

Почему не работает событие НачалоВыбораИзСписка

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

Если поле связано с обычным ссылочным реквизитом информационной базы (например, со справочником), платформа использует динамический механизм получения данных. Выпадающий список формируется платформой динамически из базы данных и истории выбора пользователя, поэтому событие НачалоВыбораИзСписка для таких реквизитов просто не вызывается.

Программная фильтрация через события формы

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

Посмотрим на пример обработчиков, позволяющих передать отбор по производителю в структуру параметров получения данных:

&НаКлиенте
Процедура МодельТехникиАвтоПодбор(Элемент, Текст, ДанныеВыбора, ПараметрыПолученияДанных, Ожидание, СтандартнаяОбработка)
	
	ПараметрыПолученияДанных.Отбор.Вставить("ПроизводителиТехники", ЭтаФорма.Объект.ПроизводителиТехники);		
	
КонецПроцедуры

&НаКлиенте
Процедура МодельТехникиОкончаниеВводаТекста(Элемент, Текст, ДанныеВыбора, ПараметрыПолученияДанных, СтандартнаяОбработка)
	
	ПараметрыПолученияДанных.Отбор.Вставить("ПроизводителиТехники", ЭтаФорма.Объект.ПроизводителиТехники);		
	
КонецПроцедуры

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

Декларативная настройка через «Связи параметров выбора»

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

Разберем по шагам, как настроить этот механизм:

1. Откроем дерево метаданных конфигуратора и найдем зависимый реквизит объекта (например, реквизит Модель).
2. В палитре свойств реквизита найдем строку Связи параметров выбора и нажмем кнопку открытия настройки.
3. Добавим новую связь: в колонке «Имя отбора» укажем Отбор.Производитель (где Производитель — реквизит подчиненного справочника), а в колонке «Поле-источник» выберем реквизит текущего объекта Производитель.

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

1. Работа во всех формах: отбор автоматически начинает действовать в документах, справочниках и отчетах, где выведен данный реквизит, без единой строчки программного кода.
2. Комплексная фильтрация: платформа автоматически накладывает отбор не только на форму выбора, но и на выпадающий список быстрого подбора по строке.
3. Корректная работа в табличных частях: если реквизиты находятся в табличной части, связь параметров выбора автоматически отслеживает значения в рамках одной и той же текущей строки.
4. Подчиненные справочники: если один справочник логически подчинен другому, достаточно заполнить свойство «Связь по владельцу», и система настроит отборы самостоятельно.

Централизация серверной логики в модуле менеджера

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

1. Откроем модуль менеджера целевого справочника (в нашем примере — справочника моделей).
2. Создадим предопределенный обработчик ОбработкаПолученияДанныхВыбора.
3. В параметре Параметры проанализируем входящие отборы, сформируем собственный запрос к базе данных и заполним список ДанныеВыбора, установив флаг СтандартнаяОбработка = Ложь.

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

Особенности истории выбора

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

1. При использовании штатного механизма «Связи параметров выбора» платформа современных версий 8.3 автоматически проверяет элементы истории на соответствие отбору и скрывает неактуальные данные.
2. Если история формируется некорректно из-за сложной динамической логики, ее можно принудительно отключить для конкретного элемента формы, установив свойство ИсторияВыбораПриВводеПоСтроке в значение НеИспользовать.
3. Для небольших справочников можно использовать свойство метаданных «Быстрый выбор» (QuickChoice), которое открывает компактный выпадающий перечень значений вместо модальной формы списка.