При масштабировании бизнеса или слиянии нескольких подразделений часто возникает задача объединения информационных баз 1С. Ситуация осложняется, когда базы "не наследуемые", то есть имеют разные уникальные идентификаторы (GUID) одних и тех же объектов (товаров, контрагентов), но при этом содержат огромный объем данных — миллионы документов. Разберем, как эффективно решить эту задачу, избежав ручного исправления дублей и обеспечив ссылочную целостность.
Рассмотрим сценарий, когда в каждой из пяти объединяемых баз 1С:Управление торговлей 11.4 содержится порядка 10 000 элементов номенклатуры, 5 000 контрагентов и более 1 000 000 документов. Главная сложность заключается в том, что стандартная выгрузка/загрузка по умолчанию ориентируется на внутренний идентификатор 1С (GUID). Поскольку базы создавались независимо, один и тот же контрагент в разных базах имеет разные GUID. Однако у нас есть зацепка — наличие общих синхронизирующих полей, таких как ИНН/КПП или специально добавленный реквизит с идентификатором из старой системы.
Разберем классический, но требующий аккуратности метод создания правил обмена (ПКО). Несмотря на трудоемкость, это самый гибкий инструмент для работы со сложными условиями сопоставления. Проанализируем основные шаги настройки:
СправочникСсылка.Номенклатура, СправочникСсылка.Контрагенты.ИНН + КПП или ваш пользовательский реквизит ID_OldSystem.Важный нюанс при больших объемах: Стандартный обмен через XML-файл может вызвать переполнение оперативной памяти. Проанализируем ситуацию: миллион документов — это гигабайты текстовых данных. Рекомендуем выгружать данные частями, например, по месяцам или по организациям. Также при загрузке в целевую базу следует использовать режим ОбменДанными.Загрузка = Истина, чтобы отключить лишние проверки и ускорить процесс.
// Пример настройки поля поиска в КД 2.1
Если НомерВариантаПоиска = 1 Тогда
// Ищем по уникальному коду из прошлой системы
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Ссылка ИЗ Справочник.Контрагенты ГДЕ КодСтаройБазы = &Код";
Запрос.УстановитьПараметр("Код", СвойстваПоиска["КодСтаройБазы"]);
// ... логика поиска
КонецЕсли;
Посмотрим на современный подход, встроенный в УТ 11.4. Механизм EnterpriseData позволяет сопоставлять данные "на лету" без написания сложных правил конвертации. Рассмотрим этот процесс подробнее:
При первой синхронизации система предложит окно сопоставления данных. Это ключевой этап. Вы можете выполнить автоматическое сопоставление по выбранным колонкам (например, по артикулу для номенклатуры). После того как вы вручную или автоматически подтвердите связи, система запишет их в регистр сведений СоответствияОбъектовИнформационныхБаз. В дальнейшем, при загрузке документов, 1С будет обращаться к этому регистру, находить правильную ссылку по GUID источника и подставлять её в документ, даже если в целевой базе у объекта совсем другой GUID.
Если время на выполнение задачи ограничено, а сервер обладает достаточными мощностями, можно применить стратегию "Сначала слияние, потом очистка". Выясним, как это сделать наиболее эффективно:
Сначала мы загружаем все данные "как есть". Это неизбежно создаст дубли. Для их устранения воспользуемся типовой обработкой "Поиск и удаление дублей". Однако на миллионе документов стандартный механизм замены ссылок может работать крайне медленно. В этом случае программисты часто прибегают к прямой подмене ссылок на уровне СУБД (SQL-запросы). Это рискованный метод, требующий остановки всех пользователей и обязательного создания бэкапа, но он сокращает время обработки с нескольких суток до нескольких часов.
Алгоритм замены ссылок:
1. Определяем "правильный" элемент (эталон).
2. Находим все "дубли".
3. SQL-запросом типа UPDATE во всех таблицах документов заменяем ID дубля на ID эталона.
4. Удаляем пустые дубли справочников средствами 1С.
Проанализируем ситуацию с точки зрения производительности. Чтобы избежать постоянных поисков НайтиПоРеквизиту() во время загрузки миллиона документов, разработаем механизм кэширования. Разберем шаги:
Подведем итог и составим пошаговый план, который минимизирует риск появления "битых ссылок":
Шаг 1: Подготовка НСИ. Загружаем только справочники (Номенклатура, Контрагенты, Партнеры) из всех пяти баз в одну целевую. Используем поиск по вашим уникальным полям (ИНН, артикул, ID). На этом этапе важно добиться того, чтобы в целевой базе справочники были "чистыми".
Шаг 2: Тотальная нормализация. Проводим финальную проверку. Если дубли все же просочились, "схлопываем" их до того, как начнем грузить документы. Проверяем заполнение всех ключевых реквизитов, которые могут понадобиться для проведения документов (ставки НДС, единицы измерения, группы финансового учета).
Шаг 3: Загрузка документов. Теперь, когда справочники синхронизированы, начинаем загрузку документов. Поскольку объекты НСИ уже существуют в базе, загрузчик найдет их по вашим правилам поиска и корректно проставит ссылки в документах. Это гарантирует, что движения по складам и взаиморасчетам "лягут" на правильные карточки.
Важное предостережение: Перед началом таких масштабных работ обязательно проверьте конфигурации на идентичность. Даже небольшое различие в типах данных или составе реквизитов в разных базах УТ 11.4 может привести к ошибкам при загрузке. Выполните тестовое объединение на небольшой выборке данных (например, за один день), чтобы убедиться в правильности выбранной стратегии.