Как настроить обмен EnterpriseData: исключение реквизитов, объектов и решение проблем с узлами?

При настройке обмена данными в формате EnterpriseData (ED) часто возникают задачи, требующие точечной доработки стандартного механизма. Например, может потребоваться исключить передачу некоторых данных или полностью запретить обмен для определенных типов объектов. Рассмотрим три частых вопроса, с которыми сталкиваются разработчики, и разберем практические способы их решения, даже если вы пока не готовы углубляться в Конвертацию Данных.

Вопрос 1: Как исключить реквизиты документа из обмена?

Представим ситуацию: нам нужно, чтобы при обмене документами, например, РеализацияТоваровУслуг, определенные реквизиты (скажем, Ответственный или Комментарий) не передавались в другую базу. Интуитивно хочется вмешаться в процесс отправки данных.

Частая ошибка — пытаться закомментировать строки, отвечающие за выгрузку реквизита, в процедуре _Отправка модуля менеджера обмена для нужного документа. Это приводит к неожиданному результату: реквизит все равно попадает в файл обмена, но в виде пустой ссылки. Система обмена знает из правил, что реквизит должен быть выгружен, и, не найдя его прямого значения, пытается выгрузить его как объект по ссылке, что нам совершенно не нужно.

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

Решение: Модификация процедуры получения данных

Вместо того чтобы изменять процедуру отправки, найдем процедуру, отвечающую за загрузку данных этого документа в базе-приемнике. Как правило, такие процедуры имеют название вида ДобавитьПКО_[ИмяОбъекта]_Получение в модуле менеджера обмена. ПКО расшифровывается как "Правило Конвертации Объекта".

Разберем по шагам, что нужно сделать:

1. Откройте конфигурацию базы-приемника.
2. Найдите модуль менеджера, отвечающий за обмен. Обычно его можно найти через глобальный поиск по конфигурации по имени объекта, например, "ОбменДаннымиПереопределяемый".
3. В этом модуле найдите процедуру, ответственную за загрузку нужного документа. Для документа "Реализация товаров и услуг" она может называться ДобавитьПКО_Документ_РеализацияТоваровУслуг_Получение.
4. Внутри этой процедуры найдите строки кода, которые отвечают за сопоставление и загрузку ненужных вам реквизитов.
5. Закомментируйте эти строки.

Посмотрим на гипотетический пример. Допустим, в процедуре есть такой код:

Процедура ДобавитьПКО_Документ_РеализацияТоваровУслуг_Получение(Правила)

    // ... прочий код ...

    // Добавляем ПКС (Правило Конвертации Свойства) для реквизита "Ответственный"
    ОбменДаннымиXDTO.ДобавитьПКС(Правила, "Ответственный", "Ответственный");

    // Добавляем ПКС для реквизита "Комментарий"
    ОбменДаннымиXDTO.ДобавитьПКС(Правила, "Комментарий", "Комментарий");

    // ... прочий код ...

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

Чтобы исключить эти реквизиты из загрузки, достаточно закомментировать соответствующие строки:

Процедура ДобавитьПКО_Документ_РеализацияТоваровУслуг_Получение(Правила)

    // ... прочий код ...

    // // Добавляем ПКС (Правило Конвертации Свойства) для реквизита "Ответственный"
    // ОбменДаннымиXDTO.ДобавитьПКС(Правила, "Ответственный", "Ответственный");

    // // Добавляем ПКС для реквизита "Комментарий"
    // ОбменДаннымиXDTO.ДобавитьПКС(Правила, "Комментарий", "Комментарий");

    // ... прочий код ...

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

Таким образом, данные реквизиты будут приходить в файле обмена, но система в базе-приемнике их просто проигнорирует. Это простой и быстрый способ решить задачу без редактирования правил в Конвертации Данных.

Вопрос 2: Как полностью запретить выгрузку объектов определенного типа?

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

Решение 1: Отключить регистрацию изменений

Это самый простой и "правильный" способ. Механизм обмена основан на регистрации изменений объектов. Если регистрация для какого-то типа объектов отключена, они просто не попадут в очередь на выгрузку.

1. Откройте нужный план обмена в режиме конфигуратора.
2. Перейдите на вкладку "Состав".
3. Найдите в дереве объектов тот, который нужно исключить (например, Справочник.Пользователи).
4. Убедитесь, что для этого объекта и его реквизитов снята галочка авторегистрации.

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

Решение 2: Программная отмена выгрузки через обработчик события

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

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

Разберем по шагам:

1. В конфигураторе откройте модуль менеджера справочника Пользователи.
2. Создайте в нем экспортную процедуру с именем ПриОтправкеДанныхПодчиненному. Система обмена автоматически вызовет ее для каждого элемента справочника перед отправкой.
3. Внутри процедуры мы можем проанализировать отправляемый объект и принять решение об отмене его выгрузки.

Посмотрим на пример кода:

// Модуль менеджера справочника "Пользователи"

Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, Узел) Экспорт

    // Для полного запрета выгрузки всех пользователей
    // просто устанавливаем флаг "Отказ" в Истину.
    ЭлементДанных.Отказаться = Истина;

    // Можно добавить условия, например, не выгружать неактивных пользователей
    // Если НЕ ЭлементДанных.Данные.Недействителен Тогда
    //     ЭлементДанных.Отказаться = Истина;
    // КонецЕсли;

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

В этом коде ЭлементДанных — это специальный объект, содержащий выгружаемые данные и служебную информацию. Установив его свойство Отказаться в Истина, мы даем команду системе обмена пропустить этот конкретный объект и не включать его в сообщение обмена. Этот метод гарантированно предотвратит выгрузку, даже если объект был зарегистрирован принудительно.

Вопрос 3: Почему возникают проблемы с ГУИДами узлов при обмене с несколькими базами?

Рассмотрим типичный сценарий: есть одна база "Управление торговлей" (УТ) и две базы "Бухгалтерия предприятия" (БП). Обмен с первой БП настроился легко, а со второй возникли проблемы: БП не видит файл обмена, приходится вручную "танцевать" с кодами узлов. В чем причина?

Причина: Неуникальность идентификаторов узлов

Ответ кроется в назначении кодов узлов в планах обмена. Часто кодам узлов присваиваются ГУИДы (глобально уникальные идентификаторы). Это делается для того, чтобы каждый участник обмена во всей распределенной системе имел свой, абсолютно уникальный идентификатор. Это позволяет избежать путаницы, когда одна центральная база обменивается данными с несколькими периферийными.

Когда вы настраиваете обмен, в каждой базе создается два узла: один для самой себя, другой для корреспондента. Система должна четко понимать, от кого пришел файл и для кого он предназначен.

Проблема возникает, когда при настройке второго обмена (УТ -> вторая БП) используются коды или префиксы, которые уже задействованы в первом обмене (УТ -> первая БП). Например, если в обеих базах БП узел для УТ будет иметь одинаковый код, система запутается.

Решение: Обеспечение уникальности настроек

Чтобы обмен заработал корректно, необходимо тщательно проверить и обеспечить уникальность настроек в каждой из баз.

1. В центральной базе (УТ):
   • Создайте две отдельные настройки обмена: одну для первой БП, другую для второй БП.
   • В плане обмена в УТ будет три узла: один для самой УТ (центральный узел) и по одному для каждой из баз БП.
   • Убедитесь, что коды и, что еще важнее, префиксы для всех трех узлов уникальны. Например: УТ (префикс "УТ"), БП1 (префикс "Б1"), БП2 (префикс "Б2").
2. В каждой базе-корреспонденте (БП1 и БП2):
   • В базе БП1 в плане обмена должно быть два узла: один для самой БП1 (с кодом и префиксом "Б1"), второй для УТ (с кодом и префиксом "УТ").
   • Аналогично в базе БП2: один узел для себя (с кодом и префиксом "Б2"), второй для УТ (с кодом и префиксом "УТ").
   • Критически важно, чтобы код узла, соответствующий базе УТ, был одинаковым в обеих базах БП и совпадал с кодом собственного узла в самой УТ. То же самое касается и кодов для БП1 и БП2 в базе УТ — они должны совпадать с кодами собственных узлов в этих базах.

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