Синхронизация данных между историческими конфигурациями на обычных формах, такими как УПП 1.3, и современными решениями на базе ERP 2.5 (или КА 2.5) часто сопровождается техническими сложностями. Одной из наиболее острых проблем является несовместимость механизмов поиска объектов, которая проявляется в виде синтаксических ошибок при выполнении запросов. Разберем детально, почему это происходит и как «подружить» эти системы. Если вместо постоянной синхронизации требуется выполнить разовую миграцию с сохранением истории учета, можно применить обработку для переноса данных из УПП 1.3 в ERP 2, которая переносит документы за выбранный период и остатки.
Рассмотрим ситуацию, когда при загрузке файла обмена в ERP возникает ошибка следующего вида:
{Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(7397)}:
Ошибка при вызове метода контекста (Выполнить) Результат = ЗапросПоиска.Выполнить;
по причине: {(1, 81)}: Синтаксическая ошибка "="
ВЫБРАТЬ Ссылка ИЗ Справочник.УпаковкиЕдиницыИзмерения ГДЕ {ИмяТипаВИБПриемнике} >= &{ИмяТипаВИБПриемнике}
И Код = &Код И {ИмяТипаВИБИсточнике} = &{ИмяТипаВИБИсточнике}
Проанализируем этот текст. Мы видим, что в тексте запроса присутствуют конструкции в фигурных скобках, такие как {ИмяТипаВИБПриемнике}. Это шаблоны подстановки, которые используются механизмом обмена данными (БСП). Ошибка возникает потому, что обработка загрузки в ERP ожидает одну структуру параметров, а файл, сформированный в УПП, содержит данные, которые заставляют движок обмена генерировать некорректный SQL-код.
Выясним причину: в современных версиях Библиотеки стандартных подсистем (БСП), на которых построена ERP, алгоритмы динамического формирования запросов изменились. УПП же использует старые алгоритмы формирования заголовка XML-файла и структуры правил. Когда включена «Синхронизация данных» через планы обмена, система пытается использовать механизмы БСП, которые в УПП и ERP имеют разрыв в развитии более чем в 10 лет.
Посмотрим на важное различие, которое часто сбивает с толку разработчиков. Если мы используем внешнюю обработку УниверсальныйОбменДаннымиXML, обмен проходит успешно. Это происходит потому, что данная обработка:
В то же время, штатная синхронизация через планы обмена (кнопка «Синхронизировать») добавляет в файл технический заголовок с указанием версии обмена. ERP, видя этот заголовок, включает режим совместимости, который в новых релизах может работать нестабильно или не поддерживать специфические конструкции поиска по полям, отличным от GUID. Для корректной организации такого переноса можно использовать расширение для обмена по правилам Конвертации данных 2.1 в ERP и КА без снятия с поддержки.
Попробуем найти штатные способы изменения версии формата. В УПП 1.3 выбор версии часто скрыт от пользователя. Проанализируем следующие места:
ВерсияФормата. Иногда достаточно принудительно установить значение 2.1.1 или выше, чтобы ERP корректно распознала входящий поток.КонвертацияОбъектовИнформационныхБаз. Если мы заменим ее код на аналогичный из свежей версии БСП (или возьмем из конфигурации-приемника), это может решить проблему генерации неверных шаблонов в запросе.Разберем более фундаментальный подход. Технология Конвертации данных 2.0 (КД 2.0) основана на жесткой привязке к метаданным обеих баз. Любое обновление ERP (например, переход с 2.4 на 2.5), где справочник «Единицы измерения» заменяется на «Упаковки», ломает правила.
Современный стандарт 1С — это EnterpriseData (ED) или КД 3.0. Рассмотрим его преимущества:
EnterpriseData остается неизменным.Однако в УПП штатная поддержка EnterpriseData отсутствует. Для реализации такого обмена нам потребуется:
Если мы решили остаться на КД 2.0, проанализируем настройки ПКО (Правил конвертации объектов) для справочников, вызывающих ошибку. В нашем примере это УпаковкиЕдиницыИзмерения.
Шаг 1: Проверка полей поиска. Если ошибка возникает на этапе ЗапросПоиска.Выполнить, значит, в правилах включен поиск по «Коду» или «Наименованию». Попробуем временно отключить эти флаги и оставить только поиск по уникальному идентификатору (GUID).
Шаг 2: Использование обработчика «Поля поиска». Вместо того чтобы полагаться на автоматическую генерацию запроса, напишем свой алгоритм поиска на стороне приемника (в ERP). В КД 2.0 в ПКО на закладке «Поля поиска» можно написать код:
Если НомерВариантаПоиска = 1 Тогда
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Ссылка
|ИЗ
| Справочник.УпаковкиЕдиницыИзмерения
|ГДЕ
| Код = &Код И Владелец = &Владелец";
Запрос.УстановитьПараметр("Код", СвойстваПоиска["Код"]);
Запрос.УстановитьПараметр("Владелец", СвойстваПоиска["Владелец"]);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Выборка.Следующий();
СсылкаНаОбъект = Выборка.Ссылка;
КонецЕсли;
КонецЕсли;
Такой подход полностью исключает использование проблемного генератора запросов БСП и позволяет точно контролировать логику сопоставления объектов.
Мы проанализировали ситуацию и пришли к выводу, что проблема «разных версий формата» — это следствие технологического разрыва между УПП и ERP. Для краткосрочного решения мы можем использовать явное описание алгоритмов поиска в КД 2.0, избегая автоматических механизмов БСП. Для долгосрочной и стабильной работы рекомендуем рассмотреть внедрение поддержки EnterpriseData в УПП, что позволит использовать современный и поддерживаемый вендором протокол обмена. Чтобы проконтролировать корректность синхронизации и исключить расхождения в учете после обмена, удобно запустить автоматическое сравнение бухгалтерских и налоговых проводок между базами.