Как ограничить доступ пользователям к созданию и редактированию контрагентов, организаций и договоров в 1С:УТ 11

Системный администратор 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

В процессе эксплуатации системы 1С:Управление торговлей 11 часто возникает необходимость жестко регламентировать ввод нормативно-справочной информации (НСИ). Беспорядочное создание контрагентов или дублирование организаций может привести к серьезным ошибкам в управленческом и бухгалтерском учете. Разберем подробно, как ограничить права обычных пользователей на редактирование и создание ключевых справочников, оставив эти полномочия только выделенным ответственным лицам.

Метод 1: Настройка профилей групп доступа (стандартный способ)

Проанализируем архитектуру прав в современных конфигурациях на базе Библиотеки стандартных подсистем (БСП). В 1С:Управление торговлей 11.4 права на объекты разделены на атомарные роли. Для каждого справочника (Партнеры, Контрагенты, Организации, Договоры) существуют отдельные роли на чтение и на изменение.

Рассмотрим пошагово, как изменить права без «прокликивания» каждой галочки в конфигураторе:

  1. Перейдем в раздел Администрирование — Настройки пользователей и прав — Профили групп доступа.
  2. Найдем профиль, который используется вашими менеджерами (например, «Менеджер по продажам»). Важно: не редактируйте типовой профиль, лучше создайте его копию.
  3. В списке разрешенных ролей воспользуемся поиском. Нам нужно найти и снять флажки со следующих ролей:
    • ДобавлениеИзменениеПартнеров
    • ДобавлениеИзменениеКонтрагентов
    • ДобавлениеИзменениеОрганизаций
    • ДобавлениеИзменениеДоговоровКонтрагентов
  4. Убедимся, что при этом остались активными роли на чтение, такие как ЧтениеПартнеров, ЧтениеКонтрагентов и так далее. Это позволит пользователям видеть данные и выбирать их в документах, но лишит возможности записи.
  5. Сохраним профиль и обновим права пользователей.

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

Метод 2: Использование расширения и подписки на события

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

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


&После("ПередЗаписью")
Процедура Расш_ПередЗаписьюКонтрагента(Отказ, Замещение)
    
    // Проверяем наличие специальной роли, которую мы дали ответственным
    Если Не РольДоступна("ПолныеПрава") И Не РольДоступна("Расш_ПравоНаРедактированиеНСИ") Тогда
        
        // Если это новый объект
        Если ЭтоНовый() Тогда
            ТекстСообщения = "У вас недостаточно прав для создания новых контрагентов!";
            ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения);
            Отказ = Истину;
        Иначе
            // Если объект редактируется
            ТекстСообщения = "Редактирование существующих контрагентов разрешено только сотрудникам отдела НСИ!";
            ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения);
            Отказ = Истину;
        КонецЕсли;
        
    КонецЕсли;

КонецПроцедуры

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

Метод 3: Ограничение доступа на уровне записей (RLS)

Проанализируем ситуацию, когда доступ нужно ограничить не всем, а разделить контрагентов между группами пользователей. В УТ 11 для этого предусмотрен механизм Групп доступа партнеров.

Рассмотрим алгоритм настройки:

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

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

Метод 4: Использование даты запрета изменения для НСИ

Малоизвестный, но эффективный способ — использование механизма ДатыЗапретаИзменения. Хотя обычно его применяют для документов, в последних версиях БСП этот механизм можно расширить и на справочники.

Посмотрим на последовательность действий:

Рекомендации по контролю за изменениями

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

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

← На главную