Как объединить несколько расширений 1С в одно без потери данных?

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

Почему нельзя просто скопировать объекты?

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

Таким образом, основной задачей при объединении является не только перенос программного кода, но и правильная миграция данных между старыми и новыми таблицами. Разберем три основных метода решения этой задачи.

Способ №1: Универсальный обмен данными (самый надежный)

Этот метод считается «золотым стандартом», так как он опирается на штатные механизмы платформы и гарантирует сохранение ссылочной целостности. Рассмотрим его по шагам:

1. Подготовка структуры. Создадим новое расширение, которое станет «результирующим». С помощью функции Сравнить, объединить с конфигурацией из файла перенесем в него все объекты метаданных и программные модули из исходных расширений.
2. Выгрузка данных. Используем обработку УниверсальныйОбменДаннымиXML. Настроим выгрузку всех данных из объектов, которые принадлежат старым расширениям. Важный момент: убедитесь, что выгрузка происходит с сохранением уникальных идентификаторов (GUID). Это критично, чтобы ссылки в документах основной конфигурации не превратились в «Объект не найден».
3. Отключение старых расширений. После того как данные в безопасности (в файле XML), мы можем удалить старые расширения. В этот момент таблицы в базе данных будут очищены. Для безопасности перед удалением структуры метаданных стоит провести резервное копирование и тестирование баз 1С, чтобы гарантированно сохранить возможность восстановления системы при сбоях.
4. Загрузка данных. Установим новое объединенное расширение и через ту же обработку УниверсальныйОбменДаннымиXML загрузим данные из файла. Платформа распределит их по новым таблицам, созданным для нового расширения.

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

Способ №2: Механизм сравнения и объединения конфигураций

Если ваши расширения содержат только доработки существующих объектов (формы, модули) и не имеют собственных данных, процесс значительно упрощается. Разберем, как выполнить техническое слияние кода:

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

Особое внимание уделим заимствованным объектам:

• Если оба расширения меняют одну и ту же форму, платформе будет сложно объединить их автоматически. Нам придется вручную переносить элементы управления и программный код.
• Для обработчиков событий (&Перед, &После, &Вместо) рекомендуется объединять логику в один метод внутри нового расширения, чтобы избежать путаницы в последовательности выполнения кода.

Способ №3: Манипуляции на уровне SQL (для опытных администраторов)

Существует «экстремальный» способ, позволяющий избежать долгой выгрузки и загрузки данных через XML. Он заключается в переименовании таблиц непосредственно в СУБД. Рассмотрим логику процесса:

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

Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Строка Из Структура Цикл
    Если Строка.ИмяМетаданных = "Справочник.ДопИнфо_Расширение1" Тогда
        Сообщить("Имя таблицы в SQL: " + Строка.ИмяТаблицыХранения);
    КонецЕсли;
КонецЦикла;

После создания нового расширения и появления в нем структуры, можно выполнить SQL-запрос типа INSERT INTO ... SELECT FROM, чтобы перелить данные из таблицы _InfoReg123 (старая) в _InfoReg456 (новая). Внимание: данный метод крайне опасен и требует обязательного создания резервной копии базы данных перед началом работ. Мы не рекомендуем использовать его без глубокого понимания внутренней структуры DataExchange 1С.

Важные нюансы и типичные ошибки

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

1. Конфликты имен. Если в Расширении №1 есть справочник ДополнительныеСведения и в Расширении №2 есть объект с таким же именем, при слиянии возникнет коллизия. Вам придется либо переименовать один из них, либо логически объединить их структуру.
2. Порядок (Приоритет) расширений. Посмотрим на свойство расширения Назначение. Если одно расширение имело тип Исправление, а другое Дополнение, убедитесь, что в итоговом расширении установлен правильный тип, иначе порядок применения механизмов &Вместо может измениться.
3. Объекты-заглушки. Часто программисты забывают заимствовать типы данных. Если ваш новый справочник имеет реквизит с типом из другого (еще не перенесенного) расширения, возникнет ошибка при проверке легитимности метаданных.

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