← На главную

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

КД 2 против КД 3: архитектурные различия и назначение

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

1. Конвертация данных 2.0 (прямой обмен «точка-точка»):

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

2. Конвертация данных 3.0 (каноническая модель EnterpriseData):

   В КД 3 обмен строится по двухэтапной схеме через единый канонический формат: на стороне базы-источника данные преобразуются в XDTO-пакет формата EnterpriseData (Объект источника → Объект формата), а на стороне базы-приемника формат преобразуется во внутренние метаданные (Объект формата → Объект приемника). Каждая конфигурация содержит свой независимый комплект правил и ничего не знает о структуре другой программы. Это позволяет обновлять одну базу независимо от другой без поломки синхронизации.

Для связок современных типовых конфигураций (например, Бухгалтерия предприятия 3.0 и Управление торговлей 11) штатным механизмом является КД 3. Инструмент КД 2 остается актуальным для переноса данных между сильно кастомизированными или устаревшими конфигурациями (например, УПП 1.3, УТ 10.3), а также для сложных разовых переносов остатков и документов с сохранением специфических движений.

Как работает версионность формата EnterpriseData

Формат EnterpriseData развивается параллельно с развитием типовых конфигураций. Версии формата нумеруются по принципу Мажорная.Минорная.Ревизия (например, 1.3.2, 1.3.4, 1.5.1). Разберем правила их взаимодействия при синхронизации:

1. Совместимость в рамках одной минорной версии: Если одна база поддерживает формат 1.3.2, а вторая — 1.3.4, они работают корректно. Обе конфигурации используют ветку 1.3, в которой поддерживается обратная совместимость ревизий.
2. Совместимость между разными версиями (снизу вверх): В типовые конфигурации с подсистемой БСП встроена поддержка сразу нескольких версий формата (например, 1.0, 1.1, 1.2, 1.3). При первой настройке синхронизации программы согласуют максимальную общую поддерживаемую версию формата. Если База 1 умеет работать с форматами до 1.2, а База 2 — до 1.3, то сеанс обмена будет автоматически происходить по общему формату 1.2.

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

Почему возникают ошибки в ПКО и ПОД типового обмена

Когда штатная синхронизация между типовыми конфигурациями завершается ошибками в правилах конвертации объектов (ПКО) или правилах обработки данных (ПОД), причинами чаще всего являются:

1. Рассинхронизация версий конфигураций: Если одна из программ обновлена до актуального релиза, а вторая осталась на старом, встроенные алгоритмы могут передавать поля, которых нет в ожидаемой схеме, либо наоборот, ожидать обязательные реквизиты, не заполненные источником.
2. Нарушение ссылочной целостности: Наличие «битых ссылок» (объектов <Объект не найден>) в составе зарегистрированных к выгрузке данных приводит к исключениям в обработчиках выборки данных.
3. Несовпадение правил идентификации: Некорректное заполнение ключевых полей (ИНН/КПП у контрагентов, артикулов и штрихкодов у номенклатуры) вызывает сбои сопоставления при загрузке XDTO-пакета в базу-приемник.

Способы корректировки и отладки обмена на КД 3

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

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