Как добавить свои реквизиты в обмен EnterpriseData через расширение

Работа с технологией EnterpriseData в 1С часто требует передачи дополнительных данных, которые не предусмотрены в типовом формате. Существует два основных пути решения этой задачи: использование собственного XDTO-пакета в расширении или передача данных через свойство AdditionalInfo. Разберем оба метода подробно, научимся анализировать конфигурации и расширения на наличие ошибок, и выясним, как заставить систему «увидеть» ваши изменения.

Метод 1. Использование собственного XDTO-пакета в расширении

Это наиболее «правильный» с точки зрения архитектуры способ. Он позволяет расширить структуру XML-файла, добавляя в него новые узлы, соответствующие вашим реквизитам. Однако он требует строгого соблюдения последовательности действий в коде Менеджера универсального обмена. Если вы работаете со сторонними сервисами, вам может быть полезна предварительная конвертация схемы XSD в модель XDTO для корректного проектирования пакета.

Рассмотрим ситуацию, когда нам нужно добавить новые реквизиты в табличную часть документа ЗаказПоставщику. Сначала мы создаем XDTO-пакет в расширении с уникальным Namespace (Пространством имен). Затем необходимо переопределить правила конвертации объектов (ПКО).

Проанализируем пример кода для инициализации расширения правил:

&ИзменениеИКонтроль("ДобавитьПКО_Документ_ЗаказПоставщику_Отправка")
Процедура адмДобавитьПКО_Документ_ЗаказПоставщику_Отправка(ПравилаКонвертации)
    ПравилоКонвертации = ОбменДаннымиXDTOСервер.ИнициализироватьПравилоКонвертацииОбъекта(ПравилаКонвертации);
    ПравилоКонвертации.ИмяПКО = "Документ_ЗаказПоставщику_Отправка";
    ПравилоКонвертации.ОбъектДанных = Метаданные.Документы.ЗаказПоставщику;
    
    // Указываем пространство имен нашего расширенного пакета
    ПравилоКонвертации.ПространствоИмен = "http://admaurl/EnterpriseData/11.17.3"; 
    
    // Инициализируем расширение правила
    ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта(ПравилоКонвертации, ПравилоКонвертации.ПространствоИмен);
    
    // Указываем объект формата из нашего пакета
    ПравилоКонвертации.ОбъектФормата = "адмДокумент.ЗаказПоставщику"; 
    
    // Добавляем свои ПКС (правила конвертации свойств)
    СвойстваТЧ = ПравилоКонвертации.Свойства; // здесь подразумевается получение структуры ТЧ
    ДобавитьПКС(СвойстваТЧ, "", "Участок", 1, "Справочник_адмУчасток_Отправка", ПравилоКонвертации.ПространствоИмен);
КонецПроцедуры

Важный момент: если ваши реквизиты не появляются в XML, проверьте, заходит ли программа в обработчик ПриОтправкеДанных. Для нетиповых справочников необходимо также создать правила обработки данных (ПОД). Если объект не зарегистрирован в плане обмена, система проигнорирует ПКО; в этом случае поможет регистрация или удаление объектов из плана обмена с формы.

Выясним причину, по которой данные могут не выгружаться, даже если код кажется верным:

1. Кэширование: На сервере 1С схемы XDTO могут кэшироваться. После изменения пакета в расширении рекомендуется перезапустить рабочий процесс сервера.
2. Версия формата: В узлах плана обмена должна быть выбрана именно та версия формата, которую вы расширяете.
3. Синхронность в базах: Пакет XDTO с абсолютно идентичным URI должен присутствовать как в базе-источнике, так и в базе-приемнике. Если конфигурации баз различаются, может потребоваться адаптивная выгрузка и загрузка данных XML с гибкими отборами.

Метод 2. Использование секции AdditionalInfo (Дополнительные сведения)

Если работа с XDTO-схемами кажется слишком громоздкой или не удается добиться валидности XML, можно воспользоваться универсальным контейнером AdditionalInfo. Это строковый реквизит, который есть практически у каждого объекта в EnterpriseData.

Рассмотрим алгоритм реализации:

1. На стороне отправителя: В процедуре ПКО_..._ПриОтправкеДанных мы собираем все нужные нам дополнительные реквизиты в структуру и сериализуем её. Подобный экспорт любых документов базы в JSON позволяет передать данные любой сложности, записывая результат в ДанныеXDTO.AdditionalInfo.
2. На стороне приемника: В процедуре ПКО_..._ПередЗаписьюПолученныхДанных мы считываем эту строку, десериализуем JSON и заполняем реквизиты объекта ДанныеИБ.

Посмотрим на пример обработки в приемнике:

Процедура ПКО_Документ_СчетПоставщика_Получение_ПередЗаписьюПолученныхДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена, СтекВыгрузки)
    // Проверяем наличие данных в AdditionalInfo
    Если ДанныеXDTO.Свойства().Получить("AdditionalInfo") = Неопределено Тогда
        Возврат;
    КонецЕсли;
    
    // Если объект новый и еще не создан системой автоматически
    Если ДанныеИБ = Неопределено Тогда
        // В некоторых случаях может потребоваться инициализация нового объекта,
        // но лучше убедиться, что ПКО настроено на создание
        Возврат; 
    КонецЕсли;

    // Читаем JSON и заполняем реквизиты
    ДопДанные = ПрочитатьJSONДанные(ДанныеXDTO.AdditionalInfo);
    Для Каждого СтрокаТЧ Из ДопДанные.ТабличнаяЧасть Цикл
        // Логика поиска строки и заполнения нетипового реквизита
    КонецЦикла;
КонецПроцедуры

Нюанс с созданием объектов: Как было замечено в обсуждении, если ДанныеИБ = Неопределено, это означает, что объект не был найден в базе. Прямое создание документа через СоздатьДокумент() внутри этой процедуры — рискованный шаг. Правильнее будет обеспечить корректную работу типового механизма поиска и создания, а в ПередЗаписью только дозаполнять данные.

Сравнение подходов

Проанализируем ситуацию: какой метод выбрать? XDTO-пакеты обеспечивают строгую типизацию и наглядность в XML-файле. AdditionalInfo в связке с JSON гораздо более гибкий инструмент: вы можете менять состав передаваемых полей без правки XDTO-пакетов.

Практический совет: если вы добавляете 1-2 реквизита в шапку, XDTO — хороший выбор. Если же вам нужно передать сложные структуры, специфичные для вашей доработки ТЧ или целые наборы связанных данных, используйте JSON внутри AdditionalInfo. Это сэкономит время на «борьбу» с валидацией схем и позволит сосредоточиться на бизнес-логике переноса данных.