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