При разработке отчетов на базе Системы компоновки данных (СКД) разработчики часто сталкиваются с ситуацией, когда пользователю предоставляется возможность отбора по иерархическому справочнику (например, по номенклатуре, контрагентам или подразделениям). Если в отчете используется вид сравнения "В группе" или "В группе из списка", логично ожидать, что пользователь должен выбирать именно группы (папки) справочника, а не конечные элементы.
Однако по умолчанию стандартная форма выбора 1С позволяет выбрать любой объект — как группу, так и элемент. Это не только путает конечного пользователя, но и может приводить к созданию неоптимальных запросов к СУБД. В рамках этой статьи мы подробно разберем, как решить эту проблему различными методами: от самого простого декларативного способа в схеме СКД до гибкого программного управления на управляемой форме.
Прежде чем перейти к реализации решений, разберем, почему важно контролировать выбор пользователя при иерархических отборах. Когда в компоновщике настроек применяется вид сравнения "В группе", платформа 1С:Предприятие транслирует запрос к базе данных с использованием конструкции В ИЕРАРХИИ. Если пользователь по ошибке выбирает в качестве значения обычный элемент справочника (товар), у которого физически нет и не может быть подчиненных элементов, система все равно выполняет сложный иерархический запрос к таблице СУБД. Это создает лишнюю бессмысленную нагрузку на сервер.
Чтобы избежать подобных ситуаций, мы должны ограничить форму выбора справочника таким образом, чтобы пользователь мог интерактивно указать только группу. Рассмотрим четыре эффективных способа реализации этой задачи.
Самое лаконичное и правильное решение, не требующее написания кода, заключается в настройке параметров редактирования конкретного поля непосредственно в схеме компоновки данных. Разберем этот процесс по шагам:
Номенклатура).После этой простой настройки при попытке интерактивного выбора значения в отборе (даже в стандартном быстром доступе) платформа автоматически откроет форму справочника в режиме выбора групп. Конечные элементы будут отображаться серым цветом (будут недоступны для выбора), либо форма будет содержать исключительно дерево папок.
Важный нюанс этого способа: Указанное ограничение применяется к полю глобально. Если пользователю в одном и том же отчете когда-нибудь понадобится сделать два разных отбора (например, один по конкретному товару через вид сравнения "Равно", а второй — по папке через "В группе из списка"), то при глобальной настройке он физически не сможет выбрать конечный элемент ни в одном из этих отборов. Если вам требуется более гибкое поведение, перейдем к следующим способам.
Если нам необходимо динамически управлять возможностью выбора групп или элементов в зависимости от выбранного пользователем вида сравнения, нам поможет программная настройка на стороне управляемой формы отчета. Рассмотрим, как это реализовать.
Мы можем перехватить момент генерации формы или момент изменения настроек отбора и программно управлять свойством элемента формы ВыборГруппИЭлементов. Проанализируем пример кода, который можно разместить в модуле управляемой формы отчета (например, в событии ПриОткрытии или при создании формы на сервере):
&НаСервере
Процедура НастроитьВыборГруппИЭлементовНаСервере()
// Получаем коллекцию элементов пользовательских настроек на форме
Для Каждого ЭлементФормы Из Элементы Цикл
// Проверяем, является ли элемент полем ввода, связанным с отбором номенклатуры
Если ТипЗнч(ЭлементФормы) = Тип("ПолеФормы") И ЭлементФормы.ПутьКДанным Подобно "*Номенклатура*" Тогда
// Устанавливаем ограничение программно
ЭлементФормы.ВыборГруппИЭлементов = ИспользованиеГруппИЭлементов.Группы;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Если мы хотим сделать поведение еще более адаптивным (чтобы при виде сравнения "Равно" можно было выбирать элементы, а при "В группе" — только группы), мы можем написать обработчик события изменения вида сравнения в таблице отборов:
&НаКлиенте
Процедура ТаблицаОтбораВидСравненияПриИзменении(Элемент)
СтрокаТаблицы = Элементы.КомпоновщикНастроекПользовательскиеНастройки.ТекущиеДанные;
Если СтрокаТаблицы <> Неопределено Тогда
// Проверяем текущий вид сравнения в строке отбора
Если СтрокаТаблицы.ВидСравнения = ВидСравненияКомпоновкиДанных.ВИерархии
Или СтрокаТаблицы.ВидСравнения = ВидСравненияКомпоновкиДанных.ВИерархииИзСписка Тогда
// Находим связанное поле ввода и ограничиваем выбор только группами
Элементы.ПолеВводаЗначенияОтбора.ВыборГруппИЭлементов = ИспользованиеГруппИЭлементов.Группы;
Иначе
// Разрешаем выбор и групп, и элементов для обычного сравнения
Элементы.ПолеВводаЗначенияОтбора.ВыборГруппИЭлементов = ИспользованиеГруппИЭлементов.ГруппыИЭлементы;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Еще один элегантный способ ограничить выбор пользователя в СКД — использовать свойство "Параметры выбора" для поля набора данных. Этот метод позволяет передать жесткий отбор в открывающуюся форму выбора справочника.
Рассмотрим, как настроить этот параметр:
Отбор.ЭтоГруппа, а в поле "Значение" установим булево значение Истина.Предупреждение о поведении платформы: При использовании видов сравнения для работы со списками (например, "В списке", "В группе из списка") система компоновки данных на некоторых релизах платформы 1С может открывать не стандартную форму выбора единичного элемента, а форму подбора или форму редактирования списка значений. В таких сценариях параметры выбора, переданные через настройки СКД, могут игнорироваться системой. Поэтому для множественных отборов более надежным решением остается использование первого или второго способа.
Если бизнес-логика вашего отчета предполагает фильтрацию не по всему справочнику номенклатуры, а только по нескольким ключевым товарным направлениям (например, группы "Товары", "Услуги", "Материалы"), мы можем полностью избавить пользователя от необходимости ориентироваться в дереве справочника. Для этого воспользуемся колонкой "Доступные значения" в СКД.
Разберем, как это работает:
При такой настройке при попытке выбрать значение отбора у пользователя вместо огромного иерархического справочника откроется лаконичный выпадающий список, содержащий исключительно предопределенные вами группы. Это полностью исключит любые ошибки ввода и сделает интерфейс отчета максимально дружелюбным.
Мы детально рассмотрели четыре различных подхода к решению проблемы выбора элементов вместо групп в отборах СКД. Для большинства стандартных отчетов идеальным выбором будет Способ 1 благодаря своей простоте реализации. Если же требуется динамика и максимальная гибкость интерфейса, рекомендуем использовать Способ 2 с программным изменением свойств элементов на клиенте управляемой формы.