Как исправить ошибку «Поле объекта не обнаружено (Комиссионер)» при расчете себестоимости в 1С:УПП?

При работе в конфигурации «1С:Управление производственным предприятием 1.3» пользователи часто сталкиваются с критической ошибкой при проведении документа Расчет себестоимости. Проблема локализуется в общем модуле УправлениеЗапасамиРасширеннаяАналитика и прерывает выполнение регламентных операций закрытия месяца. Ошибка выглядит следующим образом: {ОбщийМодуль.УправлениеЗапасамиРасширеннаяАналитика.Модуль(2017)}: Поле объекта не обнаружено (Комиссионер).

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

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

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

Если ЗначениеЗаполнено(СтрокаДокумента.Комиссионер) Тогда
    Контрагент = СтрокаДокумента.Комиссионер;
Иначе
    Контрагент = Справочники.Контрагенты.ПустаяСсылка();
КонецЕсли;

Проблема заключается в том, что переменная СтрокаДокумента в режиме РАУЗ (расширенной аналитики учета затрат) не всегда является строкой реального документа. Часто это запись из временной таблицы, сформированной на основе регистра накопления Учет затрат (регламентированный учет). Если в регистр попали данные по счетам, которые алгоритм считает «комиссионными» (например, счет 004 или 45), система пытается вычислить контрагента, обращаясь к полю Комиссионер. Если источником данных послужил документ Корректировка записей регистров, Оприходование товаров или специфическое Перемещение товаров, этого поля в структуре просто нет, что и вызывает падение системы.

Метод 1. Поиск проблемных данных в регистрах

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

1. Используем консоль запросов или универсальный отчет для анализа регистра накопления «Учет затрат (регламентированный учет)» за расчетный период.
2. Установим фильтр по счетам учета. Нас интересуют записи, где фигурируют счета: 004 (Товары, принятые на комиссию), 45.02 и 45.03 (Товары переданные).
3. Проверим документы-основания этих записей. Особое внимание уделим документам типа Перемещение товаров, Требование-накладная или ручным операциям. Если в этих документах ошибочно выбраны счета учета, предназначенные для комиссии, это спровоцирует ошибку в РАУЗ.
4. Проанализируем наличие пустых аналитик в документах типа Прочие затраты или Корректировка прочих затрат.

Метод 2. Техническая отладка и остановка по ошибке

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

Часто Расчет себестоимости выполняется в фоновом задании на сервере, поэтому обычная точка останова в толстом клиенте может игнорироваться. Для корректной отладки выполним следующие действия:

1. Запустим конфигуратор и перейдем в меню «Отладка» — «Подключение». Убедимся, что установлены флажки для подключения к серверным и фоновым заданиям.
2. В меню «Отладка» выберем пункт «Остановка по ошибке». Нажмем кнопку «Добавить» и выберем тип ошибки (или оставим «Останавливаться по любой ошибке»).
3. Запустим расчет себестоимости. Когда система дойдет до проблемной строки, выполнение прервется автоматически.
4. В окне «Локальные переменные» раскроем объект СтрокаДокумента. В нем мы увидим реквизит Регистратор или Ссылка, который укажет на конкретный документ в базе, вызвавший сбой.

Метод 3. Программное исправление (Safe Code)

Если ошибка вызвана багом релиза (что часто случалось в версиях УПП 1.3.115–1.3.125), рекомендуется внести исправления в общий модуль УправлениеЗапасамиРасширеннаяАналитика. Вместо прямого обращения к реквизиту, которое вызывает исключение, используем безопасную проверку наличия свойства.

Рассмотрим вариант исправления кода. Заменим проблемный участок на более устойчивую конструкцию:

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

Если ЕстьПолеКомиссионер И ЗначениеЗаполнено(СтрокаДокумента.Комиссионер) Тогда
    Контрагент = СтрокаДокумента.Комиссионер;
Иначе
    Контрагент = Справочники.Контрагенты.ПустаяСсылка();
КонецЕсли;

Такой подход позволит системе пропустить проверку, если поля Комиссионер нет в текущем контексте, и продолжить расчет себестоимости без аварийного завершения.

Рекомендации по профилактике

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

1. Тестирование и исправление: Регулярно запускайте процедуру проверки логической целостности базы. Это поможет выявить «битые» ссылки в регистрах накопления, которые часто становятся причиной странного поведения РАУЗ.
2. Обновление конфигурации: Проверьте текущий релиз УПП. Если ваша версия входит в диапазон известных багов (1.3.115-1.3.125), настоятельно рекомендуется обновиться до актуального релиза, где механизмы работы с комиссионными субконто были переработаны.
3. Контроль счетов учета: Ограничьте права пользователей на редактирование счетов учета в документах, если они не обладают достаточной квалификацией. Случайный выбор счета 004 в документе оприходования — прямая дорога к ошибке при расчете себестоимости.

Таким образом, мы выяснили, что ошибка вызвана попыткой алгоритма РАУЗ получить данные комиссионной торговли из объектов, которые для этого не предназначены. Использование безопасных методов обращения к реквизитам и тщательный аудит регистров позволяют полностью устранить данную проблему.