Как программно настроить условное оформление для дополнительных реквизитов в динамическом списке 1С

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

Анализ проблемы: почему оформление не работает

Разберем типичный пример. Программист пытается добавить элемент условного оформления для колонки СуммаОплаты, основываясь на значении дополнительного реквизита «Отправка». На первый взгляд код выглядит логично:

Элемент = Список.УсловноеОформление.Элементы.Добавить();

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

Элемент.Оформление.УстановитьЗначениеПараметра("ЦветФона", WebЦвета.СветлоГрифельноСиний);

ОформляемоеПоле = Элемент.Поля.Элементы.Добавить();
ОформляемоеПоле.Поле = Новый ПолеКомпоновкиДанных("СуммаОплаты");

Проблема заключается в том, что дополнительные реквизиты в конфигурациях на базе БСП (Бухгалтерия, ERP, УТ 11) имеют тип ПланВидовХарактеристикСсылка.ДополнительныеРеквизитыИСведения, а их значения хранятся как ссылки на справочник ЗначенияСвойствОбъектов. Когда мы указываем в ПравоеЗначение простую строку "Почтой", система сравнивает Ссылку со Строкой. Результат такого сравнения всегда будет ложным, и оформление не применится.

Правильная типизация данных в отборе

Для того чтобы условное оформление сработало, в правой части условия необходимо передать объект того же типа, который хранится в базе. В случае с дополнительными реквизитами типа «Дополнительное значение» нам нужно найти ссылку в справочнике ЗначенияСвойствОбъектов. Проанализируем исправленный вариант установки значения:

// Вместо строки используем поиск ссылки
ЗначениеОтбора = Справочники.ЗначенияСвойствОбъектов.НайтиПоНаименованию("Почтой");

ОтборЭлемента.ПравоеЗначение = ЗначениеОтбора;

Важный момент: если значение является предопределенным или часто используемым, безопаснее использовать метод ПредопределенноеЗначение(), чтобы избежать проблем при случайном переименовании элемента пользователем.

Особенности обращения к полям с пробелами и спецсимволами

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

1. Использование квадратных скобок: Если вы обращаетесь к полю напрямую, рекомендуется обрамлять его имя в квадратные скобки: Новый ПолеКомпоновкиДанных("[Ссылка.Отправка (Список заказов клиентов)]"). Это гарантирует, что пробелы и скобки внутри имени не будут восприняты как синтаксическая ошибка.
2. Изменение запроса динамического списка: Это более профессиональный и производительный метод. Вместо обращения «через точку» от ссылки, мы можем добавить левое соединение с таблицей дополнительных реквизитов в самом тексте запроса списка.

Рассмотрим пример настройки запроса для оптимизации оформления:

ВЫБРАТЬ
    Заказ.Ссылка КАК Ссылка,
    Заказ.Номер КАК Номер,
    ЕСТЬNULL(ДопСвойства.Значение, ЗНАЧЕНИЕ(Справочник.ЗначенияСвойствОбъектов.ПустаяСсылка)) КАК СпособОтправки
ИЗ
    Документ.ЗаказКлиента КАК Заказ
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДополнительныеСведения КАК ДопСвойства
        ПО ДопСвойства.Объект = Заказ.Ссылка
        И ДопСвойства.Свойство = &СвойствоОтправка

Теперь в условном оформлении мы можем использовать простое и понятное поле СпособОтправки, что значительно упростит код и повысит скорость работы списка.

Производительность и ограничения

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

• Проблема N+1: Когда мы обращаемся к дополнительным реквизитам через точку от ссылки (как в первом примере), платформа может выполнять отдельный запрос к базе данных для каждой отрисовываемой строки. На больших списках это приведет к заметным «тормозам» интерфейса. Использование прямого запроса (как описано выше) решает эту проблему.
• Проверка на NULL: Дополнительные реквизиты могут быть не заполнены. В этом случае значением будет NULL или Неопределено. Проанализируйте логику вашего отбора: если вам нужно оформлять только заполненные поля, добавьте дополнительное условие ВидСравненияКомпоновкиДанных.Заполнено.
• Обновление формы: Иногда после программного изменения настроек оформления требуется вызвать метод Элементы.Список.Обновить(), чтобы форсировать перерисовку данных на экране пользователя.

Альтернативный подход: Событие ПриПолученииДанныхНаСервере

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