Как исправить ошибку «Не заполнена колонка "Количество по РНПТ"» при проведении пересортицы в 1С:УТ 11.4?

← На главную

Многие пользователи и программисты сталкиваются с неприятной ситуацией в конфигурации 1С:Управление торговлей 11.4 (начиная с релиза 11.4.13.57 и выше). При попытке провести документ ПересортицаТоваров система выдает ошибку: «Не заполнена колонка "Количество по РНПТ" в строке 1 списка "Товары"». Самое странное в этой ситуации то, что учет прослеживаемых импортных товаров в базе может быть полностью отключен, а под пользователем с полными правами (Администратором) документ проводится без проблем. Давайте подробно рассмотрим эту ситуацию и выясним причину такого поведения системы, а также разберем по шагам, как устранить эту ошибку.

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

Для начала выясним причину, почему программа требует заполнения реквизита КоличествоПоРНПТ, если функциональная опция прослеживаемости выключена. Разберем несколько ключевых факторов:

Настройки номенклатуры и классификатор ТН ВЭД. Даже если глобально учет прослеживаемых товаров отключен, логика проверок 1С тесно привязана к настройкам самой номенклатуры. Если в карточке товара, который участвует в пересортице, указан код ТН ВЭД с установленным внутри признаком «Прослеживаемый товар» (или исторически стоял флаг учета по ГТД), система может классифицировать документ как прослеживаемый. Функция ЭтоПрослеживаемыйДокумент вернет Истина, что принудительно включит обязательность поля.
Разница в правах доступа (RLS). Разное поведение документа под обычным менеджером и Администратором связано с ограничениями прав доступа (RLS) на регистры сведений и справочники. При вызове функций проверки (например, ПроверитьКорректностьНастроекТоваровРНПТ) система анализирует параметры. Администратор обходит часть скрытых проверок, что позволяет логике платформы игнорировать пустое поле. У менеджера же нехватка прав вызывает некорректное срабатывание триггера проверки.
Влияние кэша и смешанных строк. Если в документе присутствует несколько строк, и хотя бы у одной «зацепился» признак прослеживаемости (например, некорректно заполнился вид запасов), программа может распространить требование заполнить РНПТ на все товары в табличной части.

Посмотрим на стандартный механизм проверки

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


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

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

Рассмотрим решение проблемы через расширение конфигурации

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

Разберем по шагам алгоритм действий:

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

Теперь напишем код, который будет принудительно удалять проблемный реквизит из массива проверяемых реквизитов перед тем, как платформа выдаст ошибку. Посмотрим на пример кода:


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

Альтернативный вариант обхода (без программирования)

Если вы не готовы использовать расширения или вам нужно быстрое решение «здесь и сейчас», рассмотрим административный путь решения проблемы:

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

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