← На главную

При настройке обмена данными через «1С:Конвертацию данных 3.0» на базе универсального формата EnterpriseData разработчики часто сталкиваются с ситуацией, когда в конфигурации-источнике присутствует специфический объект (например, Справочник.МойСправочник), аналогов которому в стандартной XDTO-схеме формата попросту нет.

Разберем основные архитектурные подходы решения этой задачи: от штатного расширения формата XDTO до передачи данных внутри служебных полей типовых объектов.

Способ 1. Штатное расширение XDTO-пакета формата EnterpriseData

Наиболее правильным и поддерживаемым способом по стандартам разработки 1С является создание собственного пакета расширения XDTO. Это позволяет не снимать типовой формат с поддержки и корректно формировать валидные XML-сообщения.

Разберем процесс реализации по шагам:

1. Создание XDTO-пакета расширения. В конфигурации (или в расширении конфигурации) создаем отдельный XDTO-пакет со своим уникальным пространством имен (URI), например http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8/custom. В директивах импорта подключаем базовую схему EnterpriseData и описываем структуру нового типа данных (все необходимые свойства и типы реквизитов).
2. Симметричность схем. Обязательно добавляем этот же XDTO-пакет с идентичным пространством имен и составом свойств в конфигурацию-приемник. Без этого входящее сообщение не пройдет валидацию XDTO-схемы при разборе XML.
3. Регистрация расширения в БСП. Чтобы подсистема обмена данными распознала новый пакет, переопределяем процедуру в общем модуле ОбменДаннымиПереопределяемый:
   Скопировать код

   
   Процедура ПриПолученииДоступныхРасширенийФормата(РасширенияФормата) Экспорт
       
       // Регистрируем соответствие версии базового формата и нашего пространства имен
       НоваяСтрока = РасширенияФормата.Добавить();
       НоваяСтрока.ВерсияФормата = "1.8";
       НоваяСтрока.ПространствоИмен = "http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8/custom";
       
   КонецПроцедуры
   

4. Настройка правил в КД 3.0. Загружаем структуру конфигураций и расширенный формат в конфигурацию «Конвертация данных 3.0». Создаем новое ПКО (Правило конвертации объектов), ПОД (Правило обработки данных) и ПКС для нетипового справочника привычным визуальным способом.
5. Инициализация расширения в модуле менеджера обмена. При генерации модуля обмена для созданного ПКО вызываем процедуру регистрации расширения:
   Скопировать код

   
   ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта(
       ПравилоКонвертации, 
       "http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8/custom"
   );
   

6. Регистрация изменений. Не забываем включить созданный справочник в состав используемого плана обмена (например, СинхронизацияДанныхЧерезУниверсальныйФормат) и настроить правила регистрации данных (ПРД), иначе изменения не будут попадать в очередь выгрузки.

Способ 2. Использование похожего типа XDTO с условием в ПОД/ПКО

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

Чтобы избежать коллизий при чтении в базе-приемнике, проанализируем маршрутизацию в правилах обработки данных (ПОД):

1. При выгрузке заполняем в объекте формата служебное поле (например, ДополнительнаяИнформация или наименование), указывая строковый маркер исходного типа — "Справочник.МойСправочник".
2. В базе-приемнике в обработчике ПОД получения данных или в алгоритме выбора ПКО прописываем условие перенаправления:
   Скопировать код

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

Способ 3. Сериализация данных в JSON внутри универсального поля

Еще один гибкий вариант без доработки XDTO-схемы — передача структуры справочника в виде текстовой строки формата JSON внутри типового поля ДополнительнаяИнформация или через типовую табличную часть ДополнительныеРеквизиты базового объекта.

Рассмотрим логику работы:

1. На стороне источника: при формировании данных объекта сериализуем реквизиты в JSON с помощью объекта ЗаписьJSON и помещаем строку в доступное текстовое свойство сообщения.
2. На стороне приемника: в обработчике ПКО (например, ПослеЗагрузки или ПриКонвертацииДанныхXDTO) десериализуем строку обратно в структуру и программно создаем либо обновляем элемент нетипового справочника:
   Скопировать код

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

Какой вариант выбрать?

Проанализируем критерии выбора подхода для вашего проекта:

1. Расширение XDTO-пакета — рекомендуется для долгосрочных проектов с большим объемом передаваемых нестандартных данных. Обеспечивает строгую типизацию, валидацию и прозрачность правил в КД 3.0.
2. Маршрутизация через служебные поля (JSON / ПОД) — подходит для точечной передачи единичных справочников, когда доработка и синхронизация схем XDTO в обеих базах избыточна по трудозатратам.