Почему при загрузке данных объекты повторно регистрируются к обмену и улетают обратно?

Многие разработчики, настраивающие обмен между конфигурациями (например, УТ 10.3 и УТ 11), сталкиваются с неприятным явлением: при загрузке данных элемент справочника или документ сразу же регистрируется к отправке в тот же узел, из которого он только что был получен. В результате возникает «эффект бумеранга» — объект бесконечно «гуляет» между базами. Давайте разберем, почему это происходит и как это исправить.

Понимание природы проблемы

Основное заблуждение заключается в надежде на флаг ОбменДанными.Загрузка = Истина. Многие полагают, что при установке этого значения платформа автоматически «забывает» о необходимости регистрации изменений. Однако это не так.

Механизм Авторегистрация в планах обмена — это встроенная функция платформы 1С. Она срабатывает на уровне ядра при вызове метода Записать() объекта. Флаг ОбменДанными.Загрузка отключает выполнение подписок на события и проверки, но он не отменяет автоматическую регистрацию изменений в таблицах регистрации плана обмена, если она включена в составе плана в конфигураторе.

Решение 1: Отключение авторегистрации в конфигураторе

Если вы используете стандартные механизмы обмена (особенно БСП), первое правило — не доверять штатной авторегистрации платформы. В документации к БСП прямо сказано, что при работе с обменами авторегистрацию в свойствах плана обмена рекомендуется отключать.

1. Откройте конфигуратор вашей базы УТ 11.
2. Найдите нужный ПланОбмена в дереве метаданных.
3. Перейдите на вкладку Состав.
4. Установите значение Авторегистрация в режим Запретить.
5. Теперь регистрация объектов должна осуществляться либо кодом самой БСП, либо через специально настроенные правила регистрации (ПРО) в Конвертации Данных 2.0.

Решение 2: Программная блокировка регистрации через дополнительные свойства

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

Рассмотрим пример того, как в коде можно отследить необходимость регистрации:

// Пример логики в модуле объекта или подписке на событие
Если Объект.ДополнительныеСвойства.Свойство("РегистрироватьОбъектНаУзлеОтправителе") Тогда
    // Если этот флаг установлен, принудительно обнуляем отправителя
    // чтобы механизм регистрации не сработал для узла-источника
    Объект.ОбменДанными.Отправитель = Неопределено;
КонецЕсли;

Этот подход требует, чтобы при загрузке данных (в правилах конвертации или в модуле обмена) вы явно добавляли свойство РегистрироватьОбъектНаУзлеОтправителе в коллекцию ДополнительныеСвойства записываемого объекта.

Решение 3: Использование правил регистрации (ПРО)

Это самый профессиональный способ решения задачи. В Конвертации данных 2.0 вы можете создать правила регистрации объектов. В них можно прописать алгоритм на 1С, который будет анализировать объект перед записью.

Внутри правил вы можете:

• Проверить текущий узел обмена.
• Сравнить его с отправителем данных.
• Если они совпадают, использовать метод ПланыОбмена.УдалитьРегистрацию(Узел, Объект), чтобы «отменить» запись в таблицу изменений, которую только что произвела платформа.

Почему возникают повторные записи?

Часто в отладчике можно заметить, что объект записывается дважды. Первый раз — это непосредственная загрузка данных. Второй раз — это может быть работа механизмов платформы при изменении номера принятого сообщения или выполнении фоновых операций БСП. Анализируя структуру метаданных, мы видим, что во втором случае Отправитель может быть пустым. Именно в этот момент авторегистрация может сработать «по умолчанию», так как для нее запись объекта с пустым отправителем выглядит как изменение, которое нужно передать во все узлы.

Рекомендации по итогам анализа

Чтобы раз и навсегда решить проблему:

1. Проверьте, используется ли в конфигурации БСП. Если да — строго следуйте правилам библиотеки: отключайте Авторегистрацию в метаданных и используйте штатные процедуры регистрации.
2. Если БСП нет, и вы пишете свой обмен: реализуйте принудительную отмену регистрации через метод УдалитьРегистрацию в модуле объекта, если объект был получен в процессе загрузки.
3. Всегда используйте ОбменДанными.Загрузка = Истина, чтобы исключить лишние проверки и записи, но помните, что это лишь вспомогательный флаг, а не панацея от авторегистрации.

Работа с обменами требует дисциплины в коде. Помните, что каждый объект, записываемый в базу при обмене, должен быть «помечен» как полученный извне, чтобы система обмена могла принять осознанное решение: отправлять его обратно или нет.