Как ограничить доступ по организации в 1С

В многофирменной базе 1С рано или поздно возникает задача: бухгалтер ООО «Альфа» не должен видеть документы и отчёты ООО «Бета», а менеджер филиала — данные головного офиса. Штатный механизм для этого в 1С — ограничение доступа на уровне записей (RLS, Record Level Security) в связке с профилями и группами доступа.

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

Ниже разобрана настройка на примере типовых конфигураций (1С:Бухгалтерия предприятия, Управление торговлей, ERP, ЗУП), где механизм реализован через «Группы доступа». Логика везде одинаковая, отличаются только названия пунктов меню.

Как устроен механизм ограничения по организации

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

Ограничение по организации реализуется через шаблоны RLS, прописанные в ролях конфигурации. Когда в группе доступа указано разрешённое значение «Организация = ООО Альфа», платформа автоматически добавляет условие отбора во все запросы к таблицам, где есть реквизит «Организация». Пользователь видит только «свои» записи в журналах документов, справочниках договоров и в отчётах.

Подготовка: что включить перед настройкой

Перед созданием профилей проверьте, что в базе включены нужные функциональные опции. В разделе «Администрирование» → «Настройки прав и пользователей» (в Бухгалтерии — «Администрирование» → «Настройки программы» → «Права доступа») должен быть включён флаг «Группы доступа» / «Ограничивать доступ на уровне записей». Без него механизм RLS не применяется, даже если группы и профили созданы.

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

Третий момент — у самого настройщика должны быть права администратора или роль «Настройка прав доступа». Обычный пользователь с полными правами на данные, но без административных ролей, группы доступа редактировать не сможет.

Создание профиля группы доступа

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

На закладке «Разрешённые действия (роли)» проверьте состав ролей: там должны быть роли на чтение и изменение нужных документов, но не должно быть роли «Полные права» и «Администратор системы» — они игнорируют RLS. Это одна из самых частых причин «не работающего» ограничения.

На закладке «Виды ограничений доступа» убедитесь, что вид доступа «Организации» присутствует в списке. В типовых конфигурациях он есть в профилях по умолчанию; если его нет, добавьте строку с видом доступа «Организации».

1. 1
   Включите «Ограничивать доступ на уровне записей» в настройках прав
2. 2
   Скопируйте типовой профиль и проверьте состав ролей без «Полных прав»
3. 3
   Создайте группу доступа на основании профиля
4. 4
   В группе укажите разрешённое значение: конкретная организация
5. 5
   Добавьте пользователей в группу доступа
6. 6
   Войдите под пользователем и проверьте журналы и отчёты

Создание группы доступа и привязка организации

Откройте справочник «Группы доступа» и создайте новый элемент, например «Бухгалтеры ООО Альфа». В поле «Профиль» укажите созданный ранее профиль. Именно на уровне группы задаётся конкретное значение ограничения.

В табличной части «Значения доступа» (или на закладке «Разрешённые значения») добавьте строку: вид доступа — «Организации», значение — конкретная организация из справочника. Если организаций несколько, добавьте несколько строк — пользователь увидит данные всех перечисленных.

На закладке «Участники» добавьте пользователей. Один пользователь может состоять в нескольких группах доступа — тогда его итоговые права складываются (объединение, а не пересечение). Это удобно, когда главбух обслуживает две организации, а рядовой бухгалтер — одну.

Обратите внимание на предопределённую группу «Администраторы» и служебных пользователей (обмен данными, регламентные задания): их не нужно ограничивать, иначе фоновые процессы могут не видеть часть данных.

Особенности в разных конфигурациях

1С:Бухгалтерия предприятия

В БП 3.0 ограничение по организации работает для документов, договоров и большинства отчётов. Учтите, что некоторые регламентные операции и справочники (например, номенклатура, контрагенты) общие для всех организаций — это нормально, они не разграничиваются по умолчанию. Если нужно разделить и контрагентов, это делается отдельными видами доступа, но такая настройка усложняет совместную работу.

1С:ЗУП

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

Управление торговлей и ERP

В УТ и ERP помимо организаций действуют виды доступа «Склады», «Подразделения», «Кассы». Ограничение по организации настраивается так же, но проверяйте пересечение: менеджеру с ограничением по складу и организации должны быть доступны оба значения, иначе документы «потеряются».

Сравнение вариантов

Группы доступа (RLS)

Штатный способ для типовых конфигураций. Гибко, без доработок, но требует дисциплины: новых пользователей нужно сразу добавлять в нужные группы.

Доработка ролей в конфигураторе

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

Раздельные базы по организациям

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

Проверка результата

Никогда не считайте настройку завершённой без входа под реальным пользователем. Создайте тестового пользователя, добавьте его только в ограниченную группу и войдите в базу под ним (через «Администрирование» → «Пользователи» → «Войти от имени» недоступно в клиент-сервере — используйте отдельный сеанс или попросите коллегу).

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

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

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

Журнал документов под пользователем

Норма

Только документы разрешённой организации

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

Видны документы других организаций — проверьте членство в других группах

Оборотно-сальдовая ведомость

Норма

Формируется только по своей организации, чужая недоступна для выбора

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

Чужая организация выбирается и данные показываются

Прямая ссылка на чужой документ

Норма

Ошибка доступа или пустая форма

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

Документ открывается и читается

Права пользователя

Норма

Нет ролей «Полные права», «Администратор системы»

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

Роли есть — RLS игнорируется

Типичные ошибки и их последствия

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

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

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

Когда штатных средств недостаточно

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

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

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

FAQ

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

Почти всегда причина в суммировании прав: пользователь состоит в другой группе доступа без ограничения по организации или ему назначены роли «Полные права» / «Администратор системы». Откройте отчёт «Права доступа» (или карточку пользователя → «Права доступа» → «Отчёт по правам») и проверьте все источники прав.

Нужно ли ограничивать доступ для программиста или администратора базы?

Нет, административные роли должны оставаться без RLS-ограничений — иначе регламентные задания, обмены и обновления могут работать некорректно. Если требуется скрыть данные от обслуживающего специалиста, используйте раздельные базы или копию с обезличенными данными для доработок.

Работает ли ограничение в отчётах, построенных на СКД?

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

Что будет, если удалить организацию, указанную в группе доступа?

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

Можно ли дать пользователю доступ к двум организациям из пяти?

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