Как правильно перевести Управление торговлей 11.0 с платформы 8.2 на 8.3 без режима совместимости

При переводе старых типовых конфигураций (например, Управление торговлей 11.0.9.8) с платформы 1С:Предприятие 8.2 на современную платформу 8.3 разработчики часто сталкиваются с дилеммой: просто снять режим совместимости в свойствах конфигурации или выполнять долгое последовательное обновление релиза до актуальной редакции. Разберем технические нюансы обоих подходов, выясним причины возможных сбоев и определим оптимальный план действий.

Анализ последствий прямого отключения режима совместимости

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

1. Модальные вызовы и синхронные методы. В платформе 8.3 без совместимости по умолчанию запрещены модальные окна (такие как ОткрытьФормуМодально(), Вопрос(), Предупреждение()) и синхронные вызовы внешних компонент. Если не установить в свойствах конфигурации параметры Режим использования модальности = Использовать и Режим использования синхронных вызовов расширений платформы и внешних компонент = Использовать, то при первом же обращении к торговому оборудованию, открытии диалогов выбора файлов или системных предупреждений возникнут критические исключения.
2. Смещение элементов и искажение интерфейса. Начиная с платформы 8.3.7, существенно изменился механизм компоновки и отрисовки управляемых форм. Старые управляемые формы конфигурации УТ 11.0, не рассчитанные на обновленный движок, отображаются с нарушенными отступами, съехавшими командными панелями и скрытыми элементами ввода. Придется вручную открывать и перенастраивать группировки в сотнях форм.
3. Ошибки прав доступа и ролей. При отключении совместимости ниже уровня 8.3.4 меняется алгоритм проверки прав и ограничений на уровне записей (RLS). Потребуется масштабный аудит и исправление ролей пользователей, иначе возможны спонтанные отказы в доступе к базовым справочникам и документам.
4. Трансформация предопределенных данных. В режиме 8.2 предопределенные элементы хранились непосредственно в метаданных. При отключении режима совместимости платформа 8.3 создает физические записи в таблицах базы данных (используя реквизит ИмяПредопределенныхДанных). Если в информационной базе присутствуют дубликаты кодов или наименований, процесс первого применения конфигурации завершится сбоем.
5. Устаревший синтаксис объектной модели. В модулях управляемых форм свойство ЭтаФорма признано устаревшим и заменено на ЭтотОбъект. Кроме того, ужесточаются правила работы с динамическими списками и методом ПоместитьВоВременноеХранилище(), который блокирует передачу несериализуемых данных с клиента.
6. Глубокая реструктуризация таблиц СУБД. Снятие совместимости инициирует перестройку таблиц итогов, служебных индексов и полей. Это требует длительного монопольного доступа и значительного свободного места на сервере баз данных под журнал транзакций.

Стратегия 1. Запуск конфигурации на платформе 8.3 с сохранением режима совместимости

Если обновление типовой конфигурации до актуальных версий (11.3/11.4/11.5) невозможно из-за огромного объема доработок или регламентных ограничений, рассмотрим наиболее безопасный компромисс. Переведем базу данных на серверную платформу 8.3, оставив свойство Режим совместимости в значении Версия 8.2.13 или Версия 8.2.16.

Разберем плюсы этого метода:

1. Не требуется править программный код и перерабатывать БСП.
2. База переносится на современный 64-битный кластер серверов 8.3 с оптимизированным распределением рабочих процессов.
3. Интерфейс форм и модальные окна сохраняют стандартное поведение платформы 8.2.

Стратегия 2. Последовательное обновление типовой конфигурации (Рекомендуемый путь)

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

Рассмотрим порядок правильного перехода по шагам:

1. Создание полной резервной копии. Выгрузим информационную базу в файл .dt и сделаем физическую копию средствами СУБД (SQL).
2. Поэтапное обновление через ключевые релизы. Выполним последовательное обновление конфигурации поставщика по рекомендованной цепочке переходов (например: 11.0.9 -> 11.1.X -> 11.2.X -> 11.3.X).
3. Запуск процедур обновления данных. После применения каждого промежуточного релиза в конфигураторе запустим базу в режиме предприятия и дождемся полного завершения регламентных процедур обновления информационной базы (обработчики БСП заполняют новые структуры данных, пересчитывают остатки и регистры).
4. Адаптация нетиповых доработок. Если в исходной конфигурации 11.0 был измененный код, перенесем доработки на новый релиз, используя современные механизмы или расширения конфигурации.

Резюме

Прямое снятие режима совместимости с версии 8.2 на платформе 8.3.10 без обновления самой конфигурации Управление торговлей 11.0 крайне нерационально: трудозатраты на ручное исправление БСП, форм, ролей и модальных окон превысят затраты на штатное последовательное обновление конфигурации до актуальной редакции.