Как программно отключить проверку заполнения реквизита табличной части в 1С

← На главную

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

Метод 1. Использование обработчика ОбработкаПроверкиЗаполнения в модуле объекта

Это стандартный и самый правильный путь управления списком обязательных полей. Когда документ записывается или проводится, платформа вызывает это событие. В него передается массив ПроверяемыеРеквизиты, содержащий пути к полям, которые система считает обязательными. Чтобы убрать проверку для конкретного реквизита табличной части, нам нужно найти его в этом массиве и удалить.

Рассмотрим пример кода, который нужно разместить в модуле объекта документа:


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

КонецПроцедуры

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

Метод 2. Проверка на уровне управляемой формы

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

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

Также важно проверить свойство элемента формы Автоотметка незаполненного. Если оно установлено в значение Да, платформа визуально выделяет поле подчеркиванием, и в некоторых случаях это может влиять на поведение системы при попытке записи. Попробуем программно изменить это свойство:


// В коде формы, например, в ПриСозданииНаСервере или при изменении условий
Элементы.ТоварыСчетУчета.АвтоотметкаНезаполненного = Ложь;

Метод 3. Влияние Библиотеки стандартных подсистем (БСП)

В современных конфигурациях, таких как Бухгалтерия предприятия 3.0, логика проверки часто вынесена в общие модули БСП. Проверка может инициироваться не платформенным механизмом FillCheck, а программным кодом в подписках на события ПередЗаписью или ПриЗаписи.

Разберем, как это диагностировать:

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

Метод 4. Связи параметров выбора и проверки типов

Иногда сообщение о незаполненном реквизите является следствием работы механизма Связи параметров выбора. Если реквизит РеквизитА является владельцем или параметром фильтрации для РеквизитаБ, платформа может блокировать работу, если РеквизитА не заполнен, так как она не может построить список выбора для зависимого поля.

Проанализируем структуру метаданных:

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

Метод 5. Особенности расширений конфигурации

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

Выполним следующие действия для проверки:

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

Итоги и рекомендации

Если вы столкнулись с "магическим" появлением ошибки заполнения при пустом массиве ПроверяемыеРеквизиты, придерживайтесь следующего алгоритма действий:

Проверьте Отказ: Убедитесь, что в процедуре ОбработкаПроверкиЗаполнения переменная Отказ установлена в значение Ложь (хотя обычно ошибка платформы сама ставит Истина, если реквизит не найден в массиве).
Проверьте форму: Исключите влияние свойства Автоотметка незаполненного и серверного обработчика формы.
Стек вызовов: Это самый надежный способ. Поймайте момент вывода сообщения через отладчик. Если сообщение выводится методом ОбщегоНазначения.СообщитьПользователю, значит, это не платформенная проверка, а программная логика конфигурации.
Путь к реквизиту: Убедитесь, что путь в массиве указан точно: ИмяТЧ.ИмяРеквизита. Ошибка в одной букве приведет к тому, что платформа проигнорирует вашу попытку удаления.

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