Условное оформление в 1С: настройки или код — как выбрать подход

Перед разработчиком 1С стоит задача: сделать поле видимым только для определённых ролей, подсветить просроченные строки красным, скрыть реквизит до проведения документа. У платформы есть минимум четыре инструмента для этого — и каждый хорош в своём сценарии. Ошибка в выборе ведёт к раздутому коду, потере гибкости или нарушению безопасности.

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

Платформа 1С:Предприятие 8.3 предлагает четыре инструмента для управления оформлением формы, которые делятся на две группы по признаку «кто создаёт правило»:

Со стороны разработчика — через конфигуратор (используются все правила сразу для всех):

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

Со стороны пользователя — через пользовательский интерфейс (персонально под себя):
4. Пользовательский интерфейс — настройка через диалог.

С точки зрения выбора все четыре инструмента группируются в три варианта:

• В1 · Пользовательский режим (инструмент 4) — пользователь меняет оформление сам, через интерфейс 1С:Предприятие.
• В2 · Конфигуратор, без кода (инструмент 1) — разработчик настраивает через палитру свойств, ни строки на встроенном языке 1С.
• В3 · Код в конфигураторе (инструменты 2 и 3) — разработчик дорабатывает конфигурацию на встроенном языке 1С: либо программной настройкой УсловноеОформление, либо прямым изменением свойств элемента.

Какой бы ни была ваша задача — к концу статьи вы сможете ответить на вопрос «какой вариант выбрать» за 30 секунд, сверившись со схемой выбора.

Рассмотрим каждый вариант подробно:

1. Конфигуратор: настройка через палитру свойств (без кода)

Условное оформление — встроенный механизм платформы, позволяющий задать правила изменения свойств элементов формы без единой строки кода. Правила описываются на уровне формы и исполняются платформой автоматически. Всё, что описано в этом разделе, настраивается в конфигураторе, через палитру свойств — и не требует написания кода на встроенном языке 1С.

1.1. Где находится:

Откройте форму в конфигураторе. В палитре свойств формы найдите закладку «Условное оформление» (или через меню «Форма → Условное оформление»).

1.2. Структура правила

Каждое правило состоит из трёх частей:

• Оформление — какие свойства меняем (видимость, доступность, цвет фона, цвет текста, шрифт и др.)
• Условие — когда применяем (может быть полем формы, отбором или параметром)
• Оформляемые поля — к каким элементам применяем (поля, колонки таблицы, группы и т.д.)

1.3. Пример: скрыть поле для непроведённого документа

Без кода, через условное оформление:

Параметр	Значение
Оформляемое поле	Номер
Свойство	Видимость = Ложь
Условие (поле)	Проведён = Ложь

Результат: после проведения документа поле Номер появляется, до — скрыто.

1.4. Типы условий

• Поле — значение реквизита формы (например, Объект.Статус = «Утверждён»)
• Отбор — для табличных полей (фильтр по колонке)
• Параметр — значение произвольного параметра, заданное программно или через настройки
• Свойство — системное свойство (например, ДоступностьПроведения)

Порядок правил имеет значение: они применяются сверху вниз. Если два правила затрагивают одно и то же свойство одного поля — будет применено правило, находящееся ниже в списке (применяется последним).

1.5. Когда использовать

• Простые зависимости «значение поля → свойство элемента»
• Несколько условий на одно поле (списком правил)
• Стандартные сценарии видимости/доступности/цвета
• Проекты, где важна скорость разработки и минимум кода
• Можно оформить сразу несколько полей, группу или всю таблицу — все выбранные элементы получат одинаковое оформление

1.6. Ограничения

• Нельзя вычислить сложное условие на встроенном языке (только сравнение или отбор).
• Можно менять только свойства, доступные в дереве оформления: Видимость, Доступность, ЦветФона, ЦветТекста, Шрифт и т.д. Свойства вроде Подсказка или Картинка недоступны.
• Поведение фиксировано на этапе проектирования (нельзя поменять правило динамически).
• Отладка правил затруднена: нет точки останова на условном оформлении.
• Производительность: не следует использовать условное оформление для скрытия строк таблицы целиком — строки физически остаются в данных, но скрываются на клиенте. Веб-клиент начинает тормозить, а при больших списках появляются артефакты отображения. Скрытие строк делайте через отбор динамического списка.
• Выбор между формой и динамическим списком: если задача может быть решена как через условное оформление динамического списка, так и через условное оформление формы — выбирайте первый вариант. Он несколько ускоряет открытие формы.

2. Условное оформление динамического списка

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

2.1. Где находится

Выберите динамический список на форме. В палитре свойств найдите закладку «Условное оформление» — она находится в свойствах динамического списка, а не формы.

2.2. Чем отличается от условного оформления формы

Характеристика	УО формы	УО динамического списка
Уровень применения	Элементы формы (поля, группы, кнопки)	Строки и колонки таблицы
Что можно красить	Фон, текст, шрифт, видимость, доступность	Фон, текст, шрифт, цвет строки целиком
Работает с отбором	Да (как условие)	Да (как условие + отбор для таблицы)
Оформление всей строки	Нет (только по колонкам)	Да (можно выделить строку целиком)
Производительность	Вычисляется на клиенте	Вычисляется на сервере при подготовке строк
Момент применения	После открытия формы	До отображения данных (при получении строк)

2.3. Преимущества

• Скорость: условное оформление динамического списка не замедляет открытие формы — оно применяется на сервере в момент чтения данных
• Оформление строки целиком: можно покрасить всю строку по условию на любой колонке, не привязываясь к конкретному элементу
• Работа с отборами: условие может использовать отбор по любой колонке, включая поля, которые не выведены на форму
• Исполнение при получении данных: не требует загрузки всех строк на клиент — платформа применяет правила по мере загрузки данных

2.4. Пример: раскраска строк по статусу документа

Сделать строки «Заказов поставщикам» цветными по статусу — без единой строки кода:

Параметр	Значение
Оформление	ЦветФона = Зелёный
Условие	Статус = Не согласован
Оформляемые поля	(пусто — применяется ко всей строке)

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

• Никакого кода не написано
• Форма открывается с той же скоростью, что и без оформления
• Строки окрашены уже в момент появления списка на экране (нет мигания)

2.5. Когда выбирать

• Список (документов, справочников, записей регистра) должен быть цветным по данным
• Нужно окрасить всю строку, а не отдельную колонку
• Критична скорость открытия формы
• Достаточно простых условий сравнения

2.6. Ограничения

• Работает только с динамическими списками (не для обычных табличных полей с программным заполнением)
• Нельзя менять видимость/доступность отдельных колонок — только цвет, фон, шрифт
• Не влияет на элементы формы за пределами таблицы (шапка, команды, кнопки)
• Условия — только сравнение/отбор, как и у формы
• При выборе между условным оформлением формы и условным оформлением динамического списка для таблицы — всегда используйте условное оформление списка. Условное оформление формы для таблицы: привязывает условие к реквизитам через конструкцию уровня формы, не позволяет покрасить строку целиком, требует дублирования правила на каждую новую колонку

Если условий сравнения недостаточно или правила должны динамически меняться — условное оформление динамического списка тоже можно настраивать в коде через объект УсловноеОформление.

3. Пользовательский подход: настройка через интерфейс 1С:Предприятие

Платформа предоставляет пользователям возможность самостоятельно настраивать условное оформление прямо в режиме работы — без участия разработчика и без изменения конфигурации.

3.1. Как это выглядит для пользователя

В форме с табличным полем или динамическим списком пользователь открывает «Ещё → Настроить список...» и переходит на вкладку «Условное оформление». Пользователь видит диалог, где может создавать свои правила: указать условие, выбрать оформляемые поля и задать цвет/видимость. Созданные правила применяются сразу и отображаются в форме.

3.2. Механизм работы

Пользовательские правила хранятся не в конфигурации, а в хранилище настроек. Каждое правило содержит:

• Оформляемые поля — перечень элементов формы и их колонок
• Условие — отбор по реквизитам формы (один уровень вложенности, сравнение)
• Оформление — ЦветФона, ЦветТекста, Шрифт (жирный/наклонный/подчёркнутый), Видимость, Доступность

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

3.3. Примеры использования пользователем

• Бухгалтер настраивает подсветку строк с отрицательной суммой красным в отчёте
• Менеджер выделяет жирным шрифтом заказы со статусом «Срочный»
• Кладовщик скрывает колонки с ценами в таблице товаров
• Оператор задаёт цвет фона для просроченных задач в списке

3.4. Взаимодействие с оформлением разработчика

Пользовательские правила применяются поверх правил, заданных разработчиком. Если пользователь изменил цвет поля — его настройка перекроет цвет, заданный в конфигураторе и/или программно. Платформа применяет правила в порядке приоритета:

1. Условное оформление конфигуратора (без кода)
2. Программное изменение свойств в коде
3. Пользовательское условное оформление (наивысший приоритет)

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

3.5. Когда использовать

Подход ориентирован на такие сценарии:

• Типовые конфигурации, где нет доступа к коду (через расширение)
• Гибкая адаптация формы под персональные предпочтения
• Быстрая реакция на изменение бизнес-требований без обновления конфигурации
• Отчёты и динамические списки, где пользователь часто меняет критерии

3.6. Ограничения

3.7. Как выбирать между подходами

Всего есть три варианта: вариант 1 - В1 (Пользовательский режим), вариант 2 - В2 (Конфигуратор, без кода), вариант 3 - В3 (Код в конфигураторе). Первый — со стороны пользователя, второй и третий — со стороны разработчика. Главный вопрос при выборе — кто и когда создаёт правило.

3.7.1. Главный принцип: кто должен управлять правилом?

Задайте себе два вопроса:

Вопрос 1. Это правило жёсткое или гибкое?

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

Вопрос 2. Правило действует на всех пользователей или на одного?

• Если скрыть поле надо для всех бухгалтеров — делайте в конфигураторе
• Если каждый пользователь сам решает, что ему видеть — отдайте настройку ему

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

• Бизнес-логика учёта: поле «Сумма» должно быть видимым только после «Утверждён»
• Единые правила для всей организации: подсветка просрочки, блокировка при статусе
• Простота: правило нужно быстро, в 1–3 формах, без планов на переиспользование

Когда то же самое лучше делать через код: если то же правило нужно в более 5 формах — вынесите его в УсловноеОформление через общий модуль. Если нужна проверка ролей или сложное условие — используйте прямое изменение свойств.

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

3.7.3. Когда выбирать пользовательские настройки

• Личные предпочтения: выделить свои задачи жирным, скрыть неиспользуемые колонки
• Адаптация под специфику рабочего места: кладовщику нужны одни колонки, менеджеру — другие
• Быстрая реакция без обновления: бизнес попросил подсветку завтра — не надо ждать релиза
• Типовые конфигурации на поддержке: нет права менять форму, а расширение писать долго

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

3.7.4. Когда выбирать доработку через УсловноеОформление

Этот подход — доработка форм через написание кода в конфигураторе. Используйте его, когда:

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

Не используйте для уникальной логики, серверных вызовов, сложных условий — это задача для прямого изменения свойств (раздел 4.2).

3.7.5. Критерии выбора

3.8. Настройка оформления интерактивно в конфигураторе vs доработка через УсловноеОформление

Оба подхода делают одно и то же — создают правила условного оформления — но разными средствами:

Правило: если правило нужно в 1–3 формах и не планируется меняться — делайте в конфигураторе. Если правило повторяется в 5+ формах или нужно централизованное управление — выносите в код через УсловноеОформление.

3.9. Практическое правило

Если правило однажды сформулировал бизнес-аналитик и оно не меняется месяцами — закладывайте в конфигуратор. Если правило меняется каждую неделю или зависит от человека — отдайте пользователю.

В сомнительной ситуации выбирайте конфигуратор: разработчик всегда может удалить правило из конфигуратора, а пользователь — переопределить его через свой интерфейс. Обратное неверно: если правило не заложено в конфигуратор, пользователь не сможет его там добавить.

4. Программный подход: код на встроенном языке 1С

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

Какой выбрать: если условие описывается простым сравнением — используйте способ A (УсловноеОформление в коде). Если нужна уникальная логика, серверный вызов, внешние данные — способ B.

4.1. Способ A: программная настройка через УсловноеОформление (стандарт 1С)

Платформа позволяет создавать и изменять правила условного оформления программно — через объект УсловноеОформление. Стандарты 1С рекомендуют именно этот способ вместо настройки правил в палитре свойств формы.

Преимущества настройки через код:

• Переиспользование: одинаковые правила можно вынести в общий модуль и применить к десяткам форм одной процедурой
• Объединение/обновление конфигураций: при сравнении и объединений код объединяется проще
• Контроль ошибок: при переименовании реквизита проверка кода модуля поймает ошибку, ошибка при настройке в палитре свойств ошибка проявится только во время работы программы

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

В этом примере:

• УсловноеОформление — встроенный объект формы, доступный на сервере
• Элементы — коллекция правил, Поля — коллекция оформляемых полей
• Отбор — коллекция условий (поддерживает группы И/ИЛИ)
• Оформление — параметры оформления (цвета, шрифт, отметка незаполненного)
• Объединение условий в группы И/ИЛИ выполняется через ГруппаЭлементовОтбораКомпоновкиДанных.

4.1.1. Программная настройка условного оформления динамического списка

Тот же механизм применим и к динамическим спискам. Объект УсловноеОформление доступен через реквизит динамического списка:

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

4.2. Способ B: Прямое изменение свойств элементов

Когда условие не укладывается в механизм УсловноеОформление (сложные вычисления, серверные вызовы, внешние данные) — свойства элементов устанавливаются напрямую, в обработчиках событий формы.

4.2.1. Пример: подсветка просроченной задачи

4.3. Когда использовать (для обоих способов)

• Сложные условия, не сводимые к простым сравнениям
• Динамическая смена логики на форме (зависит от внешних данных)
• Изменение свойств, недоступных в условном оформлении конфигуратора
• Многоуровневая логика с комбинацией ролей, времени, внешних данных

5. Комбинированный подход

Оптимальная архитектура формы часто сочетает все три варианта:

• В2 · Конфигуратор (без кода) — обязательные правила учёта и безопасности (Видимость по ролям, Доступность по статусу). Быстро, наглядно, без строки на встроенном языке 1С
• В3 · Код в конфигураторе — два технических способа:
  • УсловноеОформление в коде (раздел 4.1) — когда правило повторяется в 5+ формах или нужно централизованно менять
  • Прямое изменение свойств (раздел 4.2) — уникальная логика, сложные вычисления, серверные вызовы, внешние данные
• В1 · Пользовательский режим — индивидуальная адаптация формы (персональные цвета, скрытие колонок)

Правило выбора:

1. Может ли пользователь сам решать, применять правило или нет? Да → В1 · Пользовательский режим
2. Простое сравнение, одинаково для всех, нужно в 1–3 формах? Да → В2 · Конфигуратор (без кода)
3. Простое сравнение, 5+ форм или централизованное управление? Да → В3 · Код в конфигураторе — через УсловноеОформление
4. Сложная логика, серверный вызов или недоступные свойства? Да → В3 · Код в конфигураторе — прямым изменением свойств

Перед тем как добавлять очередное правило условного оформления, пройдите по дереву — это займёт 30 секунд, но спасёт от запутанной архитектуры.

5.1. Пример комбинирования

Документ «Заявка на расходование средств»:

• Конфигуратор (интерактивно в палитре свойств): поле «Сумма» скрыто, пока статус не равен «Черновик» (общее правило)
• Пользователь: бухгалтер настроил подсветку заявок старше 3 дней жёлтым (личное)
• Программно: кнопка «Утвердить» видна только если текущий пользователь — руководитель подразделения (проверка на сервере)

5.2. Сравнительная таблица

Мы разобрали три подхода к условному оформлению форм в 1С: через конфигуратор, через пользовательский интерфейс и программно — и подробно сравнили два бескодовых метода.

Главный вывод: каждое правило условного оформления должно лежать в том слое, где его проще всего поддерживать. Бизнес-ограничения и политики безопасности — в конфигураторе. Личные предпочтения и адаптация под роль — в пользовательских настройках. Сложная логика, проверка ролей, внешние данные — в коде.

Ключевое различие конфигуратора и пользовательского интерфейса:

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