Как программно перенести доработки из конфигурации в расширение 1С

← На главную

Перенос накопленных годами доработок из основной конфигурации в расширения — это масштабная задача, с которой сталкивается практически каждый разработчик при переходе на типовые конфигурации на "замке". Часто возникает соблазн автоматизировать этот процесс, чтобы не переносить сотни реквизитов и форм вручную. Рассмотрим подробнее, возможен ли программный перенос, какие инструменты для этого существуют и с какими подводными камнями придется столкнуться.

Использование 1C:EDT как основной инструмент рефакторинга

На сегодняшний день самым цивилизованным способом полуавтоматического переноса является использование 1C:EDT (Enterprise Development Tool). В отличие от стандартного Конфигуратора, EDT глубоко понимает структуру связей между объектами и предоставляет инструменты рефакторинга. Проанализируем, как это работает по шагам:

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

Однако стоит помнить, что автоматика часто спотыкается на сложных запросах в динамических списках или на определяемых типах. Поэтому после автоматического переноса в EDT всегда требуется ручная проверка критических узлов. Для автоматической проверки конфигураций и расширений на ошибки можно использовать инструмент для анализа конфигураций и расширений на наличие ошибок.

Программная манипуляция XML-файлами и GUID-ами

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

Заимствованный объект: Он должен ссылаться на UUID объекта в основной конфигурации. В XML-файле расширения за это отвечает атрибут mdObjectExternalId.
Собственный объект расширения: Он создается "с нуля" внутри расширения и получает новый UUID.

Проанализируем алгоритм автоматизации через скрипты (например, на OneScript):

Для успешного переноса необходимо написать парсер, который будет считывать XML-файлы основной конфигурации и генерировать на их основе файлы для расширения. Важнейшим моментом здесь является сохранение логической целостности. Если мы просто перенесем файл реквизита, но не обновим файл владельца (например, формы или самого справочника), мы получим ошибку формата потока (Stream Format Error) при попытке загрузки конфигурации в базу.

Пример структуры метаданных в XML, на которую стоит обратить внимание при программной генерации:


<ChildObjects>
    <Attribute uuid="новый-uuid-объекта">
        <Properties>
            <Name>НашНовыйРеквизит</Name>
            <Synonym/>
            <Comment/>
            <Type>
                <v8:Type>cfg:CatalogRef.Контрагенты</v8:Type>
            </Type>
        </Properties>
    </Attribute>
</ChildObjects>

Перенос программного кода и использование аннотаций

Перенос модулей — самая сложная часть задачи. Копипаст здесь работает только для полностью независимых процедур. Если же мы переносим изменения в типовых механизмах, необходимо использовать механизмы расширений. Рассмотрим наиболее эффективный метод — аннотацию &ИзменениеИКонтроль.

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


&Вместо("ТиповаяПроцедура")
Процедура Расш1_ТиповаяПроцедура()
    // #Вставлено
    Сообщить("Наш код работает до начала");
    // #КонецВставленного

    // #Удалено
    // ТиповойКод();
    // #КонецУдаленного
КонецПроцедуры

Для программного переноса кода можно использовать регулярные выражения, которые будут искать измененные участки кода (по комментариям разработчика, если они велись) и оборачивать их в структуры для расширений.

Критическая проблема: Миграция данных

Важно понимать разницу между метаданными и данными в таблицах SQL. Если мы решим перенести реквизит ДополнительнаяИнформация из основной конфигурации в расширение, просто удалив его в одном месте и создав в другом, данные будут потеряны.

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

Решение задачи миграции:

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

Программная автоматизация без учета этого этапа приведет к катастрофической потере информации в рабочей базе.

Выводы и рекомендации

Подведем итог нашему анализу. Программный перенос "в лоб" через замену GUID-ов в файлах — это трудоемкий процесс, сопряженный с высоким риском повредить структуру конфигурации. Выясним наиболее рациональные подходы:

Во-первых, используйте 1C:EDT для переноса самих объектов (метаданных). Это сэкономит массу времени на прописывании UUID-ов вручную.

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

В-третьих, всегда планируйте этап миграции данных. Помните, что расширение — это прежде всего инструмент для изменения логики (UI и кода), а для хранения данных оно требует повышенного внимания к консистентности таблиц базы данных.