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

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

Понятие и назначение подсистем в конфигурации

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

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

Использование подсистем также напрямую влияет на права доступа. Администратор может настроить роли так, что пользователь будет видеть только те разделы меню, подсистемы которых ему разрешены. Это создает безопасную среду, где бухгалтер не видит лишних кнопок склада, а кладовщик — финансовых отчетов.

⚠️ Внимание: Создание подсистемы в конфигураторе не добавляет её автоматически в интерфейс раздела "1С:Предприятие". После создания объекта его необходимо явно добавить в состав интерфейса, иначе пользователь его не увидит.

Пошаговый алгоритм создания новой подсистемы

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

После создания объекта откроется окно свойств. Первым делом необходимо задать имя объекта. Имя используется для программного доступа и должно быть уникальным в рамках конфигурации, желательно на английском языке, например, SalesSubsystem. Следующим шагом идет заполнение свойства "Синоним". Именно синоним будет отображаться в интерфейсе программы для пользователя, поэтому его следует писать понятным русским языком, например, "Продажи".

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

  • 📁 Имя — технический идентификатор объекта (латиница).
  • 📝 Синоним — видимое название в меню (кириллица).
  • 👁️ Командный интерфейс — флаг видимости раздела для пользователя.

☑️ Подготовка к созданию подсистемы

Выполнено: 0 / 4

Настройка иерархии и вложенности разделов

В современных конфигурациях на платформе 8.3 часто используется многоуровневая структура. Это означает, что одна подсистема может быть родителем для другой. Такая вложенность позволяет создавать сложные меню, где при клике на раздел "Администрирование" раскрывается список более узких подразделов: "Печатные формы", "Настройки пользователя", "Обслуживание".

Для создания вложенной структуры необходимо использовать свойство "Родитель". В окне свойств создаваемой подсистемы выберите из выпадающего списка уже существующую подсистему, которая будет являться верхнеуровневой. Визуально в дереве метаданных дочерняя подсистема отобразится со сдвигом вправо относительно родителя.

Существует ограничение на глубину вложенности, которое диктуется удобством восприятия. Слишком глубокая иерархия (более 3-4 уровней) затрудняет навигацию. Пользователю приходится совершать множество кликов, чтобы добраться до нужного документа. Оптимальной считается структура, где до любого объекта можно добраться за 2-3 клика.

Уровень вложенности Пример названия Тип объектов внутри Рекомендация
1 Продажи Документы, Отчеты Основной раздел меню
2 Оперативный учет Документы реализации Группировка по процессам
3 Возвраты Документ возврата Узкая специализация
📊 Какой уровень вложенности вы используете чаще всего?
Один уровень (плоская структура)
Два уровня (Раздел -> Подраздел)
Три уровня и более
Использую только общие подсистемы

Добавление объектов метаданных в состав подсистемы

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

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

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

⚠️ Внимание: При добавлении справочника в подсистему в интерфейс попадает только сам справочник. Папки и элементы справочника не добавляются автоматически, если они не включены в другие подсистемы или не являются общими.

Существует возможность тонкой настройки отображения. Для каждого добавленного объекта можно задать свойство "Важность". Это влияет на то, будет ли объект отображаться в основном меню или уйдет в раздел "Еще". Также можно настроить видимость для разных интерфейсов (Такси, Обычное приложение).

Особенности работы с общими подсистемами

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

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

Технические детали общих подсистем

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

При проектировании архитектуры важно решить, какие объекты вынести в общие подсистемы, а какие оставить локальными. Если объект нужен только в одном бизнес-процессе (например, "Акт сверки" только для бухгалтерии), его лучше поместить в локальную подсистему. Если же объект используется везде (например, "Контактная информация"), место ему в общей подсистеме.

  • 🌐 Доступность — объекты видны из любого раздела.
  • 🔄 Универсальность — подходят для кросс-функциональных задач.
  • ⚙️ Настройка — управляются через свойства общего назначения.

Настройка видимости и прав доступа через подсистемы

Механизм подсистем тесно интегрирован с системой прав доступа (РПЛ). При создании новой роли пользователя вы можете явно указать, какие подсистемы ей доступны. Если подсистема не включена в список разрешенных для роли, все объекты внутри неё станут невидимыми для пользователя с этой ролью.

Это мощный инструмент для кастомизации интерфейса под разные должности. Менеджеру по продажам можно открыть подсистему "CRM" и "Продажи", скрыв при этом "Зарплату" и "Банк". Технически это делается через конфигуратор в режиме редактирования прав доступа или через обработку администрирования пользователей в режиме предприятия.

Также существует понятие "Полнотекстовый поиск". Если подсистема исключена из прав доступа, но пользователь знает точное название объекта внутри неё, он все равно может найти его через поиск, если у него есть право на чтение самого объекта. Однако визуально в меню этот раздел отображаться не будет.

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

💡

Используйте префиксы в именах общих подсистем (например, Common_Reports), чтобы визуально отделять их от функциональных разделов в дереве метаданных. Это ускорит разработку в больших проектах.

Частые ошибки при проектировании структуры

Одной из распространенных ошибок является создание "сиротских" объектов. Это ситуация, когда справочник или документ создан, но не добавлен ни в одну подсистему. В результате пользователь не может найти этот объект в меню, хотя он существует в базе и доступен по правам.

Другая крайность — нарушение логической целостности. Например, размещение документа "Реализация товаров" в подсистеме "Склад", а отчета по продажам — в подсистеме "Бухгалтерия". Хотя технически это возможно, с точки зрения бизнеса это запутывает пользователя, который ожидает видеть связанные документы рядом.

Также стоит избегать дублирования. Один и тот же объект не стоит добавлять в 5-6 разных подсистем без веской причины. Это захламляет интерфейс. Если объект нужен в нескольких местах, лучше продумать единую точку входа или использовать механизм "Дополнительных команд".

💡

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

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

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

Что произойдет, если удалить подсистему из конфигурации?

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

Как скрыть подсистему от пользователя, но оставить в конфигураторе?

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

Влияет ли порядок подсистем в дереве метаданных на порядок в меню?

Нет, порядок в меню определяется свойством "Порядок" в форме редактирования интерфейса или порядком следования в списке подсистем главного раздела, а не их расположением в дереве метаданных конфигуратора.