При настройке обмена данными между конфигурациями УПП 1.3 и БП 3.0 с помощью «Конвертации данных 2.1» (КД 2.1) специалисты часто сталкиваются с ситуацией, когда объекты (например, документы) не сопоставляются по ключевым реквизитам, таким как Номер и Дата. Вместо того чтобы обновить существующий документ в базе-приемнике, система создает его дубль. Ситуация осложняется, если при попытке настроить поиск по полям система выдает непонятную синтаксическую ошибку в динамически формируемом запросе.
В этой статье мы подробно разберем, почему стандартный механизм поиска может давать сбои, как правильно настроить ПКО (Правила конвертации объектов) и какие изменения в программном коде обработки обмена помогут решить проблему. Для перехода без ручной настройки правил применяется перенос данных из УПП 1.3 в БП 3.0.
Первое, что необходимо проанализировать — это приоритетность поиска. В КД 2.1 по умолчанию часто включена настройка «Поиск по внутреннему идентификатору». Рассмотрим, как это работает: система сначала пытается найти объект в базе-приемнике по его GUID (уникальному идентификатору). Если документ в БП 3.0 был создан вручную или другим обменом, его GUID гарантированно не совпадет с GUID документа из УПП 1.3.
Если при этом в правилах не стоит флаг «Продолжить поиск по полям поиска, если по идентификатору объект не найден», система сразу перейдет к созданию нового объекта, даже не пытаясь сравнить номера и даты. Поэтому первым шагом в решении проблемы дублей является отключение поиска по внутреннему идентификатору в ПКО или установка флага продолжения поиска.
При использовании современных версий конфигураций на базе БСП (Библиотека стандартных подсистем), таких как Бухгалтерия предприятия 3.0, для загрузки данных используется встроенная обработка КонвертацияОбъектовИнформационныхБаз. В некоторых случаях при формировании запроса поиска по полям возникает ошибка:
{(1, 80)}: Синтаксическая ошибка "=" ВЫБРАТЬ Ссылка ИЗ Документ.РеализацияТоваровУслуг ГДЕ {КлючПоискаВИБИсточнике} >= &{КлючПоискаВИБИсточнике} ...
Проанализируем ситуацию: текст в фигурных скобках ({КлючПоискаВИБИсточнике}, {ИмяТипаВИБПриемнике}) — это служебные токены, которые обработка должна заменить на реальные значения перед выполнением запроса. Если этого не происходит, платформа 1С воспринимает их как некорректные конструкции языка запросов.
Для решения этой проблемы необходимо внести изменения в модуль объекта обработки КонвертацияОбъектовИнформационныхБаз (или УниверсальныйОбменДаннымиXML, если используется она). Нам нужно найти функцию НайтиЭлементЗапросом() и дополнить блок игнорирования служебных параметров.
Найдем в коде следующий фрагмент:
// Не по всем параметрам можно искать.
Если ИмяПараметра = "{УникальныйИдентификатор}" Или ИмяПараметра = "{ИмяПредопределенногоЭлемента}" Тогда
Продолжить;
КонецЕсли;
И заменим его на расширенный вариант, который исключит проблемные токены из обработки поискового запроса:
Если ИмяПараметра = "{УникальныйИдентификатор}"
Или ИмяПараметра = "{ИмяПредопределенногоЭлемента}"
Или ИмяПараметра = "{КлючПоискаВИБИсточнике}"
Или ИмяПараметра = "{ИмяТипаВИБПриемнике}"
Или ИмяПараметра = "{ИмяТипаВИБИсточнике}" Тогда
Продолжить;
КонецЕсли;
Это позволит системе корректно сформировать текст запроса, используя только те параметры (например, Номер и Дата), по которым реально установлены галочки поиска в ПКС.
Рассмотрим ситуацию, когда Номер и Дата для поиска берутся не из самого объекта источника, а из его реквизитов. Например, если мы выгружаем документ «Подтверждение отгрузки», но хотим, чтобы он сопоставился с «Реализацией товаров и услуг» по ее реквизитам. В этом случае в обработчиках ПКС Перед выгрузкой часто пишут код:
Значение = Источник.ДокументОтгрузки.Номер;
Важно помнить: чтобы система включила эти значения в запрос поиска на стороне приемника, в настройках ПКС обязательно должны стоять флаги «Поиск». Также убедитесь, что типы данных совпадают. Если в УПП номер имеет длину 11 символов, а в БП — 9, поиск может не сработать из-за несовпадения строк (разное количество лидирующих нулей). В таких случаях рекомендуется нормализовать номера перед выгрузкой или использовать программный поиск.
Проанализируем еще одну тонкую особенность КД 2.1. Существует известный баг: если в обработчике «Поля поиска» в ПКО написан любой текст, даже закомментированный (например, просто комментарий // поиск по номеру), стандартный алгоритм поиска по галочкам может отключиться или начать работать некорректно.
Рекомендация: если вы планируете использовать стандартный поиск, настроенный через флажки в ПКС, поле обработчика «Поля поиска» должно быть абсолютно пустым. Если же вам нужна сложная логика (например, поиск по началу дня для даты), пишите полноценный код с управлением переменной ПрекратитьПоиск.
Пример программного поиска по дате (начало дня) и номеру в обработчике «Поля поиска»:
Если НомерВариантаПоиска = 1 Тогда
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Ссылка
|ИЗ
| Документ.РеализацияТоваровУслуг
|ГДЕ
| Номер = &Номер
| И Дата МЕЖДУ &ДатаНачала И &ДатаОкончания";
Запрос.УстановитьПараметр("Номер", СвойстваПоиска.Получить("Номер"));
Запрос.УстановитьПараметр("ДатаНачала", НачалоДня(СвойстваПоиска.Получить("Дата")));
Запрос.УстановитьПараметр("ДатаОкончания", КонецДня(СвойстваПоиска.Получить("Дата")));
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
СсылкаНаОбъект = Выборка.Ссылка;
КонецЕсли;
ПрекратитьПоиск = Истина;
КонецЕсли;
Подводя итоги, для устранения дублей и ошибок поиска выполним следующие шаги:
НайтиЭлементЗапросом, чтобы исключить синтаксическую ошибку при обработке параметров в фигурных скобках.НомерВариантаПоиска.Следуя этим инструкциям, мы обеспечим стабильное сопоставление документов и исключим появление дублей в информационной базе 1С:Бухгалтерия. Контроль результата и поиск расхождений после обмена обеспечивает автоматическое сравнение проводок в базах 1С через COM-соединение.