Отличия между 1С: КД 2 и КД 3 (между 1С:Конвертация данных 2.0 и 3.0)

Конвертация данных и обмен XML: о чём вообще речь

Оба инструмента — и Конвертация данных 2.0, и Конвертация данных 3.0 — делают одну и ту же магию: данные из базы А оказываются в базе Б, С, D и дальше по алфавиту. Пользователю обычно всё равно, чем вы это сделали, а вот разработчику — совсем не всё равно, потому что от выбора технологии зависит сложность сопровождения, стабильность обмена и цена всей затеи.

Если сильно упростить, КД 2 — это «старый добрый обмен XML по правилам», а КД 3 — это «обмен через XDTO и универсальный формат EnterpriseData», завязанный на БСП и облачные требования. При этом это не «новая версия той же штуки», а фактически две разные парадигмы работы с обменом 1С, каждая со своей нишей.

Обмен XML в КД 2: как устроен процесс

В Конвертации данных 2.0 всё крутится вокруг XML‑правил и внешних обработок. Сначала вы выгружаете структуру метаданных конфигураций в XML с помощью MD80Exp/MD83Exp, чтобы КД знала, какие объекты есть в источнике и приёмнике. Потом в конфигурации «1С:Конвертация данных 2» настраиваете правила обмена КД: соответствия объектов, отборы, преобразование реквизитов, события до/после выгрузки и загрузки.

Когда правила готовы, в базе‑источнике запускается обработка V8Exchan/V8Exchan83, которая формирует один большой XML‑файл: внутри и данные, и инструкции, как их грузить на другой стороне. В базе‑получателе этим же «универсальным обменом XML» файл загружается, и движок КД 2 пошагово интерпретирует описанные правила. По сути это интерпретатор: правила читаются «на лету», куски кода выполняются через Выполнить(), и за счёт этого КД 2 очень гибко подстраивается под любые конфигурации.

Конвертация данных 3.0 и обмен XDTO: другой мир

КД 3.0 работает иначе: она не интерпретирует XML‑файл с правилами, а генерирует программный код — модули менеджера обмена, которые встраиваются в конфигурацию или расширение. Вместо точечного обмена XML между двумя базами используется стандарт EnterpriseData (ED), реализованный через XDTO‑пакеты и подсистему «Обмен данными» из БСП.

В конфигурации вы увидите пакеты XDTO, план обмена «СинхронизацияДанныхЧерезУниверсальныйФормат», менеджер обмена, модули ОбменДаннымиXDTOСервер, ОбменДаннымиПереопределяемый, регистр настроек обмена XDTO и так далее. Схема простая по идее, но не по реализации: объект конфигурации превращается в структуру ED, сериализуется в XDTO, отправляется в другую базу, там разворачивается обратно и записывается в свои объекты.

Смена парадигмы обмена КД: интерпретатор против кодогенератора

Главное архитектурное отличие: КД 2 — интерпретатор правил обмена XML, КД 3 — кодогенератор обмена XDTO. В КД 2 вы меняете XML‑файл с правилами — и при следующем запуске универсального обмена платформа сразу исполняет обновлённую логику. В КД 3 любое изменение обмена — это изменение сгенерированного кода, пересборка конфигурации/расширения и новый цикл доставки на рабочие базы.

Зато у кодогенерации есть свои приятные бонусы: запрещён произвольный исполняемый код из XML‑файла, что важно для облака (1С:Фреш и прочие SaaS‑сценарии), а скомпилированные модули обычно работают быстрее, чем интерпретируемый текст правил. Цена вопроса — более тяжёлый жизненный цикл разработки и обновлений, особенно если вы привыкли «подкрутить одно поле» в обмене XML прямо в правилах КД 2.

Обмен КД 2 на XML: сильные стороны старого подхода

Конвертация данных 2 ценится за адаптивность: можно настроить обмен КД между типовыми и нетиповыми конфигурациями примерно с одинаковой трудоёмкостью, потому что вы полностью контролируете правила. Для нестандартных, сильно доработанных баз это зачастую единственный вменяемый путь: описали соответствия справочников, документов, регистров — и повели данные по своему сценарию, не подгоняя всё под жесткую схему ED.

Правила КД 2 хорошо ложатся на разовые переносы: миграция с 7.7 на 8.3, перенос данных из «умирающей» нетленки в современную типовую, объединение нескольких баз в одну. Разработчикам с опытом проще быстро собрать нужный обмен XML, чем пытаться вписать экзотику заказчика в универсальный формат обмена XDTO.

Обмен XML в КД 2: где начинаются боли сопровождения

Главный минус КД 2 — сопровождение в долгую, особенно если обе стороны живут на типовых и регулярно обновляются. Каждый релиз конфигурации меняет метаданные: реквизиты переименовали, структуру справочника поправили, добавили новую табличную часть — и все эти изменения нужно отразить в правилах обмена КД.

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

Обмен XDTO в КД 3: плюсы новой архитектуры

В КД 3 обмен строится вокруг универсального формата EnterpriseData, а не вокруг структуры метаданных конкретной конфигурации — это ключевой плюс. База‑источник выгружает свои объекты в ED, база‑приёмник загружает из ED в свои объекты, и при обновлении конфигурации чаще всего править нужно только ту сторону, где что‑то поменялось.

Кроме того, ED и XDTO‑описания упрощают интеграцию с внешними системами, не обязательно на 1С: если система понимает структуру XDTO‑пакета, она может обмениваться данными без прямой привязки к метаданным 1С. Плюс сама технология КД 3 развивается и поддерживается, в отличие от КД 2, что для долгосрочных корпоративных проектов всё‑таки важно.

Обмен XDTO и КД 3: подводные камни и жёсткость стандарта

За универсальность приходится платить: XDTO требует строгого описания структуры данных, любое дополнительное поле — это изменение XDTO‑схемы, обновление модулей обмена, повторное тестирование. На небольших проектах это ощущается как «забиваем гвозди микроскопом» — особенно когда нужно просто добавить один реквизит в обмен.

При больших объёмах данных дерево XDTO съедает заметно больше оперативной памяти, чем потоковая запись XML в КД 2, и это может стать узким местом. Ещё один нюанс: если заказчик активно дорабатывает конфигурации, ED быстро перестаёт быть «типовым» — приходится расширять формат, а это усложняет сопровождение и может привести к тем же «нереально сложным» обменам, от которых изначально хотели уйти.

Математика обменов КД: факториал N и концепция точка–формат

Зачем вообще придумали КД 3 с EnterpriseData? Представьте десять конфигураций, которые должны обмениваться данными друг с другом по принципу «каждая с каждой». В парадигме КД 2 это N! связей: для 10 систем порядка девяноста пар обменов КД, которые нужно разработать, тестировать и поддерживать.

КД 3 уводит нас в подход «точка–формат»: каждая конфигурация учится выгружать в универсальный формат ED и загружать из него. Для тех же десяти систем получается всего двадцать направлений (выгрузка и загрузка для каждой базы), а не девяносто, и это кардинально упрощает сопровождение промышленной интеграции. Для крупного холдинга с «зоопарком» типовых конфигураций это не теория, а реальная экономия бюджета и нервов.

Когда выбирать обмен XML на КД 2: практический взгляд

КД 2 логично выбрать, когда задача — разовый или редкий перенос: миграция на новую конфигурацию, объединение нескольких баз, перенос огромных объёмов исторических данных, которые вручную не перетащишь. Там достаточно создать грамотные правила обмена XML, прогнать несколько итераций, убедиться, что всё сошлось, и про обмен можно на время забыть.

Вторая типичная зона применения — нетиповые и сильно кастомизированные конфигурации без БСП, где внедрение КД 3 ради одного проекта выглядит неразумно. Третья — интеграции с внешними шинами и сервисами, где удобнее управлять форматом XML напрямую и использовать свои сценарии конвертации, чем подстраиваться под EnterpriseData.

Когда ставить на обмен XDTO и КД 3: критерии выбора

КД 3 оправдывает себя там, где обмен — это не «разово перенести остатки», а постоянная, промышленная интеграция множества баз. Особенно если это типовые конфигурации (БП, УТ, ERP и т.п.), которые и так уже содержат поддержку универсального формата обмена и нужные объекты ED и XDTO.

Если решение должно работать в облаке (1С:Фреш), вопрос безопасности и запрета выполнения произвольного кода из XML становится критичным, и здесь КД 3 — естественный выбор. К тому же для типового‑к‑типовому обмена через ED стабильность при обновлениях конфигураций обычно выше, чем при ручной поддержке десятков правил КД 2.

Отладка обменов XML и XDTO: где проще жить разработчику

В КД 3 вся логика обмена XDTO живёт в обычных модулях менеджера обмена и общих модулях БСП, поэтому её удобно отлаживать стандартным пошаговым отладчиком: поставили точку останова, прошлись по коду, посмотрели значения параметров. Это привычный для 1С‑разработчика процесс, хорошо вписывающийся в нормальный жизненный цикл разработки.

В КД 2 обработчики часто спрятаны глубоко в XML‑правилах, и отладка превращается в квест: нужно выводить отладочную информацию, временно переписывать логику в общие модули или использовать дополнительные приёмы. Частично это лечится вынесением сложной логики из правил обмена в отдельные модули, которые уже можно отлаживать нормально, но порог входа для новичков от этого ниже не становится.

БСП и обмен XDTO в КД 3: цена входа

КД 3 жёстко опирается на Библиотеку стандартных подсистем: подсистему «Обмен данными», модули XDTO‑сериализации, инфраструктуру плана обмена. Для старой «нетленки» без БСП интеграция КД 3 означает сначала протащить кусок библиотеки, разобраться с её архитектурой, а уже потом думать про обмен XDTO.

С одной стороны, это даёт богатый набор стандартных возможностей: веб‑сервисы, синхронизация по расписанию, гибкие настройки направлений обмена. С другой — сильно повышает порог входа: начинающему специалисту придётся одновременно разбираться и в БСП, и в XDTO, и в самой методике EnterpriseData, прежде чем он уверенно настроит первый обмен КД 3.

Переход с обмена XML КД 2 на обмен XDTO КД 3: разумная стратегия

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

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

Небольшое отступление: как начинающему 1С‑нику не утонуть в обменах

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

Главное — увидеть глазами, как элемент из одного справочника превращается в XML‑узел, как он приезжает в другую базу и записывается в нужный объект. Потом уже гораздо легче понять, что делает EnterpriseData и чем обмен XDTO отличается от обычного обмена XML, а не наоборот. И да, иногда полезно просто открыть готовый файл обмена и спокойно его «почитать на ночь», а не сразу смотреть в модуль менеджера обмена на тысячу строк.

Типичные ошибки при выборе формата обмена КД

Первая распространённая ошибка — тянуть КД 3 туда, где нужен разовый или очень гибкий перенос: например, сложная миграция из старой кастомной конфигурации с кучей нетиповых объектов. В итоге команда тратит массу времени на подгонку под ED, хотя тот же результат можно было получить быстрее и дешевле через обмен XML на КД 2.

Вторая ошибка — наоборот, упираться в КД 2, когда уже понятно, что конфигураций много, они типовые и будут годами обновляться, причём в разных релизах. Там, где количество связей растёт как факториал, точка–формат (EnterpriseData) объективно лучше, и здесь обмен XDTO в КД 3 раскрывает себя на полную. Ошибка не в том, чтобы любить КД 2 или КД 3, а в том, чтобы пытаться решать неправильным инструментом системную задачу.

MoscowSoft, обмен XML и готовые правила Конвертации данных

Если говорить о реальной практике, сильно экономят время готовые правила обмена КД 2 в формате XML, особенно для популярных направлений переноса данных. У компании MoscowSoft таких правил много: готовые модули переноса между типовыми конфигурациями (КА 2, УТ 11, УНФ, ЗУП и другими), построенные поверх «1С:Конвертация данных 2» и «универсального обмена XML». Их можно подобрать и купить на сайтах MoscowSoft и Sky1C, в том числе через каталог переносов данных 1С.

MoscowSoft с 2019 года является партнёром фирмы 1С, а с 2023 года — аккредитованная ИТ‑компания с портфелем более чем из 60 программных продуктов, включённых в реестр российского ПО. Основная специализация — переносы данных 1С и интеграция, поэтому, если нет желания «изобретать обмен XML с нуля», можно либо взять готовые правила Конвертации данных 2, либо заказать доработку под свой кейс у команды, которая этим занимается каждый день. Для начинающего специалиста это, кстати, тоже хороший способ учиться — разбирать боевые правила обмена КД и смотреть, как это делают в продакшене.

Ещё одно отступление: обмен КД — это не только про технику

Иногда кажется, что выбор между КД 2 и КД 3 — это чисто технический вопрос: интерпретатор или кодогенератор, XML или XDTO, БСП или без БСП. Но на практике половина успеха зависит от того, насколько вы договорились с бизнесом о границах обмена: какие данные действительно нужны, как часто, с какой ответственностью за результат.

Бывали проекты, где технически всё было сделано идеально, а обменом никто не пользовался, потому что «ну мы передума́ли, нам отчёты в Excel важнее». И наоборот: кривоватый обмен XML на КД 2 годами спасал людей, пока они спокойно перестраивали учёт. Поэтому, выбирая между КД 2 и КД 3, полезно сначала честно спросить заказчика: «Вы это строите на годы или хотите просто нормально переехать?» — а уж потом открывать конфигуратор.

Итоги: Конвертация данных 2 и 3 — инструменты, а не религия

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

Оба механизмы честно выполняют свою задачу: данные из точки А оказываются в точке Б, всё остальное — вопрос архитектуры и здравого смысла. Поэтому вместо споров «КД 2 устарела» или «КД 3 сырая» полезнее задавать другой вопрос: под вашу конкретную задачу — с её сроками, бюджетами, рисками и перспективой развития — какая Конвертация данных действительно работает на вас, а не против вас?