Как настроить двусторонний обмен в 1С:Конвертация данных 3.0 и решить типичные ошибки при переходе

← На главную

Переход с технологии Конвертация данных 2.0 на версию 3.0 — это не просто обновление правил, это смена парадигмы. В КД 3.0 мы работаем через универсальный формат EnterpriseData, где вместо прямого маппинга «Объект-Объект» используется посредник в виде XDTO-пакетов. Рассмотрим подробнее, с какими трудностями сталкиваются разработчики при первой настройке такого обмена и как их преодолеть.

Управление начальной выгрузкой данных

Часто при первой настройке синхронизации между уже работающими базами (например, УНФ и БП) система пытается выгрузить десятки тысяч старых записей. Проанализируем, как взять этот процесс под контроль.

В КД 3.0 механизм регистрации изменений завязан на Планы обмена. Чтобы не выгружать всё подряд, выполним следующие шаги:

Откроем форму настройки синхронизации данных.
Найдем кнопку «Состав отправляемых данных» (в некоторых конфигурациях она находится в меню «Параметры синхронизации»).
В открывшемся окне выберем все объекты и нажмем «Отменить регистрацию». Это полностью очистит очередь выгрузки.
Если данные всё равно продолжают регистрироваться, проверим наличие обработчиков в модуле менеджера обмена, которые могут программно добавлять связанные объекты в очередь.

Почему файл выгрузки пуст при наличии зарегистрированных объектов

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

Основная логика фильтрации в КД 3.0 сосредоточена в правилах ПОД (Порядок обработки данных). Рассмотрим основные факторы:

Программные фильтры в ПОД: Если в обработчике ПриОбработке прописано условие, которое не выполняется (например, проверка на вид операции или дату), объект не будет выгружен.
Отсутствие ПКО: Если для объекта в ПОД не указано ПКО (Правило конвертации объектов), система «не знает», как упаковать данные в формат XDTO.
Инструкция удаления: Если объект зарегистрирован, но не проходит по фильтрам, КД 3.0 может вместо данных отправить инструкцию на удаление этого объекта в базе-приемнике. Это поведение регулируется флагами в обработчиках отправки.

Исправление ошибки «Значение не является значением объектного типа (ПолучитьСсылку)»

Проанализируем критическую ошибку, которая часто возникает при загрузке данных в приемник. Стек ошибки обычно указывает на общий модуль ОбменДаннымиXDTOСервер. Эта проблема связана с тем, что система не может сопоставить входящий тип данных XDTO с метаданными текущей конфигурации.

Для решения этой проблемы выполним следующие действия:

Проверка соответствия версий формата: Убедимся, что обе базы используют одну и ту же версию EnterpriseData (например, 1.10). Если отправитель шлет данные в версии, которую приемник не поддерживает, менеджер метаданных вернет Неопределено при попытке получить ссылку.
Анализ связанных справочников: Ошибка часто возникает, если документ ссылается на справочник, который не был передан или его тип не описан в правилах. Если справочник передается только как «Ссылка», а в базе-приемнике такого UUID нет, и не настроено создание нового объекта, возникает сбой.
Отладка XDTO: Рекомендуется использовать обработку «Менеджер обмена объектами XDTO» для пошаговой проверки загрузки конкретного XML-файла. Это позволит увидеть, на каком именно реквизите происходит вызов метода ПолучитьСсылку у пустого объекта.

Работа с префиксами и номерами документов

Посмотрим, как настраивается нумерация при обмене между УНФ и БУХ. В КД 3.0 правила обычно не меняют номер документа «на лету», это задача системных механизмов БСП.

Если номера приходят с неверными префиксами, проверим следующее:

В настройках синхронизации (раздел «Служебная информация») проверьте Префикс информационной базы.
В коде правил КД 3.0 обратите внимание на обработчик ПКО_..._Отправка_ПриОтправкеДанных. Именно там может быть прописана логика модификации номера перед упаковкой в XML.
Помните, что при записи в приемнике часто срабатывает событие ПриУстановкеНовогоНомера, которое добавляет префикс уже на стороне получателя.

Как запретить перезапись существующих объектов

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

Для реализации этой логики необходимо внести изменения в правила приемника (модуль менеджера обмена или через конфигурацию КД 3.1). Разберем пример кода в обработчике ПередЗаписьюПолученныхДанных для ПКО:


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

КонецПроцедуры

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