Как связать объекты в базах УТ 10.3 и БП 3.0 по ГУИД и решить проблему запросов через COM?

← На главную

Мы часто сталкиваемся со сценариями, где данные необходимо передавать между различными конфигурациями 1С, например, из сильно переписанной 1С:Управление торговлей 10.3 в типовую 1С:Бухгалтерия предприятия 3.0, которая находится "на замке". В таких случаях возникает острая необходимость в надежной идентификации объектов, таких как контрагенты и договоры, чтобы избежать дублирования и ошибок при загрузке документов. Стандартные методы идентификации, такие как ИНН, КПП, номер и дата договора, а также наименование, оказываются ненадежными, поскольку эти данные могут внезапно меняться. В этой ситуации на помощь приходят внутренние уникальные идентификаторы ГУИД (GUID). Мы подробно рассмотрим, как их использовать для связывания баз и как решить специфические проблемы, возникающие при работе с ГУИД в запросах через COM-соединение.

1. Почему стандартные методы идентификации ненадежны?

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

ИНН и КПП контрагента: Хотя ИНН обычно стабилен для юридических лиц, есть исключения. Например, для физических лиц (включая ИП) КПП может отсутствовать, а у ИП и вовсе нет КПП. Более того, даже у юридического лица КПП может измениться при изменении юридического адреса или при постановке на учет в другую налоговую инспекцию. Поиск только по ИНН может привести к проблемам, если в базе есть несколько юридических лиц с одинаковым ИНН (например, филиалы или обособленные подразделения с разными КПП).
Номер и дата договора: Это, пожалуй, одни из самых изменчивых реквизитов. Договор может быть перенумерован, датирован задним числом, или же в разных базах могут быть созданы договоры с одинаковыми номерами и датами для разных сущностей. Такая нестабильность делает их крайне ненадежными для однозначной идентификации.
Наименование организации: Наименование контрагента также может измениться (например, при переименовании юридического лица или изменении организационно-правовой формы). Автоматическое сопоставление по наименованию при таких изменениях неизбежно приведет к созданию дубликатов.
Контактные данные: Адреса, телефоны, банковские счета – все эти данные динамичны и постоянно меняются, что делает их непригодными для долгосрочной идентификации.

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

2. Как запомнить ГУИД из исходной базы (УТ) в базе-приемнике (БП)?

После того как мы приняли решение использовать ГУИД для надежной идентификации, возникает вопрос: как хранить этот ГУИД из одной базы в другой? Мы рассмотрим два основных подхода, оба из которых являются типовым функционалом платформы 1С.

2.1. Использование регистра сведений "СоответствияОбъектовИнформационныхБаз"

Это типовой и рекомендуемый подход для решения задач по сопоставлению объектов при обмене данными. РегистрСведений.СоответствияОбъектовИнформационныхБаз специально создан в конфигурациях, использующих Библиотеку стандартных подсистем (БСП), для хранения связей между объектами в разных информационных базах. Он предназначен для управления синхронизацией данных и является центральным элементом механизма обмена.

Назначение регистра: Данный регистр содержит информацию о том, какой объект в одной базе соответствует какому объекту в другой. Он хранит ссылки на объекты и их уникальные идентификаторы в других базах. Типичная структура регистра включает измерения для УникальногоИдентификатора текущей базы и УникальногоИдентификатора другой базы, а также служебные поля для управления синхронизацией.
Как это работает: При настройке типового обмена между конфигурациями, например, через помощник настройки синхронизации, этот регистр автоматически заполняется. Система регистрирует изменения объектов и при выгрузке/загрузке использует этот регистр для поиска соответствий. Если объект не найден, он создается, и его соответствие регистрируется. Это обеспечивает бесшовную и автоматическую идентификацию.
Преимущества:
- Типовое решение: Это встроенный механизм, разработанный специально для синхронизации, что обеспечивает его надежность и поддержку при обновлениях конфигурации.
- Автоматизация: При правильной настройке обмена, процесс сопоставления и регистрации ГУИД происходит автоматически, минимизируя ручное вмешательство.
- Централизованное хранение: Все соответствия хранятся в одном месте, что упрощает администрирование и отладку, особенно при сложных схемах обмена.
- Поддержка сложных сценариев: Регистр может поддерживать не только прямое соответствие, но и более сложные правила сопоставления.
Когда использовать: Этот подход идеален, если вы настраиваете полноценный типовой обмен данными и хотите использовать все преимущества встроенных механизмов синхронизации. Он требует понимания принципов работы БСП и планов обмена, но обеспечивает наиболее надежное и масштабируемое решение.

2.2. Использование дополнительных реквизитов

Если конфигурация базы-приемника (например, БП 3.0) находится "на замке" и вы хотите избежать глубокой интеграции с механизмом синхронизации БСП, или если вам требуется лишь простое хранилище для ГУИД из исходной базы без сложной логики сопоставления, то дополнительные реквизиты могут быть более простым и наглядным решением.

Как создать: В 1С:Бухгалтерии 3.0 (и многих других конфигурациях на БСП) предусмотрен функционал создания дополнительных реквизитов и сведений для справочников и документов без изменения конфигурации. Мы можем добавить новый дополнительный реквизит для справочника Контрагенты и ДоговорыКонтрагентов, например, с именем ГУИДИсточника, тип значения которого будет Строка. Выбираем тип Строка, так как он гарантированно позволяет хранить строковое представление ГУИД, полученное из другой базы.
Как это работает: При передаче данных из УТ в БП, мы будем считывать ГУИД контрагента и договора в УТ (например, через УНИКАЛЬНЫЙИДЕНТИФИКАТОР(Ссылка)), а затем записывать его строковое представление в соответствующий дополнительный реквизит созданного или найденного контрагента/договора в БП.
Преимущества:
- Простота реализации: Не требует глубоких знаний механизмов обмена, можно реализовать через внешние обработки или простые правила конвертации данных.
- Наглядность: ГУИД отображается непосредственно в форме элемента справочника, что может быть удобно для отладки и ручной проверки.
- Минимальное вмешательство: Использование типового функционала "Дополнительные реквизиты" не требует снятия конфигурации с поддержки или использования расширений, что делает его безопасным для типовых баз.
Недостатки:
- Не является частью синхронизации: Этот реквизит не будет автоматически использоваться типовыми механизмами обмена для сопоставления; логику сопоставления придется реализовывать самостоятельно в вашей обработке обмена.
- Менее производительно: При больших объемах данных поиск по дополнительному реквизиту может быть менее эффективным, чем поиск через специализированные индексы РегистраСведений.СоответствияОбъектовИнформационныхБаз.
- Необходимость контроля формата: Мы должны самостоятельно следить за тем, чтобы ГУИД всегда записывался в одном и том же строковом формате.
Когда использовать: Этот подход подходит, если вы реализуете односторонний или ограниченный обмен данными, где требуется простое хранение идентификаторов без использования полноценного механизма синхронизации БСП, и вы готовы самостоятельно управлять логикой сопоставления при загрузке.

2.3. Присвоение ГУИД при создании нового элемента

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

Как это работает: Когда мы передаем данные из УТ в БП, и система обнаруживает, что контрагент с определенным ГУИД отсутствует в БП, вместо того чтобы создавать новый элемент со своим внутренним ГУИД, мы явно присваиваем новому элементу в БП ГУИД, полученный из УТ. Для этого используются методы создания нового элемента, позволяющие передать ему уже существующий уникальный идентификатор, например:
```
НовыйКонтрагент = Справочники.Контрагенты.СоздатьЭлемент();
НовыйКонтрагент.УстановитьСсылку(НовыйКонтрагент.ПолучитьСсылку(GUIDИзУТ));
// или
НовыйКонтрагент.УстановитьСсылку(Новый КонтрагентСсылка(GUIDИзУТ));
```
После этого мы заполняем остальные реквизиты и записываем элемент.
Преимущества:
- Единый идентификатор: Объект имеет один и тот же ГУИД в обеих базах, что значительно упрощает сопоставление и поиск. Отпадает необходимость в дополнительных полях для "чужого" ГУИД.
- Оптимизация: Отсутствует необходимость в дополнительном регистре или реквизите для хранения "чужого" ГУИД, так как он становится "родным". Поиск по ссылке (которая основана на ГУИД) является самым быстрым.
Ограничения:
- Возможность изменения конфигурации: Для реализации этого метода часто требуется внесение изменений в конфигурацию базы-приемника (или использование расширений), чтобы обеспечить возможность явного присвоения ГУИД при создании объекта. Для типовой БП "на замке" это может быть проблематично без использования расширений.
- Конфликты: Необходимо тщательно продумать логику предотвращения конфликтов, если вдруг в БП уже существует объект с таким же ГУИД (что маловероятно для новых ГУИД, но возможно при ошибках в логике обмена или ручном вмешательстве).
- Последовательность: Важно, чтобы этот метод применялся только при первом создании объекта в базе-приемнике.
Когда использовать: Этот подход наиболее эффективен в сценариях, где вы имеете полный контроль над обеими конфигурациями (или используете расширения), и хотите добиться максимально простой и быстрой идентификации объектов по единому ГУИД. Это также основной принцип, лежащий в основе работы распределенных информационных баз (РИБ).

3. Проблемы сравнения ГУИД в запросах через COM-соединение

После того как мы успешно сохранили ГУИД из УТ в БП (будь то в дополнительном реквизите, регистре соответствий или присвоив его напрямую), следующая задача — использовать этот ГУИД для поиска объектов в запросах, особенно когда запрос выполняется через COM-соединение из внешней системы (или из УТ в БП).

Представим, что у нас есть такой фрагмент кода, где мы пытаемся получить данные о контрагенте по его ГУИД:


Если ЗначениеЗаполнено(ДанныеКонтрагента.ГУИДконтрагента) Тогда
    УсловиеЗапроса = " | И ПРЕДСТАВЛЕНИЕ(УНИКАЛЬНЫЙИДЕНТИФИКАТОР(РеализацияТоваровУслугУслуги.Ссылка.Контрагент.Ссылка)) = &ГУИДКонтрагента ";
Иначе
    УсловиеЗапроса = " | И РеализацияТоваровУслугУслуги.Ссылка.Контрагент.ИНН=&ИНН | И РеализацияТоваровУслугУслуги.Ссылка.Контрагент.КПП=&КПП";
КонецЕсли;

ЗапросБД = СоединениеБД.NewObject("Запрос");
ЗапросБД.Текст ="ВЫБРАТЬ
                 | РеализацияТоваровУслугУслуги.Ссылка КАК Ссылка,
                 | ПРЕДСТАВЛЕНИЕ(УНИКАЛЬНЫЙИДЕНТИФИКАТОР(РеализацияТоваровУслугУслуги.Ссылка.Контрагент.Ссылка)) КАК ГУИДКонтрагента,
                 // ... другие поля ...
                 |ИЗ
                 | Документ.РеализацияТоваровУслуг.Услуги КАК РеализацияТоваровУслугУслуги
                 |ГДЕ
                 // ... остальные условия ...
                 ";
ЗапросБД.Текст = ЗапросБД.Текст + УсловиеЗапроса;
// ... установка параметров ...
ЗапросБД.УстановитьПараметр("ГУИДконтрагента",ДанныеКонтрагента.ГУИДконтрагента);

Однако такой подход часто не срабатывает. Давайте выясним причину и рассмотрим возможные решения.

3.1. Анализ проблемы: Несовпадение представлений и типов данных

Функция УНИКАЛЬНЫЙИДЕНТИФИКАТОР(): Эта функция возвращает объект встроенного типа УникальныйИдентификатор. Это внутренний тип 1С, предназначенный для хранения GUID, и он не является строкой.
Функция ПРЕДСТАВЛЕНИЕ(): Применение функции ПРЕДСТАВЛЕНИЕ() к объекту типа УникальныйИдентификатор преобразует его в строковое представление. Однако формат этого строкового представления может быть специфичным для 1С (например, XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX без скобок) и не всегда совпадать с тем, как GUID представлен в строке, переданной из внешней системы или полученной другим способом (например, с фигурными скобками {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}). Даже небольшие отличия в форматировании (наличие/отсутствие дефисов, регистр символов) приведут к тому, что строки не будут считаться равными.
Параметр запроса &ГУИДКонтрагента через COM: Если вы передаете ГУИД как обычную строку через COM-соединение, то для 1С этот параметр является именно строкой. Сравнение ПРЕДСТАВЛЕНИЕ(УНИКАЛЬНЫЙИДЕНТИФИКАТОР(...)) (строка 1С) с &ГУИДКонтрагента (внешняя строка-параметр) может не дать ожидаемого результата из-за различий в форматировании или из-за особенностей неявных преобразований типов в COM-соединении.

Суть проблемы: Мы пытаемся сравнить строковое представление ГУИД, полученное внутренними средствами 1С, со строковым значением, переданным как параметр. Эти строковые представления могут не быть идентичными по формату, что приводит к некорректной работе условия в запросе. 1С не "понимает", что две разные строки могут представлять один и тот же ГУИД, если их форматы отличаются.

3.2. Рекомендуемое решение: Правильное приведение типов в запросе

Для корректного сравнения необходимо убедиться, что оба значения, участвующие в сравнении, имеют один и тот же тип и формат. В запросах 1С мы можем использовать функцию ВЫРАЗИТЬ для приведения к стандартному строковому виду, или, что предпочтительнее, сравнивать объекты типа УникальныйИдентификатор напрямую.

Преобразование параметра к типу УникальныйИдентификатор: Это самый надежный способ. Если есть возможность, лучше передавать параметр не как строку, а как объект типа УникальныйИдентификатор 1С. Для этого в коде на стороне, выполняющей запрос через COM, нужно сначала преобразовать строковый ГУИД в объект УникальныйИдентификатор 1С:
```
// Предположим, ДанныеКонтрагента.ГУИДконтрагента - это строка, например, "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
ГУИДДляЗапроса = СоединениеБД.NewObject("УникальныйИдентификатор", ДанныеКонтрагента.ГУИДконтрагента);
ЗапросБД.УстановитьПараметр("ГУИДКонтрагента", ГУИДДляЗапроса);
```
А затем в запросе сравнивать напрямую сам объект, а не его строковое представление:
```
УсловиеЗапроса = " | И РеализацияТоваровУслугУслуги.Ссылка.Контрагент.Ссылка = &ГУИДКонтрагента ";
```
Обратите внимание, что мы сравниваем Ссылка (которая по своей сути является УникальныйИдентификатор для объекта базы данных) с параметром типа УникальныйИдентификатор. Это наиболее эффективный и корректный способ.
Преобразование УникальныйИдентификатор в строку с фиксированным форматом: Если по каким-то причинам преобразовать параметр в УникальныйИдентификатор не получается, и вы вынуждены сравнивать строки, используйте ВЫРАЗИТЬ для получения гарантированного строкового формата ГУИД:
```
УсловиеЗапроса = " | И ВЫРАЗИТЬ(УНИКАЛЬНЫЙИДЕНТИФИКАТОР(РеализацияТоваровУслугУслуги.Ссылка.Контрагент.Ссылка) КАК СТРОКА(36)) = &ГУИДКонтрагента ";
```
Это гарантирует, что ГУИД будет представлен в стандартном формате XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (32 шестнадцатеричные цифры, разделенные четырьмя дефисами). При работе с внешними строковыми параметрами убедитесь, что они также представлены в этом формате. Например, если внешняя система передает GUID в формате с фигурными скобками (например, {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}), вам потребуется либо удалить эти скобки из параметра перед передачей в 1С, либо соответственно изменить строку запроса, включив их в выражение.

3.3. Обходное решение для COM-соединения (неэффективное, но рабочее)

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

Суть обходного решения: Вместо того чтобы пытаться сравнивать ГУИД непосредственно в условии запроса 1С, мы сначала выполняем отдельный запрос для получения всех необходимых ГУИД объектов из базы 1С в виде строк. Затем выгружаем эти данные во временную таблицу значений и уже в коде на стороне клиента (или в вызывающей обработке, которая инициирует COM-соединение) выполняем перебор этой таблицы и сравнение с переданным строковым ГУИД.

Пример кода из сообщения 32:


Если ЗначениеЗаполнено(ДанныеКонтрагента.ГУИДконтрагента) Тогда
    Запрос_БД = СоединениеБД.NewObject("Запрос");
    Запрос_БД.Текст ="ВЫБРАТЬ
                     | ПРЕДСТАВЛЕНИЕ(УНИКАЛЬНЫЙИДЕНТИФИКАТОР(Контрагенты.Ссылка)) КАК ГУИДКонтрагента,
                     | Контрагенты.ИНН КАК ИНН,
                     | Контрагенты.КПП КАК КПП
                     |ИЗ
                     | Справочник.Контрагенты КАК Контрагенты";
    // Выполняем запрос и выгружаем результат в ТаблицуЗначений
    ТЗ = Запрос_БД.Выполнить().Выгрузить(); 
            
    Для Каждого Стр Из ТЗ Цикл
        Если Стр.ГУИДКонтрагента = ДанныеКонтрагента.ГУИДконтрагента Тогда
            ДляПоискаИНН = Стр.ИНН;
            ДляПоискаКПП = Стр.КПП;
            Прервать; // Нашли соответствие, выходим из цикла
        КонецЕсли;
    КонецЦикла;
Иначе
    // Если ГУИД не заполнен, используем ИНН/КПП как резервный вариант
    ДляПоискаИНН = ДанныеКонтрагента.ИНН;
    ДляПоискаКПП = ДанныеКонтрагента.КПП;
КонецЕсли;
        
// Далее, используя ДляПоискаИНН и ДляПоискаКПП, формируется основной запрос
// к базе 1С, который уже будет использовать ИНН/КПП для поиска

Пояснение к коду:
- Сначала мы выполняем отдельный запрос к базе 1С, чтобы получить список всех контрагентов (или только тех, которые потенциально нужны) вместе с их ИНН, КПП и строковым представлением ГУИД.
- Результат запроса выгружается в таблицу значений (ТЗ), которая передается обратно через COM.
- Затем мы в цикле перебираем каждую строку этой таблицы значений.
- Внутри цикла мы сравниваем строковое представление ГУИД из таблицы (Стр.ГУИДКонтрагента) с ГУИД, переданным из исходной базы (ДанныеКонтрагента.ГУИДконтрагента). Здесь сравнение происходит уже в среде, инициирующей COM-соединение, где строковые сравнения более предсказуемы.
- При нахождении совпадения мы получаем ИНН и КПП найденного контрагента и используем их для формирования дальнейшего основного запроса к базе 1С, который уже будет использовать более привычные ИНН и КПП.
Недостатки обходного решения:
- Низкая производительность: Выгрузка всего справочника контрагентов (или его значительной части) и последующий перебор в цикле может быть очень медленным и ресурсоемким для больших баз данных, особенно при частом выполнении.
- Использование памяти: Таблица значений, содержащая данные о всех контрагентах, может занимать много оперативной памяти как на стороне сервера 1С, так и на стороне клиента COM.
- "Костыль": Это скорее "костыль", чем элегантное решение, и его следует использовать только в крайнем случае, когда нет возможности реализовать более оптимальный подход.

4. Альтернативы COM-соединению

В современных реалиях, особенно при интеграции между различными системами или при работе с клиентскими приложениями на Linux, COM-соединение постепенно уступает место более гибким и производительным технологиям. Мы рекомендуем рассмотреть веб-сервисы как альтернативный механизм обмена данными.

Веб-сервисы позволяют:

Более прозрачно работать с типами данных: В отличие от COM, где преобразование типов может быть неочевидным, веб-сервисы часто используют стандартизированные форматы (например, XML, JSON) и позволяют более четко определять типы данных, упрощая их сопоставление.
Обеспечить кроссплатформенность: Веб-сервисы не зависят от операционной системы и могут быть использованы из любых приложений и платформ, что значительно расширяет возможности интеграции.
Улучшить производительность: Зачастую веб-сервисы могут быть более оптимизированными для передачи данных по сети, так как используют более современные протоколы и методы сериализации данных.
Повысить безопасность: Веб-сервисы легко интегрируются с современными механизмами безопасности (шифрование, аутентификация, авторизация), обеспечивая защищенную передачу данных.

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

5. Практические советы по организации обмена

Чтобы обеспечить стабильность и корректность обмена данными между УТ и БП, помимо технических аспектов, важно уделить внимание организационным моментам:

Дисциплина ввода данных в УТ: Сотрудники, ведущие учет в УТ, должны быть проинструктированы о важности своевременного и корректного ввода информации. Если создается новый контрагент или изменяются важные реквизиты (особенно те, которые используются для идентификации, даже если это ГУИД, хранящийся в доп. реквизите), эта информация должна быть передана в БП до загрузки документов, ссылающихся на эти объекты. Игнорирование этого правила может привести к созданию дубликатов или ошибкам при загрузке.
Предварительная выгрузка справочников: Перед массовой загрузкой документов (например, реализаций) в БП, всегда убедитесь, что все необходимые справочники (контрагенты, договоры, номенклатура, склады и т.д.) уже существуют в БП и их соответствия установлены. Можно использовать специальные обработки для предварительной выгрузки только новых или измененных элементов справочников. Это позволяет избежать ошибок "объект не найден".
Использование префиксов баз: При настройке обмена всегда указывайте префиксы информационных баз для каждого узла обмена. Это помогает системе отличать объекты, пришедшие из разных баз, и предотвращать дублирование данных, а также упрощает их идентификацию.
Контроль за регистрацией изменений: В 1С:Управление торговлей 10.3 существует обработка "Регистрация изменений для обмена". Используйте ее для контроля, какие объекты будут выгружены. Будьте осторожны при ручной регистрации изменений справочников, чтобы случайно не выгрузить документы без сопутствующей номенклатуры или контрагентов, или не отправить уже существующие объекты без изменений.
Резервное копирование: Перед выполнением любых операций по обмену данными, особенно связанных с массовым изменением или загрузкой, всегда создавайте резервные копии обеих информационных баз. Это критически важное правило, которое спасет вас от потери данных и длительного восстановления в случае непредвиденных ошибок, сбоев или некорректной работы правил обмена.
Настройка правил обмена: Тщательно настраивайте правила обмена данными, указывая, какие именно документы, справочники и их реквизиты должны выгружаться и загружаться. Проверяйте, что в правилах обмена корректно прописаны механизмы сопоставления объектов, особенно если вы используете нестандартные подходы с ГУИД или дополнительными реквизитами.

Заключение

Связывание баз 1С:Управление торговлей 10.3 и 1С:Бухгалтерия предприятия 3.0 по ГУИД является надежным способом обеспечения целостности данных, особенно при наличии нестабильных идентификаторов. Мы рассмотрели различные подходы к хранению ГУИД в базе-приемнике: от типового регистра СоответствияОбъектовИнформационныхБаз до использования дополнительных реквизитов. Особое внимание было уделено проблеме сравнения ГУИД в запросах через COM-соединение и предложено как рекомендуемое решение с приведением типов, так и обходной путь для сложных ситуаций. Помните, что помимо чисто технических решений, критически важны дисциплина ведения учета и внимательность при работе с данными и настройке обменов.