Почему при обмене 1С (УТ и Розница) перезаписываются чужие документы и как исправить дубли ID объектов?

Рассмотрим ситуацию, с которой иногда сталкиваются при эксплуатации распределенных информационных баз (РИБ) или настроенных обменов по правилам конвертации. Имеется стабильно работающий годами обмен, например, между центральной базой «1С:Управление торговлей 10.3» и множеством периферийных узлов «1С:Розница 2.2». Внезапно выясняется, что несколько узлов Розницы начали «перебивать» друг другу документы при выгрузке в центральную базу.

Проанализируем ситуацию глубже: открыв регистр сведений СоответствиеОбъектовДляОбмена (или аналогичный регистр публичных идентификаторов), мы обнаруживаем, что документам, созданным в разных периферийных базах, присвоены абсолютно одинаковые идентификаторы (GUID). Из-за этого при загрузке пакета данных система воспринимает их как один и тот же объект и просто перезаписывает данные.

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

Как работает механизм сопоставления объектов

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

Алгоритм при загрузке работает так:

1. Система получает XML-сообщение обмена с данными документа и его переданным идентификатором.
2. Идет поиск в регистре соответствий по этому идентификатору и узлу обмена.
3. Если запись найдена — система обновляет найденный локальный объект. Если нет — создает новый и записывает связь в регистр.

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

Основные причины появления дублей идентификаторов

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

1. Вмешательство в правила обмена (Конвертация данных). Разработчики могли внести изменения в правила выгрузки (в обработчики «При выгрузке», «Перед загрузкой» или в поля поиска). Если для объекта принудительно формируется GUID на основе номера, даты или комбинации реквизитов, то при совпадении этих реквизитов (например, одинаковый номер документа) сгенерируется идентичный идентификатор. Ищите в коде вызовы функций вроде УстановитьУникальныйИдентификатор().
2. Проблема с префиксами баз. Если у разных узлов Розницы слетели настройки префиксов, они начнут нумеровать документы одинаково (например, документ «000000001»). Если правила обмена завязаны на поиске или генерации ключа по номеру, это приведет к склейке документов.
3. Клонирование баз (копирование вместо создания начального образа). Если новые узлы создавались простым копированием папки с базой старого узла, внутри остались скрытые записи регистра обмена и кэшированные идентификаторы, что рано или поздно приведет к коллизиям.
4. Совпадение GUID у разных типов объектов. Редкая ошибка, при которой правила поиска не проверяют строго тип значения (например, путают Реализацию и Поступление с одинаковыми идентификаторами).
5. Внешние загрузки данных. Использование сторонних обработок для загрузки из Excel, которые жестко синхронизируют элементы по коду и принудительно записывают «свои» связи в регистр соответствий.

Как решить проблему и исправить дубли

Посмотрим на практические шаги по устранению этой проблемы. Просто очистить регистр в одной базе недостаточно — при следующем обмене дубли прилетят снова.

Шаг 1. Анализ XML-файла выгрузки

Сначала нужно доказать, что проблема исходит из узла отправки. Выгрузите проблемный документ в файл с помощью стандартной обработки «Универсальный обмен данными в формате XML».

Откройте полученный XML-файл в текстовом редакторе и найдите тег с УИД документа (обычно это Ссылка или атрибут УникальныйИдентификатор). Сделайте то же самое во второй проблемной базе. Если GUID в файлах совпадают — проблема на 100% в правилах выгрузки или префиксах на стороне Розницы.

Шаг 2. Проверка алгоритмов в правилах обмена (КД 2.0)

Проанализируем правила конвертации объектов. Откройте правила обмена в конфигурации «Конвертация данных 2.0». Найдите проблемные документы. Проверьте вкладку «События» у Правил Конвертации Объектов (ПКО). Ищите подобный код:

// Пример потенциально опасного кода в правилах выгрузки
СтрокаУИД = ПолучитьУИДПоНомеру(Источник.Номер);
УстановитьУникальныйИдентификатор(СтрокаУИД);

Если такой код есть, и он опирается на номер документа, вам необходимо срочно проверить уникальность префиксов узлов РИБ в настройках Розницы.

Шаг 3. Синхронная очистка регистра и кэша обмена

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

1. Остановите фоновые задания обмена во всех базах.
2. Удалите зависшие файлы обмена (сообщения XML) из каталогов обмена или FTP.
3. Откройте центральную базу (УТ 10.3) и проблемные узлы (Розница 2.2).
4. В каждой базе очистите регистр СоответствиеОбъектовДляОбмена (можно удалить записи только для проблемных узлов и типов документов, чтобы не гонять весь объем данных заново).
5. Убедитесь, что префиксы узлов уникальны и документы в разных базах имеют разные номера.
6. Запустите выгрузку из узлов в центр. Регистр заполнится заново, но уже с правильными, уникальными связями.

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