При разработке в среде 1С часто возникает необходимость подключить новый документ к стандартным механизмам, таким как "Дополнительные отчеты и обработки". Обычно это реализуется через добавление документа в определяемый тип, например, ОбъектСДополнительнымиКомандами. Однако, если конфигурация находится на поддержке, прямое изменение состава типа невозможно без включения возможности изменений. В этой статье мы разберем, как решить эту задачу с помощью расширений, учитывая ограничения платформы и различные версии программных продуктов.
Первым делом проанализируем техническую возможность. Начиная с версии платформы 8.3.20.1549, разработчики 1С реализовали возможность изменять состав определяемых типов непосредственно в расширении. Однако здесь кроется важный нюанс, который часто становится камнем преткновения. Разберем его подробнее.
Режим совместимости расширения конфигурации не может быть выше режима совместимости основной конфигурации. Если ваша основная конфигурация (например, УНФ 1.6) имеет режим совместимости 8.3.14, то даже если вы используете платформу версии 8.3.22, расширение будет работать в рамках ограничений версии 8.3.14. В этом случае добавить тип в определяемый тип через расширение не получится, так как платформа просто "не увидит" этот функционал.
Рассмотрим основные правила работы с определяемыми типами в расширениях:
Если режим совместимости вашей конфигурации позволяет (8.3.20 и выше), выполним следующие шаги:
ОпределяемыеТипы.ОбъектСДополнительнымиКомандами, нажмем правую кнопку мыши и выберем "Добавить в расширение".Тип отметим галочкой наш новый документ.После этого документ станет полноценным участником типа, и механизмы БСП (Библиотеки Стандартных Подсистем) начнут с ним работать автоматически.
Что же делать, если режим совместимости ниже 8.3.20? Выясним причину, почему нам нужен этот тип. Чаще всего это требуется для работы подсистемы "Дополнительные отчеты и обработки". В БСП предусмотрены программные точки входа, которые позволяют обойти жесткую привязку к определяемому типу.
Проанализируем работу общего модуля ДополнительныеОтчетыИОбработкиПереопределяемый — для этого пригодится инструмент архитектурного анализа конфигураций и расширений 1С. Мы можем создать в расширении процедуру-перехватчик для программной регистрации объектов. Рассмотрим пример кода, который нужно разместить в модуле расширения:
&После("ПриОпределенииОбъектовСДополнительнымиКомандами")
Процедура Расш1_ПриОпределенииОбъектовСДополнительнымиКомандами(СписокОбъектов)
// Добавляем наш документ программно, даже если его нет в определяемом типе
СписокОбъектов.Добавить(Метаданные.Документы.МойНовыйДокумент);
КонецПроцедуры
Использование этого метода позволяет избежать изменения метаданных и работает на версиях платформы ниже 8.3.20. Платформа будет считать, что ваш документ поддерживает дополнительные команды, так как подсистема БСП получит его в списке разрешенных объектов при инициализации.
Иногда команды не появляются на форме документа не из-за отсутствия в типе, а из-за внутренней логики кода формы. Посмотрим на ситуацию, когда в форме документа вызывается проверка соответствия типа. Мы можем использовать расширение для подмены результата этой проверки.
Для этого в расширении создадим метод &Вместо для функции, проверяющей возможность подключения команд. Например:
&Вместо("ТипПоддерживаетДополнительныеКоманды")
Функция Расш1_ТипПоддерживаетДополнительныеКоманды(Объект)
Если ТипЗнч(Объект) = Тип("ДокументОбъект.МойНовыйДокумент") Тогда
Возврат Истина;
КонецЕсли;
Возврат ПродолжитьВызов(Объект);
КонецФункции
В конфигурации "Управление нашей фирмой" версии 1.6 часто требуется расширить тип для механизмов печати. Если ваша задача связана именно с печатью, то в расширении достаточно реализовать процедуру ДобавитьКомандыПечати в модуле менеджера вашего документа. Подсистема печати УНФ автоматически найдет эту процедуру через механизм рефлексии (анализа метаданных — см. инструменты разработчика 1С для анализа метаданных и отладки), и вам не придется трогать определяемые типы вовсе.
Порядок действий для УНФ:
Печать в расширении.Подведем итог. Проанализировав все способы, можно сделать вывод, что программный метод (через переопределяемые модули БСП) является наиболее безопасным и универсальным. Он не требует изменения структуры базы данных и не зависит от режима совместимости платформы. Для проверки корректности вызова процедур общих модулей и состава расширений пригодится инструмент для анализа расширений и поиска ошибок.
Важный момент: если вы все же решили расширять определяемый тип в 8.3.20+, помните, что при удалении расширения данные в полях, имеющих этот тип, могут быть потеряны или заменены на "Объект не найден". Поэтому для хранения ссылок в реквизитах старайтесь использовать стандартные типы или создавайте собственные объекты в расширении с осторожностью.
Мы рассмотрели различные сценарии расширения функционала без снятия конфигурации с поддержки. Выбор конкретного метода зависит от вашей версии платформы и конкретной задачи, которую необходимо решить в рамках внедрения.