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

← На главную

При активной работе с системой маркировки «Честный знак» (ИС МП) пользователи конфигурации 1С:Управление торговлей (редакция 11.4) часто сталкиваются с критической ошибкой при попытке получить коды маркировки из Станции управления заказами (СУЗ). Ошибка сопровождается диагностическим сообщением: Поле объекта не обнаружено (rejectionReason) и прерывает процесс обмена данными. Проанализируем причины возникновения этой проблемы и разберем по шагам способы ее решения.

Выясним причину возникновения ошибки

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

Проблема заключается в том, что поле rejectionReason (причина отклонения), которое программа пытается прочитать, присутствует в ответе сервера не всегда. Если заказ обработан без ошибок или, наоборот, произошел специфический сбой на стороне «Честного знака», это поле может полностью отсутствовать в структуре данных. Типовой код версии 11.4.11.71 не содержит проверки на наличие этого свойства, что и приводит к падению фонового задания с ошибкой «Поле объекта не обнаружено».

Решение 1: Программное исправление кода через проверку свойства

Рассмотрим самый эффективный метод устранения ошибки — внесение изменений в программный код модуля, который обрабатывает ответ от СУЗ. Нам необходимо убедиться, что свойство существует, прежде чем обращаться к нему. Для этого воспользуемся методом ЕстьРеквизитИлиСвойствоОбъекта из общего модуля ОбщегоНазначенияКлиентСервер.

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


// Было:
Если ЗначениеЗаполнено(СтрокGTIN.rejectionReason) Тогда
    // Обработка причины отказа
КонецЕсли;

Заменим этот блок на безопасный вариант, который сначала проверяет наличие ключа rejectionReason в структуре СтрокGTIN:


// Стало:
Если ОбщегоНазначенияКлиентСервер.ЕстьРеквизитИлиСвойствоОбъекта(СтрокGTIN, "rejectionReason")
   И ЗначениеЗаполнено(СтрокGTIN.rejectionReason) Тогда
    // Обработка причины отказа, если поле существует и заполнено
КонецЕсли;

Этот подход гарантирует стабильность работы программы даже в тех случаях, когда сервер СУЗ присылает неполный набор данных.

Решение 2: Использование расширения конфигурации

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

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

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

Решение 3: Оптимизация объема данных в заказах

Выясним еще одну важную закономерность. Как показывает практика, ошибка чаще проявляется при попытке получить коды для больших заказов (от 500 позиций и выше). В таких случаях СУЗ может отдавать ответ частями или с задержками, что провоцирует некорректное формирование структуры JSON на стороне сервера или клиента.

Рассмотрим рекомендации по работе с заказами на эмиссию:

Старайтесь дробить заказы на эмиссию кодов маркировки. Оптимальный размер одного документа — 100–150 строк.
Если ошибка уже возникла и «зациклилась» в очереди сообщений, попробуйте выполнить обмен позже. Иногда серверу «Честного знака» требуется время для финализации статуса заказа, после чего поле rejectionReason может появиться (или перестать требоваться).
Проверьте идентификатор соединения (OMS ID) в настройках обмена. Несоответствие OMS ID может приводить к пустым ответам от сервера.

Решение 4: Проверка актуальности версии и патчей

Проанализируем ситуацию с обновлениями. Фирма 1С регулярно выпускает оперативные исправления (патчи) для подсистемы интеграции с ИС МП, так как API «Честного знака» постоянно меняется.

Проверим наличие установленных патчей в системе:

Перейдем в раздел НСИ и администрирование — Обслуживание.
Выберем пункт Обновление программы — Установленные исправления (патчи).
Убедимся, что установлены последние патчи для релиза 11.4.11.71.

Если автоматическая загрузка патчей не настроена, рекомендуется скачать их вручную с портала поддержки 1С. Часто ошибка с полем rejectionReason исправляется патчем с кодом EF_00XXXXXX, предназначенным специально для модуля интеграции с ИС МП.

Также стоит обратить внимание на версию платформы. Для корректной работы с JSON-структурами в механизмах маркировки рекомендуется использовать версию платформы не ниже 8.3.15.1830 или 8.3.16.1148. В более старых версиях механизмы парсинга могут работать нестабильно, что усугубляет проблему отсутствующих полей объектов.

Резюме

Мы разобрали комплекс мер по устранению ошибки обмена с СУЗ. Наиболее надежным способом является добавление программной проверки существования свойства через расширение конфигурации. Это позволит продолжить работу с маркировкой, не дожидаясь выхода нового релиза типовой конфигурации и не снимая систему с поддержки. Сочетание этой правки с ограничением количества позиций в одном заказе обеспечит стабильную работу склада и отдела закупа при работе с маркированным товаром.