Как описать логическую структуру конфигурации при помощи объектов «Подсистема» в 1С

Объект конфигурации «Подсистема» — это основной инструмент логической декомпозиции прикладного решения в 1С:Предприятии. Подсистемы не хранят данные и не выполняют код: они описывают, какие объекты метаданных относятся к той или иной функциональной области, и формируют структуру командного интерфейса, которую видит пользователь.

Грамотно выстроенная система подсистем решает сразу несколько задач: упрощает навигацию по конфигурации, позволяет включать и отключать целые блоки функциональности через функциональные опции, облегчает разграничение прав доступа и поддержку решения. Плохо спроектированная структура, наоборот, приводит к «свалке» объектов, дублированию команд и трудностям при доработке.

Ниже разобрано, как проектировать иерархию подсистем, включать в них объекты, настраивать командный интерфейс, связывать подсистемы с функциональными опциями и проверять результат на этапе отладки.

Что такое подсистема и какую роль она играет в конфигурации

Подсистема — это объект метаданных ветки «Общие → Подсистемы» дерева конфигурации. У неё есть имя, синоним, картинка, состав (перечень входящих объектов) и настройки командного интерфейса. Подсистемы поддерживают вложенность: одна подсистема может содержать дочерние подсистемы, образуя дерево произвольной глубины.

Ключевые функции подсистем в прикладном решении:

• структурирование метаданных — разработчик и администратор видят, к какой области относится каждый объект;
• формирование командного интерфейса — панель разделов, панель навигации и панель действий строятся по подсистемам;
• управление видимостью функциональности — через функциональные опции подсистему можно скрыть целиком;
• основа для разграничения прав и для механизмов вариантов отчётов (отчёты привязываются к подсистемам).

Важно понимать: подсистема не влияет на физическое хранение данных и не является «модулем» в смысле исполняемого кода. Это декларативное описание состава и представления конфигурации.

Как спроектировать иерархию подсистем

Проектирование начинается с анализа предметной области, а не со списка уже созданных объектов. Выделите крупные области учёта: например, «Продажи», «Закупки», «Склад», «Деньги», «Кадры», «Нормативно-справочная информация», «Администрирование». Каждая такая область становится подсистемой верхнего уровня — именно они образуют панель разделов.

Внутри крупной области выделяйте дочерние подсистемы по подзадачам: в «Продажах» это могут быть «Заказы покупателей», «Отгрузка», «Ценообразование». Глубже двух-трёх уровней уходить обычно не стоит: чрезмерная вложенность усложняет навигацию и не даёт выигрыша в интерфейсе, поскольку панель разделов показывает только верхний уровень.

Практические правила декомпозиции:

• один объект — минимум одна подсистема: «висячие» объекты без подсистемы недоступны в интерфейсе и теряются при сопровождении;
• объект может входить в несколько подсистем, если он реально используется в разных областях (например, справочник «Контрагенты» в «Продажах» и «Закупках»);
• не создавайте подсистемы по типам объектов («Справочники», «Документы») — это дублирует структуру конфигуратора и не помогает пользователю;
• служебные механизмы выносите в отдельную подсистему «Администрирование» или «Сервис», скрытую от рядовых пользователей правами и настройками.

Как включать объекты в состав подсистемы

Состав подсистемы заполняется на закладке «Состав» в палитре свойств подсистемы или кнопкой «Состав» в окне редактирования. Откроется список всех объектов конфигурации с флажками: отметьте те, что относятся к данной области. Альтернативный путь — из палитры свойств самого объекта через кнопку «Подсистемы», где удобно видеть, в какие подсистемы он уже входит.

Включайте в состав не только «главные» объекты раздела. Полный состав подсистемы обычно включает:

• справочники, документы, регистры, журналы документов — ядро области;
• отчёты и обработки, относящиеся к области;
• общие модули, если подсистемы используются для декомпозиции кода (это помогает при анализе и выгрузке);
• критерии отбора и планы обмена, если они логически принадлежат области.

При добавлении нового объекта в конфигурацию сразу определяйте его подсистему — это дешевле, чем периодическая «уборка». В командной разработке полезно зафиксировать это требование в стандарте: объекты без подсистемы не принимаются в основную ветку.

1. 1
   Выделите функциональные области прикладного решения и создайте подсистемы верхнего уровня
2. 2
   Добавьте дочерние подсистемы для крупных областей (не глубже 2–3 уровней)
3. 3
   Включите объекты метаданных в состав соответствующих подсистем через закладку «Состав»
4. 4
   Настройте командный интерфейс каждой подсистемы: порядок, видимость, группы команд
5. 5
   При необходимости привяжите подсистемы к функциональным опциям
6. 6
   Проверьте результат в режиме Предприятия под пользователем с целевыми правами

Настройка командного интерфейса подсистемы

Командный интерфейс подсистемы редактируется кнопкой «Командный интерфейс» в окне редактирования подсистемы. Здесь настраиваются два списка: панель навигации (команды открытия списков и отчётов) и панель действий (команды создания объектов, обработки).

Для каждой команды доступны признаки видимости и порядок следования. Рекомендации по настройке:

• оставляйте в панели навигации только реально нужные списки — избыточные команды прячьте, пользователь откроет их через «Все функции» при необходимости;
• в панель действий выносите команды создания самых частых документов и ключевые обработки раздела;
• упорядочивайте команды по частоте использования, а не по алфавиту;
• проверяйте синонимы объектов: именно они формируют тексты команд.

Общий порядок разделов на панели разделов задаётся отдельно — в редакторе «Все подсистемы» (команда в контекстном меню ветки «Подсистемы»), где подсистемы верхнего уровня можно перетаскивать и назначать им картинки.

Связь подсистем с функциональными опциями и правами

Функциональные опции позволяют включать и отключать подсистемы целиком без изменения кода. В типовых решениях и в БСП принято создавать для значимой подсистемы функциональную опцию, в состав которой включают саму подсистему и её объекты: при отключении опции раздел исчезает из интерфейса, а связанные объекты скрываются.

Порядок привязки: создайте функциональную опцию (ветка «Общие → Функциональные опции»), в её составе отметьте подсистему и относящиеся к ней объекты, задайте хранение значения (константа или ресурс регистра). После этого включением/отключением опции вы управляете видимостью всего раздела.

Права доступа настраиваются независимо через роли, но подсистемы помогают и здесь: при проектировании ролей удобно ориентироваться на границы подсистем — роль «Менеджер по продажам» получает права на объекты подсистемы «Продажи». Это снижает риск «дыр» и избыточных прав.

Проверка результата и типовые проблемы

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

Контрольные точки проверки:

• все разделы присутствуют на панели разделов в заданном порядке и с понятными названиями;
• в панели навигации каждого раздела есть нужные списки и нет лишних;
• команды создания документов доступны из панели действий;
• при отключении функциональной опции соответствующий раздел исчезает полностью, без «осиротевших» команд;
• объекты без подсистемы отсутствуют: их можно найти поиском по составу всех подсистем или обработками анализа конфигурации.

Контрольные точки

Как проверить результат

Состав подсистем

Норма

Каждый объект конфигурации входит хотя бы в одну подсистему

Тревожный признак

Есть объекты вне подсистем — они недоступны в интерфейсе

Панель разделов

Норма

Разделы соответствуют областям учёта, порядок логичен

Тревожный признак

Технические разделы видны рядовым пользователям

Функциональные опции

Норма

Отключение опции скрывает раздел целиком

Тревожный признак

После отключения остаются команды, ведущие в ошибки прав

Интерфейс под целевой ролью

Норма

Пользователь видит только свои разделы и команды

Тревожный признак

Проверка выполнялась только под администратором

Часто задаваемые вопросы

Может ли один объект входить в несколько подсистем?

Да, и это нормальная практика для общих объектов: справочник «Контрагенты» логично включить и в «Продажи», и в «Закупки». Команда открытия списка появится в обоих разделах. Ограничение — не злоупотребляйте: если объект входит в пять-шесть подсистем, возможно, структура областей выбрана неверно.

Что будет, если объект не включить ни в одну подсистему?

Объект останется в конфигурации и будет доступен программно, но команды его открытия не попадут в командный интерфейс. Пользователь сможет открыть его только через «Все функции» (при наличии прав) или внешними средствами. При сопровождении такие объекты легко потерять.

Как скрыть служебную подсистему от пользователей?

Надёжнее всего — не давать пользователям прав на объекты этой подсистемы: пустой раздел без доступных команд не отображается. Дополнительно можно убрать видимость команд в настройках командного интерфейса и ограничить доступ через функциональную опцию.

Влияет ли удаление подсистемы на данные?

Нет. Подсистема не хранит данные, поэтому её удаление не затрагивает таблицы и записи. Но команды входящих в неё объектов пропадут из интерфейса, а если подсистема входила в состав функциональной опции — потребуется скорректировать и её.

Как упорядочить разделы на панели разделов?

Через редактор «Все подсистемы»: в дереве конфигурации откройте контекстное меню ветки «Подсистемы» и выберите соответствующую команду. В открывшемся окне подсистемы верхнего уровня перетаскиваются мышью, там же назначаются картинки разделов.

Нужно ли включать в подсистемы общие модули?

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