Как выгрузить справочник, отсутствующий в Универсальном формате (EnterpriseData) в 1С?

При интеграции конфигураций «1С:Предприятия» с помощью технологии Конвертации данных 3.0 (КД 3.0) разработчики часто сталкиваются с жестким ограничением: архитектура обмена построена вокруг Универсального формата (EnterpriseData). В отличие от старой доброй Конвертации данных 2.0, где правила описывали прямой перенос «Источник -> Приемник», в КД 3.0 схема выглядит как «Источник -> Универсальный формат -> Приемник». Такой подход гарантирует слабую связанность систем, но создает серьезную проблему, если в используемой версии формата отсутствует необходимый нам прикладной объект.

Представим ситуацию: в обеих базах (и в источнике, и в приемнике) есть нужный нам справочник (например, БрендыНоменклатуры или ВидыСкидок), но в XML-схеме EnterpriseData (XDTO-пакете) такого типа данных просто нет. Как быть в этой ситуации? Рассмотрим подробнее несколько практических, надежных и элегантных способов решения этой задачи — от простых обходных путей до использования передовых механизмов Библиотеки стандартных подсистем (БСП).

Способ 1. Использование схожего по смыслу объекта формата («Коробка для гвоздей»)

Проанализируем аналогию, прозвучавшую на форуме: если вам нужно перенести шурупы, а у вас есть только коробка с надписью «Гвозди», вы можете временно насыпать шурупы в эту коробку, перенести их и на складе получателя разложить в правильные ячейки. В КД 3.0 этот метод вполне жизнеспособен.

Суть метода заключается в том, что мы привязываем наш нетиповой справочник к любому подходящему по структуре справочнику из формата EnterpriseData. Например, мы можем использовать объект формата Справочник.КлассификаторВидовЭкономическойДеятельности или любой другой простой справочник, имеющий поля Код, Наименование и Предопределенный.

Разберем по шагам, как это настроить:

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

Преимущества метода:

• Простота реализации. Не требуется вносить изменения в метаданные конфигураций или XDTO-пакеты.
• Полная совместимость со стандартными планами обмена и типовыми правилами.

Недостатки метода:

• Метод является «костылем» с точки зрения архитектуры. Если в будущем вам действительно понадобится переносить реальный классификатор видов деятельности, возникнет жесткий конфликт правил.
• Код становится сложным для понимания другими разработчиками, которым придется разбираться, почему бренды переносятся под видом классификаторов.

Способ 2. Использование свойства AdditionalInfo (Дополнительные свойства)

Более элегантным и технологичным способом передачи нетиповых данных без изменения схемы формата является использование стандартного свойства AdditionalInfo. Практически каждый объект в схеме EnterpriseData имеет предопределенное поле AdditionalInfo с типом anyType (произвольный тип). Это штатная «лазейка», оставленная разработчиками фирмы «1С» специально для нестандартных сценариев интеграции.

Этот метод идеально подходит, если ваш отсутствующий в формате справочник логически связан с каким-то другим, типовым объектом. Например, справочник БрендыНоменклатуры выступает в качестве реквизита справочника Номенклатура.

Рассмотрим пример реализации этого подхода на уровне кода.

На стороне источника в обработчике ПКО номенклатуры (например, в событии ПриОтправкеДанных или непосредственно при заполнении свойств XDTO) мы упаковываем данные бренда в структуру и помещаем их в AdditionalInfo:

// Пример кода на стороне источника (КД 3.0 / БСП)
// В обработчике конвертации номенклатуры в данные формата

ДанныеБренда = Новый Структура;
ДанныеБренда.Вставить("Код", ДанныеИмпорта.Бренд.Код);
ДанныеБренда.Вставить("Наименование", ДанныеИмпорта.Бренд.Наименование);
ДанныеБренда.Вставить("УИД", Строка(ДанныеИмпорта.Бренд.УникальныйИдентификатор()));

// Сериализуем структуру в XML или JSON и записываем в AdditionalInfo
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ДанныеБренда);
СтрокаДанныхБренда = ЗаписьJSON.Закрыть();

// Записываем строковое представление данных в объект формата
ДанныеФормата.AdditionalInfo = СтрокаДанныхБренда;

На стороне приемника в обработчике загрузки (например, в событии ПередЗаписьюПолученныхДанных или ПослеЗагрузки для номенклатуры) мы извлекаем эти данные, программно создаем или находим нужный бренд и записываем ссылку на него в реквизит загруженной номенклатуры:

// Пример кода на стороне приемника
// Извлекаем данные из AdditionalInfo

Если ЗначениеЗаполнено(ДанныеФормата.AdditionalInfo) Тогда
    
    Попытка
        ЧтениеJSON = Новый ЧтениеJSON;
        ЧтениеJSON.УстановитьСтроку(ДанныеФормата.AdditionalInfo);
        СтруктураБренда = ПрочитатьJSON(ЧтениеJSON);
        ЧтениеJSON.Закрыть();
        
        // Ищем бренд по уникальному идентификатору или коду
        СсылкаНаБренд = Справочники.БрендыНоменклатуры.ПолучитьСсылку(Новый УникальныйИдентификатор(СтруктураБренда.УИД));
        
        Если Не ЗначениеЗаполнено(СсылкаНаБренд.ПолучитьОбъект()) Тогда
            // Если объект не найден, создаем новый
            НовыйБренд = Справочники.БрендыНоменклатуры.СоздатьЭлемент();
            НовыйБренд.Код = СтруктураБренда.Код;
            НовыйБренд.Наименование = СтруктураБренда.Наименование;
            НовыйБренд.УстановитьСсылкуНового(СсылкаНаБренд);
            НовыйБренд.Записать();
        КонецЕсли;
        
        // Устанавливаем ссылку в реквизит объекта номенклатуры
        ПолученныеДанные.Бренд = СсылкаНаБренд;
        
    Исключение
        ЗаписьЖурналаРегистрации("ОбменДанными.ЗагрузкаБренда", 
            УровеньЖурналаРегистрации.Ошибка,,, 
            ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
    КонецПопытки;
    
КонецЕсли;

Преимущества метода:

• Формат обмена остается абсолютно стандартным и «чистым». Конфигурации не нужно снимать с поддержки.
• Метод максимально надежен, так как данные передаются строго в привязке к основному объекту.

Недостатки метода:

• Метод трудно использовать для переноса полностью независимых объектов, которые не связаны с другими типовыми справочниками и документами.

Способ 3. Расширение формата обмена EnterpriseData (XDTO-расширение)

Самым правильным, профессиональным и современным подходом является создание XDTO-расширения формата обмена. В современных версиях Библиотеки стандартных подсистем (начиная с БСП 3.1.3) этот механизм поддерживается на штатном уровне. Он позволяет расширять схему EnterpriseData собственными типами объектов, не нарушая при этом стандартную поддержку конфигурации.

Проанализируем, как устроен этот процесс:

1. Создание расширения XDTO: В конфигураторе (или в расширении конфигурации) создается новый XDTO-пакет. В нем прописывается собственное уникальное пространство имен (URI пространства имен), и этот пакет импортирует базовый пакет EnterpriseData. Внутри вашего пакета описывается структура нового объекта (например, BrandType со свойствами Key, Description).
2. Регистрация расширения в БСП: Чтобы БСП узнала о новом расширенном формате, необходимо зарегистрировать его пространство имен в общем модуле ОбменДаннымиПереопределяемый в процедуре ПриПолученииДоступныхРасширенийФормата.
   Скопировать код

   
   Процедура ПриПолученииДоступныхРасширенийФормата(МассивРасширений) Экспорт
       МассивРасширений.Добавить("http://www.yourcompany.ru/EnterpriseData/Extension/1.0");
   КонецПроцедуры
   

3. Настройка правил в КД 3.0: Вы выгружаете схему формата с учетом вашего расширения, загружаете ее в КД 3.0 и получаете возможность создавать полноценные ПКО и ПОД для вашего кастомного справочника так же, как если бы он изначально присутствовал в стандарте EnterpriseData.

Преимущества метода:

• Это максимально «чистое» с точки зрения архитектуры решение.
• Позволяет переносить любые независимые структуры данных любой сложности.
• Полностью поддерживается экосистемой БСП и Конвертацией данных 3.0.

Недостатки метода:

• Высокий порог входа. Требуется хорошее понимание принципов работы XDTO-схем, пространств имен и механизмов расширений 1С.

Способ 4. Использование дополнительных реквизитов БСП

Если отсутствующий в формате справочник фактически выполняет роль дополнительной аналитики для других объектов (например, «Сезонность» у номенклатуры), можно использовать штатный механизм БСП — Дополнительные реквизиты и сведения.

В EnterpriseData этот механизм отлично поддерживается по умолчанию. Данные дополнительных реквизитов автоматически выгружаются в коллекцию AdditionalProperties (Дополнительные свойства) объектов формата. На стороне приемника БСП сама распределит эти значения по соответствующим элементам ПВХ ДополнительныеРеквизитыИСведения.

Для реализации этого метода вам вообще не придется писать код в правилах обмена — достаточно выполнить пользовательские настройки состава дополнительных реквизитов в обеих базах.

Резюме: какой способ выбрать?

Выбор оптимального способа зависит от ваших задач и сложности переносимых данных:

• Если вам нужно быстро перенести один простой справочник, который жестко связан с основным документом или номенклатурой — смело используйте Способ 2 (свойство AdditionalInfo). Это быстро и надежно.
• Если вы проектируете крупную корпоративную интеграционную систему со множеством уникальных справочников и документов — лучшим решением будет потратить время и реализовать Способ 3 (XDTO-расширение формата).
• Если данные носят характер простой аналитики — используйте стандартные дополнительные реквизиты БСП (Способ 4).
• К Способу 1 («Коробка для гвоздей») стоит прибегать только в крайних случаях, когда сроки поджимают, а объем переносимых данных минимален.