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

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

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

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

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

Алгоритм «Золотого стандарта» по переносу реквизита

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

1. Подготовительный этап. Обязательно создаем резервную копию информационной базы. Любые манипуляции со структурой данных сопряжены с риском.
2. Переименование в расширении. Открываем наше расширение, находим нужный реквизит и переименовываем его. Например, если реквизит назывался ДополнительнаяИнформация, переименуем его в Удалить_ДополнительнаяИнформация. Применяем изменения в конфигурации базы данных.
3. Создание реквизита в основной конфигурации. Теперь, когда имя ДополнительнаяИнформация свободно в пространстве имен основной конфигурации, создаем там реквизит с этим исходным именем и соответствующим типом данных.
4. Перенос данных. На этом этапе данные физически находятся в поле Удалить_ДополнительнаяИнформация, а новое поле ДополнительнаяИнформация пустое. Нам необходимо написать обработку для копирования значений.

Проанализируем пример кода для переноса данных. Рассмотрим ситуацию на примере документа РеализацияТоваровУслуг:

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

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

Работа с кодом и ссылками в конфигурации

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

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

Особенности работы с отчетами и СКД

Одной из главных причин переноса реквизитов является ограниченная поддержка расширений в Системе компоновки данных. Выясним основные причины проблем:

• Конструктор запросов: Он часто «не видит» реквизиты расширения, если они не заимствованы в текущий контекст. После переноса в основную конфигурацию реквизит станет доступен во всех конструкторах без ограничений.
• Внешние отчеты: Если реквизит создан в расширении, внешний отчет может работать нестабильно. После переноса в основную конфигурацию стабильность работы повышается.
• Производительность: На уровне SQL-запросов обращение к реквизитам расширения часто инициирует LEFT JOIN с дополнительной таблицей расширения. Перенос в основную конфигурацию объединяет данные в одну таблицу, что ускоряет выборку данных в тяжелых отчетах.

Проблемы при удалении «фантомных» реквизитов

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

1. Использование в формах: Проверьте, не выведен ли реквизит расширения на формы, которые также находятся в расширении. Пока есть визуальная связь, платформа не даст удалить объект метаданных.
2. Хранилище конфигурации: Если вы используете хранилище, убедитесь, что объект не захвачен вами или другим пользователем. Попробуйте выполнить команду «Отменить захват в хранилище» для объектов расширения.
3. Динамическое обновление: Если структура БД «зависла», рекомендуется выполнить полное обновление конфигурации (не динамическое) или запустить процедуру «Тестирование и исправление» с флагом «Реструктуризация таблиц».

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

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

1. Распределенные базы данных (РИБ): Это самый критичный момент. По умолчанию реквизиты расширений не включаются в стандартные планы обмена. Данные, записанные в такие реквизиты, не будут мигрировать между узлами без серьезной ручной доработки правил обмена или создания идентичных расширений во всех узлах сети.

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

3. Глобальный поиск: Поиск по ссылкам может не находить связи, если они ведут на объекты или реквизиты, созданные в разных расширениях.

Подводя итог, можно сказать: если реквизит расширения становится «ключевым» для бизнес-логики или отчетности, его перенос в основную конфигурацию через метод промежуточного переименования — это правильное стратегическое решение, обеспечивающее стабильность и производительность системы.