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

← На главную

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

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

Вариант 1. Сохранение нетиповых документов в основной конфигурации с частичной поддержкой

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

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

Почему этот подход удобен:

Сами метаданные нетиповых объектов никак не мешают автоматическому обновлению. Поставщик не пришлет в обновлении объект с таким же именем (если вы использовали уникальные префиксы), поэтому при обновлении эти объекты будут просто игнорироваться и бесконфликтно переходить из релиза в релиз.
Вам не придется решать сложную задачу по переносу исторических данных и перепроведению документов.
База обновляется практически в один клик, так как все программные изменения изолированы в расширении.

Вариант 2. Полный перенос нетиповых документов в расширение с миграцией данных

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

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

Выполним процедуру миграции по следующему алгоритму:

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

Рассмотрим пример кода обработки для переноса документов с сохранением UUID:


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

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

Проблема «тяжелых» управляемых форм в расширениях и пути ее решения

Одной из главных проблем ранних версий механизма расширений (до платформы 8.3.14) была избыточная зависимость заимствованных форм от родительской конфигурации. Когда мы заимствуем форму в расширение для добавления одной кнопки или реквизита, платформа физически копирует в расширение все элементы формы, ее команды и связанные реквизиты.

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

Для обхода этой проблемы на практике выработаны два надежных решения:

1. Полностью программное изменение форм

Этот метод считается наиболее надежным и «неубиваемым» при любых обновлениях типовых конфигураций. Мы заимствуем форму в расширение, но не переносим в нее визуальные элементы. Вместо визуального конструирования мы пишем код программного создания элементов в обработчике события ПриСозданииНаСервере с аннотацией &После.

Проанализируем пример такого программного добавления реквизита и поля на форму:


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

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

2. Использование современных возможностей платформы (начиная с 8.3.14)

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

Контроль стабильности при использовании аннотаций методов

При переносе программного кода в модули расширений критически важно правильно выбирать аннотации для процедур и функций. Наибольшую опасность представляет директива &Вместо.

Разберем риски использования аннотации &Вместо:

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

Рекомендации по безопасной разработке:

Минимизируйте использование директивы &Вместо. Отдавайте приоритет аннотациям &Перед и &После. Это гарантирует выполнение оригинального кода поставщика.
Всегда используйте уникальные префиксы для имен процедур и функций в расширении (например, Процедура Префикс_ПриЗаписиПосле(...)). Это защитит вас от конфликта имен, если в новом релизе поставщик добавит метод с аналогичным названием.
После каждого обновления конфигурации обязательно запускайте встроенный инструмент платформы: Конфигурация — Расширения конфигурации — Проверить применимость расширений. Это позволит вовремя обнаружить несоответствие сигнатур методов и заблокированные объекты.

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