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

← На главную

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

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

Почему не подходят стандартные решения?

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

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

Решение 1: Использование независимого регистра сведений

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

Шаг 1. Создание регистра
Создадим новый непериодический независимый регистр сведений, назовем его УточнениеОбъектов. В качестве измерения добавим ссылку на наш документ (или справочник), а ресурс можно оставить пустым или добавить информацию об авторе.

Шаг 2. Запись в регистр при автозаполнении
Если алгоритм автоподстановки при создании заявки сработал неоднозначно (найдено несколько вариантов детали), программно добавляем запись в этот регистр сведений.

Шаг 3. Программная раскраска в Обычных Формах (ОФ)
Поскольку мы работаем в обычных формах, условное оформление недоступно, поэтому будем управлять цветом программно. В обработчике события ПриОткрытии проверим наличие записи в нашем регистре. Если запись есть, меняем цвет фона:


Процедура ПриОткрытии()
    // Функция проверки наличия записи в регистре
    Если ТребуетсяУточнениеОбъекта(ЭтотОбъект.Ссылка) Тогда
        ЭлементыФормы.Объект.ЦветФона = WebЦвета.СветлоЖелтый;
        Сообщить("Внимание! Необходимо уточнить реквизит 'Объект'!");
    КонецЕсли;
КонецПроцедуры

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


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

Решение 2: Альтернативные механизмы (Задачи и Доп. свойства)

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

1. Механизм дополнительных сведений (Свойства объектов)
Во многих типовых конфигурациях есть встроенный механизм дополнительных реквизитов и сведений. Вместо своего регистра можно использовать типовой регистр ЗначенияСвойствОбъектов. Достаточно программно назначить документу дополнительное свойство "Требует уточнения", а при ручном изменении поля — удалять это свойство.

2. Механизм бизнес-процессов и задач
С точки зрения процессного подхода логичнее использовать "Задачи". Когда оператор колл-центра создает заявку с неоднозначным объектом, система формирует задачу выездному мастеру: "Уточнить тип неисправной детали в Заявке №...". Мастер открывает задачу, указывает деталь, и она автоматически переносится в документ, а задача закрывается. Это избавляет от необходимости "раскрашивать" интерфейс и минимизирует риск того, что мастер просто проигнорирует подсветку.

Надежность решения: Контроль при записи и проведении

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

Добавим контроль в модуль объекта в процедуру ОбработкаПроверкиЗаполнения или ПередЗаписью (если статус документа меняется на "Выполнен"). Если статус финальный, а запись в регистре УточнениеОбъектов всё ещё существует, система должна выдать Отказ = Истина и не дать провести документ. Также, для надежности, удаление записи из регистра лучше выполнять не только при изменении поля на форме, но и через подписку на событие ПередЗаписью, сравнивая старое значение реквизита с новым. Если значение изменилось, регистр очищается гарантированно, даже если изменение произошло групповой обработкой.