Как обойти ограничение по версии платформы 1С:Предприятие при добавлении типовой конфигурации УНФ 8?

← На главную

При попытке установить новую версию конфигурации, например, типовую УНФ 8 3.0.4, мы можем столкнуться с ситуацией, когда она требует более новую версию технологической платформы 1С:Предприятие (например, 8.3.21), в то время как наша текущая платформа (например, 8.3.20) не может быть обновлена по каким-либо причинам. Эта проблема является достаточно распространенной, и в данной статье мы рассмотрим различные подходы к ее решению, включая программные методы обхода ограничений и альтернативные стратегии. Важно понимать, что обход таких ограничений не является рекомендованным фирмой "1С" способом работы и может повлечь за собой определенные риски, о которых мы также подробно поговорим.

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

Например, в платформе 8.3.21 были расширены возможности работы с PDF-документами (просмотр, печать, проверка цифровой подписи), реализован объект ДокументPDF, а также добавлены новые возможности для работы с диаграммой Ганта и HTTP-запросами. Если конфигурация УНФ 8 3.0.4 использует эти новые возможности, то для ее корректной работы требуется платформа 8.3.21 или выше.

Официальная позиция "1С" и риски обхода ограничений

Фирма "1С" обычно рекомендует использовать актуальные версии платформы для обеспечения стабильной работы, безопасности и использования всех возможностей конфигурации. Обход ограничений версии платформы, как правило, не является поддерживаемым способом работы и может привести к серьезным проблемам. Давайте подробнее рассмотрим риски и последствия такого подхода:

Нестабильная работа и сбои: Использование конфигурации на несовместимой платформе может привести к некорректному отображению данных, ошибкам при выполнении операций, "вылетам" программы и потере данных. Система может вести себя непредсказуемо.
Ошибки в учете и отчетности: Отсутствие своевременных обновлений может привести к неактуальным расчетам налогов, страховых взносов, отпускных и невозможности сдачи отчетности в контролирующие органы. Это особенно критично для бухгалтерских и налоговых конфигураций.
Уязвимости в безопасности: В новых версиях платформы "1С" регулярно закрываются выявленные уязвимости. Игнорирование обновлений делает систему более подверженной кибератакам и потере конфиденциальных данных.
Проблемы с дальнейшими обновлениями: Модификации конфигурации или использование расширений для обхода проверки версии могут усложнить или сделать невозможным штатное обновление конфигурации в будущем. Это может привести к необходимости ручного повторения изменений при каждом обновлении.
Отсутствие технической поддержки: При возникновении проблем с нештатно измененной конфигурацией или несовместимой платформой официальная поддержка от "1С" или партнеров может быть недоступна или сильно ограничена.
Несовместимость с внешними сервисами: Устаревшая платформа может потерять совместимость с новыми версиями операционных систем, драйверами оборудования или веб-сервисами, что приведет к сбоям в работе с внешними системами, банками, ЭДО.
Снижение производительности: Новые версии платформы часто оптимизированы для повышения производительности, и использование более старых версий может привести к замедлению работы системы, особенно при большом объеме данных или интенсивной нагрузке.

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

Режим совместимости конфигурации

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

Программные решения по обходу проверки версии платформы с использованием расширений

Если обновление платформы не является возможным вариантом, мы можем попытаться "обмануть" систему проверки версии, используя расширения конфигурации. Этот подход позволяет вносить изменения в логику работы стандартных модулей без снятия конфигурации с поддержки, что является менее рискованным, чем прямые изменения в основной конфигурации. Расширения используют механизм "перехвата" вызова процедур и функций (директива &Вместо), позволяя подменить стандартную логику своей. Для этой задачи можно использовать методику переноса доработок в расширения для возврата конфигурации на стандартную поддержку.

Давайте рассмотрим несколько примеров таких модификаций, которые были предложены на форуме и показали свою эффективность.

1. Модификация функции, определяющей минимальную версию платформы

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

Пример 1: Изменение функции МинимальнаяВерсияПлатформыДляИспользования в общем модуле СтандартныеПодсистемыСервер (на примере Бухгалтерии 3.0.190.22, требующей 8.3.27.1688, но работающей на 8.3.27.1644):


// В расширении, в новом общем модуле или модуле расширения с директивой &Вместо
&Вместо("МинимальнаяВерсияПлатформыДляИспользования")
Функция Доработка_МинимальнаяВерсияПлатформыДляИспользования

    Версии = Новый СписокЗначений;
    Версии.Добавить("8.3.24", "8.3.24.1548; 8.3.25.1286; 8.3.26.1498; 8.3.27.1244");
    Версии.Добавить("8.3.25", "8.3.25.1286; 8.3.26.1498; 8.3.27.1244");
    Версии.Добавить("8.3.26", "8.3.26.1498; 8.3.27.1244");
    //моё+ вместо 8.3.27.1688 устанавливаю 8.3.27.1644
    Версии.Добавить("8.3.27", "8.3.27.1644"); // Здесь указываем текущую версию платформы
    //моё-
    Возврат Версии;

КонецФункции

В этом примере мы явно указываем, что для версии 8.3.27 допустима сборка 8.3.27.1644, даже если конфигурация изначально требовала более новую сборку 8.3.27.1688.

Пример 2: Модификация функции МинимальнаяВерсияПлатформы в общем модуле ОбщегоНазначения:


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

Здесь мы делаем так, чтобы минимально допустимая версия платформы всегда совпадала с текущей установленной версией, эффективно отключая проверку на минимальный порог.

2. Отключение проверки доступности функционала, требующего новой платформы

Некоторые функции конфигурации могут активно проверять версию платформы для определения доступности специфического функционала. Например, работа с PDF-документами, которая была расширена в платформе 8.3.21.

Пример: Модификация функции ДоступнаРаботаСоСтраницамиPDFДокумента в модуле РаботаСФайламиБЭД:


// В расширении
&Вместо("ДоступнаРаботаСоСтраницамиPDFДокумента")
Функция Доработка_ДоступнаРаботаСоСтраницамиPDFДокумента
    СистемнаяИнформация = Новый СистемнаяИнформация;
    ВерсияПлатформы = СистемнаяИнформация.ВерсияПриложения;
    //моё+ вместо 8.3.27.1688 устанавливаю 8.3.27.1644
    Возврат ОбщегоНазначенияКлиентСервер.СравнитьВерсии(ВерсияПлатформы, "8.3.27.1644") >= 0; // Сравниваем с нашей текущей версией
    //моё-
КонецФункции

В этом случае мы говорим системе, что функционал доступен, если текущая версия платформы (в нашем примере 8.3.27.1644) соответствует или выше указанной в коде, игнорируя более высокие требования типовой конфигурации.

3. Подавление сообщений о нерекомендуемой версии платформы

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

Пример 1: Модификация процедуры ПослеЗакрытияФормыНерекомендуемойВерсииПлатформы в модуле СтандартныеПодсистемыКлиент:


// В расширении
&Вместо("ПослеЗакрытияФормыНерекомендуемойВерсииПлатформы")
Процедура Доработка_ПослеЗакрытияФормыНерекомендуемойВерсииПлатформы(Результат, Параметры)
    //моё+ добавлено
    Параметры.Отказ = Ложь; // Принудительно разрешаем продолжение
    //моё-
    Если Результат <> "Продолжить" Тогда
        Параметры.Отказ = Истина;
    Иначе
        Параметры.ПолученныеПараметрыКлиента.Вставить("ПоказатьНерекомендуемуюВерсиюПлатформы");
    КонецЕсли;
    ВыполнитьОбработкуОповещения(Параметры.ОбработкаПродолжения);
КонецПроцедуры

В этом случае мы устанавливаем Параметры.Отказ = Ложь (или Параметры.Отказ = Истина;, чтобы просто закрыть окно без действия), чтобы предотвратить блокировку работы пользователя и принудительно разрешить продолжение работы, несмотря на предупреждение.

Пример 2: Другой вариант подавления сообщения:


// В расширении
&Вместо("ПослеЗакрытияФормыНерекомендуемойВерсииПлатформы")
Процедура _ПослеЗакрытияФормыНерекомендуемойВерсииПлатформы(Результат, Параметры)
    //Доработки
    Параметры.Отказ = Истина; // Этот вариант просто отключает показ и блокировку
    //КонецДоработок
    Если Результат <> "Продолжить" Тогда
        Параметры.Отказ = Истина;
    Иначе
        Параметры.ПолученныеПараметрыКлиента.Вставить("ПоказатьНерекомендуемуюВерсиюПлатформы");
    КонецЕсли;
    ВыполнитьОбработкуОповещения(Параметры.ОбработкаПродолжения);
КонецПроцедуры

В этом примере установка Параметры.Отказ = Истина; в начале процедуры блокирует дальнейшую обработку сообщения и предотвращает его появление.

4. Отключение проверки версии платформы при запуске

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

Пример 1: Модификация функции ПараметрыПроверкиВерсииПлатформыПриЗапуске в модуле ПолучениеОбновленийПрограммыВызовСервера:


// В расширении
&Вместо("ПараметрыПроверкиВерсииПлатформыПриЗапуске")
Функция Доработка_ПараметрыПроверкиВерсииПлатформыПриЗапуске
    //все типовые строки кода в данной функции удаляем и заменяем на следующие
    Результат = Новый Структура;
    Результат.Вставить("Продолжить" , Ложь);
    Результат.Вставить("ЭтоАдминистраторСистемы", Ложь);
    Результат.Продолжить = Истина; // Принудительно разрешаем продолжение
    Возврат Результат;
КонецФункции

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

Пример 2: Аналогичный, более лаконичный вариант:


// В расширении
&Вместо("ПараметрыПроверкиВерсииПлатформыПриЗапуске")
Функция Расширение1_ПараметрыПроверкиВерсииПлатформыПриЗапуске
    Результат = Новый Структура;
    Результат.Вставить("Продолжить" , Ложь);
    Результат.Вставить("ЭтоАдминистраторСистемы", Ложь);
    Результат.Продолжить = Истина;
    Возврат Результат;
КонецФункции

5. Изменение общих параметров базовой функциональности

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

Пример: Модификация процедуры ПриОпределенииОбщихПараметровБазовойФункциональности:


// В расширении
&Вместо("ПриОпределенииОбщихПараметровБазовойФункциональности")
Процедура Расш1_ПриОпределенииОбщихПараметровБазовойФункциональности(ОбщиеПараметры)
    ОбщиеПараметры.РекомендуемыйОбъемОперативнойПамяти = 3;
    ОбщиеПараметры.МинимальнаяВерсияПлатформы = "8.3.24.1467; 8.3.25.1286"; // Указываем текущую или более старую версию
    ОбщиеПараметры.РекомендуемаяВерсияПлатформы = "8.3.24.1548; 8.3.25.1286"; // Указываем текущую или более старую версию
КонецПроцедуры

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

6. Модификация функции `ИнформацияОВерсияхПлатформы`

Еще один способ "обмануть" систему при запросе информации о требуемых версиях платформы:


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

Этот код заставляет систему "думать", что текущая версия платформы является как минимальной, так и рекомендуемой, эффективно игнорируя реальные требования конфигурации.

Альтернативные подходы

Помимо программного обхода ограничений, существуют и другие, менее рискованные, но не всегда применимые варианты:

Установка требуемой версии платформы 1С параллельно: Платформа "1С:Предприятие 8.3" позволяет устанавливать несколько версий платформы на одном компьютере. Это наиболее надежный и рекомендуемый способ. Вы можете установить платформу 8.3.21 (или выше) рядом с вашей текущей 8.3.20. При запуске информационной базы через 1С:Предприятие или Конфигуратор, мы можем явно указать, какую версию платформы использовать для конкретной базы данных. Это может быть полезно для тестирования или для работы с разными базами, требующими разных версий платформы. Однако для экономии места старые версии рекомендуется удалять вручную, если они больше не нужны.
Использование более старого релиза конфигурации: Если у вас нет возможности обновить платформу, а программные методы обхода кажутся слишком рискованными, мы можем рассмотреть вариант использования более старой версии УНФ, которая гарантированно работает на вашей текущей платформе 8.3.20. Этот подход, хотя и не дает всех преимуществ новой версии конфигурации, является наиболее безопасным с точки зрения стабильности.

Управление обновлениями и версиями: Лучшие практики

Для минимизации подобных проблем в будущем, рекомендуем придерживаться следующих практик:

Постепенное обновление: Рекомендуется обновлять платформу и конфигурации поэтапно, следя за рекомендациями "1С" для каждой версии. Перед применением обновлений всегда следует делать резервные копии.
Резервное копирование: Перед любыми изменениями или обновлениями необходимо создавать резервные копии баз данных. Это может быть выгрузка в DT-файл или резервное копирование средствами СУБД.
Тестовая база: Все эксперименты с обходом ограничений или нештатными обновлениями следует проводить исключительно на тестовых копиях баз, не затрагивая рабочие данные.
Автоматическое обновление тонкого клиента: В некоторых случаях 1С может предлагать автоматическое обновление тонкого клиента, особенно для облачных сервисов, если подключение осуществляется по HTTP(S).
Фоновое задание "Обновление информации о версиях платформы": Существует регламентное задание, которое раз в сутки получает с сайта 1С информацию о минимально допустимых версиях платформы. Его можно отключить, если необходимо предотвратить автоматические проверки. Однако отключение этого задания не отменяет встроенные в конфигурацию проверки.

Заключение

В этой статье мы подробно рассмотрели проблему обхода ограничений по версии платформы 1С:Предприятие при работе с новыми версиями конфигураций, таких как УНФ 8. Мы выяснили, что оптимальным и наиболее безопасным решением всегда является обновление технологической платформы до требуемой версии. Однако, если по каким-либо причинам это невозможно, мы изучили несколько программных методов с использованием расширений, которые позволяют временно обойти эти проверки. Мы также обсудили альтернативные стратегии, такие как использование более старой версии конфигурации или параллельная установка нескольких версий платформы. При необходимости можно использовать инструмент для анализа конфигураций и расширений на наличие ошибок.

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