← На главную

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

Чем опасно частичное обновление через механизм поддержки

Рассмотрим, как платформа 1С работает с конфигурацией поставщика. Когда мы запускаем штатное обновление через меню Конфигурация — Поддержка — Обновить конфигурацию с использованием файлов .cf или .cfu, платформа выполняет полное замещение конфигурации поставщика новой версией. Даже если в дереве объединения мы снимем флажки с 80% объектов и оставим только 20%, конфигурация поставщика внутри базы данных обновится целиком.

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

1. Разрушение трехстороннего сравнения. При следующем штатном обновлении платформа будет сравнивать основную конфигурацию, старую конфигурацию поставщика и новую конфигурацию поставщика. Поскольку конфигурация поставщика уже перешла на новый релиз, все оставшиеся 80% неперенесенных типовых объектов платформа посчитает вашими ручными доработками. Это приводит к возникновению сотен ложных различий и многократно увеличивает риск случайно затереть реальный нетиповой код.
2. Появление версионного гибрида. Информационная база фактически становится «франкенштейном», собранным из фрагментов разных релизов. При таком подходе со временем накапливается критическая масса расхождений, и базу становится практически невозможно вернуть на нормальную поддержку.
3. Несоответствие номеров версий. Если же использовать простое меню Сравнить, объединить с конфигурацией из файла, конфигурация поставщика вообще не изменится. В свойствах конфигурации или регистрах сведений будет числиться один номер релиза, а фактический состав метаданных будет ему противоречить.

Подводные камни отраслевых решений: СЛК и зависимости

При работе с отраслевыми конфигурациями на базе УПП необходимо учитывать специфические технологические ограничения:

1. Система лицензирования и защиты конфигураций (СЛК). В подавляющем большинстве отраслевых решений ключевой функционал спрятан в закрытых, скомпилированных общих модулях или защищен внешними компонентами. Если перенести 20% открытого кода или форм, они могут вызвать экспортные методы закрытого модуля, которых в старой версии СЛК попросту нет. Попытка обновить сам модуль защиты может потребовать обновления сервера СЛК или новой лицензии, что заблокирует работу оставшихся 80% функционала.
2. Обработчики обновления информационной базы. В новые релизы поставщики закладывают процедуры миграции данных: создание предопределенных элементов, заполнение служебных констант, пересчет регистров. При выборочном переносе метаданных штатные обработчики обновления при запуске в режиме «1С:Предприятие» либо вовсе не запустятся, либо завершатся аварийно из-за отсутствия нужных реквизитов.
3. Скрытый граф связей. Переносимые 20% функционала редко бывают полностью изолированными. Они неявно опираются на подписки на события, параметры сеанса, роли и ограничения на уровне записей (RLS), а также вызовы привилегированных модулей. Выборочный перенос без глубокого анализа ссылок гарантированно приведет к ошибкам времени выполнения у пользователей.

Вариант 1. Изолированный перенос функционала (бэкпортинг)

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

Разберем по шагам правильный алгоритм:

1. Развертывание эталонной базы. На отдельном сервере или локальной машине разворачиваем чистый новый релиз конфигурации поставщика.
2. Анализ зависимостей. Выделяем целевые 20% функционала и с помощью поиска ссылок на объекты метаданных составляем полный список зависимостей: общие модули, константы, регистры, роли и подписки на события.
3. Изоляция доработок. Чтобы не вносить путаницу в типовые объекты поставщика, переносимые механизмы создаются с собственными уникальными префиксами либо оформляются в виде внешних отчетов, обработок и подсистем.
4. Перенос процедур инициализации. Из модуля обновления конфигурации поставщика вручную вычленяются процедуры заполнения первичных данных, относящиеся к этим 20%, и запускаются во внешней обработке однократно после обновления метаданных.

Вариант 2. Полное обновление базы на тестовой копии с обратным накатом кастомизации

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

Рассмотрим последовательность действий:

1. Подготовка копии. Создаем полную копию рабочей информационной базы и выполняем тестирование и исправление.
2. Штатное обновление конфигурации. Подключаем файл обновления поставщика и накатываем его последовательно через промежуточные релизы до целевого. На данном этапе разрешаем коллизии в пользу нового релиза поставщика, соглашаясь на замещение типовых модулей.
3. Запуск обработчиков обновления. Запускаем базу в режиме «1С:Предприятие» для корректной отработки всех служебных процедур миграции данных.
4. Повторный накат кастомизации. С помощью сравнения с исходной рабочей базой поэтапно возвращаем накопленные 80% уникальных доработок предприятия. При этом доработки адаптируются под изменившуюся логику нового релиза.
5. Комплексное тестирование. Проверяем работу как старых переписанных алгоритмов, так и вновь внедренных 20% функционала, обращая особое внимание на модули под защитой СЛК.

Управление правилами поддержки при двух поставщиках

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

Если принято решение полностью отказаться от обновлений отраслевой ветки и переносить нужные куски вручную, необходимо открыть окно Конфигурация — Поддержка — Настройка поддержки и явно перевести измененные отраслевые подсистемы в режим Объект редактируется с сохранением поддержки или полностью снять их с поддержки соответствующего вендора. Это позволит сохранить корректное и беспрепятственное обновление типового ядра УПП от «1С», исключив конфликты версий в отраслевом блоке.