Как сделать реквизит обязательным для заполнения в расширении 1С

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

Выбор способа зависит от того, где должен срабатывать контроль: только в форме при интерактивном вводе или при любой записи объекта, включая обмены, обработки и загрузку данных. Первый вариант проще и не требует кода, второй надёжнее, но требует аккуратности, чтобы не заблокировать служебные механизмы. Ниже разобраны оба подхода с конкретными шагами, ограничениями и проверкой результата.

Материал ориентирован на конфигурации на управляемых формах (Бухгалтерия 3.0, Управление торговлей 11, ERP, ЗУП 3.1) с режимом совместимости, поддерживающим расширения. Для работы понадобится конфигуратор и права на добавление расширений в информационную базу.

Подготовка: создание расширения и заимствование объекта

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

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

Если планируется проверка на форме, добавьте в расширение и основную форму объекта: правый клик по форме — «Добавить в расширение». Убедитесь, что в свойствах заимствованной формы корректно установлено «Изменение формы» — по умолчанию расширение дополняет типовую форму, а не заменяет её.

Способ 1: свойство «Проверка заполнения» без кода

Самый быстрый вариант — изменить свойство заимствованного реквизита. В дереве расширения откройте реквизиты объекта, найдите нужный и в палитре свойств установите «Проверка заполнения» в значение «Выдавать ошибку». Теперь при записи объекта платформа сама проверит заполненность и откажется сохранять документ или элемент справочника с пустым значением, выведя стандартное сообщение.

Этот способ срабатывает на уровне платформы: контроль выполняется и при интерактивной записи через форму, и при программной записи из обработок, если в них не отключена проверка заполнения. Это одновременно плюс (надёжность) и минус (риск сломать типовые обмены и регламентные загрузки, которые создают объекты без этого реквизита).

Ограничение метода: проверка безусловная. Нельзя штатным свойством задать логику вида «обязателен только если вид операции — списание» или «только для новых документов». Для условного контроля нужен программный способ. Также свойство недоступно для изменения, если реквизит добавлен не в объект, а только на форму типовой доработкой другого расширения.

1. 1
   Создайте расширение и заимствуйте объект (справочник или документ)
2. 2
   Откройте реквизит в дереве расширения и установите «Проверка заполнения» = «Выдавать ошибку»
3. 3
   Обновите конфигурацию базы данных через расширение (F7 или кнопка «Обновить»)
4. 4
   Проверьте в режиме Предприятия: запись с пустым реквизитом должна блокироваться с сообщением об ошибке

Способ 2: программная проверка в ОбработкаПроверкиЗаполнения

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

Пример кода для документа, где реквизит «Комментарий» обязателен при списании:

&После("ОбработкаПроверкиЗаполнения")
Процедура Дор_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
Если ВидОперации = Перечисления.ВидыОпераций.Списание
И Не ЗначениеЗаполнено(Комментарий) Тогда
ТекстСообщения = НСтр("ru = 'Поле ""Комментарий"" не заполнено'");
ОбщегоНазначения.СообщитьПользователю(ТекстСообщения, ЭтотОбъект, "Комментарий", , Отказ);
КонецЕсли;
КонецПроцедуры

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

Альтернативный приём — добавить имя реквизита в массив ПроверяемыеРеквизиты. Тогда платформа сама выполнит стандартную проверку на незаполненность, и писать условие не нужно. Это удобно, когда требуется простая безусловная проверка, но свойство «Проверка заполнения» по какой-то причине недоступно для изменения.

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

Проверка только на форме: события ПередЗаписью и ОбработкаПроверкиЗаполненияНаСервере

Если контроль нужен только при интерактивной работе пользователя, а обмены и фоновые загрузки трогать нельзя, размещайте проверку в модуле формы расширения. Заимствуйте форму объекта и добавьте расширение обработчика &После("ПередЗаписью") на клиенте или серверный обработчик проверки заполнения формы.

В клиентском ПередЗаписью логика проста: если реквизит пуст — вывести предупреждение и установить Отказ = Истина. Такой подход не влияет на программную запись объекта вне формы, что безопасно для интеграций. Обратная сторона — пользователь с доступом к внешним обработкам или групповому изменению реквизитов сможет обойти контроль, поэтому для критичных данных форменной проверки недостаточно.

Практический критерий выбора: если незаполненный реквизит ломает отчёты или проводки — проверяйте в модуле объекта; если это вопрос дисциплины ввода (например, обязательный комментарий при ручном создании) — достаточно формы. Комбинировать оба уровня тоже допустимо: на форме — дружелюбная подсказка, в объекте — жёсткий барьер.

Риски: обмены, обновления и обработчики других расширений

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

Если обмен должен работать без реквизита, добавьте в условие проверки исключение: например, пропускать проверку при ОбменДанными.Загрузка = Истина. Стандартный приём — первой строкой обработчика проверять это свойство параметров объекта и выходить из процедуры, не выполняя контроль.

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

Проверка результата и отладка

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

Проверьте и обратный сценарий: уже существующие объекты с пустым реквизитом должны открываться и перезаписываться либо с понятной ошибкой, либо — если вы настроили условие «только новые» — без блокировки. Непродуманное поведение для старых данных — частая причина жалоб пользователей сразу после внедрения.

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

Типичные ошибки при настройке обязательных реквизитов

Первая ошибка — забыть префикс в имени процедуры-расширения. Процедура с именем, совпадающим с типовой, при обновлении конфигурации приведёт к ошибке применимости расширения. Всегда начинайте имена с префикса расширения.

Вторая — установка Отказ = Истина без сообщения пользователю. Запись блокируется, но пользователь не понимает причину. Всегда парой к отказу выводите сообщение через СообщитьПользователю с привязкой к реквизиту.

Третья — проверка на форме при необходимости контроля в объекте, и наоборот. Это приводит либо к обходу контроля через обработки, либо к падению обменов. Четвёртая — игнорирование режима ОбменДанными.Загрузка: без исключения любая синхронизация начнёт отклонять объекты.

FAQ