Сравнение инструментов Конвертация данных 2.1 и 3.0: что выбрать и почему специалисты до сих пор используют КД2?

← На главную

В среде разработчиков «1С» вопрос выбора между Конвертацией данных 2.1 (КД2) и Конвертацией данных 3.0/3.1 (КД3) остается одним из самых дискуссионных. На первый взгляд кажется, что КД3 — это просто следующая версия продукта, которая должна заменить предыдущую. Однако на практике это два принципиально разных инструмента, предназначенных для решения различных задач. Разберем подробно, в чем заключаются их отличия, почему «народ» до сих пор активно использует КД2 и в каких ситуациях переход на КД3 становится необходимостью.

Концептуальное различие: «Каждый с каждым» против «Множество к одному»

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

В КД2 используется подход «точка-точка». Чтобы связать все базы между собой, нам придется создать правила конвертации для каждой пары баз. Математически это $N \times (N-1)$ комплектов правил. Если в одной из конфигураций изменится структура метаданных (например, удалят реквизит или переименуют справочник), нам придется переписывать правила для всех связей этой базы. Это порождает огромные затраты на поддержку в больших распределенных системах.

В КД3 реализован совершенно иной подход — использование формата-посредника EnterpriseData. Здесь каждая база «общается» не напрямую с другой базой, а с универсальным форматом. Программисту нужно лишь научить конфигурацию выгружать свои данные в EnterpriseData и загружать их обратно. Если в системе появляется шестая база, нам достаточно настроить ее интеграцию с форматом, и она сразу сможет обмениваться данными со всеми остальными участниками процесса.

Архитектурные особенности: XML против XDTO

Разберем, как технически реализована логика преобразования данных в обоих инструментах. Выясним причину, по которой многие разработчики считают КД2 более гибкой, а КД3 — более надежной.

Особенности КД2:

Логика в XML: Все алгоритмы (ПВД, ПКС, ПВД) хранятся в виде текстовых строк внутри XML-файла правил.
Интерпретация кода: При обмене платформа считывает эти строки и выполняет их через функции Выполнить() или Вычислить().
Сложность отладки: Поскольку код не находится в конфигурации, обычный отладчик «не видит» его. Разработчикам приходится использовать специальные внешние обработки для отладки правил, что значительно замедляет процесс при возникновении сложных ошибок.
Гибкость: В КД2 можно «на лету» изменить логику, просто обновив файл правил в узле обмена, не меняя саму конфигурацию.

Особенности КД3:

Логика в модулях: Все обработчики событий обмена (например, «При отправке данных» или «Перед конвертацией объекта») пишутся непосредственно в программных модулях конфигурации или расширениях.
Типизация через XDTO: Обмен строится на основе XDTO-пакетов. Это гарантирует строгую структуру данных.
Полноценная отладка: Мы можем ставить точки останова прямо в конфигураторе, просматривать значения переменных и использовать все преимущества встроенного отладчика. Это делает КД3 гораздо более предсказуемым инструментом для промышленной разработки.

Когда стоит использовать КД2?

Рассмотрим сценарии, в которых «старая добрая» КД2 остается непревзойденным лидером. Проанализируем практические ситуации:

1. Разовый перенос данных. Если ваша задача — перенести остатки и справочники из старой базы (например, «1С:Бухгалтерия 7.7» или сильно кастомизированная «УПП 1.3») в новую «ERP 2.5», тратить время на освоение КД3 и описание формата EnterpriseData бессмысленно. В КД2 такие задачи решаются быстрее за счет автоматического сопоставления метаданных.

2. Обмен между нетиповыми конфигурациями. Если вы работаете с «нетленками», где структура объектов далека от стандартов фирмы «1С», вписать их в жесткие рамки EnterpriseData будет крайне трудозатратно. Проще набросать правила в КД2.

3. Необходимость быстрой правки «на коленке». В КД2 для изменения алгоритма выгрузки достаточно выслать клиенту файл XML. В КД3 любое изменение логики — это изменение программного кода, что зачастую требует обновления конфигурации или расширения, а также перезапуска сеансов пользователей.

В каких случаях КД3 незаменима?

Посмотрим на ситуацию со стороны современных требований к разработке. Выясним, почему КД3 — это стандарт для типовых решений.

1. Синхронизация типовых конфигураций. Все современные обмены между «УТ 11», «БП 3.0», «ЗУП 3.1» и «ERP» построены на КД3. Если вам нужно добавить один реквизит в типовой обмен, правильнее будет расширить XDTO-пакет и дописать код в модуле менеджера обмена через расширение, сохранив поддержку типового механизма.

2. Работа в облаке (1С:Fresh). В облачных сервисах выполнение произвольного кода через Выполнить() запрещено из соображений безопасности. Поэтому КД2 там работать не будет, и КД3 становится единственным легитимным способом настройки синхронизации.

3. Масштабируемые системы. Если в вашей ИТ-ландшафте более 3-4 баз, использование КД3 радикально снижает «стоимость владения» интеграцией. Вам не нужно помнить про десятки файлов правил; вы работаете с единым стандартом формата данных.

Пример реализации логики в КД3

Проанализируем фрагмент кода, который может встретиться при настройке обмена в КД3. В отличие от КД2, где мы бы писали это в окне «Перед выгрузкой» в отдельном приложении, здесь мы работаем в модуле менеджера обмена через БСП (Библиотеку стандартных подсистем).

Рассмотрим пример переопределения получения данных для выгрузки объекта:


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

Обратите внимание на использование ДанныеXDTO. Мы работаем с объектом как со структурой, свойства которой жестко определены схемой. Это исключает ошибки опечаток в именах полей, которые так часто встречаются в КД2.

Сложности перехода на КД3

Многие разработчики жалуются, что КД3 «не пошла в народ». Разберем основные причины этого явления:

Высокий порог входа: Нужно понимать работу XDTO, знать структуру БСП и уметь ориентироваться в модулях менеджеров обмена.
Трудоемкость расширения формата: Чтобы передать новое поле, которого нет в стандарте EnterpriseData, нужно выполнить цепочку действий: создать расширение, добавить в него XDTO-пакет, прописать соответствие в модулях. В КД2 это делается одной галочкой и строчкой кода.
Отсутствие наглядности: В КД2 мы видим дерево «Источник — Приемник». В КД3 мы видим код, который работает с абстрактным форматом, что требует более развитого абстрактного мышления и знания структуры формата.

Подведем итоги: что выбрать?

Проанализировав доводы опытных специалистов, можно сформулировать простое правило выбора:

Выбирайте КД2, если:

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

Выбирайте КД3, если:

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

В современной практике часто встречается и третий путь — использование HTTP-сервисов для передачи данных в формате JSON. Это еще более гибкий метод, который позволяет интегрировать «1С» с любыми внешними системами (сайтами, мобильными приложениями), однако он требует написания всей логики «с нуля», в то время как КД2 и КД3 предоставляют мощный готовый каркас для работы с объектами базы данных.