Перенос доработок из основной конфигурации в расширения — это актуальная задача для многих разработчиков, стремящихся вернуть информационную базу к максимально «типовому» виду. Особенно часто это требуется при обновлении старых модулей (например, модулей интеграции с Битрикс), которые раньше поставлялись как изменения в основной конфигурации, а теперь перешли на модель расширений. Рассмотрим подробно, как выполнить этот процесс, сохранив данные и минимизировав риски.
На текущий момент в платформе 1С (включая последние версии ветки 8.3.24 и 8.3.25) отсутствует прямая кнопка «Перенести объект в расширение» с автоматической сменой принадлежности. Разберем основные способы реализации этой задачи.
1. Ручной перенос (Copy-Paste)
Это самый надежный, хотя и трудоемкий метод. Мы создаем объект в расширении вручную, копируя все его свойства, реквизиты, формы и модули. Проанализируем основные шаги:
Справочник или Документ) с префиксом, чтобы избежать конфликта имен с объектом в основной конфигурации.2. Выгрузка и загрузка через XML-файлы
Рассмотрим более продвинутый способ, который позволяет автоматизировать часть работы. Метод основан на выгрузке конфигурации в файлы:
1C:Enterprise Development Tools (EDT)).3. Использование EDT (Enterprise Development Tools)
Проанализируем возможности современной среды разработки EDT. В отличие от стандартного конфигуратора, EDT позволяет работать с конфигурацией и расширением в рамках одного рабочего пространства. Мы можем буквально перетаскивать (Drag-and-drop) объекты между проектами. Система автоматически предложит варианты обработки зависимостей, что значительно ускоряет процесс.
Самый критичный момент — это сохранение данных. При простом создании объекта в расширении платформа создает новые таблицы в СУБД. Данные из старых таблиц (основной конфигурации) сами туда не попадут. Выясним, как организовать безопасный переезд данных.
Рассмотрим стратегию «мягкого переключения»:
Удалить_).
// Пример переноса данных из основного объекта в объект расширения
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Номенклатура.Ссылка КАК Ссылка,
| Номенклатура.СтароеПолеБитрикс КАК Значение
|ИЗ
| Справочник.Номенклатура КАК Номенклатура
|ГДЕ
| Номенклатура.СтароеПолеБитрикс <> """"";
Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();
Пока Выборка.Следующий() Цикл
Объект = Выборка.Ссылка.ПолучитьОбъект();
// ПР_ПолеБитрикс - реквизит, добавленный через расширение
Объект.ПР_ПолеБитрикс = Выборка.Значение;
Объект.ОбменДанными.Загрузка = Истина;
Попытка
Объект.Записать();
Исключение
ЗаписьЖурналаРегистрации("ПереносДанных", УровеньЖурналаРегистрации.Ошибка, , , ИнформацияОбОшибке().Описание);
КонецПопытки;
КонецЦикла;
Важный нюанс: Если вы создаете новые объекты в расширении вместо использования заимствованных, помните о GUID (уникальных идентификаторах). Если данные из этих объектов участвуют в обменах с внешними системами (например, с сайтом на Битриксе), то при изменении GUID ссылки в другой системе «сломаются». В таких случаях необходимо программно устанавливать тот же GUID при создании объекта в расширении.
Разберем важный вопрос: всегда ли правильно хранить данные в расширениях? В сообществе разработчиков существует правило, которое помогает принять решение:
Контрагенты, Номенклатура, первичные документы.Проанализируем риски хранения данных в расширениях. Основная опасность заключается в том, что при критической ошибке (например, при неудачном обновлении платформы или конфликте метаданных) расширение может «отключиться». Если расширение с данными будет удалено из списка, платформа 1С инициирует удаление соответствующих таблиц в SQL, что приведет к безвозвратной потере информации. В основной конфигурации такие риски значительно ниже.
Для минимизации последствий при работе с расширениями придерживайтесь следующих правил:
.dt и SQL-бэкап перед любыми манипуляциями с составом расширений.ДокументОбъект) в расширении, часто безопаснее использовать РегистрСведений. Это изолирует данные и упрощает их восстановление в случае проблем с основным объектом.Подводя итог, перенос объектов Битрикса или других модулей в расширение — задача выполнимая, но требующая вдумчивого подхода к миграции данных и аудита кода. Если данные не являются критически важными или легко восстановимы — смело используйте расширения. Для учетных данных высокого уровня ценности лучше оставить поля в основной конфигурации, даже если она станет «не совсем типовой».