Нужно ли обновлять платформу 1С при обновлении конфигурации или можно поставить «заглушку»?

В практике сопровождения систем 1С часто возникает конфликт интересов между разработчиками (программистами 1С) и системными администраторами. Типичная ситуация: выходит новое обновление для конфигураций уровня ERP, Комплексная автоматизация (КА) или ЗУП, которое в требованиях указывает новую версию технологической платформы (например, переход с 8.3.22 на 8.3.24). Администраторы часто сопротивляются обновлению сервера, опасаясь сбоев или проблем с лицензированием, и требуют от программиста поставить программную "заглушку", чтобы система работала на старой платформе.

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

Суть проблемы: Требование платформы vs «Заглушка»

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

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

Функция ОбщиеПараметрыБазовойФункциональности(ВернутьЗакешированноеЗначение = Истина) Экспорт
    // ... код получения параметров ...
    Результат = Новый Структура;
    // Здесь задается минимальная версия
    Результат.Вставить("МинимальнаяВерсияПлатформы", МинимальнаяВерсияПлатформы()); 
    // ...
КонецФункции

Идея "заглушки" заключается в том, чтобы принудительно вернуть в этом методе версию старой платформы (например, "8.3.22"), обманув проверку при старте системы. Однако, давайте разберем, почему этот метод, скорее всего, приведет к краху системы, а не к её работе.

Почему «заглушка» не сработает: Режим совместимости

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

Разберем ситуацию подробно:

1. Каждая версия конфигурации разрабатывается под определенный РежимСовместимости.
2. Если обновление требует платформу 8.3.24, это означает, что в свойствах конфигурации установлен режим совместимости "Версия 8.3.24".
3. Платформа версии 8.3.22 физически не знает о существовании режима совместимости "Версия 8.3.24", так как он появился позже выхода самой платформы.

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

Новые возможности языка и синтаксис

Даже если предположить гипотетическую ситуацию, в которой нам удалось бы понизить режим совместимости и загрузить конфигурацию (например, через выгрузку в файлы, правку XML и обратную загрузку), мы столкнемся с синтаксическими ошибками.

Современные релизы конфигураций (особенно ERP и КА) активно используют новые возможности языка, которые появляются в свежих платформах. Рассмотрим, чего может не хватать в старой версии:

• Новые методы работы со строками и JSON: Платформа 8.3.24 и выше вводит оптимизированные методы сериализации и работы с текстом. Если код конфигурации вызывает метод, которого нет в движке 8.3.22, произойдет аварийное завершение работы (дамп) или ошибка компиляции.
• Работа с расширениями: Механизм расширений постоянно дорабатывается. Заимствование форм и модулей в новой платформе может работать иначе. На старой платформе подключение расширений, созданных в новой среде, часто приводит к неустранимым ошибкам при запуске.
• Системные перечисления: В новых версиях могут добавляться новые значения системных перечислений (например, в свойствах HTTP-запросов или криптографии). Старая платформа просто не сможет скомпилировать модуль, содержащий неизвестные ей идентификаторы.

Риски понижения режима совместимости вручную

Иногда возникает идея: "Давайте обновимся на моем локальном компьютере с новой платформой, понизим в конфигураторе режим совместимости до 8.3.22 и загрузим это на старый сервер".

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

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

Аргументы для системного администратора

Если вы столкнулись с требованием поставить "заглушку", используйте следующие аргументы для обоснования необходимости обновления платформы:

1. Техническая невозможность запуска
Объясните, что конфигурация — это не просто скрипт, а программа, скомпилированная под определенную версию виртуальной машины (платформы). Запустить код для версии 8.3.24 на движке 8.3.22 так же невозможно, как запустить современную игру на Windows 95.

2. Исправление критических ошибок
В версиях 8.3.24 и 8.3.25 исправлено множество ошибок отрисовки интерфейса (особенно в веб-клиенте) и утечек памяти, которые присутствовали в старых версиях. Переход на новую версию повысит стабильность работы сервера.

3. Поддержка ОС Linux
Если ваш сервер работает на Linux, важно учитывать совместимость системных библиотек. Новые платформы требуют обновленных версий библиотек (например, glibc). Если администратор использует старые дистрибутивы (например, Ubuntu 18.04), это может быть причиной его отказа. В этом случае необходимо планировать комплексное обновление и ОС, и платформы 1С. Тем не менее, 1С официально предупреждает о прекращении поддержки старых дистрибутивов, и работа на них становится небезопасной.

Рекомендуемый порядок действий

Чтобы избежать простоя бизнеса и конфликтов, выполним обновление правильно:

1. Развертывание тестового контура: Установите требуемую версию платформы (рекомендуется сразу ставить актуальную, например 8.3.25, так как в 8.3.24 были замечены ошибки с реквизитами) на тестовом сервере или отдельном порту рабочего сервера.
2. Тестовое обновление: Проведите обновление копии базы. Убедитесь, что конфигурация корректно запускается и проходит начальное заполнение данных.
3. Согласование времени простоя: Обновление платформы на сервере и всех клиентских машинах требует времени. Согласуйте техническое окно.
4. Обновление рабочего контура: Обновите сервер 1С Предприятия и опубликуйте дистрибутив тонкого клиента для автоматического обновления пользователей.

Вывод

Ставить "заглушки" на проверку версии платформы при обновлении типовых конфигураций (ERP, КА, УТ) — это тупиковый путь. Это технически невозможно из-за ограничений РежимаСовместимости и несет огромные риски для целостности данных. Единственное правильное решение — выполнить требование поставщика программного продукта и обновить платформу 1С:Предприятие.