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

← На главную

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

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

Проанализируем механику работы платформы 1С:Предприятие 8.3. Когда мы добавляем реквизит в основную конфигурацию, платформа создает поле в соответствующей таблице базы данных (SQL или файловой). Если же мы добавляем реквизит в расширение, платформа создает отдельную таблицу, которая связана с основной таблицей объекта по внутреннему идентификатору (ID).

Важный момент: если вы просто создадите аналогичный реквизит в расширении и удалите его из основной конфигурации, платформа при обновлении конфигурации базы данных просто уничтожит старое поле в таблице SQL вместе со всеми данными. Автоматического «переезда» значений из основной конфигурации в расширение не существует.

Более того, данные в расширении имеют специфический жизненный цикл:

Если расширение будет удалено из списка расширений — данные его реквизитов будут физически удалены из СУБД.
Если расширение станет несовместимым после обновления конфигурации или платформы, данные станут недоступны до тех пор, пока работоспособность расширения не будет восстановлена.

Алгоритм безопасного переноса данных в расширение

Рассмотрим пошагово, как выполнить миграцию, если вы все же решили вынести хранение данных в расширение:

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


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

Результат = Запрос.Выполнить().Выбрать();

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

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

Рекомендуемая архитектура: «Гибридный подход»

Многие опытные разработчики (как отмечено в сообщениях форума) придерживаются стратегии, которая минимизирует риски потери данных. Разберем ее суть:

Реквизиты оставляем в основной конфигурации. Даже если вы хотите «типовую» конфигурацию, наличие нескольких добавленных реквизитов в справочниках или документах практически не усложняет обновление. При сравнении/объединении они просто будут висеть в списке как добавленные объекты.

Логику и интерфейс выносим в расширение. В расширение переносятся:

Формы (а лучше программное изменение форм).
Модули (обработчики событий, подписки).
Макеты и отчеты.

Такой подход гарантирует, что данные никогда не «отвалятся» вместе с расширением, а основная конфигурация останется легко обновляемой.

Программная модификация форм вместо заимствования

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


&НаСервере
&Вместо("ПриСозданииНаСервере")
Процедура ИмяПрефикс_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    ПродолжитьВызов(Отказ, СтандартнаяОбработка);
    
    // Программное добавление поля на форму
    НовыйЭлемент = Элементы.Добавить("ИмяПрефикс_ПолеДопИнфо", Тип("ПолеФормы"), Элементы.ГруппаОсновное);
    НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
    НовыйЭлемент.ПутьКДанным = "Объект.ИмяПрефикс_НовыйРеквизит";
КонецПроцедуры

Этот метод позволяет не заимствовать визуальную часть формы, сохраняя гибкость при обновлениях.

Использование аннотаций: &ИзменениеИКонтроль

При работе с кодом в расширении крайне рекомендуется использовать аннотацию &ИзменениеИКонтроль (вместо &Вместо). Посмотрим, почему это важно:

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

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

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

Преимущества:

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

Недостатки: К таким данным чуть сложнее обращаться в запросах (нужно соединение с табличной частью), и они могут работать медленнее при огромных объемах данных.

Резюме

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