Как программно проверить значение дополнительного реквизита в модуле объекта 1С:ЗУП 3.1

← На главную

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

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

Почему табличная часть «Дополнительные реквизиты» может быть пустой

Проанализируем механику работы БСП. В управляемых формах дополнительные реквизиты не связаны напрямую с табличной частью объекта ДополнительныеРеквизиты в режиме реального времени. Они создаются на форме программно как динамические свойства. Когда пользователь вводит данные в эти поля, они хранятся в памяти формы.

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

Решение 1: Использование штатных возможностей БСП (без программирования)

Прежде чем приступать к написанию кода, выясним причину, по которой может подойти стандартный механизм. В ЗУП 3.1 предусмотрена гибкая настройка дополнительных реквизитов в пользовательском режиме.

Перейдем в раздел Администрирование — Общие настройки — Дополнительные реквизиты и сведения.
Найдем наш реквизит для документа ПриемНаРаботу.
В карточке реквизита обратим внимание на флажок Заполнять обязательно.
Самое важное: здесь можно настроить условие. Например, «Заполнять обязательно, если РаботаДистанционно = Истина».
Также можно настроить Видимость и Доступность. Если мы установим видимость реквизита только при условии дистанционной работы, пользователь физически не сможет заполнить его для обычного сотрудника.

Этот способ является приоритетным, так как он не требует снятия конфигурации с поддержки и корректно обрабатывается типовыми механизмами проверки заполнения.

Решение 2: Программная проверка в модуле объекта через механизмы БСП

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

Для гарантированного получения значения дополнительного реквизита в контексте объекта (даже если ТЧ еще не заполнена привычным способом) рекомендуется использовать функцию УправлениеСвойствами.ЗначениеСвойства. Проанализируем пример кода, который можно разместить в процедуре ПередЗаписью или ОбработкаПроверкиЗаполнения:


Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    
    Если ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;

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

КонецПроцедуры

В данном примере мы используем ОбщегоНазначенияКлиентСервер.СообщитьПользователю, передавая параметр Отказ. Это позволяет не только вывести предупреждение, но и заблокировать запись объекта, если условие нарушено.

Решение 3: Вызов типовой проверки заполнения свойств

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

Разберем, как это реализовать в процедуре ОбработкаПроверкиЗаполнения:


Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    
    // Вызываем стандартную проверку дополнительных реквизитов БСП
    // Она проверит все условия 'Заполнять обязательно', настроенные пользователем
    УправлениеСвойствами.ПроверитьЗаполнениеДополнительныхРеквизитов(ЭтотОбъект, Отказ);
    
    // Здесь же можно добавить свою специфическую проверку, которой нет в настройках
    // ...
    
КонецПроцедуры

Важный нюанс: Проверка в ОбработкаПроверкиЗаполнения выполняется перед началом транзакции записи. Это «экологичный» способ проверки, который не нагружает базу данных лишними откатами транзакций. Однако помните, что эта процедура вызывается только при интерактивном проведении или при явном вызове метода ПроверитьЗаполнение().

Сводная таблица методов проверки

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

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

Выясним причину, почему автор темы на форуме сомневался в ПередЗаписью. Его беспокоило нахождение внутри транзакции. В современных реалиях 1С и мощностей серверов, простая проверка одного значения не вызовет проблем с производительностью. Если проверка критична для целостности данных — смело используйте ПередЗаписью в расширении модуля объекта.

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