Как эффективно переносить объекты между основной конфигурацией 1С и расширением

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

Проблема ручного копирования и потери типов

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

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

Способ 1. Использование 1C:Enterprise Development Tool (EDT)

EDT — это современная среда разработки, которая работает с конфигурацией как с набором XML-файлов. В отличие от классического «Конфигуратора», EDT предоставляет гораздо более гибкие инструменты миграции метаданных, хотя объединение модулей в разрезе методов сегодня доступно и в обычном конфигураторе.

Разберем алгоритм работы в EDT:

1. Импортируйте вашу основную конфигурацию в проект EDT.
2. Создайте в этом же рабочем пространстве (workspace) новый проект расширения.
3. Используйте механизм Drag-and-Drop: просто перетащите необходимые объекты из дерева метаданных конфигурации в дерево расширения.
4. Проанализируйте ошибки: среда автоматически проверит зависимости. Если объект расширения ссылается на тип, который остался в основной конфигурации, EDT предложит добавить этот объект в расширение как «заимствованный».

Этот метод считается наиболее безопасным, так как EDT корректно правит связи в XML-структурах, сохраняя целостность типов данных.

Способ 2. Сравнение и объединение через «Эталонную базу»

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

1. Создайте пустую базу и добавьте в нее пустое расширение.
2. В режиме конфигуратора расширения выберите пункт меню «Конфигурация — Сравнить, объединить с конфигурацией из файла...».
3. В качестве файла выберите .cf вашей основной разработки.
4. В появившемся окне сравнения снимите все флажки и выберите только нужную вам подсистему. Система предложит включить все связанные объекты — соглашайтесь.
5. Важный момент: убедитесь, что в правилах объединения указано соответствие объектов. Это позволит системе «понять», что объекты из CF должны стать новыми объектами расширения, а не пытаться изменить структуру самой конфигурации.

Способ 3. Автоматизация через OneScript и выгрузку в XML

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

Схема работы скрипта:

1. Выполняется стандартная команда: Designer.exe /DumpConfigToFiles [ПутьКПапке].
2. Скрипт на OneScript анализирует файл ConfigDumpInfo.xml, чтобы найти объекты, принадлежащие вашей подсистеме.
3. Скрипт копирует XML-файлы этих объектов в новую структуру каталогов, которая соответствует формату расширения.
4. В главном файле описания конфигурации (Configuration.xml) меняется заголовок (Namespace) на соответствующий расширению.
5. Выполняется сборка расширения из файлов обратно в .cfe.

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

Критический нюанс: Перенос данных в СУБД

Выясним причину, по которой нельзя просто «перекидывать» объекты туда-сюда на живой базе. Когда вы создаете Справочник.МойСправочник в основной конфигурации, платформа создает в SQL таблицу с именем вроде _Reference75. Если вы переместите этот объект в расширение, платформа создаст новую таблицу с префиксом расширения, например _Reference75_EXT1.

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

Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ * ИЗ Справочник.МойСправочник"; // Источник (в CF)
Результат = Запрос.Выполнить().Выгрузить();

Для Каждого Строка Из Результат Цикл
    НовыйОбъект = Расширение_Справочники.МойСправочник.СоздатьЭлемент();
    ЗаполнитьЗначенияСвойств(НовыйОбъект, Строка);
    НовыйОбъект.Записать();
КонецЦикла;

Совместимость со старыми платформами

Если ваша задача — поддержка УТ 10.3 или систем с режимом совместимости 8.3.6, использование расширений для хранения данных невозможно. В таких случаях рекомендуем использовать «Гибридный метод»:

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

Если РасширенияКонфигурации.Получить().Количество() > 0 Тогда
    // Логика для современных систем
КонецЕсли;

Выводы

Подводя итог, можно сказать, что выбор метода зависит от частоты обновлений. Если вы обновляете подсистему раз в полгода — достаточно метода со «Сравнением и объединением». Если же вы ведете активную разработку, настоятельно рекомендуем перейти в EDT или настроить автоматизированную сборку через OneScript. Это исключит человеческий фактор и ошибки типизации при миграции объектов между основной конфигурацией и расширением.