При настройке стандартной синхронизации данных между конфигурациями «Управление торговлей» (УТ 11) и «Бухгалтерия предприятия» (БП 3.0) по универсальному формату (EnterpriseData) разработчики и администраторы часто сталкиваются с неприятной проблемой. После успешного завершения сеанса обмена в базе-приемнике (БП) в документах «Поступление (акт, накладная, УПД)» остаются незаполненными реквизиты «Номер вх. документа» и «Дата вх. документа». При этом в базе-источнике (УТ) в документах «Приобретение товаров и услуг» эти поля заполнены корректно.
Для бухгалтерии отсутствие этих реквизитов критично, поскольку они напрямую влияют на корректность формирования книги покупок и отчетности по НДС. В этой статье мы подробно разберем технические причины возникновения этой ошибки, выясним, почему она проявляется на определенных релизах, и рассмотрим несколько практических способов ее решения — от простого обновления до точечного исправления кода через расширение конфигурации.
Для того чтобы понять природу сбоя, проанализируем, как устроен перенос данных в универсальном формате. Начиная с версии формата EnterpriseData 1.6, архитектура схемы XDTO претерпела изменения. В предыдущих версиях формата (например, EnterpriseData 1.5 и младше) реквизиты входящего документа передавались как простые, «плоские» свойства самого объекта XML.
В формате версии 1.6 структуру оптимизировали: входящие номер и дата были вынесены внутрь иерархической структуры ключевых свойств объектов. Ошибка кроется непосредственно в коде Библиотеки стандартных подсистем (БСП), которая отвечает за сериализацию и десериализацию объектов XDTO. При генерации правил конвертации функция ТаблицаПравилКонвертации общего модуля БСП некорректно обрабатывала вложенные ветки иерархических свойств в схеме XDTO. Модуль сериализации попросту «не видел» реквизиты, находящиеся на уровень ниже основного объекта, из-за чего они игнорировались и физически не выгружались в XML-файл обмена.
Данная проблема является официально зарегистрированной ошибкой БСП в компоненте синхронизации данных. Ошибка проявляет себя на стыке релизов УТ 11.4.7 и БП 3.0.67 / 3.0.68.
Ниже подробно рассмотрим четыре способа устранения этой проблемы в зависимости от возможности обновления ваших баз данных.
Поскольку проблема вызвана ошибкой в коде БСП, фирма «1С» оперативно выпустила исправление в последующих релизах библиотек и типовых конфигураций. Если ваши информационные базы находятся на стандартной поддержке и не имеют сильных кастомных изменений, самым правильным и безопасным решением будет их обновление.
Разберем, в каких версиях конфигураций данная ошибка была окончательно исправлена:
После обновления обеих конфигураций до указанных релизов иерархическая структура EnterpriseData 1.6 начнет обрабатываться корректно, и номера входящих документов будут автоматически переноситься без дополнительных доработок.
Если конфигурация «Управление торговлей» сильно доработана, находится на нетиповой поддержке, а процесс ее обновления требует длительного времени и больших ресурсов, можно прибегнуть к временному обходному пути. Поскольку в версии формата 1.5 входящие номера передавались по «плоской» схеме и обрабатывались корректно, мы можем принудительно заставить систему использовать формат EnterpriseData 1.5 вместо используемого по умолчанию 1.6.
Для реализации этого метода нам потребуется создать расширение в базе-источнике (УТ) и переопределить функцию определения максимальной версии формата обмена. Проанализируем программный код, который необходимо внедрить.
Добавим в расширение конфигурации УТ общий модуль ОбменДаннымиXDTOСервер и перехватим функцию МаксимальнаяОбщаяВерсияФормата с помощью аннотации &Вместо:
&Вместо("МаксимальнаяОбщаяВерсияФормата")
Функция Испр_МаксимальнаяОбщаяВерсияФормата(ИмяПланаОбмена, ВерсииФорматаКорреспондента) Экспорт
// Вызываем оригинальный алгоритм для выполнения сопутствующей логики системы
МаксимальнаяОбщаяВерсия = ПродолжитьВызов(ИмяПланаОбмена, ВерсииФорматаКорреспондента);
// Принудительно ограничиваем версию формата до стабильной 1.5
Возврат "1.5";
КонецФункции
Важное предупреждение: Использование данного способа несет в себе определенные риски. Откат версии обмена до EnterpriseData 1.5 лишает вас возможности использовать новые механизмы, добавленные в версии 1.6 и выше. Например, могут возникнуть сложности с обменом документами, содержащими новые ставки НДС или реквизиты системы прослеживаемости импортных товаров. Рассматривайте этот способ исключительно как временную меру до полноценного обновления конфигураций.
Если вы хотите сохранить обмен на современной и полноценной версии формата EnterpriseData 1.6, но обновлять всю конфигурацию целиком пока не планируете, можно точечно исправить ошибку разбора схемы XDTO в модуле БСП.
Для этого необходимо перенести алгоритм исправления из новых релизов БСП в ваше расширение. Исправлению подлежит процедура заполнения списка свойств объектов XDTO. Посмотрим, как выглядит архитектура исправления:
ОбменДаннымиXDTOСервер.ЗаполнитьСписокСвойствОбъектаXDTO на исправленную версию из релиза БСП 3.0.2.140 (или конфигурации УТ 11.4.8). Новая версия процедуры научилась осуществлять рекурсивный обход дерева свойств, корректно заходя во вложенные типы метаданных.ED_ТаблицаПравилКонвертации, добавив в нее корректный вызов обновленной процедуры заполнения списка свойств.Пример структуры кода для переноса функции генерации таблицы правил конвертации в расширение:
&Вместо("ТаблицаПравилКонвертации")
Функция ED_ТаблицаПравилКонвертации(XMLСхема, МенеджерОбмена, НаправлениеОбмена, ПравилаОбработкиДанных)
// Полностью заменяем код функции на аналогичный из релиза УТ 11.4.8.
// В месте, где происходит вызов ЗаполнитьСписокСвойствОбъектаXDTO,
// обеспечивается передача и разбор иерархических свойств формата 1.6.
// [Здесь размещается оригинальный текст исправленной функции БСП]
КонецФункции
Этот способ является наиболее технологичным и правильным с точки зрения разработки, так как сохраняет актуальную версию формата обмена и точечно устраняет баг в логике платформенных механизмов.
Рассмотрим еще один альтернативный сценарий, который не затрагивает системный код БСП и не требует понижения версии формата обмена. Мы можем передать входящий номер и дату документа «в обход» стандартного сопоставления схемы через узел дополнительных свойств ДополнительныеСвойства (в схеме XDTO этот узел называется AdditionalInfo).
Схема реализации данного подхода состоит из двух шагов:
Шаг 1. Перехват отправки в УТ 11
В расширении в модуле менеджера обмена УТ переопределяем обработчик события отправки документа приобретения (например, в процедуре ПКО_Документ_ПриобретениеТоваровУслуг_ПриОтправкеДанных) и записываем необходимые реквизиты в структуру дополнительных свойств:
// В обработчике при отправке данных в УТ
СтруктураДопСвойств = Новый Структура;
СтруктураДопСвойств.Вставить("НомерВходящегоДокумента", ДанныеИБ.НомерВходящегоДокумента);
СтруктураДопСвойств.Вставить("ДатаВходящегоДокумента", ДанныеИБ.ДатаВходящегоДокумента);
// Записываем структуру в узел AdditionalInfo передаваемого XDTO-объекта
ПолученныеДанные.Вставить("ДополнительныеСвойства", СтруктураДопСвойств);
Шаг 2. Прием данных в БП 3.0
В базе БП 3.0 в расширении переопределяем процедуру получения данных (например, ПКО_Документ_ПоступлениеТоваровУслуг_ПриПолученииДанных). Считываем переданные значения и напрямую записываем их в реквизиты создаваемого документа:
// В обработчике при получении данных в БП
Если ПолученныеДанные.Свойство("ДополнительныеСвойства") Тогда
ДопСвойства = ПолученныеДанные.ДополнительныеСвойства;
Если ТипЗнч(ДопСвойства) = Тип("Структура") Тогда
Если ДопСвойства.Свойство("НомерВходящегоДокумента") Тогда
ДанныеИБ.НомерВходящегоДокумента = ДопСвойства.НомерВходящегоДокумента;
КонецЕсли;
Если ДопСвойства.Свойство("ДатаВходящегоДокумента") Тогда
ДанныеИБ.ДатаВходящегоДокумента = ДопСвойства.ДатаВходящегоДокумента;
КонецЕсли;
КонецЕсли;
КонецЕсли;
Данный подход полностью независим от версий формата обмена и платформенных ошибок в БСП, однако требует внесения доработок как на стороне источника (УТ), так и на стороне приемника (БП).
Мы детально проанализировали проблему отсутствия входящих номеров документов при синхронизации через EnterpriseData и рассмотрели четыре различных подхода к ее решению. На практике наиболее предпочтительным шагом является Способ 1 (обновление конфигураций). Если же обновление недоступно в ближайшей перспективе, мы рекомендуем использовать Способ 3 (исправление алгоритма БСП), так как он локализует исправление непосредственно в ошибочном блоке кода и не создает ограничений на использование современного формата 1.6 в будущем.