Что выбрать для обмена между нетиповой конфигурацией и БП 3.0: Конвертация данных 2.0 или 3.0?

← На главную

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

Архитектурные концепции: прямое сопоставление против формата-посредника

Для понимания разницы проанализируем принципы работы каждого инструмента:

КД 2.0 (Прямой обмен точка-точка): Логика строится на сопоставлении двух конкретных метаданных — базы-источника и базы-приемника. Формируется единый файл правил обмена (XML), в котором жестко описаны правила конвертации объектов (ПКО) и свойств (ПКС). Обработка УниверсальныйОбменДаннымиXML интерпретирует этот файл и выполняет алгоритмы на встроенном языке с помощью динамического исполнения кода. Если в одной из баз меняется реквизитный состав, правила требуют ручной корректировки.
КД 3.0 (Универсальный формат EnterpriseData): Архитектура использует единый формат-посредник на базе XDTO. Каждая база взаимодействует не с соседней конфигурацией, а со стандартизированным форматом EnterpriseData. Источник выгружает данные в формате XML/XDTO, а приемник считывает их и загружает в свои объекты по собственным правилам конвертации.

Плюсы и минусы КД 2.0 в связке со старыми конфигурациями

Рассмотрим особенности применения КД 2.0 при наличии самописной базы на обычных формах:

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

Особенности и барьеры внедрения КД 3.0 для нетиповых баз

Конвертация данных 3.0 предлагает мощный механизм интеграции, однако накладывает жесткие требования к архитектуре баз данных. Проанализируем ограничения:

Зависимость от БСП: КД 3.0 полностью опирается на подсистему «Обмен данными» из Библиотеки стандартных подсистем. Актуальные версии БСП требуют управляемого режима и версии платформы не ниже 8.3.14. Внедрить такие модули в базу на обычных формах со старым режимом совместимости технически крайне сложно или невозможно без переработки всей конфигурации.
Жесткость формата EnterpriseData: Обмен данными возможен только теми объектами, которые описаны в XDTO-пакете. Если в самописной базе есть уникальные документы или справочники (например, «Заявка на расходование ДС» с кастомными аналитиками), их невозможно передать штатно без расширения XDTO-схемы формата EnterpriseData или упаковки данных в структуру ДополнительныеРеквизиты (AdditionalInfo).
Удобство отладки и производительность: Логика правил КД 3.0 компилируется в виде чистого программного кода на встроенном языке (модуль менеджера плана обмена или внешняя обработка МенеджерОбменаЧерезУниверсальныйФормат). Это позволяет использовать штатные точки останова и замер производительности.

Как организовать интеграцию через EnterpriseData без внедрения БСП

Если поставлена цель использовать возможности КД 3.0 на стороне БП 3.0 (где правила уже встроены и поддерживаются разработчиками 1С), но в нетиповую базу внедрить БСП нельзя, рассмотрим альтернативный подход. Нетиповая база может напрямую формировать файл выгрузки по схеме EnterpriseData с помощью объектов платформы ЗаписьXML и ФабрикаXDTO.

Посмотрим на пример базовой сериализации данных через фабрику XDTO:


ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.ОткрытьФайл(ПутьКФайлу, "UTF-8");
ЗаписьXML.ЗаписатьОбъявлениеXML();

// Инициализируем корневой элемент сообщения формата EnterpriseData
ЗаписьXML.ЗаписатьНачалоЭлемента("Message", "http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8");

// Пример формирования объекта XDTO для выгрузки контрагента
ТипКонтрагента = ФабрикаXDTO.Тип("http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8", "Справочник.Контрагенты");
ОбъектXDTO = ФабрикаXDTO.Создать(ТипКонтрагента);
ОбъектXDTO.Наименование = ВыборкаКонтрагентов.Наименование;
ОбъектXDTO.ИНН = ВыборкаКонтрагентов.ИНН;
ОбъектXDTO.КПП = ВыборкаКонтрагентов.КПП;

ФабрикаXDTO.ЗаписатьXML(ЗаписьXML, ОбъектXDTO);

ЗаписьXML.ЗаписатьКонецЭлемента();
ЗаписьXML.Закрыть();

Сформированный файл загружается в БП 3.0 стандартной обработкой ВыгрузкаЗагрузкаEnterpriseData (раздел Все функции / Функции для технического специалиста - Обработки).

Итоговые рекомендации по выбору решения

Подведем итог и определим порядок действий при выборе технологии:

Выбираем КД 2.0, если:
1. Нетиповая база работает на обычных формах (режим совместимости 8.2 или ранние 8.3), внедрение подсистем БСП не планируется.
2. Обмен строится строго между двумя базами, а передаваемые структуры данных сильно отличаются от типовых объектов конфигураций 1С.
3. Требуется реализовать задачу в сжатые сроки с минимальными изменениями метаданных обеих конфигураций.
Выбираем КД 3.0 / EnterpriseData, если:
1. Интеграция строится в рамках единого информационного пространства из нескольких баз (например, УТ 11, ЗУП 3.1, БП 3.0), где БСП уже внедрена во все участники обмена.
2. В нетиповой конфигурации передаются стандартные бизнес-сущности (накладные, платежки, контрагенты, номенклатура), а базу БП 3.0 необходимо обновлять на новые релизы без регулярной правки правил обмена.
3. Есть возможность реализовать на стороне нетиповой базы автономный модуль формирования пакетов EnterpriseData без полного внедрения подсистем БСП.