Как настроить односторонний обмен данными из нескольких баз БП 3.0 в одну базу управленческого учета через собственные планы обмена и правила?

← На главную

Реализация консолидации данных из нескольких независимых информационных баз 1С:Бухгалтерия предприятия 3.0 (БП 3.0) в единую базу для управленческого учета (УУ) — это классическая задача, требующая комплексного подхода. Мы имеем дело с идентичными конфигурациями, что на первый взгляд упрощает задачу, но на практике возникают вопросы синхронизации справочников, предотвращения дублирования данных и интеграции собственного механизма обмена в современный интерфейс Библиотеки стандартных подсистем (БСП). Рассмотрим пошагово, как реализовать такую архитектуру, используя Конвертацию данных 2.1 и механизмы платформы 1С:Предприятие 8.3.

Шаг 1: Подготовка правил обмена в Конвертации данных 2.1

Поскольку базы идентичны, мы можем использовать традиционный подход через XML-обмен. Основная проблема при объединении двух баз в одну — это возможное появление дублей в справочниках (Контрагенты, Номенклатура, Статьи затрат), если они заводились в БУ1 и БУ2 независимо. Разберем, как настроить правила поиска.

Проанализируем стратегию поиска. По умолчанию 1С ищет объекты по УникальномуИдентификатору (GUID). Если справочник в БУ1 и БУ2 заполнялся вручную, GUID у одних и тех же контрагентов будут разными. Для управленческого учета нам нужно "склеить" эти записи в базе-приемнике. В КД 2.1 для этого используются Поля поиска.

Для справочника Контрагенты настроим поиск сначала по ИНН и КПП. Если соответствие не найдено — создаем новый объект.
Для справочника Номенклатура эффективнее всего использовать Артикул или комбинацию Наименование + ЭтоГруппа.
Чтобы визуально разделять данные из разных источников, воспользуемся советом автора: в правилах выгрузки (ПКО) пропишем алгоритм, который будет помещать номенклатуру и контрагентов в родительские папки (например, "Организация 1" и "Организация 2").

Рассмотрим пример кода в обработчике ПриЗагрузке для автоматического распределения по папкам:


Если Не Объект.ЭтоГруппа Тогда
    ИмяПапки = ?(Параметры.БазаИсточник = "БУ1", "Закупки БУ1", "Закупки БУ2");
    РодительОбъекта = Справочники.Номенклатура.НайтиПоНаименованию(ИмяПапки, Истина);
    Если Не РодительОбъекта.Пустая() Тогда
        Объект.Родитель = РодительОбъекта;
    КонецЕсли;
КонецЕсли;

Шаг 2: Создание собственного плана обмена в конфигураторе

Нам необходимо фиксировать изменения в базах-источниках, чтобы выгружать только новые или измененные документы. Разберем, как лучше создать план обмена.

Для конфигураций на БСП (каковой является БП 3.0) не рекомендуется просто копировать существующие типовые планы обмена, такие как СинхронизацияДанныхЧерезУниверсальныйФормат. Это потянет за собой массу лишних зависимостей. Проанализируем правильный алгоритм:

Создаем новый объект ПланОбмена с нуля.
Устанавливаем свойство Распределенная информационная база в значение Ложь.
В составе плана обмена отмечаем нужные нам 4 типа документов (РеализацияТоваровУслуг, ПоступлениеТоваровУслуг, СписаниеСРасчетногоСчета, ПоступлениеНаРасчетныйСчет) и все необходимые справочники.
Важно: для каждого объекта в составе плана обмена устанавливаем Авторегистрация в значение Разрешить (если мы хотим, чтобы 1С сама ставила объекты в очередь на выгрузку при записи).

Добавим в план обмена реквизиты, которые помогут нам в идентификации: Префикс и ДатаНачалаВыгрузки. Это стандарт де-факто для любых обменов в экосистеме 1С.

Шаг 3: Вывод плана обмена в пользовательский интерфейс БП 3.0

Многие разработчики сталкиваются с тем, что созданный план обмена не виден в разделе "Администрирование — Синхронизация данных". В БП 3.0 за это отвечает механизм БСП. Чтобы наш план обмена появился в списках, необходимо зарегистрировать его программно.

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

Пример внесения изменений в модуль ОбменДаннымиПереопределяемый:


Процедура ПолучитьПланыОбмена(ПланыОбменаПодсистемы) Экспорт
    ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена.МойУправленческийОбмен);
КонецПроцедуры

После этого система позволит создавать настройки синхронизации через стандартный помощник, где можно будет загрузить созданные нами в КД 2.1 правила XML.

Шаг 4: Выбор между КД 2.1 и КД 3.0 (Enterprise Data)

Рассмотрим важную альтернативу. Современная БП 3.0 ориентирована на Enterprise Data (КД 3.0). Если мы планируем часто обновлять базы БУ1 и БУ2, правила КД 2.1 могут стать обузой, так как при каждом изменении метаданных от фирмы "1С" правила придется перевыгружать и обновлять.

Преимущества КД 2.1:

Быстрая разработка при прямой конвертации "точка-точка".
Полный контроль над XML-структурой.

Преимущества КД 3.0:

Независимость от изменений в структуре конфигурации (формат EnterpriseData стабилен).
Возможность использовать типовые механизмы обработки коллизий.

Однако, как отметили специалисты в обсуждении, типовой формат EnterpriseData для БП-БП может не содержать всех необходимых полей для управленческого учета "из коробки". Поэтому для специфических задач УУ использование КД 2.1 с собственным планом обмена остается наиболее гибким решением.

Шаг 5: Организационные и технические нюансы

Для стабильной работы системы "2 источника -> 1 приемник" следует придерживаться следующих правил:

Префиксы: Обязательно назначьте уникальные префиксы баз (БУ1 - "Б1", БУ2 - "Б2", УУ - "УУ"). Это критически важно для предотвращения дублирования номеров документов.
Режим загрузки: В базе УУ при загрузке данных программно устанавливайте флаг ОбменДанными.Загрузка = Истина. Это позволит избежать лишних проверок (например, на наличие остатков или корректность корреспонденции счетов), которые уже были выполнены в исходных базах.
Статьи ДДС и затрат: Эти справочники часто требуют ручного маппинга. Посмотрим на ситуацию: в одной базе статью назвали "Аренда офиса", в другой — "Оплата помещения". В базе УУ они должны "схлопнуться". Мы рекомендуем использовать регистр сведений "Соответствие объектов информационных баз" для хранения таких связок, вместо поиска только по наименованию.

Разберем, как предотвратить раздувание базы УУ. Поскольку это база управленческого учета, нам часто не нужна регистрация изменений для обратной отправки (обмен односторонний). В плане обмена в базе УУ следует программно отключать регистрацию изменений для всех объектов при их записи, чтобы таблицы _ChangeRec не росли бесконечно.

Подведем итог: использование собственного плана обмена в связке с КД 2.1 — это надежный и проверенный метод. Главное — правильно интегрировать его в ОбменДаннымиПереопределяемый и тщательно проработать поля поиска в правилах конвертации, чтобы обеспечить чистоту данных в консолидированной базе управленческого учета.