Какую версию «Конвертации данных» выбрать для обмена КА 2.5 с БП 3.0?

Для обмена КА 2.5 → БП 3.0 я бы в первую очередь выбирал Конвертацию данных 3.0, если обе конфигурации поддерживают обмен через EnterpriseData, а доработки не требуют передачи полностью нетиповых объектов.

Если нужно передавать произвольные документы, собственные справочники и реквизиты, которых нет в EnterpriseData, тогда практичнее Конвертация данных 2.0.

## Основная разница

| Критерий | КД 2.0 | КД 3.0 |
|—|—|—|
| Принцип обмена | Прямые правила «КА 2.5 → БП 3.0» | Обмен обеих баз с универсальным форматом EnterpriseData |
| Тип правил | Индивидуальные для конкретной пары баз | Универсальные правила источника и приемника |
| Формат | Обычно XML по правилам КД 2 | EnterpriseData |
| Передача произвольных объектов | Гибкая | Ограничена составом EnterpriseData |
| Работа с типовыми КА и БП | Возможна | Основное назначение |
| Устойчивость к обновлениям типовых конфигураций | Ниже | Выше |
| Отладка | Сложнее | Удобнее |
| Возможность не снимать конфигурацию с поддержки | Обычно требуется внешняя обработка или доработки | Хорошо поддерживается через внешние правила и расширения |
| Настройка сложных преобразований | Очень гибкая | Гибкая, но в рамках структуры EnterpriseData |
| Подходит для обмена КА 2.5 → БП 3.0 | Да | Обычно предпочтительный вариант |

## Как работает КД 2.0

В КД 2.0 создаются правила непосредственно для конкретного направления:

Например, создается правило:

В нем настраиваются:

— соответствие объектов;
— правила поиска;
— соответствие реквизитов;
— правила конвертации значений;
— обработчики перед загрузкой и после загрузки;
— проведение документов;
— создание движений;
— заполнение дополнительных реквизитов;
— преобразование видов операций;
— загрузка нетиповых объектов.

КД 2.0 подходит, когда требуется жестко управлять каждым объектом и каждой парой конфигураций.

Например, в КА есть документ:

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

или:

В КД 2 это обычно реализуется более прямолинейно.

Недостаток заключается в том, что правила сильно зависят от структуры конкретных конфигураций. При существенном обновлении КА или БП правила приходится проверять и иногда переделывать.

## Как работает КД 3.0

КД 3.0 не строит обмен как прямую связку:

В основе используется универсальный формат:

У каждой конфигурации есть собственные правила преобразования во внутренний универсальный формат и обратно:

За счет этого правила не настолько жестко привязаны друг к другу. КА может обновляться отдельно от БП, а БП может обновляться чаще.

Упрощенно схема выглядит так:

Это особенно удобно, если:

— КА 2.5 остается на определенном релизе;
— БП 3.0 регулярно обновляется;
— конфигурации не сняты с поддержки;
— нужно изменить стандартную логику загрузки;
— необходимо использовать внешние правила обмена;
— передаваемые объекты уже поддерживаются EnterpriseData.

## Что выбрать именно для КА 2.5 и БП 3.0

### Выбирайте КД 3, если нужно доработать стандартную синхронизацию

Например, стандартный механизм не устраивает по следующим причинам:

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

Если сами объекты являются типовыми и передаются в рамках EnterpriseData, КД 3 будет более правильным инструментом.

В таком случае обычно не нужно полностью создавать обмен с нуля. Практичнее:

1. Проанализировать типовые правила синхронизации.
2. Найти место, где возникает ошибка.
3. Скопировать или переопределить необходимые правила.
4. Подключить внешнего менеджера обмена или расширение.
5. Оставить стандартную регистрацию объектов.
6. Изменить только проблемную логику.

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

### Выбирайте КД 2, если стандартный обмен принципиально не подходит

КД 2 лучше, если задача выглядит примерно так:

Также КД 2 предпочтительнее, если:

— требуется обмен собственными объектами КА;
— нужно передавать нетиповые справочники;
— необходимо передавать новые виды документов;
— нужно выгружать табличные части, отсутствующие в EnterpriseData;
— требуется сложное преобразование структуры документа;
— данные нужно передавать не в типовой документ БП, а в собственный документ или регистр;
— нужно обмениваться с конфигурацией, которая не поддерживает EnterpriseData;
— требуется полный контроль над XML-файлом;
— обмен должен быть построен независимо от механизмов БСП.

## Что важно проверить перед выбором КД 3

В КА 2.5 и БП 3.0 нужно проверить следующие возможности.

### 1. Поддерживается ли EnterpriseData

В конфигурациях должны присутствовать механизмы:

— синхронизации данных;
— универсального формата;
— плана обмена синхронизации;
— менеджера обмена через универсальный формат;
— регистрации объектов для обмена.

Если одна из конфигураций не поддерживает требуемый формат, КД 3 в стандартном варианте может не подойти.

### 2. Поддерживаются ли нужные объекты

Для каждого объекта нужно проверить:

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

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

1. передать его через AdditionalInfo;
2. использовать дополнительные свойства;
3. изменить схему формата;
4. выполнять заполнение на стороне приемника;
5. использовать КД 2 для этого объекта.

### 3. Какие именно недочеты есть в типовой синхронизации

Это важный момент. Не каждый недочет требует перехода на КД 2.

Например:

| Недочет | Возможное решение |
|—|—|
| Неверный поиск контрагента | Изменить правила поиска в КД 3 |
| Не заполняется договор | Доработать обработчик загрузки |
| Не передается дополнительный реквизит | AdditionalInfo, дополнительное свойство или расширение |
| Неверный вид операции | Алгоритм преобразования в КД 3 |
| Не загружается нестандартный документ | Возможно, потребуется КД 2 |
| Нужен новый табличный раздел | Проверить возможность изменения формата |
| Нужно создать документ, которого нет в EnterpriseData | Чаще всего КД 2 |
| Нужно загрузить данные в регистр напрямую | Обычно КД 2 или отдельная обработка |
| Нужно перенести историю нестандартных документов | Чаще всего КД 2 |

Если проблема только в заполнении реквизитов и алгоритмах, КД 3 обычно справится.

## Вариант с КД 3 без снятия БП с поддержки

Для БП 3.0 обычно можно использовать внешние правила.

Общая схема:

1. В КД 3 создаются правила обмена КА 2.5 с EnterpriseData.
2. Формируются правила загрузки в БП 3.0.
3. Правила выгружаются во внешнюю обработку.
4. В БП 3.0 создается или настраивается синхронизация.
5. В настройках синхронизации указывается внешний менеджер обмена.
6. При выполнении обмена используются внешние правила, а не измененный основной модуль конфигурации.

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

После этого становится доступно поле, в котором можно указать путь к внешнему менеджеру обмена.

Конкретные названия команд зависят от релиза БП и версии БСП, поэтому их нужно проверять в вашей конфигурации.

## КД 3 не обязательно означает полную замену типовой синхронизации

Можно использовать смешанный вариант:

— стандартную регистрацию объектов оставить;
— стандартный формат EnterpriseData оставить;
— изменить только правила выгрузки;
— изменить только правила загрузки;
— дополнительные алгоритмы вынести во внешнюю обработку;
— после загрузки выполнять отдельную обработку исправления данных.

Например:

Это обычно надежнее, чем полностью переписывать механизм обмена.

## Когда КД 2 может оказаться проще

Несмотря на возраст, КД 2 может быть удобнее для разового или специализированного переноса.

Например, нужно:

— один раз перенести документы за 5 лет;
— загрузить только закрытые периоды;
— не поддерживать постоянный обмен;
— изменить документы при загрузке;
— не использовать планы обмена;
— не регистрировать изменения;
— сформировать один или несколько XML-файлов;
— загрузить данные в сильно доработанную БП.

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

— контроль регистрации;
— контроль повторной выгрузки;
— контроль дублей;
— контроль версий правил;
— контроль удаления объектов;
— контроль очередности загрузки;
— восстановление после частичной ошибки;
— повторная загрузка отдельных объектов.

## На что обратить внимание при обмене документами

Обмен документами между КА и БП сложнее обмена справочниками.

Нужно заранее определить:

— какие документы передаются;
— за какой период;
— передаются ли проведенные документы;
— передаются ли непроведенные документы;
— нужно ли переносить пометки удаления;
— нужно ли переносить движения;
— нужно ли проводить документы в БП;
— в какой последовательности загружаются документы;
— как сопоставляются организации;
— как сопоставляются склады;
— как сопоставляются договоры;
— как сопоставляются статьи затрат;
— как сопоставляются счета учета;
— как передаются характеристики и серии;
— как передается НДС;
— как обрабатываются корректировки;
— как загружаются документы по взаиморасчетам.

Например, если в КА документ реализации формирует управленческие движения, а в БП должен сформировать бухгалтерские проводки, недостаточно просто перенести реквизиты документа. Нужно, чтобы в БП:

1. был корректно определен вид операции;
2. были заполнены счета учета;
3. были заполнены договор и расчетный документ;
4. были заполнены статьи доходов и расходов;
5. были заполнены настройки отражения;
6. документ был проведен;
7. движения соответствовали ожидаемому учету.

Иначе документ загрузится, но бухгалтерские отчеты могут не сформироваться.

## Производительность

Для небольших объемов данных подойдет как КД 2, так и КД 3.

Для больших объемов нужно заранее проектировать обмен:

— сначала загружать НСИ;
— потом начальные остатки;
— затем документы;
— документы передавать частями;
— не выгружать повторно уже загруженные справочники;
— использовать правила поиска;
— включать запоминание выгруженных объектов;
— избегать запросов внутри циклов;
— не проводить огромные пакеты одной транзакцией;
— разделять загрузку и проведение;
— вести журнал ошибок по отдельным объектам.

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

## Практическая рекомендация для вашей задачи

Для проекта КА 2.5 → БП 3.0 логика выбора такая:

### Берите КД 3, если

— обмен постоянный;
— обе базы типовые или умеренно доработанные;
— БП нужно оставить на поддержке;
— основные объекты есть в EnterpriseData;
— нужно исправить стандартную логику;
— нужно изменить соответствия и заполнение реквизитов;
— нужно управлять отбором и преобразованием документов;
— нужно сохранить совместимость с последующими обновлениями БП.

### Берите КД 2, если

— нужно передавать нетиповые объекты;
— есть собственные документы и справочники;
— нужно преобразовывать структуру объектов;
— объекты отсутствуют в EnterpriseData;
— нужно загружать данные напрямую в регистры;
— требуется полный контроль над XML;
— обмен будет разовым переносом;
— типовая архитектура EnterpriseData сильно ограничивает задачу.

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

Перед разработкой правил составьте таблицу:

| Объект КА | Объект БП | Передавать | Способ |
|—|—|—|—|
| Номенклатура | Номенклатура | Да | КД 3 |
| Контрагент | Контрагент | Да | КД 3 |
| Договор | Договор | Да | КД 3 |
| Реализация | Реализация | Да | КД 3 |
| Собственный документ | Нет аналога | Да | КД 2 или расширение формата |
| Дополнительный реквизит | Дополнительный реквизит | Да | КД 3 через дополнительные сведения или алгоритм |
| Нестандартная табличная часть | Нет аналога | Да | КД 2 или изменение EnterpriseData |
| Регистры накопления | Регистры БП | Возможно | Отдельная логика, чаще КД 2 |

Также рекомендую посмотреть здесь:

— https://infostart.ru/1c/articles/695523/
— https://infostart.ru/1c/articles/720321/
— https://infostart.ru/1c/articles/839146/