Ситуация, когда необходимо наладить обмен данными между двумя абсолютно одинаковыми конфигурациями (например, 1С:Бухгалтерия предприятия КОРП), возникают довольно часто: при слиянии компаний, выделении филиалов или необходимости синхронизации работы удаленных офисов. Рассмотрим подробно все доступные механизмы решения этой задачи, начиная от штатных средств платформы и заканчивая программными методами.
Классический подход подразумевает использование механизма РИБ. Обычно это происходит путем создания «образа» подчиненного узла из главной базы. Однако, если у нас уже есть две существующие и наполненные данными базы, мы можем прибегнуть к «хитрому» способу их связки. Проанализируем этот алгоритм по шагам.
Шаг 1. Подготовка конфигураций
Прежде всего, убедимся, что версии конфигураций в обеих базах идентичны. Если они различаются, необходимо обновить их до одного релиза. В противном случае механизм обмена заблокирует загрузку данных из-за несоответствия метаданных.
Шаг 2. Настройка префиксов
Для того чтобы документы, созданные в разных базах, не конфликтовали по номерам, в каждой базе необходимо задать уникальный префикс информационной базы. Это делается в разделе Администрирование — Синхронизация данных.
Шаг 3. Ручная программная связка узлов
Разберем ситуацию, когда мы хотим превратить одну из существующих баз в «подчиненную» без создания образа. В первой (основной) базе создаем узел в плане обмена. Во второй базе также создаем узел, который будет соответствовать основной базе. Теперь нам нужно программно объяснить второй базе, что она является подчиненной в распределенной сети. Для этого мы можем использовать следующий код в обработке:
// Устанавливаем признак того, что данная база является подчиненной
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаУзелГлавнойБазы);
// Завершаем настройку РИБ через константу
Константы.НастройкаПодчиненногоУзлаРИБЗавершена.Установить(Истина);
// Фиксируем статус в регистре сведений
МенеджерЗаписи = РегистрыСведений.ОбщиеНастройкиУзловИнформационныхБаз.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Узел = СсылкаНаУзелГлавнойБазы;
МенеджерЗаписи.НастройкаЗавершена = Истина;
МенеджерЗаписи.Записать();
После выполнения этих действий система начнет воспринимать вторую базу как периферийную. Рассмотрим нюанс: если при обмене возникнет ошибка соответствия конфигураций, необходимо выгрузить файл конфигурации (.cf) из центральной базы и загрузить его в подчиненную через режим Конфигуратор.
Если мы хотим избежать жесткой зависимости РИБ (когда изменения метаданных в главной базе блокируют работу подчиненной до обновления), наиболее предпочтительным вариантом является Enterprise Data. Этот механизм позволяет обмениваться данными через независимый формат XML.
Выясним основные преимущества этого способа:
Проанализируем процесс настройки:
В разделе Администрирование выбираем Синхронизация данных. Создаем новый обмен, выбрав пункт "Синхронизация через универсальный формат". В качестве транспорта можно использовать общую сетевую папку или FTP-сервер. Важно на этапе первой синхронизации внимательно пройти шаг "Сопоставление данных", чтобы избежать дублирования справочников Контрагенты и Номенклатура.
Если оба компьютера находятся в одной локальной сети, мы можем настроить обмен без использования промежуточных файлов. Одна база будет подключаться к другой «на лету».
Этот способ настраивается в том же помощнике синхронизации. Мы указываем путь к базе-корреспонденту, логин и пароль пользователя. Платформа будет использовать COMConnector для передачи данных. Это значительно ускоряет процесс, так как исключается этап записи и чтения файлов на диск.
Рассмотрим критическую проблему, о которой часто забывают: уникальные идентификаторы. В двух разных базах один и тот же контрагент (например, "ПАО Сбербанк") имеет разные GUID (внутренние ссылки). При простом копировании документа из базы А в базу Б через РИБ, система увидит незнакомый GUID контрагента и создаст нового — так появляются дубли.
Как мы можем этого избежать?
ИНН + КПП.Выгрузка и загрузка данных XML с включенной опцией "Поиск по полям".Для продвинутых пользователей и разработчиков существует вариант написания собственного обмена через HTTP-сервисы или Web-сервисы. Это позволяет реализовать максимально гибкую логику. Например, в момент проведения документа в одной базе, он автоматически «проталкивается» во вторую базу через POST-запрос.
Пример простейшего GET-запроса для получения данных из другой базы может выглядеть так:
Соединение = Новый HTTPСоединение("server_address", , "user", "password");
Запрос = Новый HTTPЗапрос("/base_name/hs/exchange/get_data/123");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
ДанныеJSON = Ответ.ПолучитьТелоКакСтроку();
// Обработка полученных данных
КонецЕсли;
Если задача обмена стоит в контексте слияния компаний, иногда разумнее не мучиться с постоянным обменом, а один раз объединить базы. Проанализируем этот сценарий:
В одной из баз выполняется процедура "Свертка информационной базы" (удаляются лишние документы за прошлые периоды, остаются только остатки). После этого с помощью обработки Выгрузка и загрузка данных XML или Конвертация данных все объекты переносятся в основную базу. После объединения работа продолжается в одной базе, возможно, с использованием механизма разделения по организациям.
Подведем итог: для быстрого решения «здесь и сейчас» лучше всего подходит штатный механизм Синхронизации данных через универсальный формат. Если же требуется жесткая идентичность баз и полная автоматизация — выбираем РИБ, не забывая про программную настройку узлов, если базы уже существуют.