При настройке обмена данными между двумя уже работающими базами 1С (например, Зарплата и управление персоналом и Бухгалтерия предприятия) основной проблемой становится возникновение дублей в справочниках. Если в обеих базах уже заведены одни и те же контрагенты, сотрудники или организации, система при первом обмене может не «узнать» их и создать копии. Разберем подробно, как работают типовые механизмы сопоставления и какие инструменты предоставляет вендор для решения этой задачи.
В современных конфигурациях 1С, построенных на базе БСП, этап сопоставления данных является неотъемлемой частью процесса настройки синхронизации. Рассмотрим, как это работает изнутри. Когда мы настраиваем новую синхронизацию, система не просто перебрасывает данные, а проходит через шаг «Сопоставление данных».
Проанализируем алгоритм работы этого этапа:
ИНН + КПП для контрагентов или СНИЛС для физических лиц).Многие пользователи сталкиваются с тем, что обработка СопоставлениеОбъектовИнформационныхБаз выдает ошибку «Не предназначена для непосредственного использования». Выясним причину: эта обработка требует инициализации через конкретный «Узел обмена». Чтобы ее запустить, необходимо сначала создать настройку синхронизации (хотя бы в режиме «только ручная выгрузка»), и тогда в мастере настройки станет доступна форма сопоставления.
Вся информация о том, какой объект в базе А соответствует объекту в базе Б, хранится в специальном регистре СоответствияОбъектовИнформационныхБаз. Рассмотрим подробнее его структуру и принцип работы:
Регистр хранит связи на уровне GUID (уникальных идентификаторов). Запись в регистре выглядит примерно так: [Узел обмена] + [Тип объекта] + [Ссылка в текущей базе] + [Уникальный идентификатор в другой базе].
Важные моменты работы с регистром:
Если типовых полей поиска недостаточно, мы можем вмешаться в процесс через Конвертацию данных (КД). Разберем отличия в подходах:
В КД 2.0 (XML-обмен) мы настраиваем «Правила поиска» (ПП). Рассмотрим пример кода, который можно написать в обработчике «Поля поиска» для реализации сложной логики:
// Пример логики поиска контрагента по ИНН, а если не найден - по наименованию
Если НомерВариантаПоиска = 1 Тогда
Отбор = Новый Структура("ИНН", СвойстваПоиска["ИНН"]);
Если ЗначениеЗаполнено(СвойстваПоиска["ИНН"]) Тогда
СсылкаНаОбъект = Справочники.Контрагенты.НайтиПоРеквизиту("ИНН", СвойстваПоиска["ИНН"]);
КонецЕсли;
ИначеЕсли НомерВариантаПоиска = 2 Тогда
СсылкаНаОбъект = Справочники.Контрагенты.НайтиПоНаименованию(СвойстваПоиска["Наименование"]);
КонецЕсли;
В КД 3.0 (Enterprise Data) сопоставление вынесено в модули менеджера обмена. Здесь акцент делается на использовании XDTO-пакетов и универсальных идентификаторов, что делает систему более стабильной при обновлении конфигураций.
Проанализируем ситуацию, когда у нас есть две базы с накопленными данными. Чтобы «скрестить» их безболезненно, рекомендуем придерживаться следующего плана:
COM-соединение или Web-сервисы сопоставят объекты и программно заполнят регистр СоответствияОбъектовИнформационныхБаз.Иногда стандартного поиска по полному совпадению строк недостаточно (например, «ООО Ромашка» и «Общество с ограниченной ответственностью "Ромашка"»). Рассмотрим вариант использования внешней компоненты для нечеткого поиска (расстояние Левенштейна).
Посмотрим на пример подключения такой компоненты в коде 1С:
Попытка
ЗагрузитьВнешнююКомпоненту("StrMatch.dll");
StrMatch = Новый ("AddIn.StrMatchExtension");
ИспользоватьКомпоненту = Истина;
Исключение
Сообщить("Ошибка загрузки компоненты поиска: " + ИнформацияОбОшибке().Описание);
ИспользоватьКомпоненту = Ложь;
КонецПопытки;
Если ИспользоватьКомпоненту Тогда
// Алгоритм сравнения строк с процентом схожести
РезультатСравнения = StrMatch.Compare(НаименованиеПриемник, НаименованиеИсточник);
КонецЕсли;
В современных реалиях вместо DLL часто используют Полнотекстовый поиск 1С или интеграцию с сервисами нормализации данных (например, Дадата). Это позволяет привести наименования и адреса к единому стандарту перед началом сопоставления.
Выясним еще одну важную деталь: что происходит, когда объект ссылается на другой объект, который еще не передан? В 1С существует механизм создания «объектов-пустышек».
Если при загрузке документа система видит ссылку на контрагента, который еще не пришел в текущем пакете обмена, она создает запись в справочнике, где заполнен только GUID. В интерфейсе это выглядит как <Объект не найден> (83:af82...).
Важно: При ручном сопоставлении нужно быть внимательными, чтобы не привязать живой объект к такой «пустышке», если она уже была создана ошибочно. Всегда лучше сначала сопоставить основные справочники (НСИ), а уже потом приступать к переносу документов.
Подводя итог, можно сказать, что «тупой» алгоритм сопоставления в типовых решениях — это осознанный выбор разработчиков 1С в пользу производительности и предсказуемости. Для успешного слияния баз мы рекомендуем:
Рассмотренные инструменты и подходы позволят вам контролировать процесс «скрещивания» информационных систем и избежать хаоса в данных.