Рано или поздно перед разработчиком или администратором базы данных 1С встает задача: вернуть конфигурацию, которая была снята с поддержки и доработана "внутри", к типовому виду. Основная цель этого процесса — упростить будущие обновления, сохранив при этом весь накопленный функционал. С появлением и развитием механизма расширений такая задача стала выполнимой без потери данных. Рассмотрим подробнее, как правильно организовать этот процесс, какие этапы необходимо пройти и каких технических ловушек стоит избегать.
Прежде чем приступать к техническим действиям, проанализируем основные опасения. Существует мнение, что расширения существенно замедляют работу системы. Однако это не совсем так. Платформа компилирует код расширения вместе с основным кодом. Если мы используем аннотации &Перед или &После, влияние на скорость выполнения практически нулевое. Проблемы могут возникнуть только при избыточном использовании аннотации &Вместо или при добавлении огромного количества новых реквизитов в расширение, что усложняет структуру таблиц в СУБД.
Разберем еще один миф: при обновлении расширения нужно отключать. На самом деле расширения влияют только на структуру метаданных и логику выполнения, они не препятствуют обновлению основной конфигурации поставщика. Главное — следить за режимом совместимости и корректностью заимствованных объектов.
Переход не должен быть разовым "прыжком", особенно если база большая. Мы рекомендуем действовать поэтапно, разделяя перенос логики и перенос данных. Рассмотрим общую последовательность действий:
м_ или НазваниеКомпании_). Это предотвратит конфликты имен, если в будущем фирма "1С" добавит объект с таким же именем в типовой релиз..cf файла поставщика.Если у вас есть добавленные справочники или реквизиты, просто удалить их из основной конфигурации и создать в расширении нельзя — данные будут потеряны. Выясним причину: при удалении объекта из основной конфигурации платформа удаляет соответствующую таблицу в СУБД. Поэтому применим безопасную схему "двойного реквизита".
Разберем этот процесс на примере добавленного справочника:
_Удалить_. Примените изменения. Данные при этом останутся на месте, просто изменится имя таблицы.
Выборка = Справочники["_Удалить_ВашСправочник"].Выбрать();
Пока Выборка.Следующий() Цикл
НовыйОбъект = Справочники.Префикс_ВашСправочник.СоздатьЭлемент();
ЗаполнитьЗначенияСвойств(НовыйОбъект, Выборка);
НовыйОбъект.Записать();
КонецЦикла;
Проанализируем ситуацию, когда справочников много и они связаны ссылками. В этом случае порядок переноса имеет значение. Начинайте с тех справочников, которые являются независимыми (не имеют ссылок на другие ваши доработки), и двигайтесь к более сложным объектам. Если база очень большая, для ускорения можно использовать выгрузку-загрузку через XML, но только для конкретных переносимых объектов.
Посмотрим на пример, когда ваш справочник используется как тип значения в ПВХ (например, в дополнительных реквизитах). Здесь есть тонкость: расширения позволяют расширять тип значения ПВХ, но это может вызвать длительную реструктуризацию таблиц итогов (например, в регистрах бухгалтерии), если ПВХ там используется.
Важно: Если вы работаете на платформе ниже 8.3.14, возможности расширения данных сильно ограничены. На современных версиях (8.3.15+) работать с данными в расширениях стало гораздо безопаснее, так как расширения создают свои собственные таблицы в СУБД "рядом" с основными.
Самое приятное в расширениях — возможность "очистить" типовые формы. Рассмотрим, как это сделать правильно:
&Вместо. Почему? Потому что при обновлении типовой конфигурации 1С может полностью изменить код процедуры. Если у вас стоит &Вместо, ваш старый код просто затрет новый типовой код, и вы можете получить трудноуловимые ошибки в бизнес-логике.&Перед для предварительных проверок и &После для пост-обработки данных или изменения интерфейса после отработки типового кода.После того как вы перенесли всю логику и данные в расширение, а старые объекты в основной конфигурации переименовали в _Удалить_, пора возвращать конфигурацию "под замок".
Выполните сравнение и объединение с типовым .cf файлом соответствующей версии. При объединении снимите галочки со всех ваших объектов с префиксом _Удалить_ (чтобы они не удалились раньше времени, если вы еще не до конца проверили данные) и установите режим "Взять из файла" для всех типовых объектов, которые вы когда-то меняли.
После того как вы убедитесь, что расширение работает корректно, а данные в новых объектах расширения верны, объекты с префиксом _Удалить_ можно окончательно удалить из основной конфигурации через "Конфигурация — Поддержка — Настройка поддержки", вернув объектам статус "На поддержке (замочек)".
Помните, что расширение — это такая же часть программного кода, как и основная конфигурация. Для расширений существует свое собственное хранилище. Если в разработке участвует несколько человек, обязательно настройте хранилище расширения, чтобы не потерять правки. И всегда делайте полную копию базы данных (dt или выгрузка на уровне СУБД) перед каждым этапом реструктуризации данных!
Таким образом, переход на связку "Типовая + Расширения" — это инвестиция в будущее. Хотя процесс переноса данных может быть трудоемким, в дальнейшем вы получите возможность обновлять конфигурацию в автоматическом или полуавтоматическом режиме, тратя на это минуты вместо часов или дней ручного сравнения кода.