Как настроить обмен по формату EnterpriseData в КД 3.0 для нетиповой конфигурации?

При разработке обменов данными через конфигурацию «Конвертация данных 3.0» (КД 3.0) разработчики часто сталкиваются с ситуацией, когда в исходной отраслевой или самописной конфигурации отсутствуют типовые XDTO-пакеты формата EnterpriseData и ExchangeMessage. Разберем по шагам, как правильно добавить формат в нетиповую базу, сопоставить отраслевые документы со стандартными сущностями формата и избежать типичных синтаксических ошибок при выгрузке программного кода правил.

Шаг 1. Добавление пакета EnterpriseData в нетиповую конфигурацию

Создавать XDTO-пакет вручную с нуля в дереве метаданных не требуется — это слишком трудоемко и неизбежно приведет к ошибкам в типах данных. Для добавления формата в базу-источник выберем один из двух штатных путей:

1. Экспорт и импорт XML-схемы (XSD): Откроем типовую конфигурацию (например, «Бухгалтерия предприятия» или «ERP»), найдем в ветке XDTO-пакеты нужный пакет формата актуальной версии (например, EnterpriseData_1_4_2). Нажмем на нем правой кнопкой мыши и выберем пункт «Экспорт XML-схемы». Затем откроем нетиповую конфигурацию, создадим новый пустой XDTO-пакет и выполним команду «Импортировать схему XML».
2. Копирование через буфер обмена: Можно открыть две конфигурации в режиме «Конфигуратор», скопировать ветку XDTO-пакета из типовой базы и вставить в дерево метаданных своей нетиповой конфигурации. Также не забываем скопировать пакет ExchangeMessage, который отвечает за транспортную обертку сообщения обмена.
3. Использование поставки БСП: Если в конфигурацию внедрена «Библиотека стандартных подсистем» (БСП), возьмем готовые объекты метаданных и подсистему «Обмен данными» из дистрибутива БСП согласно документации на ИТС.

В саму конфигурацию «Конвертация данных 3.0» формат EnterpriseData загружается через стандартную обработку загрузки структуры формата напрямую из файла схемы .xsd без необходимости прямого подключения к рабочей информационной базе.

Шаг 2. Сопоставление нетиповых документов со стандартным форматом

Разберем ситуацию, когда в отраслевой конфигурации есть документы, которых нет в типовых решениях (например, специфические документы списания или начисления), но данные по ним должны попадать в бухгалтерскую базу (например, в документы «Реализация товаров и услуг», «Отчет о розничных продажах» или «Счет на оплату покупателю»).

Вносить изменения в схему формата и добавлять собственные типы данных XDTO следует только в крайнем случае, так как модификация XDTO-пакета усложнит последующие обновления конфигураций и потребует ручной доработки алгоритмов чтения в базе-приемнике. Рассмотрим правильный подход к сопоставлению данных:

1. Мэппинг на существующие типы формата: Если отраслевой документ отражает торговую или расчетную операцию, сопоставим его с подходящим типом EnterpriseData (например, Документ.ОтчетОРозничныхПродажах или Документ.СчетНаОплатуКлиенту). В КД 3.0 для этого создается отдельное Правило обработки данных (ПОД) для исходного документа, которое направляет выгрузку в стандартное Правило конвертации объекта (ПКО).
2. Сведение нескольких документов к одному ПКО: В КД 3.0 допускается создавать несколько правил ПОД для разных объектов метаданных источника, которые будут использовать одно и то же правило ПКО для формирования единого типа объекта формата.
3. Передача специфических реквизитов: Если необходимо передать дополнительные свойства, которых нет в базовом составе реквизитов типа XDTO, используем табличную часть ДополнительныеРеквизиты объекта формата. Это избавит от необходимости ломать структуру XSD и нарушать валидацию при десериализации.

Шаг 3. Устранение синтаксических ошибок в именах процедур модуля обмена

При генерации модуля правил КД 3.0 формирует программный код на встроенном языке 1С, создавая процедуры инициализации правил вида ДобавитьПОД_ИмяПравила() и ДобавитьПКО_ИмяПравила(). Если при настройке правил в КД 3.0 были допущены синтаксические неточности, сформированный модуль вызовет синтаксическую ошибку платформы при компиляции.

Рассмотрим пример некорректно сгенерированного кода:

#Область Отправка
#Область СправочникСсылка.Контрагенты
Процедура ДобавитьПОД_СправочникСсылка.Контрагенты(ПравилаОбработкиДанных)
    // Ошибка: точка в имени процедуры недопустима в синтаксисе 1С
КонецПроцедуры
#КонецОбласти
#КонецОбласти

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

Для исправления ошибки выполним следующие действия в КД 3.0:

1. Откроем форму соответствующего правила ПОД.
2. В поле «Идентификатор» зададим корректное строковое имя без точек, спецсимволов и пробелов. Рекомендуется использовать шаблон с подчеркиваниями, например: Справочник_Контрагенты_Отправка или СправочникСсылка_Контрагенты.
3. Проверим аналогичные поля идентификаторов в правилах ПКО (Правила конвертации объектов) и ПХД (Правила конвертации предопределенных данных).
4. Повторно запустим выгрузку модуля МенеджерОбменаЧерезУниверсальныйФормат.

Посмотрим на пример корректно сгенерированного кода процедуры:

#Область Отправка
#Область Справочник_Контрагенты
Процедура ДобавитьПОД_Справочник_Контрагенты_Отправка(ПравилаОбработкиДанных)
    Правило = ПравилаОбработкиДанных.Добавить();
    Правило.Имя = "Справочник_Контрагенты_Отправка";
    Правило.ОбъектВыгрузки = "СправочникСсылка.Контрагенты";
    Правило.ПравилоКонвертации = "Справочник_Контрагенты";
КонецПроцедуры
#КонецОбласти
#КонецОбласти

Соблюдение правил именования идентификаторов и использование стандартных типов формата EnterpriseData гарантируют стабильную работу обмена и простоту сопровождения конфигурации при дальнейших обновлениях.