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