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