Синхронизация данных между конфигурациями 1С с использованием технологии EnterpriseData (ED) — один из самых гибких и современных способов интеграции. Однако при обновлении информационных баз разработчики часто сталкиваются с необходимостью перехода на более свежую версию формата (например, с устаревшего 1.1 на 1.3 или 1.6). В процессе такого перехода нередко возникает неприятная ситуация: выгрузка из базы-источника проходит успешно, файл XML формируется корректно, загрузка в базе-приемнике завершается без видимых ошибок, но сами документы в программе не появляются либо загружаются «пустыми» — без табличных частей и ключевых реквизитов (таких как валюта, контрагент или договор).
В этой статье мы подробно проанализируем причины такого поведения системы, разберем особенности взаимодействия общего и версионного менеджеров обмена БСП (Библиотеки стандартных подсистем), выясним, почему пропускаются обработчики конвертации данных, и рассмотрим правильный алгоритм переноса нетиповых документов на новые версии формата EnterpriseData.
---
Рассмотрим ситуацию изнутри. При выполнении обмена БСП считывает входящий XML-файл. Если в процессе разбора XML-схемы система встречает неизвестный ей тип данных или не находит сопоставленного правила конвертации объектов (ПКО) для текущей версии формата, она выполняет так называемый «тихий пропуск». Система логично предполагает, что если для данного объекта в текущей версии формата правила не определены, то загружать его в текущую базу не требуется. Чтение файла продолжается, транзакция завершается успешно, никаких критических ошибок в журнал регистрации не записывается, но объект в базе физически не создается.
Для того чтобы понять, почему объект игнорируется, необходимо проанализировать цепочку вызовов обработчиков обмена. Обычно при загрузке кастомного документа должны последовательно отрабатывать три ключевые процедуры:
Если в процессе отладки выясняется, что система заходит только в процедуру чтения («Получение»), но полностью игнорирует этапы конвертации и записи, это явный признак того, что БСП не смогла связать десериализованный объект XDTO с зарегистрированными правилами обмена для новой версии формата.
---
Проанализируем архитектуру БСП в части работы с универсальным форматом. Процесс обмена опирается на два типа общих модулей менеджеров обмена:
МенеджерОбменаЧерезУниверсальныйФормат — базовый (общий) модуль, выступающий в роли единой точки входа. Он считывает заголовок сообщения, определяет версию формата и координирует дальнейшую работу.МенеджерОбменаЧерезУниверсальныйФормат[НомерВерсии] (например, МенеджерОбменаЧерезУниверсальныйФормат13) — версионный модуль, содержащий правила, специфичные исключительно для конкретной версии формата (в данном случае ED 1.3).Если при отладке вашего доработанного документа система обращается к обработчикам сразу обоих модулей (и общего, и версионного), в то время как типовые документы используют только версионный модуль ...13, это свидетельствует о некорректной регистрации правил. Происходит это по следующим причинам:
...13, но при этом старые обработчики или ссылки на них не были очищены в базовом общем модуле.ПриПолученииНастроек менеджера плана обмена.---
Каждая версия формата EnterpriseData имеет свое уникальное пространство имен XML. Например:
http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.3Если вы перенесли реквизиты документа в XDTO-пакет, но не адаптировали описание структуры документа под схему версии 1.3, фабрика XDTO при чтении XML-файла не сможет сопоставить типы данных. Для системы этот документ останется объектом старого формата 1.1. Так как выгрузка идет в формате 1.3, система просто проигнорирует несовпадающие типы данных, что приведет к пропуску процедур конвертации.
---
Даже если документ частично создается, отсутствие заполнения табличных частей и ссылочных реквизитов (например, Валюта, Контрагент) указывает на следующие ошибки:
Валюта заполнился, в правилах обмена версии 1.3 должно быть активно и корректно настроено соответствующее правило (например, ПКО_Справочник_Валюты_Получение). Если связь между ПКО документа и ПКО справочника нарушена, реквизит останется пустым.---
Откат синхронизации на устаревший формат 1.1 (как часто делают разработчики в условиях жестких дедлайнов) — это крайне опасное решение. При первом же обновлении конфигурации базы-приемника (например, «Бухгалтерии предприятия») все ваши ручные изменения в модулях устаревшего формата будут безвозвратно затерты типовым кодом, а сама поддержка формата 1.1 в новых релизах БСП со временем полностью исчезнет.
Рассмотрим по шагам, как правильно и надежно интегрировать нетиповой документ в современный формат EnterpriseData (на примере ED 1.3):
Ни в коем случае не редактируйте типовые XDTO-пакеты конфигурации! Правильный подход заключается в создании собственного расширения XDTO-пакета:
http://www.yourcompany.ru/EnterpriseData/1.3).Чтобы система распознала ваше расширение XDTO при инициализации обмена, его необходимо зарегистрировать. Для этого перейдите в общий модуль ОбменДаннымиПереопределяемый и добавьте код в процедуру ПриПолученииДоступныхРасширенийФормата:
Процедура ПриПолученииДоступныхРасширенийФормата(ДоступныеРасширения) Экспорт
НовоеРасширение = ДоступныеРасширения.Добавить();
НовоеРасширение.Имя = "CustomDocumentExtension";
НовоеРасширение.ПространствоИмен = "http://www.yourcompany.ru/EnterpriseData/1.3";
НовоеРасширение.ВерсияФормата = "1.3";
КонецПроцедуры
Для создания корректных правил конвертации объектов (ПКО) настоятельно рекомендуется использовать специализированный инструмент — конфигурацию «Конвертация данных 3.0» (КД3):
MD83Exp.epf.Полученный из КД3 код необходимо внедрить в версионный модуль менеджера обмена (например, МенеджерОбменаЧерезУниверсальныйФормат13). Чтобы сохранить конфигурацию на поддержке, реализуйте это через расширение конфигурации, переопределив соответствующие процедуры инициализации ПКО и ПОД. Пример структуры инициализации кастомного ПКО в версионном модуле:
Процедура ДобавитьПКО_Документ_ВашДокумент_Получение(ПравилаКонвертации)
Правило = Rules.Добавить();
Правило.Имя = "Документ_ВашДокумент_Получение";
Правило.ОбъектПриемник = "Документ.ВашДокумент";
Правило.ОбъектИсточникXDTO = "Document.ВашДокумент";
// Описание правил конвертации свойств (ПКС)
ДобавитьПКС(Правило, "Организация", "Организация", , "Справочник_Организации_Получение");
ДобавитьПКС(Правило, "Контрагент", "Контрагент", , "Справочник_Контрагенты_Получение");
ДобавитьПКС(Правило, "Договор", "ДоговорКонтрагента", , "Справочник_Договоры_Получение");
ДобавитьПКС(Правило, "Валюта", "Валюта", , "Справочник_Валюты_Получение");
// Описание ПКС для табличной части
ТабличнаяЧасть = ДобавитьПКТЧ(Правило, "Товары", "Товары");
ДобавитьПКС(ТабличнаяЧасть, "Номенклатура", "Номенклатура", , "Справочник_Номенклатура_Получение");
ДобавитьПКС(ТабличнаяЧасть, "Количество", "Количество");
ДобавитьПКС(ТабличнаяЧасть, "Цена", "Цена");
ДобавитьПКС(ТабличнаяЧасть, "Сумма", "Сумма");
КонецПроцедуры
---
Если структура вашего нетипового документа достаточно простая или вам нужно передать всего несколько дополнительных реквизитов, которых нет в стандартном формате, можно обойтись без создания новых XDTO-пакетов и сложных схем.
В объектной модели EnterpriseData практически каждый тип наследуется от базового типа, имеющего свойство AdditionalInfo (Дополнительная информация), которое представляет собой структуру свободного XML. Вы можете поместить любые нетиповые данные в это свойство на стороне источника, а в базе-приемнике в обработчике ПриКонвертацииXDTO версионного менеджера перехватить эти данные из структуры XDTO и программно заполнить нужные реквизиты документа 1С. Это существенно сократит время разработки и упростит последующую поддержку синхронизации при обновлениях.