При сопровождении нетиповых решений часто возникает ситуация, когда конфигурация была снята с поддержки (или поставлена на поддержку с возможностью изменения) ради добавления одного-двух реквизитов. Со временем это превращается в обузу при обновлении. Современный стандарт разработки в экосистеме 1С:Предприятие 8.3 диктует правило: «максимальная чистота основной конфигурации». Рассмотрим подробнее, как перенести уже накопленные данные из самописного реквизита основной конфигурации в расширение, чтобы вернуть базу на полную поддержку.
Основная цель — вернуть конфигурацию на «замок» (полную поддержку). Это позволяет обновлять систему в автоматическом режиме «далее-далее». Однако перенос данных в расширение таит в себе технические нюансы. Проанализируем ситуацию: в отличие от основной конфигурации, данные расширений хранятся в отдельных таблицах СУБД. Если расширение будет удалено из списка (через кнопку «Удалить»), платформа физически удалит и таблицу с данными. Поэтому, выбирая путь расширений, мы должны быть уверены в регламентах обслуживания базы.
Этот метод подходит, если вам принципиально важно наличие реквизита именно как части метаданных объекта. Разберем по шагам алгоритм действий:
ПоступлениеТоваровУслуг) в расширение, но не будем переносить туда старый реквизит._ВероисповеданиеКонтрагента.
Выборка = Документы.ПоступлениеТоваровУслуг.Выбрать();
Пока Выборка.Следующий() Цикл
Если ЗначениеЗаполнено(Выборка.ВероисповеданиеКонтрагента) Тогда
Объект = Выборка.ПолучитьОбъект();
// Заполняем реквизит расширения
Объект["_ВероисповеданиеКонтрагента"] = Выборка.ВероисповеданиеКонтрагента;
Объект.ОбменДанными.Загрузка = Истина; // Чтобы не срабатывали лишние проверки
Объект.Записать();
КонецЕсли;
КонецЦикла;
ВероисповеданиеКонтрагента из основной конфигурации и принимаем изменения БД._ВероисповеданиеКонтрагента в ВероисповеданиеКонтрагента. Платформа сопоставит данные внутри таблиц расширения.Выясним причину, почему этот способ часто считается предпочтительным для типовых конфигураций, таких как 1С:Бухгалтерия или 1С:ERP. Эти программы построены на Библиотеке стандартных подсистем (БСП), которая уже содержит готовый механизм хранения любых свойств объектов без изменения метаданных.
Преимущества этого метода:
ДополнительныеЗначения), которые никогда не удалятся при манипуляциях с расширениями.Чтобы реализовать этот переход, нужно создать программно или вручную элемент в плане видов характеристик ДополнительныеРеквизитыИСведения, привязанный к набору свойств вашего документа. Затем так же, как в первом варианте, перенести данные из старого реквизита в таблицу дополнительных сведений. Для пользователя разницу можно нивелировать, программно выведя этот доп. реквизит в удобное место формы через расширение.
Рассмотрим еще один безопасный и профессиональный метод — вынос реквизита в отдельный регистр сведений. Это особенно актуально, если реквизитов много или они требуют хранения истории (хотя в нашем случае это просто замена реквизита).
Разберем алгоритм:
ДанныеДокументовРасширение).ДокументСсылка.ПоступлениеТоваровУслуг).ВероисповеданиеКонтрагента.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПоступлениеТоваровУслуг.Ссылка КАК Ссылка,
| ПоступлениеТоваровУслуг.ВероисповеданиеКонтрагента КАК Значение
|ИЗ
| Документ.ПоступлениеТоваровУслуг КАК ПоступлениеТоваровУслуг
|ГДЕ
| ПоступлениеТоваровУслуг.ВероисповеданиеКонтрагента <> ЗНАЧЕНИЕ(Справочник.Вероисповедания.ПустаяСсылка)";
Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();
Пока Выборка.Следующий() Цикл
МенеджерЗаписи = РегистрыСведений.ДанныеДокументовРасширение.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Ссылка = Выборка.Ссылка;
МенеджерЗаписи.ВероисповеданиеКонтрагента = Выборка.Значение;
МенеджерЗаписи.Записать();
КонецЦикла;
Для того чтобы данные в регистре были актуальными, нам потребуется в расширении перехватить событие ПередЗаписью или ПриЗаписи документа и дописать код синхронизации. Это гарантирует, что при изменении данных в форме они попадут в нашу «sidecar-таблицу».
Если в базе сотни тысяч документов, простая обработка вызовет долгую блокировку таблиц и раздувание лога транзакций. Проанализируем, как сделать переход незаметным для пользователей:
Важный совет: Перед удалением реквизита из основной конфигурации обязательно сделайте копию базы и проверьте, не используется ли этот реквизит в запросах других объектов (отчетов, обработок, модулей менеджеров), которые не попали в расширение. Основная конфигурация «не видит» поля расширений в обычных запросах, поэтому такие участки кода придется также переносить в расширение.
Посмотрим на ситуацию со стороны производительности: программное добавление реквизитов на форму (через ЭтаФорма.Элементы.Добавить) может незначительно замедлять открытие, если реквизитов десятки. Для одного-двух полей разница будет незаметна. Однако наиболее стабильным и «правильным» с точки зрения архитектуры 1С является путь интеграции с подсистемой Свойства из БСП.