В экосистеме 1С:Предприятие навигация пользователя часто запутана из-за огромного количества справочников, документов и отчетов, сваленных в одну кучу. Без логической структуры найти нужный раздел становится сродни поиску иголки в стоге сена, что снижает производительность труда персонала. Именно для решения этой проблемы архитекторы платформы внедрили механизм подсистем, позволяющий группировать объекты метаданных в тематические блоки. Это фундаментальный инструмент, без которого невозможно представить качественную разработку конфигураций любой сложности, от простой обработки до ERP-систем.
Подсистема представляет собой контейнер, который не хранит данные сам по себе, но организует отображение других объектов в интерфейсе такс-клиента или обычного приложения. Вы можете представить её как папку в файловом менеджере или раздел в оглавлении книги. При правильной настройке пользователь видит только те пункты меню, которые относятся к его зоне ответственности, что существенно упрощает восприятие информации. В этой статье мы детально разберем функциональное назначение подсистем, способы их создания в конфигураторе и тонкости настройки видимости через роли.
Функциональное назначение и роль в архитектуре
Основная задача подсистемы — логическое разделение функциональности программы на независимые или слабо связанные модули. Например, в типовой конфигурации «Бухгалтерия предприятия» вы легко найдете подсистемы «Банк и касса», «Продажи», «Покупки» или «Зарплата и кадры». Внутри каждой из них находятся строго отфильтрованные документы и отчеты, релевантные именно этому участку учета. Это позволяет разработчику структурировать код и интерфейс, а пользователю — быстро ориентироваться в меню.
Однако роль подсистем выходит далеко за рамки простого украшения интерфейса. Они являются ключевым элементом системы безопасности 1С. Механизм ролевого доступа тесно переплетен с подсистемами: права на использование конкретной подсистемы определяют, увидит ли пользователь соответствующий раздел в навигационной панели. Если у сотрудника нет права на просмотр подсистемы «Регламентированный учет», он физически не сможет попасть в этот раздел, даже если у него есть права на отдельные документы внутри него, но не на саму структуру.
⚠️ Внимание: Удаление подсистемы из конфигурации не удаляет объекты, которые в ней находились. Справочники и документы останутся в базе данных, но потеряют свою привязку к интерфейсу и могут стать недоступными для пользователей, если не будут добавлены в другие разделы.
Также подсистемы используются для оптимизации производительности при запуске приложения. Платформа может загружать ресурсы, необходимые для конкретной подсистемы, только при обращении к ней, хотя в современных версиях это работает неявно. Важно понимать, что избыточное количество вложенных уровней подсистем может усложнить навигацию, поэтому рекомендуется придерживаться принципа разумной достаточности.
При проектировании новой конфигурации всегда начинайте с схемы подсистем на бумаге или в графическом редакторе, прежде чем создавать их в конфигураторе. Это поможет избежать хаоса в структуре меню.
Создание и базовая настройка подсистем
Процесс создания новой подсистемы начинается в окне конфигуратора в дереве метаданных. Разработчику необходимо выбрать ветку «Подсистемы», нажать правую кнопку мыши и выбрать пункт «Добавить». В открывшемся окне свойств задаются основные параметры, определяющие поведение объекта. Ключевым свойством является Синоним, так как именно он будет отображаться в интерфейсе пользователя вместо технического имени объекта.
Важнейшим параметром является свойство Включать в состав интерфейсов. По умолчанию новая подсистема не видна ни в одном интерфейсе, пока вы явно не укажете это. В окне настройки интерфейсов можно выбрать, в каких именно режимах (Такси, Обычное, Полноэкранное) будет отображаться данная подсистема. Это дает гибкость: можно создать специализированный раздел, видимый только в полном экране для администраторов, и скрыть его от рядовых пользователей в режиме Такси.
- 📂 Имя: Уникальный идентификатор объекта в метаданных, используется в коде и при ссылке из других объектов.
- 🏷️ Синоним: Читаемое название, которое видит пользователь в меню и заголовках окон.
- 👁️ Видимость: Настройка отображения через флаги включения в конкретные интерфейсы конфигурации.
Для группировки элементов внутри подсистемы часто используется свойство Порядок. Оно определяет последовательность отображения пунктов меню. Если порядок не задан явно, 1С сортирует элементы по алфавиту их синонимов, что не всегда удобно. Рекомендуется вручную проставлять числа порядка, чтобы важные разделы (например, «Рабочее место кассира») находились в начале списка, а справочная информация — в конце.
Иерархия и вложенные структуры
Подсистемы в 1С поддерживают иерархическую структуру, что позволяет создавать многоуровневое меню. Вы можете создать родительскую подсистему, например, «Производство», и вложить в неё дочерние: «Планирование», «Учет выработки» и «Нормирование». В интерфейсе это может отображаться как раскрывающийся список или как отдельная страница навигации с плитками, в зависимости от настроек интерфейса Такси.
Вложенность реализуется через свойство Родитель в форме элемента подсистемы. При выборе родителя текущая подсистема становится его частью. Однако стоит помнить о правиле «трех кликов»: пользователь не должен делать более трех переходов, чтобы добраться до нужного документа. Глубокая вложенность (более 3-4 уровней) часто свидетельствует о плохом проектировании архитектуры приложения и усложняет поддержку.
// Пример получения подсистемы по имени в коде
Подсистема = Метаданные.Подсистемы.Продажи;
Если Подсистема.ЭтоГруппа Тогда
Сообщить("Это групповая подсистема");
КонецЕсли;
Существует также понятие независимой подсистемы. Если подсистема не имеет родителя и не включена в состав других подсистем, она отображается как отдельный крупный раздел в панели разделов (слева в режиме Такси). Это идеальный вариант для глобальных функциональных блоков, таких как «Администрирование» или «НСИ и Администрирование».
⚠️ Внимание: Изменение структуры вложенности подсистем в уже работающей базе может привести к тому, что у пользователей «поедет» интерфейс. Все сохраненные настройки пользовательского интерфейса могут перестать корректно отображать новые группы.
Наполнение подсистем объектами метаданных
Сама по себе подсистема пуста. Чтобы она стала полезной, в неё необходимо добавить содержимое. Это могут быть справочники, документы, отчеты, обработки, планы счетов или даже другие подсистемы. Добавление объектов осуществляется через форму элемента подсистемы на закладке «Подсистема» (или «Состав» в старых версиях).
При добавлении объекта вы можете настроить его представление. Например, один и тот же документ «Реализация товаров» может быть добавлен в подсистему «Продажи» с именем «Продажа товаров», а в подсистему «Склад» — с именем «Отгрузка со склада». Это достигается за счет переопределения свойства Представление для конкретного вхождения объекта в подсистему.
| Тип объекта | Рекомендуемое место | Особенности отображения |
|---|---|---|
| Справочники | Раздел «НСИ» или тематический | Часто группируются по папкам внутри раздела |
| Документы | Журналы документов | Автоматически формируют журналы по типу документа |
| Отчеты | Раздел «Отчеты» или тематический | Могут быть вынесены в отдельные пункты меню |
| Обработки | Сервисные разделы | Требуют явного добавления в состав подсистемы |
Важно следить за дублированием объектов. Один и тот же объект метаданных может входить в состав нескольких подсистем одновременно. Это допустимо и часто необходимо (например, справочник «Номенклатура» нужен и в закупках, и в продажах). Но избыточное дублирование пунктов меню может запутать пользователя, который не поймет, через какой раздел правильнее открыть нужный список.
Техническая деталь хранения связей
Связь между объектом и подсистемой хранится не в самом объекте, а в структуре подсистемы. Это означает, что удаление объекта из подсистемы не влияет на его свойства в метаданных.
Управление видимостью через роли и права
Механизм разграничения прав доступа в 1С напрямую зависит от подсистем. В профиле группы доступа или в конкретной роли существует специальный раздел «Прочие права», где указывается список используемых подсистем. Если подсистема не отмечена в профиле прав пользователя, она полностью исчезает из его интерфейса, независимо от прав на вложенные объекты.
Это создает двухуровневую систему защиты. Первый уровень — видимость раздела (подсистемы). Второй уровень — права на выполнение действий внутри объектов (чтение, запись, проведение). Даже если пользователь видит подсистему «Зарплата», он не сможет изменить данные в документе «Начисление зарплаты», если у него нет соответствующих прав на сам документ. Но если подсистема скрыта, он даже не узнает о существовании такого функционала.
- 🔐 Полный доступ: Пользователь видит подсистему и все объекты внутри неё (при наличии прав).
- 🚫 Отсутствие права: Подсистема скрыта из интерфейса полностью.
- 👀 Только просмотр: Пользователь видит раздел, но не может создавать или изменять объекты (зависит от прав на объекты).
При разработке новых ролей рекомендуется сначала создать базовую роль с правами на основные подсистемы, а затем расширять её специализированными правами. Использование предопределенных ролей, таких как ПолныеПрава, дает доступ ко всем подсистемам автоматически, но для рабочих мест это избыточно и небезопасно.
Скрытие подсистемы через права доступа — самый эффективный способ упростить интерфейс для пользователя, не удаляя функционал из конфигурации.
Динамическое управление и программное скрытие
Иногда статической настройки прав недостаточно, и требуется скрывать или показывать подсистемы в зависимости от контекста, лицензии или настроек конкретной базы. Для этого используется программный код. В модуле менеджера или в обработках можно dynamically изменять состав интерфейса, хотя это сложная задача, требующая глубокого понимания платформы.
Более распространенный сценарий — использование функциональных опций. В свойствах подсистемы можно указать функциональную опцию, от которой зависит её видимость. Если опция выключена (например, «Использовать оптовую торговлю»), соответствующая подсистема автоматически скроется из интерфейса всех пользователей, у которых нет полных прав на обход ограничений.
// Проверка доступности подсистемы в коде клиента
Если Не Подсистемы.Продажи.Доступно Тогда
Сообщить("Раздел продаж временно недоступен");
Возврат;
КонецЕсли;
Такой подход позволяет создавать универсальные конфигурации, которые адаптируются под нужды конкретного клиента без изменения кода. Например, в одной базе можно включить подсистему «Бюджетирование», а в другой, где этот учет не ведется, — скрыть её через одну галочку в настройках параметров системы.
⚠️ Внимание: Функциональные опции влияют на видимость подсистем глобально для всей базы или профиля, если не настроена персонализация. Изменение опции может потребовать перезапуска приложения у всех пользователей для применения изменений.
Часто задаваемые вопросы (FAQ)
Можно ли добавить один документ в две разные подсистемы с разными названиями?
Да, это стандартная практика. Вы добавляете объект «Документ.СчетФактура» в подсистему «Покупки» с синонимом «Счета от поставщиков», и в подсистему «Продажи» с синонимом «Выданные счета». В метаданных это один объект, но в интерфейсе он представлен двумя разными пунктами меню.
Почему подсистема видна в конфигураторе, но не отображается у пользователя в 1С?
Наиболее вероятная причина — подсистема не включена в состав используемого интерфейса. Проверьте свойства подсистемы и убедитесь, что стоит галочка напротив нужного интерфейса (например, «Основной интерфейс»). Вторая причина — отсутствие права на использование подсистемы в роли пользователя.
Как удалить подсистему, не удаляя находящиеся в ней документы?
Просто удалите саму подсистему из дерева метаданных. Объекты, которые в ней лежали (справочники, документы), останутся в конфигурации. Они просто перестанут быть сгруппированы в этом разделе. Чтобы они не пропали из интерфейса совсем, добавьте их в другие существующие подсистемы.
Влияет ли количество подсистем на скорость работы базы данных?
Нет, подсистемы — это объекты метаданных, они влияют только на структуру интерфейса и логику прав доступа. Они не создают дополнительных таблиц в базе данных SQL и не замедляют выполнение запросов. Производительность зависит от объема данных и качества кода запросов, а не от структуры меню.