Зачем нужна проверка заполнения у реквизитов справочника 1С

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

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

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

Что именно контролирует проверка заполнения

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

Платформа проверяет не только «пусто / не пусто» визуально. Для строки пустым считается значение без символов (строка из одних пробелов при этом может пройти проверку — это частая причина «мусорных» данных). Для чисел пустым считается ноль, для дат — пустая дата, для ссылок — пустая ссылка соответствующего типа. Это важно учитывать: если бизнес-смысл требует ненулевой цены или корректной даты, стандартной проверки заполнения достаточно, а вот проверку «цена больше нуля» или «ИНН содержит 10 или 12 цифр» придётся реализовывать отдельно.

Почему именно справочники нуждаются в контроле в первую очередь

Справочник — это источник данных для других объектов. Документ «Реализация товаров» ссылается на контрагента, договор, номенклатуру и склад. Если в карточке номенклатуры не заполнена ставка НДС, ошибка возникнет уже в документе, и исправлять её придётся в момент проведения, когда менеджер ждёт накладную. Контроль на уровне справочника смещает исправление на момент ввода данных, когда ничего не горит.

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

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

Какие реквизиты делать обязательными

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

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

Условная обязательность

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

Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
	Если ЮрФизЛицо = Перечисления.ЮрФизЛицо.ЮрЛицо Тогда
		ПроверяемыеРеквизиты.Добавить("ИНН");
	Иначе
		Индекс = ПроверяемыеРеквизиты.Найти("ИНН");
		Если Индекс <> Неопределено Тогда
			ПроверяемыеРеквизиты.Удалить(Индекс);
		КонецЕсли;
	КонецЕсли;
КонецПроцедуры

Как настроить проверку заполнения: порядок действий

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

Если нужна условная логика или проверка не только заполненности, но и корректности значения (формат ИНН, диапазон дат, уникальность по комбинации полей), добавьте обработчик ОбработкаПроверкиЗаполнения в модуль объекта. Внутри обработчика можно управлять массивом ПроверяемыеРеквизиты и выдавать собственные сообщения через объект СообщениеПользователю с установкой Отказ = Истина.

1. 1
   Определите список критичных реквизитов: те, без которых ломаются документы, отчёты или обмены
2. 2
   В конфигураторе установите для них «Проверка заполнения» = «Выдавать ошибку»
3. 3
   Для желательных полей установите «Выдавать предупреждение»
4. 4
   Для условной обязательности добавьте логику в ОбработкаПроверкиЗаполнения
5. 5
   Обновите конфигурацию БД и проверьте запись элемента с пустым и заполненным реквизитом
6. 6
   Проверьте существующие элементы: обработкой найдите записи с пустыми обязательными реквизитами и запланируйте их дозаполнение

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

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

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

Ограничения и альтернативы

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

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

FAQ: частые вопросы о проверке заполнения