Как проверить поле "Сумма" по виду документа в 1С:Документооборот через расширение?

Часто при доработке конфигураций возникает задача: запретить запись документа, если не заполнено определенное поле, но только для конкретных видов документов. Проанализируем ситуацию: в 1С:Документооборот 8 КОРП 2.1 при создании внутреннего документа нужно проверять реквизит Сумма. Если сумма равна нулю для вида документа «Закупочная документация», система должна выдавать ошибку и прерывать запись. При этом доработка ведется через расширение, чтобы не снимать конфигурацию с поддержки.

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

Ошибка поиска по наименованию: почему условие не работает?

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

СтрокаНаименования = "Заявка на закупку";
ИскомыйВидДокумента = Справочники.ВидыВнутреннихДокументов.НайтиПоНаименованию(СтрокаНаименования);

Если Сумма = 0 и ВидДокумента = ИскомыйВидДокумента Тогда 
    Сообщить("Сумма равна " + Сумма + ". Запись невозможна!");
    Отказ = Истина;
КонецЕсли;

На первый взгляд, код кажется логичным. Однако при выполнении условие ВидДокумента = ИскомыйВидДокумента часто возвращает ложь, даже если визуально в отладчике значения совпадают. Выясним причину такого поведения.

Метод НайтиПоНаименованию имеет серьезные недостатки при использовании в бизнес-логике:

1. Дубли в справочнике. Если пользователи случайно создадут второй вид документа с точно таким же именем (или пометят один на удаление и создадут новый), система найдет первый попавшийся элемент. Ссылка найденного элемента не будет совпадать с той, что выбрана в документе.
2. Изменение наименования. Пользователь может переименовать вид документа (например, добавить пробел, изменить регистр или переименовать в "Заявка на закупку (новая)"). Код сразу же перестанет работать.
3. Возврат пустой ссылки. Если элемент не найден, метод возвращает не Неопределено и не булево значение, а пустую ссылку: СправочникСсылка.ВидыВнутреннихДокументов.ПустаяСсылка. Сравнение заполненного реквизита с пустой ссылкой всегда дает ложь.

Именно поэтому поиск элементов по наименованию (так называемый «хардкод») считается плохой практикой.

Правильные архитектурные решения для расширений

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

Способ 1: Использование штатных настроек 1С:Документооборот (Оптимальный)

В типовой конфигурации 1С:Документооборот 2.1 уже заложен богатый функционал параметризации видов документов. Если зайти в карточку «Вид внутреннего документа» в режиме предприятия, можно найти настройку «В документе указывается сумма».

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

Если ВидДокумента.ВестиУчетПоСуммам И Сумма = 0 Тогда
    Сообщить("Для данного вида документа необходимо указать сумму. Запись невозможна!");
    Отказ = Истина;
КонецЕсли;

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

Способ 2: Использование дополнительных реквизитов (Пользовательская настройка)

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

В коде расширения при обработке события перед записью документа останется только программно считать значение этого доп. реквизита. Это делает систему гибкой, а управление проверками полностью передается пользователям или администраторам базы.

Способ 3: Поиск по уникальному идентификатору (GUID)

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

Сначала получите GUID нужного вида документа (например, с помощью внешней обработки или консоли запросов). Затем пропишите его в коде расширения. Разберем пример реализации:

// Получаем ссылку по неизменному GUID
УИД = Новый УникальныйИдентификатор("12345678-1234-1234-1234-1234567890ab");
ИскомыйВидДокумента = Справочники.ВидыВнутреннихДокументов.ПолучитьСсылку(УИД);

Если ВидДокумента = ИскомыйВидДокумента И Сумма = 0 Тогда 
    Сообщить("Сумма равна 0. Запись невозможна!");
    Отказ = Истина;
КонецЕсли;

Важно: этот способ надежен, но при переносе разработки между разными базами (например, из базы разработки в рабочую) убедитесь, что GUID элементов справочника совпадают.

Способ 4: Создание Константы или Регистра сведений в расширении

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

Используя предложенные методы, вы сможете настроить надежную проверку заполнения суммы в 1С:Документооборот, которая будет стабильно работать в расширениях, не ломаясь от действий пользователей в системе.