При работе с классическими конфигурациями, такими как «1С:Комплексная автоматизация 1.1» или «Управление производственным предприятием 1.3», разработчики часто сталкиваются с желанием использовать современные механизмы платформы, в частности — расширения конфигурации. Однако попытка добавить расширение в базу, которая годами работала на платформе 8.2, а затем была перенесена на 8.3 без изменения внутренних настроек, часто заканчивается ошибкой: «Структура данных не поддерживает хранение расширений. Необходимо отключить режим совместимости». Рассмотрим подробно, почему это происходит и какие существуют пути решения данной проблемы.
Первым делом проанализируем ситуацию. Конфигурация КА 1.1 была разработана во времена платформы 8.2. Несмотря на то что современные клиенты запускают её под управлением платформы 8.3.20 или даже 8.3.25, сама логика построения таблиц в базе данных остается «замороженной» в прошлом. Это регулируется свойством корневого объекта конфигурации под названием РежимСовместимости.
Когда в свойствах конфигурации установлено Режим совместимости = Версия 8.2.13 (типично для КА 1.1), платформа блокирует создание многих современных объектов. Механизм расширений требует наличия в базе данных специальных служебных таблиц, в которых будут храниться метаданные самого расширения и данные его объектов. В режиме совместимости 8.2 этих таблиц в структуре базы просто не существует. Именно поэтому платформа выдает ошибку о «структуре данных».
Давайте посмотрим на хронологию развития механизма расширений, чтобы понять, что именно нам нужно от конфигурации:
В нашем случае задача автора — добавить значение в перечисление ВидыАгентскихДоговоров. Проанализируем ситуацию: даже если мы технически «заставим» базу принимать расширения, нам потребуется режим совместимости не ниже 8.3.15, чтобы платформа позволила модифицировать структуру существующего перечисления. В КА 1.1 режим совместимости по умолчанию — 8.2, что делает задачу невыполнимой без глубокого вмешательства в настройки.
Рассмотрим важный организационный момент. Зачастую клиент запрещает снимать конфигурацию с поддержки. Однако, чтобы включить поддержку расширений в старой базе, необходимо изменить свойство конфигурации. Любое изменение свойств корневого объекта (включая режим совместимости или режим использования синхронных вызовов) требует перехода в режим редактирования, что автоматически означает снятие «замочка» (полное или с сохранением поддержки).
Если конфигурация находится на поддержке без возможности редактирования, вы физически не сможете изменить РежимСовместимости. Следовательно, расширение не будет создано. Это тупиковая ситуация для тех, кто хочет сохранить «типовую» конфигурацию в первозданном виде.
Если же компромисс с клиентом достигнут и вы готовы к изменениям, разберем по шагам, как активировать расширения в старой базе:
Режим совместимости. Установите значение Не использовать или версию выше 8.3.15.Важное предостережение: Изменение режима совместимости в такой сложной конфигурации, как КА 1.1, может привести к непредсказуемым ошибкам в коде. Обычные формы могут начать вести себя иначе, а некоторые функции встроенного языка могут изменить логику работы. После такого изменения потребуется полное регрессионное тестирование системы.
Проанализируем еще один нюанс. КА 1.1 построена на Обычных формах. Механизм расширений проектировался в первую очередь для Управляемых форм. Хотя в последних версиях платформы работа расширений с обычными формами была улучшена, добавление значения перечисления через расширение не гарантирует, что оно автоматически появится в списках выбора на формах. Вам, скорее всего, все равно придется перехватывать процедуру ПриОткрытии или ПередОткрытием формы через расширение модуля, чтобы программно добавить новое значение в элементы интерфейса.
Пример кода для программного добавления значения в список выбора на форме (через расширение модуля формы):
&После("ПриОткрытии")
Процедура Расш1_ПриОткрытииПосле(Отказ)
// Добавляем новое значение в выпадающий список, если оно не добавилось автоматически
ЭлементыФормы.ВидАгентскогоДоговора.СписокВыбора.Добавить(Перечисления.ВидыАгентскихДоговоров.РеализацияТоваров);
КонецПроцедуры
Выясним, как можно решить задачу автора без использования расширений и изменения режима совместимости, если «замочек» снимать нельзя:
1. Использование механизма Дополнительных сведений. В КА 1.1 реализован механизм свойств и категорий. Если вам нужно просто пометить договор как «Реализация товаров», вы можете создать дополнительное сведение с типом «Значение свойств объектов». Это не потребует изменения кода и метаданных. Однако логику проведения документов под этот признак подстроить будет сложно без изменения модулей.
2. Внешние обработки заполнения. Если стоит задача автоматизировать заполнение данных, можно использовать внешние обработки. Они подключаются к информационной базе без изменения конфигурации и позволяют реализовывать произвольную логику.
3. Подписки на события. Это наиболее «чистый» способ кастомизации конфигурации, но он все равно требует снятия с поддержки для добавления нового объекта «Подписка на событие». Преимущество в том, что вы не меняете штатный код, а выносите свою логику в отдельный общий модуль.
Подводя итог, можно сказать следующее: использование расширений в конфигурации КА 1.1 — это технически сложная задача, требующая обязательного изменения режима совместимости платформы. Если клиент категорически против снятия конфигурации с поддержки, использовать расширения для изменения структуры данных (добавления перечислений) невозможно.
Рациональным подходом будет либо разовое снятие с поддержки для изменения режима совместимости (с последующим тестированием), либо отказ от расширений в пользу классических методов доработки через подписки на события и внешние компоненты. Помните, что платформа 8.2, под которую проектировалась КА 1.1, физически не знала о существовании расширений, и эта архитектурная пропасть преодолевается только через обновление метаданных самой базы.