Разработка и Конфигурация · 10 мин
Для чего предназначен объект «Подсистема» в конфигурации 1С
Разбираем, для чего нужен объект метаданных «Подсистема» в 1С: структура командного интерфейса, права доступа, группировка объектов, вложенность и практические примеры настройки.
Объект метаданных «Подсистема» в 1С отвечает за логическую группировку прикладных объектов конфигурации и за формирование командного интерфейса, который видит пользователь. Каждый раздел, который отображается в панели разделов управляемого приложения — «Продажи», «Закупки», «Склад», «Зарплата» — это и есть подсистема. Без подсистем конфигурация технически работает, но пользователю приходится искать документы и отчёты через общее меню «Все функции», что для прикладной работы неприемлемо.
Подсистема не хранит данные и не выполняет бизнес-логику: она решает три задачи — определяет, какие объекты относятся к функциональной области, как они представлены в интерфейсе, и кому из пользователей эта область доступна. Поэтому корректно спроектированные подсистемы — это одновременно вопрос удобства, безопасности и сопровождаемости конфигурации.
Понимание назначения подсистем важно и разработчику, который дорабатывает типовую конфигурацию, и администратору, разграничивающему доступ, и внедренцу, проектирующему структуру нового решения. Ниже разобраны все основные сценарии использования этого объекта.
Какие задачи решает подсистема в конфигурации
Первая задача — структурирование метаданных. В типовой конфигурации сотни объектов: справочники, документы, регистры, отчёты, обработки. Подсистема позволяет отнести каждый объект к одной или нескольким функциональным областям, и разработчик в конфигураторе может отфильтровать дерево метаданных по подсистеме, чтобы видеть только нужный контур.
Вторая задача — построение командного интерфейса. Именно подсистемы верхнего уровня формируют панель разделов, а входящие в них объекты попадают в панель функций соответствующего раздела. Порядок, группировка и видимость команд настраиваются через редактор командного интерфейса подсистемы.
Третья задача — разграничение прав. В ролях платформы можно указать, какие подсистемы доступны носителю роли. Если у пользователя нет ни одной роли, дающей доступ к подсистеме, соответствующий раздел полностью скрывается из его интерфейса — вместе со всеми командами внутри него.
Как подсистемы формируют интерфейс пользователя
Подсистемы первого уровня отображаются в панели разделов управляемого приложения. Вложенные подсистемы (второго и более глубоких уровней) формируют группы внутри панели функций родительского раздела. Так, в разделе «Продажи» могут быть вложенные подсистемы «Заказы», «Счета на оплату», «Отчёты по продажам».
У каждой подсистемы есть представление (синоним), картинка и порядок отображения. Картинка задаётся из библиотеки картинок конфигурации и показывается в панели разделов. Порядок разделов настраивается в свойствах подсистем либо перетаскиванием в редакторе «Панель разделов» в конфигураторе.
Внутри подсистемы команды объектов распределяются по группам панели функций: «Важное», «Обычное» и «См. также». Разработчик вручную раскладывает команды по этим группам, чтобы часто используемые функции были на виду, а редкие не загромождали интерфейс. Видимость каждой команды можно управлять и по ролям.
Состав подсистемы: какие объекты в неё включают
В состав подсистемы включаются объекты метаданных через свойство «Подсистемы» самого объекта или через закладку «Состав» в редакторе подсистемы. Один и тот же объект может входить в несколько подсистем одновременно — например, отчёт по остаткам может быть доступен и в разделе «Склад», и в разделе «Закупки».
Типичный состав функциональной подсистемы:
- справочники предметной области (номенклатура, контрагенты, склады);
- документы и их журналы (заказы, накладные, счета);
- отчёты и обработки по области учёта;
- регистры сведений и накопления, обслуживающие область;
- планы обмена, константы и другие вспомогательные объекты при необходимости;
- вложенные подсистемы для детализации структуры.
Регистры, как правило, не выводят в пользовательский интерфейс напрямую — их включают в подсистему для удобства разработчика и для корректной работы механизмов, анализирующих состав областей, но команды открытия регистров убирают из панели функций.
Подсистемы и права доступа
Связь подсистем с ролями настраивается в редакторе роли: на закладке «Подсистемы» отмечается, какие разделы видны носителю роли. Это не заменяет настройку прав на сами объекты — право на чтение документа определяется отдельно, — но скрывает раздел целиком, что упрощает интерфейс и снижает риск ошибочных действий.
Практический принцип: пользователь должен видеть только те разделы, с которыми работает. Кладовщику не нужен раздел «Зарплата», а кадровику — раздел «Закупки». Избыточная видимость не даёт лишних прав на данные сама по себе, но создаёт ложное ощущение доступности функций и увеличивает число обращений в поддержку.
При доработке типовой конфигурации новые роли и подсистемы лучше создавать отдельно, не меняя типовые, чтобы не усложнять последующие обновления. Типовые подсистемы при обновлении могут быть перезаписаны, и внесённые в их состав изменения потеряются.
Практика: как создать и настроить подсистему
Создание подсистемы выполняется в конфигураторе и не требует программирования — вся работа идёт в визуальных редакторах.
- 1Откройте конфигуратор и в дереве метаданных найдите ветку «Общие» → «Подсистемы»
- 2Добавьте новую подсистему, задайте имя (латиницей, без пробелов) и синоним — именно синоним увидит пользователь
- 3Назначьте картинку из библиотеки картинок конфигурации для отображения в панели разделов
- 4На закладке «Состав» отметьте объекты, которые должны входить в подсистему
- 5Откройте «Командный интерфейс» подсистемы и распределите команды по группам: Важное, Обычное, См. также
- 6Настройте видимость команд по ролям при необходимости
- 7Проверьте положение раздела через «Панель разделов» в конфигураторе
- 8Обновите конфигурацию базы данных и проверьте результат под пользователем с целевой ролью
После обновления конфигурации базы данных проверку следует выполнять под учётной записью реального пользователя с целевым набором ролей, а не под администратором с полными правами: администратор видит все разделы независимо от настроек, и ошибки видимости под ним не заметны.
Вложенность и типовые ошибки проектирования
Платформа поддерживает многоуровневую вложенность подсистем, но глубокая иерархия ухудшает навигацию: пользователю приходится искать функции внутри раздела по мелким группам. Практически оправданы два, реже три уровня. Если внутри раздела накапливается больше десятка вложенных групп — это сигнал пересмотреть структуру.
Другая крайность — одна подсистема на всю конфигурацию. Тогда панель разделов теряет смысл, панель функций превращается в бесконечный список, а разграничение видимости по областям становится невозможным.
Как проверить результат настройки
Корректность настройки подсистем оценивается по трём признакам: раздел виден нужным пользователям и невидим остальным, внутри раздела команды расположены в логичном порядке, а все прикладные объекты конфигурации входят хотя бы в одну подсистему.
Как проверить результат
Раздел отображается в панели разделов, команды внутри доступны
Раздел отсутствует или виден пользователям, которым не должен быть доступен
Каждый прикладной объект входит минимум в одну подсистему
Объекты доступны только через «Все функции»
Частые команды в группе «Важное», редкие — в «См. также»
Все команды свалены в одну группу в порядке по умолчанию
Скрытый раздел совпадает с отсутствием прав на объекты
Раздел скрыт, но объекты открываются через «Все функции» или по ссылке
Частые вопросы о подсистемах в 1С
Чем подсистема отличается от функциональной опции?
Подсистема группирует объекты и строит интерфейс, а функциональная опция включает или отключает возможность в зависимости от настроек программы. Они дополняют друг друга: например, раздел может быть доступен по роли, но часть команд внутри него скрыта отключенной функциональной опцией.
Может ли один объект входить в несколько подсистем?
Да, это штатная возможность. Объект будет представлен командами в каждом разделе, куда включён. Злоупотреблять этим не стоит: если один и тот же отчёт есть в пяти разделах, пользователи теряются, а сопровождение усложняется.
Что будет, если удалить подсистему?
Сами объекты не удалятся — они останутся в конфигурации, но исчезнут из интерфейса раздела. Если объект не входит в другие подсистемы, он станет доступен только через «Все функции». Удаление типовой подсистемы может нарушить логику типовых ролей и обновлений.
Скрывает ли подсистема данные от пользователя?
Нет. Видимость подсистемы управляет только интерфейсом. Доступ к данным определяется правами роли на конкретные объекты. Пользователь со скрытым разделом, но с правами на чтение объекта сможет открыть его через «Все функции» или по прямой ссылке.
Нужно ли создавать свои подсистемы при доработке типовой конфигурации?
Рекомендуется. Собственная подсистема для доработанных объектов упрощает сопровождение: сразу видно, что добавлено внедрением, а при обновлении типовые подсистемы не затрагивают ваши настройки. Новые объекты можно включать и в типовые разделы, но осознанно, понимая риск перезаписи при обновлении.
Почему новый раздел не появился у пользователя после настройки?
Чаще всего причина в том, что роли пользователя не дают доступа к подсистеме, либо конфигурация базы данных не обновлена, либо пользователь работает в сеансе, открытом до изменений. Проверьте закладку «Подсистемы» в его ролях, выполните обновление конфигурации БД и перезапустите сеанс.
Что важно запомнить
Подсистема в 1С группирует объекты по функциональным областям, формирует панель разделов и панель функций интерфейса и используется в ролях для скрытия разделов. Подсистема не защищает данные — права настраиваются отдельно. Каждый прикладной объект должен входить хотя бы в одну подсистему, а результат настройки проверяется под пользователем с целевыми ролями, а не под полными правами.