Чем грозит принудительное изменение режима совместимости в 1С:ERP и как сделать это правильно?

← На главную

При администрировании и разработке крупных систем на базе 1С, таких как 1С:ERP Управление предприятием, специалисты часто сталкиваются с необходимостью использования новых механизмов платформы. Самый простой и очевидный путь, который приходит в голову разработчику для разблокировки нового функционала (например, механизмов расширений) — это просто изменить свойство РежимСовместимости в свойствах конфигурации в Конфигураторе. Однако в крупных тиражных решениях этот шаг может повлечь за собой критические сбои. Давайте подробно проанализируем, почему «простое переключение тумблера» не сработает, какие технические риски несет данная процедура и как правильно решить эту задачу.

Проблема принудительного переключения: почему система откажется запускаться?

Если мы откроем Конфигуратор 1С:ERP 2.4 (находящейся, к примеру, в режиме совместимости Версия 8.3.10) и принудительно переставим значение свойства на Версия 8.3.11 или выше, то при первом же запуске в режиме «1С:Предприятие» мы получим критическую ошибку, после чего программа аварийно завершит работу.

Выясним причину этого поведения. Современные конфигурации 1С построены на базе БСП (Библиотеки стандартных подсистем). В коде БСП жестко прописаны проверки на соответствие версии используемой платформы и установленного режима совместимости конфигурации. При запуске срабатывают специализированные механизмы инициализации.

Рассмотрим, где именно в коде кроется данная проверка. Обычно это происходит в общем модуле СтандартныеПодсистемыСервер в процедуре ПередЗапускомПрограммы() или связанных с ней процедурах проверки параметров системы. Ниже представлен пример упрощенного алгоритма, который выполняет БСП при старте:


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

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


&Вместо("ПередЗапускомПрограммы")
Процедура Расш_ПередЗапускомПрограммы(ПараметрыЗапуска)
    // Обход стандартной проверки БСП для экспериментального запуска
    // Логика проверки отключается или модифицируется под нужный режим
КонецПроцедуры

Важное предупреждение: подобный обход проверок крайне опасен для рабочей базы данных и может применяться исключительно на тестовых копиях для проведения экспериментов!

Возможности расширений при смене режима совместимости

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

Создание собственных справочников и документов: Механизм полноценного добавления новых объектов метаданных (справочников, документов, бизнес-процессов) в расширениях (так называемое «Расширение данных») появился начиная с версии платформы 8.3.11. Чтобы использовать этот функционал, режим совместимости и основной конфигурации, и самого расширения должен быть не ниже Версия 8.3.11.
Создание собственных регистров: Если вам требуется создавать в рамках расширений новые регистры накопления, регистры бухгалтерии или регистры расчета, то режима Версия 8.3.11 или Версия 8.3.12 будет недостаточно. Для поддержки этих объектов потребуется перевести конфигурацию в режим совместимости не ниже Версия 8.3.14.
Главное правило совместимости расширений: Запомните ключевое правило платформы — режим совместимости расширения не может быть выше, чем режим совместимости основной конфигурации. Если ERP работает в режиме совместимости Версия 8.3.10, вы не сможете подключить к ней расширение, разработанное под свойства Версия 8.3.11 или в режиме Не использовать.

Новые механизмы для РИБ (начиная с версии 8.3.12)

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

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

Технические риски принудительного изменения режима совместимости на рабочей базе

Если проигнорировать рекомендации и принудительно сменить режим совместимости на «живой» базе ERP, можно столкнуться с серьезными техническими проблемами. Проанализируем основные риски:

Длительная реструктуризация таблиц СУБД: При изменении режима совместимости и сохранении конфигурации база данных инициирует глубокое обновление физической структуры таблиц на сервере СУБД (MS SQL, PostgreSQL и др.). Для крупных баз данных ERP (объемом от нескольких сотен гигабайт до терабайтов) этот процесс может занимать десятки часов. В процессе реструктуризации серверу требуется колоссальный объем свободного дискового пространства (в 2–3 раза больше размера самой базы), а также существует риск аварийного завершения операции по ошибке Out of Memory.
Изменение логики работы SQL-запросов: Каждая новая версия платформы вносит изменения в транслятор запросов 1С в код SQL. После смены режима совместимости некоторые сложные запросы, отчеты СКД или динамические списки могут начать работать некорректно, выдавать ошибки СУБД или приводить к зависанию сеансов из-за неоптимальных планов запросов. Также могут появиться проблемы с получением представлений битых ссылок (появление надписей «Объект не найден»).
Нарушение верстки интерфейса («поплывшие» формы): Смена режима совместимости (особенно полный уход от нее в режим Не использовать) влечет за собой смену алгоритмов отрисовки интерфейса Такси. На управляемых формах могут некорректно отображаться элементы: кнопки накладываются друг на друга, поля ввода сжимаются или растягиваются, ломается автовысота строк в таблицах. Потребуется масштабное тестирование интерфейсов ключевых рабочих мест пользователей.

Резюме и правильное решение

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

Единственным верным и безопасным решением является штатное обновление конфигурации 1С:ERP до актуального релиза, в котором разработчики фирмы «1С» уже официально и на уровне кода БСП перевели конфигурацию на нужный режим совместимости (или полностью отключили его). В таком случае все механизмы, формы и SQL-запросы уже прошли комплексное тестирование вендора, что гарантирует стабильную работу вашей учетной системы.