При работе с универсальным форматом обмена данными (EnterpriseData) разработчики часто сталкиваются с ситуацией, когда после обновления типовой конфигурации появляется новая версия XDTO-пакета (например, переход с версии 1.15 на 1.16). Если в расширении конфигурации были добавлены собственные поля или объекты через механизм расширения XDTO-пакета, возникает вопрос: подхватятся ли эти изменения новой версией формата автоматически или требуется ручное вмешательство? Разберем эту ситуацию подробно и рассмотрим несколько стратегий решения задачи.
Для начала проанализируем техническую причину, по которой расширения XDTO не являются универсальными. Каждый XDTO-пакет в системе 1С имеет уникальное пространство имен (Namespace). Например, для версии 1.15 это может быть http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.15, а для версии 1.16 — http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.16.
Когда мы создаем расширение XDTO-пакета в расширении конфигурации, платформа жестко связывает его с конкретным базовым пакетом по его пространству имен. С точки зрения платформы «1С:Предприятие», пакеты разных версий EnterpriseData — это абсолютно разные, не связанные друг с другом объекты. Следовательно, расширение, созданное для версии 1.15, физически не может дополнить структуру версии 1.16. Ответ на основной вопрос: да, для каждой новой версии формата EnterpriseData необходимо создавать свое расширение XDTO-пакета, если вы хотите использовать новые возможности этой версии.
Рассмотрим стандартный путь, который предлагает методология 1С. Если нам критически важно использовать самую свежую версию формата (которая обычно устанавливается в настройках плана обмена автоматически), мы должны выполнить следующие шаги:
EnterpriseData_1_16_1) в наше расширение конфигурации.МенеджерОбменаЧерезУниверсальныйФормат (или соответствующие переопределяемые модули), чтобы логика заполнения новых полей работала и для новой версии.Такой подход требует много рутинной работы при каждом обновлении. Чтобы облегчить себе жизнь, рассмотрим альтернативные методы.
Если добавленные вами поля стабильны и вам не требуются новшества, появившиеся в свежем типовом пакете EnterpriseData, мы можем заставить систему использовать старую версию формата, для которой расширение уже настроено. Рассмотрим, как это сделать программно.
В типовых конфигурациях за список доступных версий отвечают специальные модули. Для «Бухгалтерии предприятия» это ОбменДаннымиПереопределяемый, для ERP, КА или УТ 11 — ОбменДаннымиЛокализация. Нам нужно перекрыть процедуру ПриПолученииДоступныхВерсийФормата в расширении.
Проанализируем пример кода для фиксации версии:
&Вместо("ПриПолученииДоступныхВерсийФормата")
Процедура ИмяПрефикса_ПриПолученииДоступныхВерсийФормата(ВерсииФормата)
// Удаляем или не добавляем новые версии, оставляя только нужную
// ВерсииФормата — это Соответствие, где Ключ - номер версии, Значение - менеджер обмена
ВерсииФормата.Вставить("1.8.6", ОбщийМодуль.МенеджерОбменаЧерезУниверсальныйФормат);
КонецПроцедуры
Таким образом, даже если в конфигурации есть пакет 1.16, план обмена будет предлагать версию 1.8.6 как основную, и ваше расширение XDTO продолжит работать без изменений.
Выясним, как можно вообще уйти от необходимости править XDTO-пакеты. В структуре EnterpriseData практически у каждого объекта (документа или справочника) есть узел AdditionalInfo (Дополнительные сведения). Это универсальный контейнер, предназначенный именно для таких случаев.
Рассмотрим алгоритм работы через AdditionalInfo:
AdditionalInfo структуру или XML-строку с нашими данными.AdditionalInfo и записываем в нужные реквизиты объекта.Пример заполнения в менеджере обмена:
// В обработчике ПрОтправкеДанных
СтруктураДопДанных = Новый Структура;
СтруктураДопДанных.Вставить("CustomField", ДанныеИБ.НашОсобыйРеквизит);
// Сериализуем структуру в строку (например, через JSON или XDTO)
ДанныеXDTO.AdditionalInfo = ЗначениеВСтрокуВнутр(СтруктураДопДанных);
Преимущество: полная независимость от обновлений версий формата. Недостаток: данные в AdditionalInfo не типизированы в самой схеме XDTO, их сложнее контролировать при обмене со сторонними системами (не 1С).
Еще один продвинутый способ — скопировать типовой XDTO-пакет целиком в свою конфигурацию (или расширение), присвоив ему уникальное имя (например, Мой_EnterpriseData_1_8_6). В синониме пакета можно указать версию с постфиксом, например 1.8.6.custom.
Выясним преимущества этого метода:
Для подключения такого пакета также используется процедура ПриПолученииДоступныхВерсийФормата, где вы регистрируете свой менеджер обмена для своей версии пакета. Это позволяет «заморозить» протокол обмена на неопределенный срок, обеспечивая стабильность интеграции.
Выбор стратегии зависит от частоты обновлений вашей системы и объема доработок:
AdditionalInfo. Это самый экономный с точки зрения поддержки вариант.Помните, что при использовании расширений XDTO важно обеспечивать идентичность расширенных пакетов в обеих базах (источнике и приемнике), иначе при попытке прочитать неизвестное поле система выдаст ошибку валидации XML.