При организации обмена данными между базами 1С, особенно если они являются идентичными конфигурациями, специалисты часто сталкиваются с проблемой: стандартные механизмы пытаются сопоставить объекты исключительно по их Уникальному Идентификатору (GUID). Если номенклатура создавалась в разных базах вручную, GUID у них будут разными, даже если артикул и наименование полностью совпадают. В этой ситуации стандартная обработка «Выгрузка и загрузка данных XML» создаст дубли.
Разберем подробно, как изменить это поведение, какие инструменты использовать и почему прямая правка кода типовой обработки — не самый эффективный путь.
Рассмотрим ситуацию, с которой сталкиваются многие разработчики. Популярная обработка ВыгрузкаЗагрузкаДанныхXML.epf предназначена для быстрого переноса данных между абсолютно одинаковыми конфигурациями. Проблема заключается в ее архитектуре: она использует механизм XDTO-сериализации. Когда вы нажимаете кнопку «Загрузить», система выполняет метод ПрочитатьXML(). Этот метод работает на низком уровне платформы: он видит в файле GUID объекта и пытается найти его в базе. Если объекта с таким идентификатором нет, он просто создает новый.
Проанализируем сообщение опытных разработчиков: «Там объект создаётся прямой десериализацией XML. Замучаешься этот кусок править». Попытка программно вмешаться в этот процесс потребует перехвата чтения каждого узла XML, что крайне трудозатратно и чревато ошибками производительности. Поэтому для решения задачи мы воспользуемся более гибкими инструментами.
Самый правильный и надежный способ изменить логику поиска — это создание правил обмена в конфигурации «Конвертация данных 2.0». Даже если ваши базы идентичны, использование правил позволит вам тонко настроить сопоставление объектов.
Разберем этот процесс по шагам:
Номенклатура.Артикул. В колонке «Поиск» установим соответствующий флаг.После настройки правил их нужно выгрузить в XML-файл и использовать в обработке Универсальный обмен данными в формате XML (известная как V8Exch82.epf). В этом случае поиск по артикулу будет работать «из коробки» без изменения кода самой обработки.
Иногда требуется более сложная логика. Например, если артикул содержит префиксы или если поиск должен зависеть от группы номенклатуры. В этом случае мы воспользуемся обработчиком Поля поиска в ПКО. Рассмотрим пример кода, который можно написать внутри правил конвертации:
// Пример в обработчике "Поля поиска" (ПКО Номенклатура)
Если СвойстваПоиска.Свойство("Артикул") И ЗначениеЗаполнено(СвойстваПоиска["Артикул"]) Тогда
СсылкаНаОбъект = Справочники.Номенклатура.НайтиПоРеквизиту("Артикул", СвойстваПоиска["Артикул"]);
// Если по артикулу нашли, сообщаем системе, что объект найден
Если Не СсылкаНаОбъект.Пустая() Тогда
ПрекратитьПоиск = Истина;
КонецЕсли;
КонецЕсли;
Этот подход позволяет реализовать многоуровневый поиск: сначала ищем по внутреннему коду, затем по артикулу, и в последнюю очередь по штрихкоду. Мы полностью контролируем процесс сопоставления данных.
Если вы работаете в современных конфигурациях (например, 1С:ERP, Управление торговлей 11 или Бухгалтерия 3.0), там используется механизм Библиотеки Стандартных Подсистем (БСП). В этом случае логика поиска часто описывается в общем модуле МенеджерОбменаЧерезУниверсальныйФормат или подобных.
Проанализируем ситуацию в БСП:
в этих конфигурациях настройки поиска часто вынесены в так называемый «Состав полей поиска». Мы можем программно переопределить эти поля в модуле менеджера обмена, не меняя сами правила XML. Это делается через процедуру ПриОпределенииПолейПоиска. Такой подход более современен, так как он не требует использования внешних обработок и работает в рамках регламентных заданий синхронизации.
Существует еще один обходной путь, если вы все же хотите продолжать использовать простую обработку ВыгрузкаЗагрузкаДанныхXML. Мы можем написать небольшую внешнюю обработку, которая «подружит» объекты в двух базах. Проанализируем алгоритм:
Важно помнить, что в 1С нельзя просто так поменять УникальныйИдентификатор у существующей ссылки. Поэтому для реализации этого метода используется создание новой ссылки через метод УстановитьСсылкуНового() при копировании объекта или использование специализированных инструментов по замене ссылок. Однако этот метод считается «грязным» и рекомендуется только в исключительных случаях.
Переходя от поиска по GUID к поиску по текстовым полям (артикулу), мы должны учитывать несколько критических факторов:
Номенклатура включен контроль уникальности артикула. Если в базе-приемнике окажется два товара с одинаковым артикулом, стандартный поиск НайтиПоРеквизиту вернет ссылку на первый найденный объект. Данные из базы-источника могут записаться в совершенно другой товар.СокрЛП().Подведем итог: для решения задачи автора самым эффективным и профессиональным методом будет использование Конвертации данных 2.0. Это позволит избежать «коверканья» кода типовых обработок и даст полный контроль над процессом синхронизации справочников.