ОбработкаПроверкиЗаполнения в 1С: когда вызывается и как использовать

ОбработкаПроверкиЗаполнения — это событие модуля объекта (справочника, документа, плана счетов и других прикладных объектов), которое платформа 1С вызывает автоматически при записи объекта в базу данных. Его назначение — проверить, что обязательные реквизиты заполнены, а значения не противоречат бизнес-логике, и при необходимости отказать в записи.

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

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

В какие моменты платформа вызывает обработчик

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

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

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

Порядок событий при записи объекта

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

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

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

Стандартная проверка и массив ПроверяемыеРеквизиты

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

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

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

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

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

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

При выводе ошибки по строке табличной части важно правильно сформировать путь к данным, чтобы платформа подсветила именно ту ячейку, где проблема. Для этого используется обобщенный путь вида «Объект.Товары[Индекс].Номенклатура».

Для Каждого Строка Из Товары Цикл
	Если Строка.Количество = 0 Тогда
		Поле = "Товары[" + Формат(Товары.Индекс(Строка), "ЧГ=") + "].Количество";
		ОбщегоНазначения.СообщитьПользователю(
			"В строке " + Строка.НомерСтроки + " не указано количество",
			ЭтотОбъект, Поле, "Объект", Отказ);
	КонецЕсли;
КонецЦикла;

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

Отличия для формы объекта и кода на клиенте

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

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

Типичные ошибки при работе с обработчиком

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

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

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

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

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

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

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