При обновлении конфигурации «1С:Управление производственным предприятием» (УПП) системные администраторы и программисты часто сталкиваются с жестким требованием системы обновить платформу 1С:Предприятие 8. Если проигнорировать эти требования, программа может просто не запуститься или начать выдавать критические ошибки при выполнении базовых операций. Разберем подробно, какие версии являются минимально необходимыми, почему возникли такие ограничения и как можно программно обойти проверку версии, если немедленное обновление инфраструктуры невозможно.
Проанализируем документацию к последним выпускам конфигурации. Фирма «1С» установила базовый порог для использования УПП — версия 8.3.14.2095. Однако важно понимать, что работа конфигурации осуществляется в режиме совместимости Версия 8.2.13. Несмотря на этот «древний» режим, для каждой ветки платформы 8.3 существуют свои минимальные сборки, ниже которых запуск программы будет заблокирован программным кодом самой конфигурации.
Рассмотрим актуальный список минимальных сборок, который стал обязательным после массового обновления систем защиты в ноябре 2022 года:
Если ваша текущая платформа входит в одну из этих веток, но имеет номер сборки ниже указанного, при запуске в режиме Предприятие вы увидите сообщение о невозможности продолжения работы.
Выясним причину такой жесткой привязки. Существует три основных фактора, заставивших разработчиков пойти на этот шаг:
Иногда возникают ситуации, когда обновить платформу на сотнях рабочих мест мгновенно невозможно (например, из-за несовместимости с другим ПО, таким как Альфа-Авто на старом сервере). В этом случае проанализируем, где именно в коде УПП зашита проверка версии. За логику проверки отвечает общий модуль ОбщегоНазначенияПереопределяемый.
Рассмотрим по шагам, как найти и изменить этот алгоритм:
1. Откройте конфигуратор и перейдите в процедуру ПриОпределенииОбщихПараметровБазовойФункциональности общего модуля ОбщегоНазначенияПереопределяемый.
2. Найдите блок кода, где заполняется структура ОбщиеПараметры. Нас интересует параметр РаботаВПрограммеЗапрещена.
Пример типового кода, вызывающего блокировку:
ИначеЕсли ВерсияПлатформыБезНомераСборки = "8.3.19" Тогда
ВерсияПлатформы = "8.3.19.1723";
Если ОбщегоНазначения.СравнитьВерсии(НомерВерсииПлатформы, ВерсияПлатформы) < 0 Тогда
ОбщиеПараметры.РаботаВПрограммеЗапрещена = Истина;
КонецЕсли;
КонецЕсли;
Проанализируем ситуацию: если ваша платформа 8.3.19.1522, то условие сработает и флаг запрета станет Истина. Чтобы временно разрешить работу на текущей версии, можно либо закомментировать строку установки флага, либо заменить эталонную версию на вашу фактическую.
Рассмотрим вариант корректировки кода под вашу версию (например, 8.3.19.1522):
// В процедуре ПриОпределенииОбщихПараметровБазовойФункциональности
// Ищем нужную ветку платформы и подменяем требование
ИначеЕсли ВерсияПлатформыБезНомераСборки = "8.3.19" Тогда
// Заменяем типовое требование 8.3.19.1723 на нашу реальную сборку
ВерсияПлатформы = "8.3.19.1522";
// Либо принудительно отключаем запрет
// ОбщиеПараметры.РаботаВПрограммеЗапрещена = Ложь;
КонецЕсли;
Важно: Подобные изменения вы вносите на свой страх и риск. Это может привести к ошибкам формата SDBL (Ошибка SDBL: Ожидается выражение) или некорректной работе COM-соединений при обмене данными между базами на разных платформах.
Если после обновления конфигурации или манипуляций с версией платформы вы столкнулись с ошибкой SDBL, выполните следующие действия:
%AppData%\1C\1Cv8\.Посмотрим на ситуацию, когда на одном сервере должны работать несколько версий платформы (например, старая для отраслевых решений и новая для УПП). В этом случае системному администратору необходимо:
ragent на других портах (например, порты 1640, 1641 вместо стандартных 1540, 1541).8.3.19.1723).Таким образом, использование последних релизов УПП требует внимательного подхода к инфраструктуре. Рекомендуемым сценарием является переход на ветку 8.3.21 или 8.3.22 с последними патчами, что гарантирует отсутствие проблем с лицензированием и стабильную работу механизмов защиты.