Как отключить контроль реквизитов в 1С

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

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

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

Как устроен контроль реквизитов в платформе 1С

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

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

Кроме того, в конфигурациях на БСП действует подсистема «Свойства» и механизм обязательных реквизитов в некоторых прикладных объектах, а также проверки на уровне бизнес-логики — например, контроль контрагентов или проверка заполнения табличных частей при проведении.

Способ 1. Отключение проверки через конфигуратор

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

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

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

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

Способ 2. Программный обход проверки при записи

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

Установка свойства ОбменДанными.Загрузка = Истина перед записью отключает большинство проверок: платформа не вызывает обработчики проверки заполнения и не выполняет стандартные контроли. Объект записывается «как есть».

ОбъектСправочника = Справочники.Контрагенты.СоздатьЭлемент();
ОбъектСправочника.Наименование = "Тестовый контрагент";
ОбъектСправочника.ОбменДанными.Загрузка = Истина;
ОбъектСправочника.Записать();

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

Способ 3. Переопределение процедуры ОбработкаПроверкиЗаполнения

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

При доработке через расширение можно использовать аннотацию &ИзменениеИКонтроль или &Вместо, чтобы исключить конкретную проверку. Внутри процедуры ненужный реквизит добавляется в массив непроверяемых реквизитов:

&Вместо("ОбработкаПроверкиЗаполнения")
Процедура Расш1_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
	Непроверяемые = Новый Массив;
	Непроверяемые.Добавить("Комментарий");
	ОбщегоНазначения.УдалитьНепроверяемыеРеквизитыИзМассива(ПроверяемыеРеквизиты, Непроверяемые);
КонецПроцедуры

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

Как выбрать подходящий способ

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

Проверка результата и типичные ошибки

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

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

Часто задаваемые вопросы