Как правильно перенести изменения из расширения в основную конфигурацию 1С и избежать потери данных

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

Анализ причин и подготовка к переносу

Перед тем как приступать к активным действиям, проанализируем текущую ситуацию. Основная сложность заключается в том, что 1С не предоставляет штатной кнопки «Объединить расширение с основной конфигурацией». Нам придется действовать комбинированным методом: ручной перенос метаданных, программный перенос данных и использование механизмов сравнения/объединения.

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

Шаг 1: Подготовка структуры в основной конфигурации

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

1. Снимем основную конфигурацию с поддержки (с сохранением поддержки и возможностью изменений) или включим возможность изменения для конкретных объектов.
2. Вручную создадим в основной конфигурации все реквизиты, которые ранее были добавлены только в расширении. Важно максимально точно соблюдать типы данных и длину строк.
3. Для массового переноса метаданных проанализируем технический прием: выгрузим расширение в файл .cf. Затем создадим пустую базу, загрузим в нее этот .cf как основную конфигурацию. Теперь из нашей рабочей базы мы можем запустить «Сравнение и объединение» с этой новой базой. Это позволит нам отметить галочками нужные объекты и перенести их структуру, не перебивая всё «ручками» с нуля.

Шаг 2: Программный перенос накопленных данных

Выясним, как не потерять данные. Пока расширение еще подключено, а в основной конфигурации уже созданы аналогичные реквизиты (но с другими именами, например, ИмяРеквизита_Осн), нам нужно написать обработку, которая скопирует значения.

Пример логики для переноса данных в справочнике:

Выборка = Справочники.Контрагенты.Выбрать();
Пока Выборка.Следующий() Цикл
    ОбъектОсн = Выборка.ПолучитьОбъект();
    // Предположим, 'ДопКонтакт' - реквизит расширения, а 'ДопКонтакт_Новый' - основной конфигурации
    ОбъектОсн.ДопКонтакт_Новый = ОбъектОсн.ДопКонтакт; 
    ОбъектОсн.ОбменДанными.Загрузка = Истина;
    ОбъектОсн.Записать();
КонецЦикла;

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

Шаг 3: Перенос программного кода и логики

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

• Используйте подписки на события: Это самый «чистый» способ. Если в расширении был код в ПередЗаписью, создайте в основной конфигурации ПодпискаНаСобытие, вынесите логику в общий модуль. Это упростит будущие обновления от вендора.
• Программная модификация форм: Вместо визуального изменения форм в расширении, используем возможности общих модулей типа МодификацияКонфигурацииПереопределяемый. Это позволит программно добавлять кнопки и элементы управления при создании формы на сервере.

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

// В общем модуле (серверном)
Процедура ПриЗаписиОбъектаДляПереноса(Источник, Отказ) Экспорт
    // Источник - это наш документ или справочник
    Если Источник.ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;
    // Ваша логика, которая раньше была в расширении
КонецПроцедуры

Шаг 4: Борьба с ошибками SQL и индексами

Посмотрим на ситуацию, описанную в Сообщении 12. Иногда при удалении реквизитов расширения система выдает ошибку уникальности индексов или ошибку SDBL: Некорректное использование LOCAL/GLOBAL в SET GENERATION.

Разберем алгоритм решения, если система «спотыкается» при реструктуризации:

1. Проанализируем версию платформы. Если она ниже 8.3.12.1616, крайне рекомендуется обновиться. В ранних релизах 12-й ветки механизмы очистки таблиц расширений работали нестабильно.
2. Если ошибка уникальности индекса все же возникла (например, из-за появления дублирующих записей в таблице версий), может потребоваться вмешательство на уровне SQL. Проанализируем проблемную таблицу, найдем дубли по ключевым полям и удалим лишние записи.
3. Как отмечалось в обсуждении, иногда помогает временное удаление индексов у проблемных таблиц в SQL перед сохранением изменений в конфигураторе, после чего обязательно нужно запустить Тестирование и Исправление (ТИИ) с включенным режимом реиндексации для восстановления структуры.

Шаг 5: Права доступа и роли

Не забудем про важный нюанс: права доступа. Объекты в расширении могли иметь свои роли или быть добавлены в заимствованные. При переносе объектов в основную конфигурацию они автоматически не попадут в типовые роли (например, «Пользователь»).

Нам необходимо:

• Создать новую роль в основной конфигурации для наших доработок.
• Либо вручную добавить права на новые объекты в существующие роли.
• Проверить функциональные опции, если они использовались в расширении.

Итоги и рекомендации

Отказ от расширения — трудоемкий процесс, требующий внимательности к данным. Мы проанализировали основные риски и выяснили, что ключ к успеху лежит в последовательности: структура -> перенос данных -> перенос кода -> очистка расширения.

Старайтесь минимизировать использование прямой правки модулей объектов в пользу подписок на события. Это позволит вам сохранить конфигурацию максимально близкой к типовой, что существенно облегчит жизнь при следующем обновлении на новые релизы ERP или Бухгалтерии.