При настройке обмена данными между конфигурациями 1С, например, при переходе с «Бухгалтерии предприятия 2.0» на версию 3.0, специалисты часто сталкиваются с техническими сложностями в работе служебных регистров. Одним из наиболее проблемных объектов является регистр сведений СоответствиеОбъектовИнформационныхБаз. В этой статье мы подробно разберем, почему в нем могут накапливаться десятки тысяч записей, почему они не удаляются автоматически и как восстановить нормальную скорость обмена.
Рассмотрим типичную ситуацию: настроен обмен (часто односторонний для бизнес-логики, но технически двусторонний) между базами. В базе-приемнике (БП 3.0) в регистре СоответствиеОбъектовИнформационныхБаз скапливается огромное количество записей к регистрации (например, 87 000 из 150 000). Это приводит к тому, что процесс выгрузки данных затягивается на десятки минут, хотя фактически в файл обмена новые данные не попадают.
Почему это происходит? Проанализируем механизм: при каждой загрузке данных база-приемник создает записи в этом регистре, чтобы сопоставить внутренний идентификатор (GUID) объекта в текущей базе с идентификатором в базе-источнике. Эти записи автоматически ставятся на регистрацию для отправки обратно, чтобы база-источник тоже «узнала» о связях объектов. Если механизм подтверждения получения данных (квитирование) не срабатывает, записи будут предлагаться к выгрузке вечно.
Выясним причину, по которой записи «застревают» в очереди на выгрузку. В системе обмена 1С реализован механизм очистки регистрации на основе номеров сообщений. Рассмотрим эту логику по шагам:
Если записи в СоответствиеОбъектовИнформационныхБаз не удаляются, значит, База А (в нашем случае БП 3.0) не получает от Базы Б (БП 2.0) подтверждения, что пакет с этими данными был успешно обработан.
Проанализируем ситуацию, когда файлы обмена вроде бы выгружаются, но номера сообщений не синхронизируются. Одной из частых причин является путаница с префиксами и именами файлов. Посмотрим на важные настройки:
Проверьте в «Бухгалтерии предприятия 3.0» (и зеркально в 2.0) регистр сведений ОбщиеНастройкиУзловИнформационныхБаз. Обратите внимание на поля Префикс и ПрефиксКорреспондента. Если префиксы настроены неверно, система может формировать файлы с именами, которые вторая база просто «не узнает» как предназначенные ей.
Например, если внутри архива Message_БП_ВТ.zip находится файл с некорректным внутренним именем Message_БП_ВТ.xml вместо ожидаемого Message_ВТ_БП.xml, загрузка может пройти формально (без критических ошибок платформы), но бизнес-логика обмена не обновит номер принятого сообщения.
Чтобы понять, где именно происходит сбой, выполним следующие действия:
Рассмотрим ситуацию автора темы: обмен идет только из 2.0 в 3.0. В этом случае БП 2.0 является «мастером» данных. Нужны ли ей записи о соответствии из БП 3.0?
Технический нюанс: Для самой очистки регистрации в БП 3.0 передавать записи РС СоответствиеОбъектовИнформационныхБаз в БП 2.0 не обязательно. Достаточно того, чтобы БП 2.0 просто успешно приняла технический файл (квитанцию) и отправила назад номер сообщения.
Однако, если записи все равно копятся и мешают работе, можно применить радикальное решение — исключить этот регистр из состава плана обмена в БП 3.0. Если база 2.0 никогда не будет приемником данных, ей не нужно знать о соответствии идентификаторов.
Если вы выяснили, что 87 000 записей — это «мусор», который накопился из-за старых ошибок настройки, их можно удалить вручную, чтобы вернуть обмену былую скорость. Разберем, как это сделать:
Воспользуйтесь стандартной обработкой «Регистрация изменений для обмена данными» (она входит в состав БСП или доступна как внешняя «Регистрация изменений для обмена» в составе инструментов разработчика).
Пошаговый алгоритм:
СоответствиеОбъектовИнформационныхБаз.После этого первый же обмен пройдет мгновенно. Если проблема в настройках сохраняется, записи начнут копиться снова, но вы уже будете знать, что причина в несовпадении номеров принятых/отправленных сообщений.
В некоторых случаях удобно использовать небольшой программный код для очистки регистрации по конкретному узлу. Посмотрим на пример:
УзелОбмена = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоКоду("ВТ");
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, Метаданные.РегистрыСведений.СоответствиеОбъектовИнформационныхБаз);
Этот код мгновенно очистит очередь выгрузки для указанного регистра по конкретному узлу, что позволит возобновить обмен без долгого ожидания обработки старых записей.
Подводя итог, отметим: регистр СоответствиеОбъектовИнформационныхБаз критически важен для корректной связи объектов, но его «раздувание» — это всегда симптом проблем с подтверждением пакетов. Всегда проверяйте зеркальность префиксов, доступность путей обмена и соответствие номеров сообщений в обеих базах.