Как правильно перенести доработки из основной конфигурации в расширение при переходе с БП 2.0 на БП 3.0

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

Почему стандартный механизм работает иначе для нетиповых объектов

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

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

Шаг 1. Подготовка расширения и перенос метаданных

Первым делом проанализируем текущее состояние базы. У нас есть обновленная до БП 3.0 конфигурация, где наши доработки все еще находятся в основной ветке. Нам необходимо создать чистое расширение.

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

1. Откроем конфигуратор и создадим новое расширение.
2. В основной конфигурации выделим нужный объект (например, документ или регистр сведений).
3. Используем стандартное сочетание клавиш Ctrl + C.
4. Перейдем в окно конфигурации расширения. Внимание: вставлять объект нужно строго в соответствующую ветку. Если копируете документ — выделите заголовок «Документы» в расширении и нажмите Ctrl + V.

Проанализируем ситуацию: после вставки платформа может автоматически добавить индекс к имени (например, МойРегистр1). Это происходит, если объект с таким именем все еще существует в основной конфигурации. На данном этапе это нормально.

Шаг 2. Использование префиксов и уникальных идентификаторов

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

Для предотвращения конфликтов имен в будущем (например, если фирма «1С» встроит в типовую БП объект с таким же названием), крайне рекомендуется добавить к имени объекта в расширении уникальный префикс, например пр_.

Пример переименования:

• В основной конфигурации: РегистрСведений.ДополнительныеДанные
• В расширении: РегистрСведений.пр_ДополнительныеДанные

Шаг 3. Алгоритм «Безопасный перенос данных»

Самое распространенное заблуждение — вера в то, что данные «подцепятся» автоматически. В серверном варианте работы таблицы расширений в базе данных SQL физически отделены от таблиц основной конфигурации и имеют префиксы вида _Ext.... Следовательно, после удаления объекта из основной конфигурации данные исчезнут, если их не переместить.

Разберем промышленный стандарт переноса:

1. В основной конфигурации переименуем старые объекты, добавив суффикс _Удалить (например, РегистрСведений.пр_Сведения_Удалить).
2. В расширение скопируем этот объект с правильным целевым именем (например, РегистрСведений.пр_Сведения).
3. Выполним обновление конфигурации базы данных. На этом этапе у нас будут существовать две таблицы: одна старая с данными, другая новая (в расширении) — пустая.
4. Напишем и запустим обработку для программного переноса данных.

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

Выборка = РегистрыСведений.пр_Сведения_Удалить.Выбрать();
Пока Выборка.Следующий() Цикл
    МенеджерЗаписи = РегистрыСведений.пр_Сведения.СоздатьМенеджерЗаписи();
    ЗаполнитьЗначенияСвойств(МенеджерЗаписи, Выборка);
    // Если есть ссылки на переносимые документы, здесь нужно логику сопоставления
    МенеджерЗаписи.Записать();
КонецЦикла;

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

Шаг 4. Очистка основной конфигурации

После того как мы убедились, что все данные успешно перенесены в объекты расширения и проверили работу функционала:

1. Удалим объекты с пометкой _Удалить из основной конфигурации.
2. Установим конфигурацию на полную поддержку (закроем «замочек»), если в ней больше не осталось других доработок.
3. Выполним финальное обновление базы данных.

Важные предостережения

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

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

Использование данного метода позволяет полностью освободить основную конфигурацию от изменений, что значительно упрощает эксплуатацию системы 1С:Бухгалтерия предприятия 3.0 в долгосрочной перспективе.