Как выбрать между КД2 и КД3 для переноса данных с изменением значений в идентичную базу 1С?

Часто перед разработчиками встает специфическая задача: необходимо организовать перенос документов из одной базы 1С в другую (абсолютно идентичную по конфигурации), но при этом "на лету" модифицировать данные. Ярким примером такой задачи является пересчет всех цен и сумм в документах из одной валюты в другую. Проанализируем ситуацию и разберем по шагам, какой инструмент — Конвертация данных 2 (КД2), Конвертация данных 3 (КД3) или альтернативные методы — подойдет для этого лучше всего.

Анализ Конвертации данных 2 (КД2)

Исторически КД2 является самым популярным инструментом для обмена данными. Для обмена между идентичными конфигурациями в КД2 можно практически в один клик создать автоматическое сопоставление метаданных.

Рассмотрим подробнее преимущества и недостатки этого подхода для нашей задачи:

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

Если вы выбираете КД2, посмотрим на пример того, как правильно обрабатывать пересчет. Недостаточно просто умножить сумму на курс в момент выгрузки. Рекомендуется использовать обработчик ПослеЗагрузки или ПриЗагрузке объекта в базе-приемнике. Перенесите документы "как есть", а затем вызовите экспортные методы документа для корректного пересчета налогов и итогов:

// Пример кода для обработчика "После загрузки" в КД2
Если Объект.Свойство("ВалютаДокумента") Тогда
    Объект.ВалютаДокумента = Справочники.Валюты.НайтиПоКоду("810"); // Нужная валюта
    Объект.КурсВзаиморасчетов = ПолучитьКурсВалютыНаДату(Объект.Дата);
    
    // Вызов типового метода конфигурации для пересчета ТЧ
    ОбработкаТабличныхЧастей.ПересчитатьСуммыДокумента(Объект);
КонецЕсли;

Анализ Конвертации данных 3 (EnterpriseData)

КД3 работает совершенно по иному принципу. Она использует универсальный формат EnterpriseData, а логика обмена вынесена из правил непосредственно в код самой конфигурации 1С (в общие модули).

Разберем, подойдет ли этот формат для модификации данных:

1. Отладка: Это главное преимущество. Вы можете поставить точку останова прямо в конфигураторе в модуле МенеджерОбменаЧерезУниверсальныйФормат и видеть, как формируются данные.
2. Избыточность для идентичных баз: Формат EnterpriseData является "усредненным". Если в ваших идентичных конфигурациях есть добавленные нетиповые реквизиты, типовой обмен их не увидит. Вам придется дорабатывать пакеты XDTO в обеих базах, что неоправданно долго для такой задачи.
3. Готовые модули: Можно взять типовой план обмена (например, обмен между двумя Бухгалтериями) и просто вмешаться в алгоритм заполнения цен.

Решение через типовой обмен и Расширения конфигурации

Если конфигурации типовые (или почти типовые), выясним причину, почему стоит отказаться от написания правил с нуля. Вместо этого можно настроить стандартный обмен через формат EnterpriseData, а логику пересчета валют внедрить в базу-приемник с помощью механизма расширений.

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

&После("ПриЗагрузкеДанных")
Процедура ПересчетВалют_ПриЗагрузкеДанных(ОбъектДанных, ПравилоКонвертации, Отказ)
    Если ТипЗнч(ОбъектДанных) = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
        // Получаем нужный курс из регистра
        НовыйКурс = РегистрыСведений.КурсыВалют.ПолучитьПоследнее(ОбъектДанных.Дата);
        
        Для Каждого СтрокаТЧ Из ОбъектДанных.Товары Цикл
            СтрокаТЧ.Цена = СтрокаТЧ.Цена * НовыйКурс.Курс;
            СтрокаТЧ.Сумма = СтрокаТЧ.Цена * СтрокаТЧ.Количество;
            // Логика расчета НДС
        КонецЦикла;
    КонецЕсли;
КонецПроцедуры

Альтернативный подход: HTTP-сервисы и формат JSON

Проанализируем ситуацию, если обмен должен быть не разовым, а постоянным (online-обмен). Стандартные XML-выгрузки (как КД2, так и КД3) создают файлы на диске и работают относительно медленно. Современным стандартом для таких задач является использование HTTP-сервисов и JSON.

1. В базе-приемнике публикуется HTTPСервис, ожидающий POST-запросы.
2. В базе-источнике при проведении документа формируется структура данных (Структура или Соответствие).
3. Данные сериализуются в JSON с помощью объекта ЗаписьJSON и отправляются по сети.
4. Пересчет цен можно сделать прямо в момент формирования структуры в базе-источнике (перед сериализацией).

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

Нюансы бизнес-логики: "Копейки раздора"

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

Если вы просто перемножите итоговую сумму документа на курс, у вас неизбежно поедут формулы в строчных частях. Всегда соблюдайте строгое правило пересчета:

1. Сначала пересчитывается базовая Цена с нужным округлением.
2. Затем вычисляется Сумма (Цена умноженная на Количество).
3. Только после этого рассчитывается СуммаНДС от новой суммы строки.

Также не забудьте настроить синхронизацию справочника Валюты и регистра сведений КурсыВалют. Если в базу-приемник не передать актуальные курсы на дату документа, при первом же перепроведении документа пользователем (или регламентным заданием) суммы могут быть искажены.

Подведение итогов

Подытожим критерии выбора для решения поставленной задачи:

1. Используйте КД2, если обмен нужен разово, конфигурации сильно кастомизированы, а вы уже уверенно владеете этим инструментом. Это сэкономит время на настройке.
2. Используйте КД3 (EnterpriseData) + Расширения, если конфигурации максимально близки к типовым и вы хотите использовать стандартные планы обмена, внедряясь в них кодом.
3. Разработайте интеграцию через HTTP-сервисы и JSON, если заказчику требуется постоянный обмен в режиме реального времени с высокой скоростью работы.