К статье
Практический материал

Разработка и Конфигурация · 10 мин

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

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

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

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

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

Как подсистемы формируют интерфейс приложения

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

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

У каждой подсистемы есть свойство «Картинка» — иконка раздела в панели разделов, и свойство «Включать в командный интерфейс», которое позволяет временно скрыть раздел, не удаляя саму подсистему. Это удобно на этапе разработки, когда часть функциональности ещё не готова к показу пользователям.

Что входит в состав подсистемы и как это настроить

Наполнение подсистемы задаётся на закладке «Состав» в палитре свойств объекта. Там отмечаются флажками объекты конфигурации, которые должны отображаться в этом разделе: документы, справочники, журналы, отчёты, обработки, планы обмена и другие объекты, имеющие представление в интерфейсе.

Один и тот же объект можно включить сразу в несколько подсистем. Например, справочник «Контрагенты» логично показывать и в разделе «Продажи», и в разделе «Закупки». Это нормальная практика: подсистема задаёт не владение объектом, а точки его отображения. Объект остаётся единственным, просто ссылки на него появляются в нескольких разделах.

Как создать подсистему и наполнить её
  1. 1
    Откройте конфигуратор, в дереве конфигурации найдите ветку «Общие» → «Подсистемы» и добавьте новый объект
  2. 2
    Задайте имя и синоним — синоним увидят пользователи как название раздела
  3. 3
    На закладке «Состав» отметьте объекты, которые должны входить в раздел
  4. 4
    Назначьте картинку раздела и при необходимости создайте вложенные подсистемы
  5. 5
    Обновите конфигурацию базы данных (F7) и проверьте интерфейс в режиме предприятия

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

Подсистемы и разграничение прав доступа

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

Дополнительно в ролях есть настройка видимости подсистем: для каждой роли можно указать, какие подсистемы ей доступны. Это позволяет целиком скрыть раздел «Зарплата» у складских работников, даже если отдельные объекты в нём им формально доступны для чтения.

Подсистемы и функциональные опции

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

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

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

Проектирование новой конфигурации с нуля

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

Доработка типовой конфигурации

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

Анализ чужой конфигурации

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

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

Частые ошибки при работе с подсистемами

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

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

Типичные ошибки
01
Объект не включён ни в одну подсистему — пользователи не видят его в интерфейсе и считают, что функционала нет
02
Слишком глубокая вложенность подсистем — раздел становится труднодоступным, пользователи не находят команды
03
Дублирование подсистем по типам объектов вместо бизнес-областей — интерфейс не отражает реальные задачи пользователей
04
Изменение типовых подсистем без необходимости — усложняет обновление конфигурации на поддержке

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

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

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

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

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

Видимость раздела
Норма

Подсистема отображается в панели разделов с заданной иконкой и названием

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

Раздела нет — проверьте флажок «Включать в командный интерфейс» и права роли

Состав раздела
Норма

Все нужные объекты доступны в панели навигации и панели действий

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

Часть объектов отсутствует — проверьте состав подсистемы и функциональные опции

Интерфейс под ограниченной ролью
Норма

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

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

Видны лишние команды или, наоборот, пропали нужные — пересмотрите настройки ролей

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

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

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

Что произойдёт с данными, если удалить подсистему?

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

Чем подсистема отличается от функциональной опции?

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

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

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

Сколько подсистем должно быть в конфигурации?

Жёсткого ограничения нет, но ориентируйтесь на удобство: обычно 5–10 разделов верхнего уровня покрывают потребности среднего прикладного решения. Если разделов больше — пользователям трудно ориентироваться, стоит объединить смежные области.

Можно ли изменить порядок разделов в панели разделов?

Да, порядок разделов соответствует порядку подсистем в дереве конфигурации. Перетащите подсистемы в конфигураторе в нужное положение и обновите конфигурацию базы данных — после перезапуска приложения панель разделов изменится.

Итог

Что важно запомнить

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