При обслуживании систем на платформе «1С:Предприятие 8.3» часто возникает ситуация, когда подрядчик или штатный специалист обновляет конфигурацию не последовательно, а «прыжком», устанавливая сразу финальный релиз из цепочки обновлений. Рассмотрим подробнее, чем это грозит, как технически реализуется такой переход и, самое главное, как проверить, не пострадала ли структура данных и все ли необходимые процедуры трансформации информации были выполнены.
Разберем ситуацию с технической стороны. В конфигураторе 1С существует несколько способов изменения версии конфигурации:
.cfu и последовательно их применяет. Пропустить релизы здесь практически невозможно, если они отмечены вендором как обязательные..cfu, конфигуратор выдаст предупреждение «Файл не содержит доступных обновлений».Проанализируем риски. Основная опасность заключается не в самой замене кода, а в пропуске обработчиков обновления. Это специальные процедуры на языке 1С, которые пересчитывают остатки, переносят данные из удаленных реквизитов в новые или создают необходимые записи в регистрах сведений. Если вы «прыгнули» с версии 3.0.60 на 3.0.100, минуя промежуточные этапы в режиме «1С:Предприятие», данные могут остаться в старой структуре, что приведет к ошибкам в отчетах или невозможности проведения документов.
Первым делом проверим историю действий в системе. Рассмотрим, как найти следы обновления в Журнале регистрации. Нам необходимо установить отбор по событиям, связанным с изменением конфигурации и запуском системы в режиме обновления.
Выполним следующие шаги:
Конфигурация.Обновление конфигурации базы данных.Информационная база.Обновление версии. В комментарии к этому событию БСП (Библиотека стандартных подсистем) обычно пишет, с какого релиза на какой осуществляется переход.Если в журнале мы видим запись вида «Обновление версии с 3.1.10.5 на 3.1.14.33», это прямое подтверждение того, что система попыталась выполнить все обработчики за один раз, пропустив запуск промежуточных версий.
Современные типовые конфигурации (БП 3.0, ЗУП 3.1, ERP) используют механизмы БСП для управления обновлением. Вся информация о том, какие процедуры были запущены и успешно завершены, хранится в информационной базе. Разберем, где именно ее искать.
Проанализируем содержимое регистра сведений ОбработчикиОбновления. Это можно сделать через меню «Функции для технического специалиста» (или «Все функции»):
ОбработчикиОбновления.Важный момент: 1С проектирует обработчики так, чтобы они могли выполняться цепочкой. Однако, если разрыв между релизами составляет несколько лет, код старых обработчиков может быть физически удален из общего модуля ОбновлениеИнформационнойБазы в свежем релизе. В этом случае данные не обновятся, а в регистре может появиться информация о невозможности выполнения.
Выясним, в каком состоянии находится поддержка конфигурации. При некорректном обновлении через «Сравнение и объединение» часто забывают обновить конфигурацию поставщика.
Посмотрим на статус в окне «Настройка поддержки» (Конфигурация — Поддержка — Настройка поддержки):
.cfu не сработает, так как система будет искать файлы обновлений именно для версии 3.1.10.5.Чтобы исправить эту ситуацию, необходимо «подтянуть» конфигурацию поставщика. Для этого выполним процедуру Конфигурация — Поддержка — Обновить конфигурацию, выбрав полный .cf файл текущего релиза (3.1.14.33). В окне сравнения и объединения важно снять все галочки, чтобы не затереть возможные доработки в основной конфигурации, но нажать «Выполнить». Система обновит именно конфигурацию поставщика.
Если есть сомнения, что все процедуры завершились корректно, можно инициировать процесс проверки еще раз. Рассмотрим использование специального ключа запуска.
Создадим ярлык для запуска 1С или воспользуемся командной строкой, добавив параметр:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F "ПутьКБазе" /C ЗапуститьОбновлениеИнформационнойБазы
Параметр /C ЗапуститьОбновлениеИнформационнойБазы заставляет систему при старте запустить проверку всех обработчиков обновления, зарегистрированных в БСП. Если система обнаружит невыполненные процедуры, она попытается их запустить в монопольном режиме. Это безопасный способ убедиться, что логическая структура данных соответствует текущей версии кода.
В большинстве современных конфигураций отчет о ходе обновления доступен непосредственно пользователю. Рассмотрим, как его найти:
В открывшемся окне мы увидим список всех выполненных этапов. Если там висят предупреждения о невыполненных процедурах или ошибках в дополнительных обработчиках, это верный признак того, что «прыжок» прошел неудачно. Проанализируем колонку «Статус»: процедуры, помеченные красным значком, требуют ручного вмешательства или повторного запуска.
Подведем итог. Само по себе обновление «через релизы» (используя .cf) технически допустимо и часто экономит время программиста. Однако оно требует обязательного соблюдения трех условий:
Если вы обнаружили, что подрядчик обновил систему «прыжком» и конфигурация поставщика не актуальна — обязательно проведите процедуру восстановления поддержки и запустите проверку обработчиков, как описано выше. Это минимизирует риски потери данных в долгосрочной перспективе.