Каждый разработчик и администратор 1С рано или поздно сталкивается с ситуацией, когда типовой механизм обновления конфигурации начинает вести себя непредсказуемо. Типичный сценарий: база долгое время не обновлялась, накопилось множество пропущенных релизов, и для экономии времени было решено обновить ее путем сравнения и объединения с финальным файлом полной конфигурации (.cf). Внешне всё проходит успешно — номер версии в справке «О программе» меняется на актуальный, пользователи работают без нареканий. Однако при попытке установить следующее плановое обновление через файл обновлений (.cfu) или напрямую с сайта поддержки 1С, система выдает критическую ошибку: «Несоответствие версии конфигурации поставщика».
В этой статье мы подробно разберем, почему возникает эта ошибка, как устроена архитектура хранения метаданных в платформе «1С:Предприятие 8», и пошагово восстановим корректную работу механизма обновлений.
Для того чтобы понять природу проблемы, нам необходимо заглянуть под капот платформы 1С. В любой информационной базе, находящейся на поддержке, одновременно сосуществуют три конфигурации. Проанализируем их роли:
F7 (или синей бочки). Именно с этой конфигурацией физически работают пользователи в режиме предприятия..cfu.Когда мы выполняем некорректное обновление (например, путем простой загрузки измененного cf файла через меню Конфигурация — Загрузить конфигурацию из файла или некорректно выполненного сравнения), мы принудительно перезаписываем структуру Основной конфигурации. При этом Конфигурация поставщика внутри базы остается старой версии! Получается замкнутый круг: в справке о программе система рапортует о новом релизе, а при попытке применить файл обновления .cfu платформа сверяет его со скрытой версией поставщика и сообщает, что база «не доросла» до этого патча.
Рассмотрим ситуацию, описанную пользователем на форуме. Конфигурация поставщика в базе застряла на релизе 2.4.6.189, в то время как основная конфигурация и конфигурация базы данных уже имеют версию 2.4.7.147. При попытке обновиться на версию 2.4.8.х через файл дифференциального обновления .cfu, платформа сверяет требования этого файла с версией поставщика (2.4.6.189) и блокирует процесс, поскольку данный файл обновления предназначен строго для установки на версию не ниже 2.4.7.147.
Для того чтобы вернуть конфигурацию поставщика на «нормальные рельсы» и выровнять версии без потери доработок, мы выполним процедуру фиктивного сопоставления. Нам понадобится полный дистрибутив конфигурации (файл .cf) той самой версии, которая фактически сейчас установлена в вашей базе (в нашем примере — это 2.4.7.147).
Рассмотрим этот процесс по шагам:
Перед началом любых манипуляций в Конфигураторе обязательно создайте резервную копию базы данных. Сделайте выгрузку информационной базы (.dt) или создайте копию файла 1Cv8.1CD для файлового варианта, либо выполните бэкап средствами СУБД для клиент-серверного варианта.
.cf (эталонный дистрибутив) текущей версии вашей конфигурации (например, 2.4.7.147).Поскольку версии конфигураций совпадают, платформа проанализирует структуру метаданных и выдаст критически важное диалоговое окно следующего содержания: «Обнаружена совместимая конфигурация поставщика. Поставить на поддержку?». Нам необходимо ответить «Да».
Если данное окно не появилось (например, если база была полностью снята с поддержки ранее), то предварительно выполните аналогичную процедуру через меню Конфигурация — Поддержка — Настройка поддержки — Сравнить и объединить, выбрав тот же самый файл cf.
После сопоставления объектов перед вами откроется стандартное окно сравнения и объединения конфигураций.
Внимание! Если вы нажмете кнопку «Выполнить» прямо сейчас, вы затрете абсолютно все свои нетиповые доработки и вернете базу к чистому типовому виду. Чтобы этого избежать, выполните следующие действия:
Теперь зайдите в меню Конфигурация — Поддержка — Настройка поддержки. Вы увидите, что версия конфигурации поставщика стала актуальной и полностью совпадает с версией основной конфигурации. Теперь вы можете без проблем накатывать стандартные обновления через файлы .cfu.
Хотя описанный выше метод полностью решает проблему с технической доступностью последующих обновлений, мы обязаны предупредить вас о серьезных скрытых опасностях, которые возникают при обновлении конфигураций «одним махом» через полный cf файл в обход цепочки релизов.
Проанализируем две ключевые проблемы, которые могут проявиться уже в режиме «1С:Предприятие» при работе пользователей:
Разработчики фирмы 1С постоянно оптимизируют структуру метаданных конфигураций. Например, если в версии 2.4.6 использовался реквизит Организация в определенном регистре, а в версии 2.4.8 этот регистр решили упразднить и перенести данные в новый справочник, этот процесс происходит поэтапно:
УдалитьОрганизация.Если вы «перепрыгиваете» через эти релизы, загружая финальный cf, база данных мгновенно перестраивается под конечную структуру. Все промежуточные реквизиты удаляются физически, а данные из них пропадают навсегда, так как обработчики обновления просто не найдут источников для переноса информации.
Современные конфигурации 1С используют механизмы БСП для проведения регламентных процедур после обновления конфигурации базы данных. При первом запуске системы после обновления запускаются так называемые отложенные обработчики. При сильном «прыжке» через релизы эти обработчики гарантированно завершатся с ошибками, поскольку они не рассчитаны на одновременный запуск без соблюдения строгой последовательности версий.
Для принудительного контроля выполнения таких процедур программисты часто используют следующий код в консоли кода или во внешних обработках для проверки статуса обновления:
ПараметрыОбновления = ОбновлениеИнформационнойБазы.ПараметрыОбновления();
ПараметрыОбновления.ВыполнитьОтложенноеОбновление = Истина;
ОбновлениеИнформационнойБазы.ВыполнитьОбновление(ПараметрыОбновления);
Если запуск этих процедур завершается аварийно, в дальнейшем вы гарантированно столкнетесь с ошибками при формировании регламентированной отчетности, закрытии месяца или проведении документов.
Чтобы навсегда забыть о сложностях ручного сравнения и объединения модулей при каждом обновлении, мы рекомендуем переходить на современную технологию платформы 1С — Расширения конфигурации.
Постарайтесь вынести все ваши доработки (новые реквизиты, печатные формы, доработки бизнес-логики в подписках на события или переопределяемых модулях) в отдельные расширения. Саму основную конфигурацию при этом необходимо полностью вернуть к типовому виду и поставить на «замок» (запретить редактирование). В таком сценарии последующие обновления базы будут происходить в полностью автоматическом режиме в один клик, не затрагивая ваш кастомный код.