← На главную

При попытке настроить нетиповой или односторонний обмен данными в современных типовых конфигурациях 1С (включая 1С:Бухгалтерия предприятия 3.0) разработчики часто сталкиваются с неожиданной ситуацией: в составе метаданных планов обмена находятся только макеты с правилами регистрации объектов, а привычный макет ПравилаОбмена отсутствует.

Рассмотрим подробнее, с чем связаны такие изменения в архитектуре типовых решений, как теперь устроена конвертация данных и какими способами можно доработать или настроить собственный обмен.

Причина отсутствия макетов правил обмена

Разберем эволюцию механизмов интеграции в решениях на платформе 1С:Предприятие 8.3. В старых конфигурациях и при использовании технологии Конвертация данных 2.0 (КД 2.1) правила конвертации объектов выгружались в виде XML-файлов и вшивались непосредственно в макеты планов обмена (например, ПравилаОбмена или ПравилаОбменаЗагрузка).

В современных конфигурациях фирма «1С» полностью перешла на Универсальный формат обмена (EnterpriseData) и концепцию Конвертации данных 3.0. Ключевые особенности этой архитектуры:

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

Как устроена конвертация данных 3.0 (EnterpriseData)

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

1. Объект источника конвертируется в XML-структуру формата EnterpriseData (согласно XDTO-схеме).
2. XML-структура формата EnterpriseData конвертируется в объект приемника.

За обработку этих этапов отвечает программный код в модуле менеджера обмена. Поэтому правила конвертации хранятся в коде общего модуля МенеджерОбменаЧерезУниверсальныйФормат, а не в текстовых макетах.

Как редактировать и дорабатывать правила обмена в КД 3.0

Если требуется изменить стандартную логику выгрузки/загрузки или настроить нетиповой обмен, разберем по шагам правильный алгоритм действий:

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

Альтернативные варианты для реализации нетипового обмена

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

1. Использование классической КД 2.1 и внешнего XML-файла: Не обязательно вшивать правила в макеты плана обмена. Вы можете выгрузить структуру метаданных через ВыгрузкаСтруктурыМетаданных.epf, настроить правила в «Конвертации данных 2.1» и использовать сформированный XML-файл в типовой обработке УниверсальныйОбменДаннымиXML или загрузить его в регистр сведений ПравилаДляОбменаДанными.
2. Передача произвольных данных через AdditionalInfo: В формате EnterpriseData для передачи дополнительных нетиповых реквизитов предусмотрена встроенная коллекция AdditionalInfo, что позволяет передавать произвольные данные без изменения XDTO-схемы формата.
3. Использование HTTP-сервисов или Web-API: Для точечного интеграционного взаимодействия часто эффективнее написать собственный HTTP-сервис или задействовать OData, обмениваясь данными в формате JSON.