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

← На главную

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

Постановка задачи и анализ рисков

Представим ситуацию: в типовой конфигурации «Управление торговлей 11.4» были добавлены собственные реквизиты в справочник Номенклатура и документ РеализацияТоваровУслуг. Наша задача — перенести эти данные в расширение, чтобы основная конфигурация полностью соответствовала релизу поставщика. Основной риск заключается в механизме реструктуризации базы данных. В СУБД (MS SQL Server или PostgreSQL) данные основной конфигурации и данные расширения хранятся в разных физических колонках, а иногда и в разных таблицах. Простое «перемещение» объекта в дереве метаданных невозможно.

Метод 1: Программный перенос через временные реквизиты в расширении

Этот метод считается наиболее надежным и рекомендуемым в сообществе 1С-разработчиков. Разберем его по шагам:

Создание реквизитов в расширении. Добавим необходимые объекты в расширение, но дадим им временные имена. Например, если в основной конфигурации реквизит назывался СрокГарантии, в расширении создадим его как СрокГарантии_Временный.
Обновление структуры данных. Применим изменения (F7). Теперь в базе данных существуют две колонки: одна со старыми данными, вторая — пустая в расширении.
Написание обработки для переноса. Напишем небольшую процедуру, которая скопирует значения из старых реквизитов в новые. Рассмотрим пример кода для справочника:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   Номенклатура.Ссылка КАК Ссылка,
    |   Номенклатура.СрокГарантии КАК СтароеЗначение
    |ИЗ
    |   Справочник.Номенклатура КАК Номенклатура
    |ГДЕ
    |   Номенклатура.СрокГарантии <> 0"; // Условие зависит от типа данных

Выборка = Запрос.Выполнить().Выбрать();

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

Удаление реквизитов из основной конфигурации. После того как мы убедились, что данные успешно скопированы в СрокГарантии_Временный, мы можем смело удалять реквизиты из основной конфигурации и приводить её к типовому виду.
Финальное переименование. Теперь в расширении переименуем СрокГарантии_Временный в оригинальное название СрокГарантии. Платформа при переименовании внутри расширения данные сохранит.

Метод 2: Использование типовых механизмов БСП (Дополнительные реквизиты)

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

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

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

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

Технические нюансы: Режим совместимости и СУБД

Важно помнить, что работа с данными в расширениях полноценно появилась только в последних версиях платформы. Для корректной работы расширение должно иметь свойство ИзменяетСтруктуруДанных установленным в значение Истина.

Проанализируем критические моменты, упомянутые опытными разработчиками:

Режим совместимости: Если ваша база работает в режиме совместимости ниже 8.3.12, возможности расширений по хранению данных будут сильно ограничены или нестабильны.
Тестирование и исправление (ТиИ): Будьте осторожны при запуске ТиИ. На некоторых старых релизах платформы (8.3.14.х) существовала ошибка, при которой очистка ссылок на несуществующие объекты могла затронуть данные в расширениях, если те были временно отключены.
Идентификаторы объектов: При удалении реквизитов из основной ИБ и добавлении их в расширение, их внутренние идентификаторы (GUID) изменятся. Это означает, что если эти реквизиты использовались во внешних отчетах или интеграциях через OData/COM, их придется перенастраивать.

Метод 3: Сериализация в JSON или XML (Внешнее хранилище)

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

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

Пример структуры выгрузки:


// Пример структуры в JSON
[
    {"Ref": "550e8400-e29b-41d4-a716-446655440000", "Value": "24 месяца"},
    {"Ref": "670e8400-e29b-11d4-a716-446655440001", "Value": "12 месяцев"}
]