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

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

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

Ниже разобраны все рабочие варианты — от простейшего свойства до условной проверки в коде, а также способы проверить результат и типичные ошибки, из-за которых проверка «не срабатывает».

Способ 1. Свойство «Проверка заполнения» в конфигураторе

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

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

У свойства четыре значения. «Не проверять» — контроль отключён. «Выдавать ошибку» — запись или проведение блокируется, пользователь видит сообщение о незаполненном поле. «Выдавать предупреждение» — объект записывается, но пользователь получает уведомление (подходит для мягкого переходного периода). «Использовать как есть» — наследуется поведение по умолчанию.

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

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

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

Когда обязательность зависит от условий — вида операции, статуса, значения другого поля — простого свойства недостаточно. В этом случае используется обработчик модуля объекта «ОбработкаПроверкиЗаполнения», где можно описать любую логику.

Обработчик получает два параметра: «Отказ» (если установить в Истина, запись блокируется) и «ПроверяемыеРеквизиты» (массив имён реквизитов, которые платформа проверит стандартно). Из этого массива можно удалить реквизит, чтобы отключить типовую проверку, или проверить поле вручную и вызвать сообщение об ошибке.

Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)

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

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

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

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

Способ 3. Обязательность на уровне формы без изменения модуля объекта

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

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

Способ 4. Расширение конфигурации для типовых решений

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

Создайте расширение (Конфигурация → Расширения конфигурации → Создать), заимствуйте нужный документ или справочник, добавьте в его модуль объекта обработчик с аннотацией «&После» или «&Вместо» и разместите там свою проверку. Для управляемых форм можно также заимствовать форму и установить свойство «АвтоотметкаНезаполненного» у элемента, чтобы поле визуально подчёркивалось красным.

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

Способ 5. Настройки в пользовательском режиме без конфигуратора

В типовых конфигурациях на базе Библиотеки стандартных подсистем часть задач решается без программирования. Механизм «Групповое изменение реквизитов» позволяет массово заполнить пустые поля в уже существующих данных перед включением контроля. А подсистема запрета редактирования реквизитов («Объекты с заблокированными реквизитами») заставляет пользователя осознанно подтверждать изменение ключевых полей.

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

Как проверить, что обязательность работает

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

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

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

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

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

Частые вопросы