При осуществлении двустороннего обмена данными между конфигурациями «Управление торговлей» (УТ) и «Бухгалтерия предприятия» (БП) пользователи часто сталкиваются со сбоями загрузки документов. Одной из наиболее распространенных ошибок является отказ системы регистрировать документ из-за некорректной длины его номера.
В этой статье мы подробно проанализируем, почему возникает ошибка Поле Номер полученного объекта имеет некорректное значение. Загрузка не возможна, разберем методологические причины ее появления и рассмотрим несколько практических способов решения этой проблемы: от простого изменения метаданных до программирования правил обмена в формате XDTO.
---
При обмене данными через универсальный формат EnterpriseData (на что указывает обработчик ПриКонвертацииДанныхXDTO в системном логе) библиотека стандартных подсистем (БСП) выполняет строгую валидацию входящих XML-данных перед записью объекта в базу-приемник. В стандартной конфигурации 1С:Бухгалтерия предприятия редакции 3.0 длина системного реквизита Номер для документа Поступление (акт, накладная) (в конфигураторе — ПоступлениеТоваровУслуг) по умолчанию ограничена 11 символами.
Если в базе-источнике (УТ) документу присвоен длинный номер, например, 01/202002190379 (14 символов) или более, то при попытке загрузить его в БП валидатор XDTO определяет, что значение превышает допустимую длину поля в метаданных приемника. В результате транзакция прерывается, и в журнал регистрации записывается ошибка.
---
Прежде чем переходить к техническим решениям, важно понять методологическую суть проблемы. В программных продуктах 1С у входящих документов (таких как поступление товаров и услуг от поставщика) есть два разных реквизита:
Номер) — используется исключительно для внутреннего учета, сортировки и обеспечения уникальности записей в вашей базе данных 1С. По умолчанию он имеет длину 11 символов и генерируется автоматически.НомерВходящегоДокумента) — это реальный номер накладной или акта, который вам предоставил поставщик. Его длина в конфигурации «Бухгалтерия предприятия» составляет от 30 до 50 символов, что позволяет вводить любые сложные комбинации знаков.Часто пользователи в базе-источнике (УТ) вручную записывают длинный номер поставщика непосредственно в поле Номер, вместо того чтобы вносить его в поле входящего документа. При переносе данных это приводит к конфликту ограничений метаданных.
Если изменить бизнес-процесс заполнения документов на стороне источника невозможно, рассмотрим технические варианты устранения проблемы.
---
Это самый быстрый способ, который использовал автор темы на форуме. Он заключается в непосредственном увеличении лимита символов для номера документа в конфигураторе базы-приемника.
Рассмотрим этот процесс по шагам:
1С:Бухгалтерия предприятия в режиме Конфигуратор.Конфигурация -> Поддержка -> Настройка поддержки. Обратите внимание, что для этого потребуется установить статус «Редактируется с сохранением поддержки» для нужного документа.Документы и выберите документ ПоступлениеТоваровУслуг (в пользовательском интерфейсе он называется «Поступление (акт, накладная)»).11 на необходимое (например, 25 или 30).Важное предупреждение: Данный способ имеет существенный недостаток. Изменение метаданных напрямую в основной конфигурации снимает объект с полной поддержки. Это может усложнить процесс последующих обновлений программы (потребуется ручное объединение при обновлении релиза).
---
Если вы используете платформу 1С:Предприятие версии 8.3.22 и выше, вы можете изменить длину номера документа, не снимая основную конфигурацию с поддержки. Для этого используются механизмы расширения конфигурации.
Проанализируем этот современный подход:
Конфигурация -> Расширения конфигурации.ПоступлениеТоваровУслуг, нажмите на него правой кнопкой мыши и выберите команду Добавить в расширение.При таком подходе основная конфигурация остается на стандартной поддержке, обновления будут проходить в обычном автоматическом режиме, а измененная логика длины номера сохранится в расширении.
---
Наиболее правильным решением с точки зрения архитектуры систем является перенаправление данных в процессе обмена. Мы можем сделать так, чтобы длинный номер из УТ при загрузке в БП автоматически записывался в реквизит НомерВходящегоДокумента, а системный номер БП генерировался автоматически в пределах стандартных 11 символов.
Для реализации этого механизма можно использовать доработку общего модуля менеджера обмена через универсальный формат. Рассмотрим пример кода, который перехватывает данные перед записью объекта в базу-приемник:
Процедура ПередЗаписьюПолученныхДанных(ПолученныеДанные, ДокументОбъект, КомпонентОбмена) Экспорт
// Проверяем, что обрабатываемый объект является поступлением товаров и услуг
Если ТипЗнч(ДокументОбъект) = Тип("ДокументОбъект.ПоступлениеТоваровУслуг") Тогда
// Анализируем длину номера, пришедшего из базы-источника
Если СтрДлина(ДокументОбъект.Номер) > 11 Тогда
// Если реквизит входящего номера пуст, переносим туда оригинальный длинный номер
Если ПустаяСтрока(ДокументОбъект.НомерВходящегоДокумента) Тогда
ДокументОбъект.НомерВходящегоДокумента = ДокументОбъект.Номер;
КонецЕсли;
// Очищаем системный номер, чтобы сработал механизм автонумерации БП,
// либо принудительно обрезаем его до допустимых 11 символов
ДокументОбъект.Номер = "";
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Этот код позволяет полностью избежать модификации структуры метаданных базы данных. Все длинные номера поставщиков будут корректно сохранены в предназначенном для этого поле НомерВходящегоДокумента, а системные номера документов БП останутся в рамках стандартной сквозной нумерации.