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

← На главную

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

Почему данные не переносятся автоматически?

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

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

Пошаговый алгоритм переноса реквизитов

Рассмотрим стандартную и наиболее безопасную методику переноса, которую рекомендуют опытные специалисты.

Создание реквизита в основной конфигурации. Добавим в документ основной конфигурации нужный реквизит. На этом этапе крайне важно не допустить конфликта имен. Если реквизит в расширении называется ПРМ_ЛогикаРасчета, мы можем временно назвать новый реквизит ПРМ_ЛогикаРасчета_Новый или сразу использовать целевое имя, но тогда в расширении старый реквизит придется предварительно переименовать (например, в Удалить_ПРМ_ЛогикаРасчета).
Программный перенос данных. Это самый ответственный этап. Нам необходимо написать обработку, которая прочитает значения из поля расширения и запишет их в поле основной конфигурации.
Проверка и рефакторинг кода. После переноса данных нужно найти все упоминания старого реквизита в коде (запросы, формы, модули) и заменить их на новый реквизит. Помните, что платформа не делает этого автоматически при перемещении между слоями конфигурации.
Удаление расширения. Только убедившись, что данные на месте и код работает исправно, мы можем удалить реквизит из расширения и само расширение.

Пишем обработку для переноса данных

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


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

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

Оптимизация при больших объемах данных

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

При использовании SQL-запроса (на свой страх и риск и только на клиент-серверном варианте) суть сводится к выполнению команды UPDATE, которая скопирует данные из одной колонки в другую. Но для этого нужно точно знать структуру хранения, используя функцию ПолучитьСтруктуруХраненияБазыДанных().

Нюансы с типами данных и ссылками

Выясним причину возможных сложностей при работе с другими типами данных, отличными от Булево:

Ссылочные типы: Если реквизит ссылается на справочник, который уже есть в основной конфигурации, проблем не будет. Уникальные идентификаторы (GUID) сохранятся.
Типы из расширения: Если вы переносите реквизит, тип которого — это новый справочник, также созданный в расширении, вам сначала придется перенести этот справочник в основную конфигурацию, а затем уже заниматься реквизитом.
Версионирование: Если у вас включена история изменений (версионирование), имейте в виду, что старые версии объектов в регистре ВерсииОбъектов будут хранить данные в формате XML, где будет фигурировать старое имя реквизита из расширения. После удаления расширения просмотр истории изменений за прошлые периоды может стать неполным.