Как правильно расширить XDTO-пакет для КД3, чтобы добавить новый реквизит в табличную часть документа?

← На главную

Коллеги, сегодня мы с вами погрузимся в одну из самых сложных и обсуждаемых тем в разработке на 1С – расширение XDTO-пакетов и их корректную интеграцию с «Конвертацией данных 3.0» (КД3) — для этого подойдут правила обмена EnterpriseData для КД3. Особенно актуальна эта задача, когда требуется добавить новый реквизит простого типа в табличную часть документа, а стандартные механизмы КД3 почему-то не справляются или ведут себя непредсказуемо. Многие сталкиваются с тем, что КД3 либо неверно подгружает формат расширенного пакета, либо не формирует критически важную строку ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта(), необходимую для работы с расширениями. Рассмотрим эту проблему подробно и найдем пути её решения.

Особенности расширения XDTO-пакета для КД3

Расширение XDTO-пакета для использования с КД3 – это не просто добавление нового поля. Это многоступенчатый процесс, требующий глубокого понимания как структуры XDTO, так и внутренних механизмов КД3. Если наш архитектор требует делать все строго через расширения, это означает, что нам предстоит столкнуться с рядом нюансов. Давайте разберем основные шаги и моменты, на которые стоит обратить внимание.

Создание расширяющего XDTO-пакета. Мы начинаем с создания нового XDTO-пакета в конфигурации, который будет дополнять уже существующий стандартный пакет (например, EnterpriseData) — для такой задачи есть расширение EnterpriseData для регулярной синхронизации. Важно, чтобы этот расширяющий пакет явно наследовал от стандартного, используя директивы импорта. Это критично для корректной ссылки на базовые объекты формата и работы с их свойствами. Например, при расширении пакета EnterpriseData часто требуется явно включить ExchangeMessage в расширение:
```
<xs:import namespace="http://www.1c.ru/SSL/Exchange/Message" schemaLocation="ExchangeMessage.xsd"/>
<xs:import namespace="http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8" schemaLocation="EnterpriseData_1_8.xsd"/>
```
Именно эти импорты позволяют вашему расширяющему пакету "видеть" и ссылаться на типы, определенные в базовых пакетах.
Наполнение пакета новыми свойствами. После создания пакета мы добавляем в него новые типы и свойства, которые нам необходимы. В нашем случае это новый реквизит простого типа в табличной части документа. Для этого необходимо связать тип объекта, для которого расширяется табличная часть, с типом объекта базового пакета EnterpriseData. Важно понимать, что расширенный пакет должен включать не только сам этот тип объекта, но и все вышестоящие типы в иерархии базового пакета, чтобы КД3 могла корректно построить структуру. При добавлении новых свойств их пространство имен должно быть указано при инициализации и затем передано в качестве параметра ПространствоИмен в метод ДобавитьПКС(). В некоторых случаях полезно изучить конвертацию схемы XSD в модель XDTO, если вы планируете использовать сложные типы данных.
Идентичность схемы XSD. Крайне важно, чтобы схема XSD расширяющего XDTO-пакета была абсолютно идентична в обеих конфигурациях 1С, участвующих в обмене (источника и приемника), включая порядок объектов. Любое несоответствие может привести к ошибкам при загрузке формата в КД3 или некорректной конвертации данных.
Настройка конвертации в КД3. Это наиболее сложный этап. После экспорта XDTO-пакетов из конфигурации в .xsd файлы, нам необходимо загрузить структуру формата в КД3, а затем загрузить структуру метаданных конфигураций. Именно на этом этапе мы часто сталкиваемся с проблемами. Найти нужные элементы в структуре поможет портативный обозреватель правил конвертации свойств.
Выгрузка модуля менеджера обмена и доработка. Если КД3 все же удалось корректно загрузить формат, мы выгружаем модуль менеджера обмена из КД3 в конфигурацию, а затем дорабатываем модули конфигурации и правила регистрации, чтобы учесть новые реквизиты.

Проблемы с загрузкой расширенного формата в КД3 и магическая строка

Автор нашей темы столкнулся с двумя ключевыми проблемами: КД3 неверно подгружает формат и не формирует заветную строку ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта(). Давайте выясним причины этого поведения.

Почему КД3 не генерирует `ИнициализироватьРасширениеПравилаКонвертацииОбъекта`?

Эта строка является ключевой для работы с расширенными пакетами. Она позволяет КД3 понять, какие пространства имен относятся к расширениям и как с ними работать. Из обсуждения мы видим важный диагностический момент: КД3 генерирует вызов ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта только в том случае, если в объекте используется ПКС (правило конвертации свойства) с расширенным свойством формата.

Что это значит? Когда мы добавляем в расширенный XDTO-пакет новое свойство, а затем в КД3 создаем для него ПКС, КД3 должна распознать, что это свойство пришло из расширения. Если же КД3 «думает», что это обычное свойство базового формата, то и вызов для инициализации расширения не будет сгенерирован.

Рассмотрим, как это работает в разных версиях КД3:

В ранних версиях КД3 (до 3.1.2.21): Часто требовалось вручную добавлять вызовы процедуры ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта в модули конвертации и явно указывать ПравилоКонвертации.ПространствоИмен для новых типов в расширенном формате. Это был трудоемкий процесс, подверженный ошибкам.
В актуальных версиях КД3 (3.1.2.21 и выше): По идее, КД3 должна автоматически генерировать вызов ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта в правилах конвертации объектов (ПКО) расширяемых объектов формата. Кроме того, в ПКО расширяемых объектов для свойств, характерных для расширенного формата, должен быть корректно определен шестой параметр с пространством имен расширенного пакета.

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

Добавление нового реквизита в табличную часть документа: пошаговый подход

Для нашей задачи — добавления нового реквизита простого типа в табличную часть документа — рассмотрим шаги более детально, учитывая вышеупомянутые особенности. Для этого есть набор доработанных правил обмена EnterpriseData.

Определяем структуру XDTO.

В вашем расширяющем XDTO-пакете (например, MyExtension.xsd) необходимо определить новый тип, который будет представлять вашу расширенную табличную часть, наследуя его от базового типа табличной части EnterpriseData.
Затем в этом новом типе вы добавляете ваш новый реквизит.
Обязательно убедитесь, что ваш расширяющий пакет импортирует все необходимые базовые пакеты (ExchangeMessage, EnterpriseData) с правильными пространствами имен.

Пример (упрощенный, для понимания структуры):


<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:ent="http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8"
           xmlns:ext="http://www.mycompany.com/MyExtension"
           targetNamespace="http://www.mycompany.com/MyExtension"
           elementFormDefault="qualified">

    <xs:import namespace="http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8" schemaLocation="EnterpriseData_1_8.xsd"/>

    <xs:complexType name="Документ_МойДокумент.ТабличнаяЧасть1Расширение">
        <xs:complexContent>
            <xs:extension base="ent:Документ_МойДокумент.ТабличнаяЧасть1">
                <xs:sequence>
                    <xs:element name="НовыйРеквизит" type="xs:string" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <xs:complexType name="Документ_МойДокументРасширение">
        <xs:complexContent>
            <xs:extension base="ent:Документ_МойДокумент">
                <xs:sequence>
                    <xs:element name="ТабличнаяЧасть1" type="ext:Документ_МойДокумент.ТабличнаяЧасть1Расширение" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

</xs:schema>

Загрузка структуры формата в КД3.
- Экспортируйте все необходимые XDTO-пакеты (базовые и ваш расширяющий) из конфигурации в отдельные .xsd файлы.
- В КД3 сначала загрузите базовые пакеты, затем ваш расширяющий пакет.
Настройка правил конвертации объектов (ПКО) в КД3.
- Откройте ПКО для вашего документа и создайте ПКС для нового реквизита.
- Критически важно: убедитесь, что КД3 распознала пространство имен расширения.

Альтернативные подходы к расширению XDTO-пакета

Если борьба с КД3 кажется невыносимой, существуют альтернативные стратегии.

1. Расширение кодом (ручная доработка менеджера обмена)

Этот подход подразумевает, что мы позволяем КД3 сгенерировать базовый модуль обмена, а затем вручную дорабатываем его, чтобы учесть наши расширения.

Суть подхода:

Генерация модуля обмена в КД3 с минимальным учетом расширений.
Ручное добавление кода для обработки новых реквизитов через XDTOСвойство.

Недостатки: Сложность поддержки при перегенерации правил.

2. Полная замена EnterpriseData (копирование и доработка нового пакета)

Это более радикальный подход — создание копии стандартного XDTO-пакета со своими изменениями. Это позволяет избежать проблем с "нераспознаванием" расширений в КД3, но значительно усложняет обновление формата в будущем.

Выводы и рекомендации

Работа с расширениями XDTO-пакетов в КД3 требует методичного подхода и внимания к деталям.

Наши рекомендации:

Проверяйте версию КД3. Рекомендуется 3.1.2.21 или выше.
Тщательно проверяйте XSD-схемы. Любая ошибка в импортах приведет к неверной загрузке.
Понимание принципа генерации ИнициализироватьРасширениеПравилаКонвертацииОбъекта. Строка генерируется только при явном использовании расширенного свойства в ПКС.
Избегайте ручной доработки. Старайтесь, чтобы КД3 сама генерировала весь необходимый код для долгосрочной стабильности системы.

Несмотря на все сложности, расширение XDTO-пакетов и их интеграция с КД3 является мощным инструментом для обмена данными в 1С. Главное — это методичный подход и глубокое понимание принципов работы платформы.