Как настроить синхронизацию данных между существующими базами 1С:Бухгалтерия предприятия 3.0?

← На главную

При ведении учета в нескольких базах 1С:Бухгалтерия предприятия 3.0 (БП 3.0) рано или поздно возникает задача консолидации данных. Например, когда необходимо настроить одностороннюю или двустороннюю выгрузку данных из двух второстепенных баз (источников) в одну центральную (приемник). При этом базы уже существуют, активно ведутся пользователями и содержат большой объем накопленных данных.

В этой статье мы подробно разберем, какие механизмы синхронизации предлагает платформа 1С, проанализируем риски использования распределенных информационных баз (РИБ) для уже существующих конфигураций, детально изучим современный формат EnterpriseData и выясним, как настроить автоматический обмен без дублирования нормативно-справочной информации (НСИ).

---

Почему классический РИБ не подходит для связывания уже существующих баз?

Первое решение, которое часто приходит на ум разработчикам, — настроить распределенную информационную базу (РИБ). Однако здесь кроется серьезная методологическая и техническая ошибка.

Механизм РИБ изначально проектировался для создания структуры «сверху вниз». Это означает, что периферийный узел должен создаваться как «начальный образ» из главного узла. В этом случае базы имеют абсолютно идентичную структуру метаданных, а главное — одинаковые уникальные идентификаторы (UUID/GUID) для всех предопределенных элементов, справочников и документов, которые были созданы до разделения баз.

Рассмотрим ситуацию, когда базы создавались независимо:

В базе БП_2 создан контрагент «ООО Вектор» с ИНН 7701010101. Ему присвоен GUID_А.
В базе БП_3 вручную создан этот же контрагент «ООО Вектор» с тем же ИНН. Ему присвоен GUID_Б.
В Главной БП также есть этот контрагент с GUID_В.

Если попытаться принудительно связать такие базы через РИБ (например, программно вызвав метод ПланыОбмена.УстановитьГлавныйУзел() в подчиненной базе), механизм синхронизации начнет сопоставлять объекты исключительно по их внутренним идентификаторам (UUID). Поскольку UUID у одного и того же контрагента в базах различаются, система не поймет, что это один и тот же объект. В результате в Главной базе появятся три дублирующих элемента «ООО Вектор».

Программное принудительное назначение главного узла выглядит следующим образом (настоятельно не рекомендуется применять этот код для объединения уже наполненных баз):


// Пример принудительного установления связи, опасный для наполненных баз
УзелГлавный = ПланыОбмена.УдалитьНастройкаОбменаДанными.НайтиПоКоду("ЦБ");
Если ЗначениеЗаполнено(УзелГлавный) Тогда
    ПланыОбмена.УстановитьГлавныйУзел(УзелГлавный);
    ЗаписьЖурналаРегистрации("Синхронизация", УровеньЖурналаРегистрации.Информация, , , "Установлен главный узел РИБ");
КонецЕсли;

Вывод: Для связывания ранее независимых, уже наполненных баз данных стандартный механизм РИБ использовать категорически нельзя.

---

Оптимальное решение: Универсальный формат обмена EnterpriseData

Современные версии конфигурации «1С:Бухгалтерия предприятия 3.0», построенные на базе Библиотеки стандартных подсистем (БСП), содержат мощный встроенный инструмент — универсальный формат обмена EnterpriseData (формат XML). Этот формат позволяет настроить обмен между любыми базами, поддерживающими стандарт, включая сценарий БП 3.0 <-> БП 3.0.

Рассмотрим преимущества интеграции через EnterpriseData:

Независимость от версий конфигурации. При обновлении релизов «1С:Бухгалтерии» фирма «1С» автоматически обновляет встроенные менеджеры обмена. Ваша интеграция не «сломается», как это часто происходит с правилами КД 2.0.
Гибкость настройки. Вы можете настроить односторонний обмен, выгружая из баз-источников только документы и справочники, без обратной загрузки изменений.
Автоматизация процесса. Настройка расписания регламентных заданий позволяет полностью исключить ручной труд.
Интерактивное сопоставление. Возможность ручного сопоставления объектов при первом запуске обмена.

---

Пошаговый алгоритм настройки обмена через EnterpriseData

Выполним настройку синхронизации между подчиненной базой БП_2 (источник) и Главной БП (приемник) через универсальный формат.

Шаг 1. Подготовка баз данных

Перед началом настройки убедимся, что в обеих базах включена возможность синхронизации. Перейдем в раздел Администрирование -> Синхронизация данных и установим флаг «Синхронизация данных».

Шаг 2. Создание настройки в базе-источнике (БП_2)

Перейдем по ссылке «Настройки синхронизации данных» и нажмем кнопку «Новая синхронизация данных» (или «Создать»). Из предложенного списка выберем пункт «Другая программа» (в некоторых релизах он называется «Синхронизация данных через универсальный формат»):

Выберем способ транспорта данных. Наиболее надежный вариант для серверных баз — обмен через сетевой каталог, FTP-ресурс или напрямую через веб-сервис (подключение к базе-приемнику по протоколу HTTP/HTTPS).
Если выбираем локальный или сетевой каталог, укажем путь к общей папке, к которой имеют доступ обе службы кластера серверов 1С (для серверного варианта).
Настроим правила отправки данных: укажем, с какой даты начать выгрузку документов, и определим фильтры по организациям, если это необходимо.
На этапе завершения первого шага система создаст файл настроек (обычно с расширением .xml) для базы-приемника. Сохраним его.

Шаг 3. Настройка в базе-приемнике (Главная БП)

Запустим Главную БП, перейдем в раздел настроек синхронизации данных и создадим новое подключение, выбрав импорт настроек из сохраненного на предыдущем шаге XML-файла:

Система автоматически считает параметры транспорта, коды узлов информационных баз и правила сопоставления.
Настроим правила получения данных в Главной базе (например, укажем значения по умолчанию для пустых реквизитов).
Выполним тестовое подключение для проверки связи.

---

Решение проблемы дублирования НСИ (Контрагенты, Номенклатура)

Самый критический момент при объединении независимых баз — предотвращение появления дублей справочников. Как было сказано ранее, сопоставление по UUID не сработает. Однако БСП предоставляет разработчикам и администраторам встроенный инструмент решения этой проблемы.

Проанализируем работу Помощника сопоставления данных, который автоматически запускается при первом сеансе синхронизации:

При первой загрузке данных в Главную БП система не запишет новые элементы сразу. Она откроет форму сопоставления.
По умолчанию для справочника «Контрагенты» будут применены правила поиска по полям: ИНН + КПП. Для «Номенклатуры» — по полям: Артикул или Наименование.
Помощник покажет процент сопоставленных объектов. Например, если в БП_2 и в Главной БП существовал контрагент с ИНН 7701010101, система сопоставит их со 100%-ной точностью, несмотря на разные UUID.
Если у каких-то объектов совпадение частичное, пользователь может связать их вручную на специальной интерактивной форме.

После того как связь между объектами установлена (автоматически или вручную), информация об этом записывается в специальный технический регистр сведений «Соответствия объектов информационных баз» (РегистрСведений.СоответствияОбъектовИнформационныхБаз). При всех последующих обменах система будет обращаться сначала к этому регистру. Если запись найдена, обновление произойдет по уже существующей ссылке, полностью исключая дублирование.

Для понимания логики работы приведем пример кода, выполняющего поиск сопоставления в регистре БСП:


Функция ПолучитьСопоставленныйОбъект(УзелИнформационнойБазы, ИсходнаяСсылкаСсылка) Экспорт
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Соответствия.СобственнаяСсылка КАК СобственнаяСсылка
        |ИЗ
        |   РегистрСведений.СоответствияОбъектовИнформационныхБаз КАК Соответствия
        |ГДЕ
        |   Соответствия.УзелИнформационнойБазы = &УзелИнформационнойБазы
        |   И Соответствия.УникальныйИдентификаторИсточника = &УникальныйИдентификаторИсточника";
    
    Запрос.УстановитьПараметр("УзелИнформационнойБазы", УзелИнформационнойБазы);
    Запрос.УстановитьПараметр("УникальныйИдентификаторИсточника", Строка(ИсходнаяСсылкаСсылка.УникальныйИдентификатор()));
    
    РезультатЗапроса = Запрос.Выполнить();
    Если Не РезультатЗапроса.Пустой() Тогда
        Выборка = РезультатЗапроса.Выбрать();
        Выборка.Следующий();
        Возврат Выборка.СобственнаяСсылка;
    КонецЕсли;
    
    Возврат Неопределено;
КонецФункции

---

Использование Конвертации данных: КД 2.0 против КД 3.0

Если стандартных правил обмена через универсальный формат недостаточно (например, требуется сложная трансформация данных «на лету», перенос самописных реквизитов или специфическая фильтрация документов), придется прибегнуть к кастомизации правил синхронизации.

В экосистеме 1С существуют две версии конфигурации «Конвертация данных»:

Конвертация данных 2.0 (КД 2.0). Работает по принципу прямого сопоставления «Метаданные Источника -> Метаданные Приемника». Правила выгружаются в XML-файл. Хотя для одинаковых конфигураций (БП 3.0 -> БП 3.0) сгенерировать такие правила в КД 2.0 достаточно просто, этот подход имеет огромный минус. При каждом обновлении БП 3.0 (а бухгалтерия обновляется очень часто) структура метаданных может измениться, и правила обмена перестанут работать.
Конвертация данных 3.0 (КД 3.0). Работает на основе концепции обмена через формат EnterpriseData. Вместо прямого сопоставления метаданных вы настраиваете сопоставление вашей конфигурации с универсальным XDTO-пакетом. Плюс этого подхода в том, что даже при обновлении релизов «1С:Бухгалтерии», пока формат обмена остается неизменным, ваши правила продолжат успешно функционировать без вмешательства программиста.

Посмотрим на пример логики настройки поиска в КД 2.0, если вы все же решили использовать этот инструмент. Чтобы избежать дублей, в ПКО (Правилах конвертации объектов) для справочника «Контрагенты» необходимо отключить поиск по УИД и установить флаги поиска по ИНН и КПП:


// Пример обработчика "Поля поиска" в правилах КД 2.0
Если СвойстваПоиска["ИНН"] <> Неопределено Тогда
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Контрагенты.Ссылка КАК Ссылка
        |ИЗ
        |   Справочник.Контрагенты КАК Контрагенты
        |ГДЕ
        |   Контрагенты.ИНН = &ИНН";
    Запрос.УстановитьПараметр("ИНН", СвойстваПоиска["ИНН"]);
    
    Результат = Запрос.Выполнить();
    Если Не Результат.Пустой() Тогда
        Выборка = Результат.Выбрать();
        Выборка.Следующий();
        СсылкаНаОбъект = Выборка.Ссылка;
        ПрекратитьПоиск = Истина;
    КонецЕсли;
КонецЕсли;

При использовании КД 3.0 аналогичная логика поиска настраивается в модуле менеджера обмена через переопределение алгоритмов сопоставления объектов формата и объектов ИБ, что гораздо более технологично и отказоустойчиво.

---

Настройка автоматического расписания

Чтобы настроить регулярный автоматический обмен без участия пользователей, выполним следующие шаги:

В окне «Синхронизация данных» выберем созданную настройку обмена и нажмем кнопку «Сценарии синхронизации».
Создадим новый сценарий обмена. Укажем в табличной части наше подключение и выберем выполняемые действия (например, «Получение данных», затем «Отправка данных»).
Настроим расписание выполнения. Например, запускать обмен каждые 30 минут в течение рабочего дня или один раз в сутки ночью.
Сохраним настройки. Система автоматически создаст фоновое регламентное задание, которое будет выполняться на сервере 1С под управлением планировщика.

Для мониторинга работы автоматического обмена всегда используйте встроенный «Журнал регистрации» с отбором по событию «Синхронизация данных», чтобы оперативно отслеживать ошибки транспорта или блокировки объектов при параллельной работе пользователей.