Как исправить ошибку с некорректным номером документа при синхронизации УТ 11 и БП 3.0

← На главную

При настройке и обновлении обмена между конфигурациями «1С:Управление торговлей 11» и «1С:Бухгалтерия предприятия 3.0» разработчики нередко сталкиваются с ситуацией, когда привычные механизмы обмена по правилам конвертации перестают функционировать, а при переходе на универсальный формат EnterpriseData загрузка прерывается с ошибкой вида: «Номер полученного объекта имеет некорректное значение». Разберем по шагам, почему это происходит, как устроена работа форматов обмена и какими способами можно быстро устранить неполадку.

Почему не удается вернуть обмен по правилам КД 2.0 в БП 3.0

Проанализируем архитектурные изменения в типовых конфигурациях. Начиная с релизов ветки 3.0.44 в «Бухгалтерии предприятия» классический обмен по правилам конвертации данных 2.0 (через отдельные XML-файлы правил) был признан устаревшим и выведен из типовой поставки. На смену ему пришел обмен через универсальный формат данных (EnterpriseData / КД 3.0).

Попытка вернуть старый обмен простым добавлением строки в общем модуле ОбменДаннымиПереопределяемый в процедуре ПолучитьПланыОбмена():


ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятияКОРП30);

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

Если вам критически важно продолжать использовать правила КД 2.0 без перехода на EnterpriseData, штатная подсистема БСП уже не подойдет. Единственным рабочим решением останется регулярный запуск внешней обработки «Универсальный обмен данными в формате XML» вручную или через отдельное регламентное задание с передачей параметров выгрузки и загрузки.

Влияет ли несовпадение минорных версий EnterpriseData (1.2.1 и 1.2.2)

Рассмотрим распространенное заблуждение: при анализе ошибки разработчики часто предполагают, что сбой вызван несовпадением подверсий формата, например, когда в УТ используется EnterpriseData версии 1.2.1, а в БП — 1.2.2. Это не так. Подсистема обмена через универсальный формат в библиотеке стандартных подсистем (БСП) обладает встроенной обратной совместимостью в рамках одной основной ветки (в данном случае 1.2). База-приемник с более свежей версией схемы корректно распознает и обрабатывает структуры данных младшей подверсии, поэтому экстренно обновлять конфигурацию только ради подверсии формата схемы нет необходимости.

Анализ ошибки: «Номер полученного объекта имеет некорректное значение»

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

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

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

Способ 1. Исправление номеров и автонумерации на стороне УТ 11

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

Найдем в УТ 11 документы с нестандартной длиной номера (дольше стандартных 11 знаков).
Скорректируем номера этих документов вручную или воспользуемся стандартной обработкой «Групповое изменение реквизитов».
Проверим настройки префиксов в карточке организации и параметрах синхронизации, чтобы суммарный префикс не приводил к переполнению строки.
Повторим регистрацию документов к отправке и выполним обмен.

Способ 2. Корректировка номера через расширение конфигурации (КД 3.0)

В концепции КД 3.0 правила конвертации хранятся не в файлах XML, а описываются программным кодом в общих модулях (например, МенеджерОбменаЧерезУниверсальныйФормат). Для внесения изменений вовсе не обязательно разворачивать саму конфигурацию «Конвертация данных 3.0» — логику можно переопределить с помощью расширения.

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


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

Аналогичным образом обработку можно добавить на стороне источника (УТ 11) в момент выгрузки данных, укорачивая исходящий номер заказа функцией Лев() или Прав() перед формированием сообщения EnterpriseData.

Способ 3. Увеличение длины номера в метаданных БП 3.0

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

Откроем дерево метаданных и найдем документ СчетНаОплатуПокупателю.
Перейдем в свойства стандартного реквизита Номер.
Увеличим значение свойства Длина (например, с 11 до 12 или 15 символов), чтобы оно гарантированно вмещало входящие номера из УТ 11.
Применим изменения структуры конфигурации базы данных.

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