Разработка через расширения конфигурации (Extensions) стала стандартом де-факто в мире 1С. Это удобно, безопасно и позволяет обновлять типовые конфигурации с минимальными затратами. Однако нередко возникает обратная задача: доработки, сделанные в расширении, необходимо "влить" в основную конфигурацию. Причины могут быть разными: от снятия конфигурации с поддержки до требований производительности или архитектурных изменений.
В этой статье мы подробно разберем, как выполнить этот перенос грамотно. Казалось бы, задача тривиальная, но она таит в себе множество подводных камней, связанных с уникальными идентификаторами (UUID), переносом форм и, самое главное, адаптацией программного кода.
Самый очевидный и простой способ, который первым приходит на ум — это использование буфера обмена или перетаскивание объектов мышью.
Давайте рассмотрим алгоритм действий:
Ctrl + C (или Ctrl + Ins) в расширении и Ctrl + V (или Shift + Ins) в основной конфигурации. Либо просто перетаскиваем объекты мышкой.Этот метод работает быстро, но у него есть критический недостаток, о котором мы обязаны предупредить. При копировании объекта создается новый внутренний идентификатор (UUID). Если в вашей базе данных уже есть ссылки на этот объект (например, в сохраненных настройках пользователей, вариантах отчетов или, тем более, если вы планируете переносить данные), эти связи будут разорваны.
Когда применять этот метод?
Мы рекомендуем использовать этот способ только для простых, изолированных объектов: новых отчетов, обработок или вспомогательных справочников, которые не имеют жестких связей с другими объектами и по которым еще нет накопленных данных в рабочей базе.
Более профессиональный подход, позволяющий сохранить идентификаторы объектов и выполнить перенос более контролируемо — это использование механизма «Сравнить, объединить с конфигурацией из файла».
Однако здесь мы сталкиваемся с техническим ограничением: платформа 1С не позволяет напрямую сравнивать основную конфигурацию с файлом расширения (.cfe). Платформа ожидает файл конфигурации (.cf). Но, как мы знаем, структура этих файлов внутри контейнера практически идентична.
Разберем по шагам, как обойти это ограничение:
.cfe..cfe в .cf. Для этого существуют специализированные утилиты, такие как В8АнПак — новый распаковщик конфигураций. Если же утилиты под рукой нет, можно воспользоваться HEX-редактором или применить универсальный распаковщик и запаковщик файлов, позволяющий манипулировать внутренним содержимым контейнера.
Суть метода с HEX-редактором заключается в изменении сигнатуры файла. Мы открываем файл и меняем первые байты заголовка, чтобы платформа распознала его как обычную конфигурацию. Это позволяет "обмануть" механизм сравнения и объединения.
.cf файл, мы возвращаемся в конфигуратор. Выбираем: «Конфигурация — Сравнить, объединить с конфигурацией из файла» и указываем наш конвертированный файл.Преимущества этого метода:
Самая трудоемкая часть задачи — это перенос кода. Если метаданные (справочники, документы) переносятся относительно легко, то с модулями все гораздо сложнее.
Код в расширениях использует специфические аннотации и директивы компиляции, которые не работают в основной конфигурации. Давайте проанализируем, с чем придется столкнуться.
В расширении вы, скорее всего, использовали конструкции вида:
&Вместо("РассчитатьСумму")
Процедура Расш1_РассчитатьСумму(Параметры)
// Ваша логика
ПродолжитьВызов(Параметры);
КонецПроцедуры
Или:
&После("ПриЗаписи")
Процедура Расш1_ПриЗаписи(Отказ)
// Дополнительные проверки
КонецПроцедуры
Если мы просто скопируем этот текст в модуль объекта основной конфигурации, платформа выдаст синтаксическую ошибку, так как она не знает, что такое &Вместо или &После внутри обычного модуля.
Что делать? Нам придется заниматься ручным рефакторингом (переработкой) кода:
РассчитатьСумму).&После, вставляем наш код в конец типовой процедуры.&Перед, вставляем код в начало.&Вместо, нам нужно полностью заменить тело типовой процедуры на код из расширения, либо (что правильнее) аккуратно встроить изменения внутрь существующей логики.Это кропотливая работа, требующая высокой внимательности. Чтобы облегчить этот процесс, можно применить инструмент для объединения модулей в разрезе методов, который позволяет значительно упростить ручной рефакторинг кода при переносе логики из расширения в основную конфигурацию.
Отдельного внимания заслуживают управляемые формы. В расширении формы часто хранятся не целиком, а в виде "разностных изменений" (дельты). Например, в расширении может быть информация только о том, что на форму добавлена одна кнопка и одно поле ввода.
При переносе в основную конфигурацию мы рекомендуем следующий подход:
Если вы ведете разработку в среде 1C:EDT (Enterprise Development Tools), задача решается несколько иначе. Поскольку проект в EDT представляет собой структуру файлов и папок на диске, мы можем оперировать файлами метаданных.
Мы можем физически переместить файлы, описывающие объекты, из папки проекта расширения (src) в папку проекта конфигурации. Среда разработки поможет отследить некоторые зависимости, но, как и в случае с конфигуратором, код модулей придется адаптировать вручную, избавляясь от аннотаций расширения.
Перенос функционала из расширения в конфигурацию — это не просто "Copy/Paste". Чтобы не нарушить целостность базы данных и логику работы, мы советуем придерживаться следующего плана:
.cf и объединение, чтобы сохранить UUID.&Вместо, &Перед, &После и встраивая логику в типовые процедуры. Для финальной проверки системы после ручного переноса кода незаменимым помощником станет анализ конфигураций и расширений на наличие ошибок.И помните: если есть возможность оставить код в расширении, не ломая процесс обновления типовой конфигурации — лучше оставить его там. Перенос в основную конфигурацию оправдан только тогда, когда изменения становятся неотъемлемой частью ядра системы.