Валидация в 1С: что это и как работает проверка данных

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

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

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

Что такое валидация в контексте 1С

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

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

Какие проверки платформа выполняет автоматически

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

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

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

Проверка заполнения: настройка без программирования

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

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

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

Программная валидация: обработчик ОбработкаПроверкиЗаполнения

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

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

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

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

1. 1
   Откройте модуль объекта в конфигураторе и добавьте обработчик ОбработкаПроверкиЗаполнения
2. 2
   Опишите условие ошибки и вызовите СообщитьПользователю с указанием имени реквизита
3. 3
   Установите Отказ = Истина через параметр метода сообщения
4. 4
   Проверьте интерактивно: запись с нарушением должна блокироваться, сообщение — вести к нужному полю
5. 5
   Проверьте программную запись и обмен: обработчик должен срабатывать и при загрузке данных

Валидация на уровне формы и при вводе

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

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

Хорошая практика — двухуровневая схема: быстрые подсказки на клиенте (формат, обязательность), строгая проверка на сервере в ОбработкаПроверкиЗаполнения. Клиентская проверка улучшает удобство, серверная гарантирует целостность данных независимо от способа записи.

Валидация при обмене и загрузке данных

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

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

Типичные ошибки при реализации валидации

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

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

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

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

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

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