← На главную

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

Опасность пропуска релизов и поведение обработчиков обновления БСП

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

1. Удаление устаревших процедур обновления разработчиком. Фирма «1С» регулярно оптимизирует код подсистем: процедуры в модулях обновления (метод ПриДобавленииОбработчиковОбновления), предназначенные для версий двух- или трехлетней давности, со временем удаляются. Если перескочить цепочку релизов одним шагом, данные не будут преобразованы под новую структуру, поскольку требуемые обработчики в целевой версии просто отсутствуют.
2. Сбои монопольных и отложенных обработчиков. Процедуры обновления БСП делятся на оперативные (выполняемые при монопольном первом входе) и фоновые (выполняемые регламентными заданиями). Если на базу накатывается следующий релиз до того, как завершилась обработка данных от предыдущего шага, регистры сведений по версиям подсистем переходят в аварийное состояние, блокируя дальнейшую работу.
3. Скрытая потеря данных. База после некорректного прыжка через версии может штатно открываться в режиме предприятия, но при попытке выполнить процедуру «Закрытие месяца», пересчитать итоги или сформировать регламентированную отчетность пользователи столкнутся с неустранимыми ошибками из-за разорванной целостности таблиц.

Технология поэтапного обновления на тестовом контуре

Рассмотрим безопасную последовательность действий при обновлении конфигурации через серию релизов поставщика:

1. Развертывание точной копии рабочей базы. Ни в коем случае не проводим эксперименты и первичные обновления на промышленном сервере.
2. Определение ключевых (переходных) релизов. Изучаем порядок обновления на официальном портале обновлений и выбираем минимально возможную цепочку версий, через которые допускается последовательный переход.
3. Накат релиза и трехстороннее сравнение. Используем штатный механизм «Конфигурация — Поддержка — Обновить конфигурацию». При трехстороннем сравнении сопоставляются старая конфигурация поставщика, новая конфигурация поставщика и текущая основная конфигурация. Анализируем дважды измененные объекты, сохраняя пользовательский функционал.
4. Запуск предприятия и завершение обработчиков. После принятия изменений конфигурации запускаем базу в режиме «1С:Предприятие» и контролируем форму «Результаты обновления программы». Ждем полного завершения всех фоновых заданий БСП.
5. Формирование промежуточного файла поставки. Сохраняем готовую конфигурацию в отдельный файл cf (с указанием точной версии релиза) и повторяем шаги для следующего контрольного релиза.
6. Перенос на рабочую базу. В день технологического окна последовательно загружаем подготовленные файлы cf на рабочий контур, обязательно запуская предприятие после каждого шага для отработки служебных процедур БСП.

Стратегия разделения доработок: что переносить в расширение, а что оставить

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

1. Модификация форм и интерфейса

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

2. Бизнес-логика и алгоритмы модулей

Процедуры и функции переносим в расширение, используя директивы &Перед, &После либо &Вместо. В случаях, когда требуется изменить типовой код точечно, используем аннотацию &ИзменениеИКонтроль. Начиная с платформы 8.3.24, в данной директиве поддерживаются инструкции #Вставка и #Удаление, что позволяет удерживать под контролем лишь модифицированный фрагмент строки, минимизируя сбои при последующих обновлениях поставщика.

3. Хранимые данные (новые объекты и реквизиты)

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

1. Необходимость миграции данных. Созданный в расширении реквизит получает отдельную физическую колонку в таблице базы данных СУБД. Автоматически данные из реквизита основной конфигурации туда не перейдут: потребуется писать отдельную обработку переноса, а также переписывать все существующие запросы в отчетах.
2. Риск безвозвратной потери данных. Если расширение конфигурации будет случайно отключено администратором, повреждено или удалено при аварийном сбое, все созданные им таблицы и поля в СУБД физически удаляются платформой без возможности восстановления штатным путем.
3. Ограничения метаданных. Объекты из расширений имеют технические ограничения: их сложнее связывать с критериями отбора (например, для отображения связанных документов) и нельзя включать в стандартные планы обмена распределенных информационных баз (РИБ).

Таким образом, наилучшая и безопасная тактика: очистить основную конфигурацию от изменений типового программного кода и форм, оставив добавленные ранее реквизиты и справочники в основной ветке метаданных. Всю программную логику и новые доработки переносим в расширение. Это позволит накатывать новые релизы 1С типовым обновлением за минимальное время, сохраняя полную стабильность базы данных.