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

← На главную

Объединение нескольких разрозненных баз в одну — задача, с которой часто сталкиваются при централизации учета или реорганизации структуры компаний. Когда конфигурации идентичны (например, три базы БП 3.0 одинаковых релизов), процесс кажется простым, но он таит в себе множество нюансов: от задвоения справочников до конфликтов нумерации документов. В этой статье мы подробно разберем, как реализовать этот переход, проанализируем различные инструменты и выберем наиболее эффективную стратегию.

Подготовительный этап: что нужно сделать до начала переноса

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

Установка префикса информационной базы. В каждой базе (Администрирование — Синхронизация данных) должен быть установлен уникальный префикс (например, «Б1», «Б2», «Б3»). Это обеспечит уникальность номеров документов и кодов справочников при загрузке в общую базу.
Префиксы организаций. Проверим, чтобы у каждой организации в справочнике Организации также стоял свой уникальный буквенный код.
Аудит справочников. Проанализируем справочники Номенклатура и Контрагенты. Если в разных базах есть одни и те же сущности, созданные вручную, у них будут разные внутренние идентификаторы (GUID). Это неизбежно приведет к дублям, которые придется «схлопывать» после переноса.
Создание резервных копий. Это обязательный пункт. Любые операции по объединению должны проводиться только при наличии актуальных бэкапов всех баз.

Вариант 1: Использование универсальной обработки «Выгрузка и загрузка данных XML»

Это самый простой способ, подходящий для абсолютно идентичных конфигураций. Мы используем обработку V8Exchan.epf (или встроенную «Универсальный обмен данными в формате XML»). Рассмотрим алгоритм работы:

В базе-источнике мы выбираем необходимые объекты (справочники, документы, регистры) и выгружаем их в файл. В базе-приемнике производим загрузку. Важный нюанс: предопределенные элементы справочников (например, основные счета или типы цен), зашитые в конфигурацию, не задвоятся, так как система идентифицирует их по внутреннему имени. Однако обычные элементы справочников, такие как «Бумага А4», могут появиться в трех экземплярах, если они имели разные коды или наименования в исходных базах.

После загрузки нам обязательно потребуется стандартная обработка «Поиск и замена дублей». Мы настроим поиск, например, по ИНН для контрагентов и по Артикулу для номенклатуры, чтобы объединить одинаковые позиции.

Вариант 2: Метод через механизм РИБ (Распределенные Информационные Базы)

Довольно элегантный способ «обмануть» систему и заставить ее саму объединить данные. Проанализируем этот сценарий подробнее:

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


// Пример отключения главного узла, чтобы сделать базу автономной
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

Этот метод хорош тем, что он «штатный», однако требует определенного опыта работы с планами обмена, чтобы не затереть данные в процессе первичной синхронизации.

Вариант 3: Мощный инструмент «Конвертация данных 2.0»

Если нам нужна максимальная гибкость, мы выбираем Конвертацию данных 2.0. Даже для идентичных баз правила обмена позволяют нам на лету менять данные при переносе. Посмотрим на практический пример: нам нужно добавить префикс базы к кодам справочников и номерам документов прямо в процессе выгрузки, чтобы не заниматься перенумерацией в исходных базах.

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


// Алгоритм для подстановки префикса базы при переносе
Префикс = Параметры.Префикс; // Передаем префикс как параметр выгрузки
МетаданныеОбъекта = Источник.Метаданные();
ИмяОбъектаМетаданных = МетаданныеОбъекта.ПолноеИмя();

Если СтрНайти(ИмяОбъектаМетаданных, "Справочник") > 0 Тогда
    СтандартнаяДлинаКода = МетаданныеОбъекта.ДлинаКода;
    ТекущийКод = Источник.Код;
Иначе
    СтандартнаяДлинаКода = МетаданныеОбъекта.ДлинаНомера;
    ТекущийКод = Источник.Номер;
КонецЕсли;

// Формируем новый номер/код с учетом префикса
Если СтрДлина(ТекущийКод) < СтандартнаяДлинаКода Тогда
    Значение = Префикс + "-" + ТекущийКод;
Иначе
    // Если места мало, заменяем первые символы префиксом
    Значение = Префикс + Сред(ТекущийКод, СтрДлина(Префикс) + 1);
КонецЕсли;

Использование правил обмена позволяет решить проблему синхронизации объектов не только по внутреннему идентификатору (GUID), но и по полям поиска. Мы можем указать, что Контрагентов нужно искать по ИНН + КПП, и если такой контрагент уже есть в базе-приемнике (приехал из первой базы), то для второй базы новый объект создан не будет, а документ просто «привяжется» к существующему. Это избавляет от 90% работы по поиску дублей в будущем.

Вариант 4: Перенос документов или ввод остатков?

Рассмотрим ситуацию с точки зрения методологии учета. Часто объединение баз — это повод избавиться от «хвостов». Вместо переноса всех документов за 10 лет, мы рекомендуем:

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

Это значительно облегчит базу-приемник и ускорит ее работу. Выясним причину, почему это важно: БП 3.0 при проведении документов делает записи во множество регистров (бухгалтерских, налоговых, по НДС). При массовом переносе документов за огромный период легко нарушить последовательность, что приведет к некорректному расчету себестоимости и налогов. Ввод остатков — самый безопасный путь.

Анализ проблемных зон после объединения

После того как данные загружены в единую базу, мы должны проанализировать результат. Проверим следующие моменты:

1. Учетная политика. Зайдем в раздел «Главное — Настройки — Учетная политика». В одной базе организации могут иметь разные способы оценки МПЗ (ФИФО или «По средней»). Убедимся, что для каждой организации настройки перенеслись корректно или созданы заново.

2. Банковские счета. Часто в разных базах один и тот же банк заведен как два разных элемента справочника Банки. Это может привести к ошибкам в платежках. Рекомендуем обновить справочник БИК из классификатора и объединить дубли банков.

3. Ответственные лица. Проверьте регистр сведений Ответственные лица. Руководители и главные бухгалтеры должны быть привязаны к своим организациям с правильными датами вступления в должность.

4. Сверка ОСВ. Сформируем Оборотно-сальдовую ведомость в исходных базах и в новой общей базе (с отбором по конкретной организации). Итоговые суммы должны совпадать до копейки. Если есть расхождения — ищем пропущенные документы или неверно перенесенные остатки в регистрах.

Таким образом, объединение баз — это не просто технический экспорт-импорт, а полноценный проект по трансформации данных. Использование Конвертации данных или метода РИБ является наиболее профессиональным подходом, позволяющим сохранить целостность учета и минимизировать ручную чистку дублей.