Перенос доработок из основной конфигурации в расширения — это стратегическая задача для любого разработчика 1С, стремящегося упростить процесс обновления типовых решений, таких как «Управление торговлей 11» или «ERP». Рассмотрим этот процесс подробно, проанализируем риски и разберем по шагам, как выполнить миграцию объектов метаданных и программного кода, сохранив целостность информационной системы.
Основная цель — вернуть типовую конфигурацию на «замочек» (полную поддержку). Это позволяет специалистам, не знакомым с вашими доработками, выполнять обновление платформы и конфигурации в автоматическом или полуавтоматическом режиме. При этом все ваши изменения остаются в отдельном слое — расширении, которое «накладывается» на типовой функционал сверху. Проанализируем ситуацию: если раньше добавление нового реквизита в справочник требовало снятия объекта с поддержки, то теперь расширение позволяет сделать это, не меняя структуру основной конфигурации.
Начиная с платформы 8.3.11, разработчики получили возможность создавать собственные справочники, документы и планы видов характеристик непосредственно в расширении. Выясним важный нюанс: если вы добавили объект в расширение, платформа создает для него отдельную таблицу в базе данных SQL. Это означает, что просто «перетащить» справочник мышкой из основной конфигурации в расширение и нажать «Удалить» в основной конфигурации нельзя — вы потеряете все накопленные данные.
Рассмотрим правильный алгоритм переноса созданных ранее объектов:
Расш_).Для сохранения GUID при программном переносе данных используем метод УстановитьСсылкуНового(). Разберем пример кода для переноса элемента справочника:
НовыйЭлемент = Справочники.Расш_Контрагенты.СоздатьЭлемент();
СтараяСсылка = Справочники.Контрагенты.НайтиПоКоду("001");
НовыйЭлемент.УстановитьСсылкуНового(Справочники.Расш_Контрагенты.ПолучитьСсылку(СтараяСсылка.УникальныйИдентификатор()));
ЗаполнитьЗначенияСвойств(НовыйЭлемент, СтараяСсылка);
НовыйЭлемент.Записать();
В ранних версиях (8.3.11) существовало ограничение на добавление регистров накопления в расширения. Однако в современных релизах платформы (8.3.12+) это ограничение снято. Разберем ситуацию, если вам нужно расширить типовой регистр (например, «ЗаказыКлиентов»). Платформа до сих пор не позволяет добавлять измерения или ресурсы в типовые регистры через расширение. В таких случаях мы используем стратегию «параллельного регистра»:
Создаем в расширении свой регистр сведений или накопления, где в качестве одного из измерений выступает регистратор или ссылка на основной объект. Данные в такой регистр записываются через подписки на события или аннотации &После в модулях наборов записей.
Один из самых частых страхов разработчиков — потеря данных при сбое расширения. Проанализируем разницу между состояниями:
Важный совет: Ограничьте права доступа к форме «Управление расширениями». Только узкий круг администраторов должен иметь возможность удалять расширения, содержащие данные.
Ранее расширения не передавались автоматически между узлами РИБ, что создавало огромные риски. Посмотрим, как это решается сейчас. В свойствах расширения необходимо установить флаг «Использовать в распределенной информационной базе». Также убедитесь, что версия платформы на всех узлах совпадает и поддерживает используемый функционал расширений.
Перенос программного кода (процедур и функций) — самая приятная часть работы с расширениями. Вместо того чтобы менять типовой код, мы используем механизм аннотаций. Рассмотрим основные варианты:
&Перед("ИмяПроцедуры") — для предварительных проверок или подготовки данных.&После("ИмяПроцедуры") — для выполнения дополнительных действий после завершения типового алгоритма (например, отправка уведомления после проведения чека).&Вместо("ИмяПроцедуры") — для полной замены типовой логики. Используйте этот метод осторожно, так как при обновлении типовой конфигурации логика исходной процедуры может измениться, и ваша замена станет некорректной.Проанализируем пример использования аннотации &После для добавления логгирования в типовой документ:
&После("ОбработкаПроведения")
Процедура Расш_ОбработкаПроведения(Отказ, РежимПроведения)
// Наша дописка
ТекстЛога = "Документ " + Строка(ЭтотОбъект) + " проведен пользователем " + ПараметрыСеанса.ТекущийПользователь;
ЗаписьЖурналаРегистрации("ПроведениеДокументов", УровеньЖурналаРегистрации.Информация, , , ТекстЛога);
КонецПроцедуры
Перед началом миграции обязательно проверьте свойство «Режим совместимости» основной конфигурации. Даже если вы установили платформу 8.3.24, но ваша конфигурация работает в режиме совместимости 8.3.10, вы не сможете использовать многие функции расширений (например, собственные регистры). Выясним причину: расширение не может иметь режим совместимости выше, чем у основной конфигурации. Если типовое решение требует старого режима, вам придется либо смириться с ограничениями, либо повышать режим совместимости всей базы, что требует тщательного тестирования всей системы.
Подведем итог нашего анализа. Перенос дописок в расширения — это не просто «копипаст» кода, а серьезное изменение архитектуры хранения данных. Рассмотрим ключевые правила безопасности:
Следуя этим шагам, мы сможем эффективно поддерживать систему, минимизировать время на обновления и использовать все современные преимущества платформы 1С:Предприятие 8.3.