При разработке дополнительных отчетов и обработок на базе Библиотеки стандартных подсистем (БСП) программисты часто сталкиваются с желанием максимально автоматизировать процесс регистрации. Одной из таких задач является автоматическое определение подсистемы (например, "Продажи" или "Закупки"), в которой должен появиться отчет или обработка сразу после загрузки в информационную базу. Однако, несмотря на кажущуюся логичность такой настройки, архитектура 1С и БСП накладывает определенные ограничения.
В этой статье мы подробно разберем, почему попытки добавить подсистему в массив Назначение не приносят результата, выясним разницу между объектами назначения и разделами интерфейса, а также рассмотрим правильный порядок действий при регистрации внешних модулей. Для быстрой подготовки каркаса модуля можно использовать шаблон дополнительной обработки для конфигураций на БСП.
Для начала нам необходимо четко разграничить два понятия, которые часто путают начинающие разработчики:
Назначение): этот параметр используется исключительно для "контекстных" обработок. Сюда относятся виды: ПечатнаяФорма, ЗаполнениеОбъекта, СозданиеСвязанныхОбъектов. В этот массив добавляются полные имена объектов метаданных (документов, справочников), в формах которых должна появиться кнопка вызова вашей обработки.ДополнительныйОтчет и ДополнительнаяОбработка.Проанализируем ситуацию, описанную в обсуждении. Разработчик пытается использовать метод:
ПараметрыРегистрации.Назначение.Добавить("Подсистема.Продажи");
Система игнорирует эту запись, так как Подсистема не является объектом, к которому можно "прикрепить" функционал заполнения или печати. БСП ожидает в этом массиве только те типы объектов, которые имеют формы и поддерживают механизм подключаемых команд.
Рассмотрим причины, по которым разработчики БСП намеренно не реализовали возможность программного выбора разделов интерфейса в функции СведенияОВнешнейОбработке:
1. Административный контроль и права доступа. Распределение отчетов по разделам интерфейса — это задача администратора системы, а не разработчика кода. В разных компаниях одна и та же конфигурация может быть настроена по-разному: где-то раздел "Продажи" переименован, где-то скрыт, а где-то права пользователей ограничены так, что им запрещено видеть определенные разделы. Если бы разработчик жестко прописал подсистему в коде, это могло бы нарушить логику безопасности конкретной внедренной системы.
2. Разные подсистемы в составе БСП. Как справедливо отмечено в обсуждении, механизмы регистрации и механизмы отображения команд в разделах — это разные части БСП. Они не имеют жесткой программной связи через структуру параметров регистрации. Информация о разделах хранится не в коде обработки, а в табличной части Разделы элемента справочника ДополнительныеОтчетыИОбработки.
3. Метод поиска метаданных. При регистрации обработки система выполняет проверку имен, указанных в массиве Назначение, с помощью функции Метаданные.НайтиПоПолномуИмени(). Несмотря на то что подсистема является объектом метаданных, она не входит в список допустимых типов для командного интерфейса дополнительных обработок.
Давайте рассмотрим правильный пример реализации функции для дополнительного отчета, который должен быть доступен в разделах интерфейса. Обратите внимание, что массив Назначение в данном случае остается пустым или вообще не заполняется, так как отчет предназначен для общего использования, а не для конкретного документа.
Функция СведенияОВнешнейОбработке() Экспорт
ПараметрыРегистрации = ДополнительныеОтчетыИОбработки.СведенияОВнешнейОбработке("2.2.2.1");
ПараметрыРегистрации.Вид = ДополнительныеОтчетыИОбработкиКлиентСервер.ВидОбработкиДополнительныйОтчет;
ПараметрыРегистрации.Наименование = "Анализ продаж по регионам (внешний)";
ПараметрыРегистрации.Версия = "1.1";
ПараметрыРегистрации.БезопасныйРежим = Истина;
// Для глобального отчета массив Назначение не заполняется!
// Настройка разделов производится вручную при загрузке в справочник.
НоваяКоманда = ПараметрыРегистрации.Команды.Добавить();
НоваяКоманда.Представление = "Открыть отчет 'Анализ продаж'";
НоваяКоманда.Идентификатор = "ОсновнаяКоманда";
НоваяКоманда.Использование = ДополнительныеОтчетыИОбработкиКлиентСервер.ТипКомандыОткрытиеФормы();
НоваяКоманда.ПоказыватьОповещение = Ложь;
Возврат ПараметрыРегистрации;
КонецФункции
Если же мы создаем обработку заполнения объекта, то массив Назначение обязателен, но в нем должны быть указаны только объекты (документы или справочники):
// Пример для обработки заполнения
ПараметрыРегистрации.Вид = ДополнительныеОтчетыИОбработкиКлиентСервер.ВидОбработкиЗаполнениеОбъекта();
ПараметрыРегистрации.Назначение.Добавить("Документ.РеализацияТоваровУслуг");
ПараметрыРегистрации.Назначение.Добавить("Документ.ЗаказКлиента");
Поскольку программный путь закрыт, разберем стандартный алгоритм действий администратора или внедренца:
.epf.После этого в интерфейсе выбранных разделов, в пункте "Дополнительные отчеты/обработки", появится ваша разработка. Для автоматизации переноса и настройки элементов справочника между базами подойдёт обработка для массового экспорта и импорта дополнительных отчетов и обработок.
Выясним, можно ли все-таки заставить систему саму выбирать разделы. Технически, можно написать код внутри самой обработки (например, в процедуре ПриОткрытии основной формы), который будет программно находить элемент справочника ДополнительныеОтчетыИОбработки, соответствующий этой обработке, и модифицировать его табличную часть Разделы.
Однако делать так крайне не рекомендуется по нескольким причинам:
Резюме: В актуальных версиях 1С (платформа 8.3) и БСП возможность указания подсистемы внутри кода внешней обработки отсутствует. Программно задается только связь с объектами (через Назначение), а принадлежность к разделам интерфейса определяется исключительно настройками в пользовательском режиме.