При настройке обмена данными между конфигурациями 1С:Управление торговлей 10.3 и 1С:Бухгалтерия предприятия 3.0 (или любыми другими парами баз) одним из ключевых механизмов является использование регистра сведений СоответствияОбъектовИнформационныхБаз. Понимание принципов его работы критически важно для предотвращения дублирования данных и корректного сопоставления объектов. Рассмотрим подробно устройство этого регистра, алгоритмы поиска и способы решения возникающих проблем. Для организации корректной выгрузки данных можно использовать актуальные правила обмена из УТ 10.3 в БП 3.0.
Разберем ситуацию, которая часто вводит в заблуждение: наличие одноименного регистра в обеих базах. На первый взгляд может показаться, что базы обращаются к общей таблице, но это не так. Каждая база — и УТ, и БП — имеет свой собственный локальный регистр, который является своего рода «словарем» для перевода внутренних ссылок объектов в понятные для другой базы идентификаторы.
Проанализируем, как это работает на практике. Когда мы инициируем выгрузку из УТ 10.3, система не заглядывает в базу БП 3.0. Она обращается к своему локальному регистру СоответствияОбъектовИнформационныхБаз. Если для объекта (например, документа «Реализация товаров и услуг») уже есть запись, УТ берет сохраненный уникальный идентификатор приемника и записывает его в XML-файл обмена. Если записи нет — выгружается собственный GUID объекта.
Важно понимать: для каждой базы приоритетным является ее собственный регистр. В момент загрузки пакета база-приемник не может «спросить» регистр базы-источника. Она оперирует только теми данными, которые пришли в файле, и теми, что хранятся в ее собственной информационной базе. Для регулярной отправки и загрузки таких файлов по расписанию применяется программа автоматического обмена данными между базами 1С.
Рассмотрим структуру регистра, чтобы понять, зачем в нем дублируются, казалось бы, одинаковые данные. В регистре часто встречаются поля «Уникальный идентификатор приемника» (измерение) и «Уникальный идентификатор источника строкой» (ресурс). Выясним причину такого проектирования:
UUID платформы 1С.Посмотрим на логику, по которой база 1С принимает решение: обновить существующий объект или создать новый. Этот алгоритм выполняется строго последовательно:
GUID, пришедший из файла, и ищет его в своем регистре СоответствияОбъектовИнформационныхБаз. Если связь найдена, объект в текущей базе обновляется. Это самый быстрый и надежный способ.GUID, какой указан в файле. Если такой объект обнаружен, они сопоставляются «на лету», и в регистр вносится новая запись.ИНН + КПП, для номенклатуры — Артикул или Наименование. Если объект найден по этим полям, он сопоставляется с пришедшим идентификатором, и создается запись в регистре.Проанализируем ситуацию, когда регистр повреждается или очищается в одной из баз. Если мы очистим регистр в БП, но оставим в УТ, то при следующей выгрузке из УТ в БП возможны два сценария:
GUID, дублей не будет. БП найдет объект на шаге 2 (по внутреннему GUID) и просто заново заполнит регистр.GUID у них разные), то БП «не узнает» старый объект и создаст дубль.Как исправить появившиеся дубли? Существует два основных подхода:
Это продвинутый метод, который позволяет программно сопоставить данные. Мы можем написать обработку, которая через COM-соединение подключится к обеим базам одновременно. Рассмотрим примерную логику кода для сопоставления:
// Пример логики поиска и сопоставления
Соединение = Новый COMОбъект("V83.COMConnector");
БазаПриемник = Соединение.Connect("Srvr='ServerName';Ref='BaseName';");
// Получаем ссылку в текущей базе
СсылкаТут = Справочники.Контрагенты.НайтиПоРеквизиту("ИНН", ТекущийИНН);
// Получаем GUID из другой базы
СсылкаТам = БазаПриемник.Справочники.Контрагенты.НайтиПоРеквизиту("ИНН", ТекущийИНН);
СтрокаGUIDТам = БазаПриемник.String(СсылкаТам.UUID());
// Записываем в регистр соответствий
МенеджерЗаписи = РегистрыСведений.СоответствияОбъектовИнформационныхБаз.СоздатьМенеджерЗаписи();
МенеджерЗаписи.СобственныйОбъект = СсылкаТут;
МенеджерЗаписи.УникальныйИдентификаторПриемника = СтрокаGUIDТам;
МенеджерЗаписи.Записать();
В современных конфигурациях на базе БСП (например, БП 3.0) предусмотрена встроенная обработка «Сопоставление объектов информационных баз». Она позволяет наглядно увидеть объекты, которые еще не связаны между собой, и вручную установить соответствие. После ручного сопоставления в регистры обеих баз запишутся корректные связи, и проблема дублей исчезнет.
Важный совет по производительности: Если регистр СоответствияОбъектовИнформационныхБаз разрастается до миллионов записей, поиск по нему может замедляться. Рекомендуется периодически проводить аудит и очищать записи, относящиеся к удаленным узлам обмена или помеченным на удаление объектам. Для этого следует использовать специализированные обработки по очистке «битых» ссылок.
Подводя итог, отметим, что регистр соответствий — это фундамент стабильного обмена. Его корректное заполнение гарантирует, что данные между УТ 10.3 и БП 3.0 будут передаваться без искажений и повторений. Для проверки результатов переноса и выявления расхождений можно использовать обработку для сверки документов между УТ 10.3 и БП 3.0.