Как перенести реквизиты из основной конфигурации в расширение без потери данных

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

Почему нельзя просто создать реквизит в расширении

Проанализируем техническую сторону вопроса. Когда мы добавляем реквизит в основную конфигурацию, платформа создает соответствующее поле в таблице СУБД (например, _Fld1234). Если мы создаем реквизит в расширении, платформа создает другое поле (например, _Fld1234_Ext1). Даже если имена и типы данных совпадают, физически это разные колонки в базе данных. Поэтому «перенос» реквизита — это всегда двухэтапный процесс: создание структуры в расширении и физическая миграция данных программным способом.

Метод 1: Миграция при переходе с редакции 2.0 на 3.0

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

1. Подготовка целевой конфигурации: Сначала загрузите типовую конфигурацию БП 3.0. Чтобы данные из БП 2.0 «приземлились» правильно при обновлении, вам придется временно снять конфигурацию 3.0 с поддержки (или разрешить изменения) и вручную добавить в нужные объекты те же реквизиты, которые были в 2.0, с теми же именами и типами.
2. Выполнение обновления: Проведите процедуру обновления (миграции данных) из 2.0 в 3.0. Платформа сопоставит реквизиты по именам, и ваши данные окажутся в основной конфигурации 3.0.
3. Создание расширения: Создайте новое расширение. Добавьте в него (заимствуйте) объекты, в которых находятся ваши реквизиты.
4. Создание дублирующих реквизитов: В расширении создайте новые реквизиты. Рекомендуется использовать префикс, чтобы не путать их (например, Доп_ВажныйПараметр).
5. Перенос данных внутри 3.0: Напишите и запустите внешнюю обработку, которая перепишет значения из реквизитов основной конфигурации в реквизиты расширения.
6. Очистка: После проверки данных удалите нетиповые реквизиты из основной конфигурации 3.0 и верните ее на замок (полную поддержку).

Метод 2: Программный перенос данных (универсальный способ)

Если база уже работает на 3.0, но изменения все еще находятся в основной конфигурации, рассмотрим алгоритм «бесшовного» переноса. Выясним, как написать код для миграции данных. Предположим, у нас есть документ РеализацияТоваровУслуг и добавленный в него реквизит НомерКонтейнера.

Разберем пример кода для миграции:

Процедура ПеренестиДанныеВРасширение()
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Ссылка,
        |   НомерКонтейнера КАК СтароеЗначение
        |ИЗ
        |   Документ.РеализацияТоваровУслуг КАК Реализация
        |ГДЕ
        |   НомерКонтейнера <> """""; // Условие, чтобы не обрабатывать пустые
    
    Результат = Запрос.Выполнить();
    Выборка = Результат.Выбрать();
    
    Пока Выборка.Следующий() Цикл
        Объект = Выборка.Ссылка.ПолучитьОбъект();
        // Реквизит_Расширения - это имя нового реквизита, созданного в расширении
        Объект.Реквизит_Расширения = Выборка.СтароеЗначение;
        
        Попытка
            Объект.Записать(РежимЗаписиДокумента.Запись);
        Исключение
            Сообщить("Ошибка при записи объекта " + Выборка.Ссылка + ": " + ОписаниеОшибки());
        КонецПопытки;
    КонецЦикла;
КонецПроцедуры

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

Метод 3: Использование временного файла конфигурации

Рассмотрим более хитрый способ, который обсуждался программистами для сохранения идентификаторов (хотя он не отменяет логику работы колонок SQL, он помогает при массовом переносе метаданных):

1. Снимите основную конфигурацию с поддержки.
2. Объедините её со старой конфигурацией, чтобы все реквизиты появились в объектах.
3. Создайте расширение и заимствуйте эти объекты вместе с реквизитами.
4. Сохраните расширение в файл .cfe.
5. Верните основную конфигурацию к типовому состоянию (через "Загрузить конфигурацию из файла", выбрав типовой .cf).
6. Загрузите ранее сохраненное расширение.

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

Анализ альтернатив: Дополнительные реквизиты (БСП)

Проанализируем ситуацию: стоит ли вообще использовать расширение? Если ваши реквизиты носят справочный характер и не требуют сложной логики в запросах, рассмотрите механизм Дополнительных реквизитов и сведений из состава Библиотеки Стандартных Подсистем (БСП).

Преимущества этого подхода:

• Конфигурация остается на полной поддержке.
• Не нужно возиться с расширениями и их обновлением.
• Данные хранятся в типовых таблицах БСП и не пропадают при обновлении или удалении расширения.

Однако помните, что обращение к доп. реквизитам в коде и запросах происходит медленнее и выглядит сложнее, чем работа с прямым реквизитом объекта.

Критически важные рекомендации

При работе с расширениями всегда помните о следующих рисках:

1. Удаление расширения: В отличие от основной конфигурации, если вы случайно удалите расширение из списка в базе данных, платформа мгновенно удалит все данные в реквизитах этого расширения из СУБД без возможности восстановления (кроме бэкапа).
2. Распределенные базы данных (РИБ): Работа с реквизитами расширений в РИБ требует особой осторожности. Убедитесь, что расширение установлено во всех узлах, иначе миграция данных может привести к ошибкам синхронизации.
3. Индексация: Если вы перенесли высоконагруженный реквизит в расширение, обязательно проверьте настройки индексирования. В расширениях они могут отличаться, что приведет к замедлению работы отчетов.

Таким образом, мы выяснили, что прямого способа «перетащить» реквизит из основной конфигурации в расширение простым кликом мыши не существует. Оптимальный путь — это создание структуры в расширении и программная миграция данных с помощью внешней обработки. Это гарантирует сохранность информации и чистоту основной конфигурации.