← На главную

При обслуживании доработанных конфигураций «1С:Бухгалтерия 8» (редакция 3.0) специалисты часто сталкиваются с ситуацией, когда база не обновлялась несколько месяцев или даже полгода. Последовательная установка десятков файлов обновлений (*.cfu) требует колоссальных затрат времени. Возникает логичный вопрос: можно ли ускорить процесс и сразу обновить базу, применив полный файл конфигурации поставщика (*.cf) последнего релиза? Разберем подробно, как ведет себя платформа в таком сценарии, с какими подводными камнями можно столкнуться и как правильно организовать процедуру.

Как работает механизм обновления при перескакивании через релизы

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

Если база была обновлена конфигуратором с версии, например, 3.0.120 до 3.0.140 за один шаг, БСП при запуске определит текущую версию данных и целевую версию конфигурации. Система попытается последовательно вызвать алгоритмы пересчета и переноса данных для каждого из 20 пропущенных релизов.

Однако в этой схеме скрывается ключевой риск, связанный с удалением и переименованием реквизитов или табличных частей.

Анализ рисков и причин возможной потери данных

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

1. Релиз 1: Существует справочник с реквизитом Адрес, в котором хранятся важные пользовательские данные.
2. Релиз 2: Разработчики меняют архитектуру. Реквизит переименовывается в УдалитьАдрес, а новые данные теперь должны храниться в отдельном регистре сведений. В этот релиз закладывается обработчик обновления, который считывает данные из УдалитьАдрес и записывает их в новый регистр.
3. Релиз 3: Реквизит УдалитьАдрес окончательно удаляется из структуры метаданных конфигурации.

Теперь посмотрим на ситуацию, если мы перескакиваем с Релиза 1 сразу на Релиз 3 с помощью одного *.cf файла:

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

Аналогичная ситуация периодически возникает и с регистрами сведений (например, при реструктуризации регистров учета НДС или сведений о физических лицах).

Правильная методика обновления нетиповой базы

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

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

Рассмотрим пошаговый алгоритм безопасности при обновлении нетиповой конфигурации:

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

Перенос доработок в расширения как превентивная мера

Чтобы в будущем полностью исключить сложности при накатывании обновлений на измененную конфигурацию, рекомендуется выносить доработки из основного дерева метаданных в расширения конфигурации (*.cfe). Это позволяет вернуть основную конфигурацию на полный типовой режим поддержки, после чего регулярные обновления *.cf файлами будут проходить быстро и без риска повреждения пользовательского кода.