Каждый разработчик 1С рано или поздно сталкивается с ситуацией, когда при попытке записать новый элемент справочника или документ система выдает раздражающее сообщение: «Поле не заполнено». При этом визуально на форме все обязательные реквизиты подчеркнуты красным и честно заполнены пользователем. Ситуация становится еще более загадочной, когда существующие элементы базы данных открываются, редактируются и перезаписываются без каких-либо нареканий.
В этой статье мы подробно разберем, почему возникает такое неочевидное поведение платформы «1С:Предприятие», как взаимодействуют стандартные механизмы автонумерации и проверки заполнения, а также рассмотрим эффективные методы диагностики и программные способы решения этой проблемы.
Главная причина подобного поведения кроется во внутреннем механизме валидации стандартных реквизитов (таких как Код у справочников или Номер у документов). Давайте разберем по шагам, что происходит под капотом платформы в момент записи объекта.
Когда мы пытаемся записать элемент, система автоматически инициирует событие проверки заполнения. Поведение платформы кардинально отличается в зависимости от настроек автонумерации:
Код свойство «Проверка заполнения» установлено в значение «Выдавать ошибку», платформа пропустит этот шаг без генерации предупреждений.Код начинает вести себя как обычный обязательный реквизит. При попытке записать новый элемент с незаполненным кодом платформа прерывает запись и выдает ошибку заполнения.Важное примечание: Именно поэтому старые, уже созданные элементы справочника перезаписываются без проблем. В базе данных у них уже сохранен заполненный код, поэтому при повторном редактировании проверка заполнения успешно проходит этот реквизит.
Очень часто разработчики не могут быстро локализовать проблему из-за использования синонимов. Рассмотрим классическую ситуацию:
Код разработчик задает синоним, например, «Имя компьютера».Код (с синонимом «Имя компьютера») отсутствует или скрыто программно (либо через функциональные опции), то всплывающее облако с ошибкой буквально «подвисает» в воздухе. Красный маркер незаполненного поля не может привязаться ни к одному элементу формы, что часто вводит в ступор как пользователей, так и программистов.Проанализируем основные инструменты, которые помогают быстро локализовать источник фантомной ошибки заполнения.
Способ 1. Анализ массива проверяемых реквизитов в коде
Платформа выполняет проверку через системные механизмы, но мы можем перехватить этот процесс. Для этого в модуле объекта достаточно временно объявить предопределенную процедуру ОбработкаПроверкиЗаполнения и установить внутри нее точку останова:
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
// В точке останова смотрим коллекцию "ПроверяемыеРеквизиты"
// Здесь мы увидим истинное имя реквизита (например, "Код")
КонецПроцедуры
В массиве ПроверяемыеРеквизиты будут перечислены имена всех полей, заполненность которых платформа собирается проверять. Наличие там элемента со значением "Код" сразу укажет на источник проблемы.
Способ 2. Замер производительности
Если ошибка вызывается кастомным кодом, можно использовать стандартный замер производительности в Конфигураторе:
Способ 3. Настройка отладчика на «Остановку по ошибке»
В конфигураторе через меню Отладка -> Настройка отладки можно включить признак «Останавливаться по ошибке». При попытке записи элемента отладчик остановится ровно в тот момент, когда платформа инициирует генерацию исключения или сообщения об ошибке заполнения.
Способ 4. Глобальный поиск по синониму
Если текст ошибки содержит непонятное название поля (например, «Имя компьютера»), эффективнее всего запустить глобальный поиск по конфигурации (сочетание клавиш Ctrl + Shift + F) по этому словосочетанию, чтобы быстро определить, какой именно реквизит скрывается под этим синонимом.
Если логика работы вашего справочника действительно требует ручного заполнения кода (без автонумерации), у нас есть три пути решения этой проблемы.
Решение 1. Изменение свойств метаданных (если код заполнять не обязательно)
Если код справочника не несет важной смысловой нагрузки, мы можем просто отключить обязательность его заполнения в конфигураторе:
Код.Решение 2. Программное исключение из проверки заполнения
Если в некоторых случаях код должен проверяться, а в некоторых нет, мы можем управлять этим процессом динамически. В модуле объекта в процедуре ОбработкаПроверкиЗаполнения исключим Код из массива проверок платформы:
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
ИндексКода = ПроверяемыеРеквизиты.Найти("Код");
Если ИндексКода <> Неопределено Тогда
ПроверяемыеРеквизиты.Удалить(ИндексКода);
КонецЕсли;
КонецПроцедуры
Решение 3. Использование события «ПриУстановкеНовогоКода»
Если автонумерация отключена, но код всё же должен формироваться по определенному алгоритму программно перед записью, правильным подходом будет использование предопределенного события модуля объекта ПриУстановкеНовогоКода. Опишем собственную логику генерации значения, чтобы к моменту валидации свойство Код уже было заполнено:
Процедура ПриУстановкеНовогоКода(СтандартнаяОбработка, Префикс)
// Отключаем стандартную генерацию кода платформой
СтандартнаяОбработка = Ложь;
// Реализуем собственный алгоритм заполнения реквизита Код
ЭтотОбъект.Код = ПолучитьНовыйУникальныйКодКомпьютера();
КонецПроцедуры
Применение одного из этих подходов позволит полностью избавиться от «невидимых» ошибок валидации стандартных реквизитов и обеспечит стабильную работу бизнес-логики вашего решения на платформе «1С:Предприятие».