При разработке в среде 1С:Предприятие программисты часто сталкиваются с необходимостью расширения функционала типовых решений. Одной из типовых задач является добавление нового типа документа в существующий реквизит (например, в ДокументОснование). Однако при попытке сделать это через механизм расширений часто возникает ошибка: «Изменение типов недопустимо в режиме совместимости 8.3.17 и ниже». В этой статье мы подробно разберем, почему это происходит, какие опасности таит в себе изменение режима совместимости и какими альтернативными способами можно решить задачу связи документов.
Первым делом проанализируем ситуацию с точки зрения технологической платформы. Ошибка, с которой сталкивается разработчик, не является случайным багом — это жесткое архитектурное ограничение. Возможность изменять (добавлять новые типы) в заимствованные реквизиты через расширения появилась только в режиме совместимости 8.3.18.
Если ваша основная конфигурация (например, решение от «1С-Рарус» или типовая «Бухгалтерия предприятия») работает в режиме совместимости 8.3.16, то даже если вы установите самую последнюю версию платформы (например, 8.3.25), расширение все равно будет ограничено правилами старого режима. Платформа эмулирует поведение версии 8.3.16 для обеспечения стабильности кода. Таким образом, просто обновить платформу на сервере недостаточно — нужно менять свойства самого объекта Конфигурация.
Рассмотрим подробнее риски, связанные с принудительным повышением режима совместимости в сложных тиражных решениях. Многие ошибочно полагают, что это формальное переключение свойства, но на деле это меняет глубокие внутренние механизмы работы 1С.
Таким образом, для тиражных решений повышение режима совместимости требует проведения полного цикла регрессионного тестирования, что в рамках одной задачи по добавлению реквизита является неоправданно дорогим удовольствием.
Если ситуация позволяет «снять конфигурацию с поддержки» (разрешить изменения), то это самый простой и безопасный путь с точки зрения стабильности кода. Разберем по шагам, почему это иногда лучше расширения:
Когда мы добавляем тип в ДокументОснование непосредственно в основной конфигурации, нам не требуется режим 8.3.18. Мы просто работаем с метаданными напрямую. Если вы уже все равно разблокировали конфигурацию для каких-то целей, то использование расширения для этой конкретной задачи теряет смысл.
Посмотрим на логику: расширение предназначено для сохранения типовой конфигурации на «замке». Если замок уже открыт, лучше внести изменения в метаданные объекта напрямую, так как это гарантирует отсутствие конфликтов при обновлении типов в будущем.
Если же мы принципиально хотим оставить основную конфигурацию максимально чистой, рассмотрим архитектурный подход без изменения состава типов реквизита. Проанализируем ситуацию: нам нужно связать документ Платеж и Платежное поручение.
Вместо того чтобы вписывать Платеж в тип реквизита ДокументОснование, мы можем создать в расширении новый Регистр сведений (например, ДополнительныеСвязиДокументов).
Структура регистра может быть следующей:
ДокументОбъект (Тип: ЛюбаяСсылка)ДокументОснование (Тип: ЛюбаяСсылка)При записи вашего документа Платеж вы просто делаете запись в этот регистр. А для того чтобы пользователь видел эту связь в форме, вы можете через расширение формы Платежного поручения добавить декорацию или кнопку, которая будет подтягивать данные из этого регистра. Это полностью обходит ограничение режима совместимости.
Проанализируем возможности Библиотеки Стандартных Подсистем (БСП), которая есть почти в каждой современной конфигурации. Если в системе подключена подсистема «Свойства», мы можем решить задачу вообще без программирования в конфигураторе:
Платежное поручение и добавляем ему дополнительное сведение с типом Документ Платеж.Этот метод не требует изменения режима совместимости, не снимает базу с поддержки и позволяет хранить нужные ссылки. Однако стоит учесть, что работа с доп. сведениями в коде требует использования функций БСП.
Выясним, зачем пользователю вообще нужно заполнять ДокументОснование. Обычно это требуется для корректного отображения в отчете «Структура подчиненности». Если вы добавите в свой самописный документ Платеж реквизит Основание с типом ДокументСсылка.ПлатежноеПоручение, то связь уже будет существовать в базе данных.
Чтобы она появилась в стандартном отчете, достаточно через расширение подправить запрос в обработке СтруктураПодчиненности или добавить свой документ в определяемый тип ОбъектСУчетомИерархии (если режим совместимости позволяет работать с определяемыми типами).
Если вы выбрали путь с регистром сведений (Решение №2), рассмотрим пример кода для получения основания документа:
Функция ПолучитьОснованиеДокумента(ТекущийДокумент) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Связи.ДокументОснование КАК Основание
|ИЗ
| РегистрСведений.ДополнительныеСвязиДокументов КАК Связи
|ГДЕ
| Связи.ДокументОбъект = &ТекущийДокумент";
Запрос.УстановитьПараметр("ТекущийДокумент", ТекущийДокумент);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
Возврат Выборка.Основание;
КонецЕсли;
Возврат Неопределено;
КонецФункции
Попытка поднять режим совместимости ради одной задачи в расширении — это опасный путь, который может привести к непредсказуемым последствиям в работе типовых механизмов (особенно в конфигурациях от Рарус).
Мы рекомендуем придерживаться следующей стратегии: