Переход на современную платформу «1С:Предприятие 8.3» и конфигурацию «Управление торговлей» редакции 11 (а также ERP и Комплексную автоматизацию) часто вызывает ступор у специалистов, привыкших к логике работы систем прошлых поколений (например, «1С:Предприятие 7.7» или «Управление производственным предприятием 1.3» / «Управление торговлей 10.3»).
В этой статье мы подробно разберем, как устроена современная концепция администрирования пользователей, почему классический путь через Конфигуратор теперь является ошибочным, как правильно распределять права с помощью профилей и групп доступа, и куда разработчики переместили привычные персональные настройки пользователя вроде «склада по умолчанию» или «основного покупателя».
В старых версиях систем 1С процесс заведения нового сотрудника выглядел стандартно: администратор открывал Конфигуратор, создавал нового пользователя информационной базы, вручную отмечал галочками доступные роли, а затем переходил в режим «1С:Предприятие», открывал специальный регистр сведений или обработку «Настройки пользователей» и жестко прописывал там значения по умолчанию (основную организацию, кассу, склад, покупателя).
Попытка применить этот же алгоритм в «1С:Управление торговлей 11» приводит к хаосу: назначенные в Конфигураторе права «слетают» при первом же обновлении или изменении настроек в режиме предприятия, а привычного диалогового окна с персональными настройками в программе попросту нет. Давайте разберем по шагам, как построена логика в современных конфигурациях на базе БСП (Библиотеки стандартных подсистем), и как с ней правильно работать.
Современные конфигурации 1С используют гибридную схему управления учетными записями. Данные о пользователях хранятся в двух местах одновременно:
Справочник.Пользователи (в режиме «1С:Предприятие») — для ведения аналитического учета, связи сотрудников с документами, задачами, бизнес-процессами и разграничения прав доступа.Важное правило: инициатором создания связи всегда должен выступать режим «1С:Предприятие». Если мы создадим пользователя напрямую в Конфигураторе, программа не сможет корректно связать его со служебными таблицами в базе данных. В результате при попытке входа такой пользователь либо получит ошибку авторизации (например, «Нет прав на запуск требуемого вида клиента»), либо его права будут работать некорректно, так как они не прописаны в системных регистрах сведений.
Рассмотрим, как выглядит концептуальная схема правильной работы с пользователями на встроенном языке (это помогает понять, какие механизмы БСП запускает под капотом):
// Пример того, как система программно создает пользователя через БСП
НовыйПользователь = Справочники.Пользователи.СоздатьЭлемент();
НовыйПользователь.Наименование = "Иванов Иван Иванович";
НовыйПользователь.Недействителен = Ложь;
НовыйПользователь.Записать();
// На основании элемента справочника БСП сама генерирует пользователя ИБ:
ПользовательИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
ПользовательИБ.Имя = "ИвановИИ";
ПользовательИБ.ПолноеИмя = "Иванов Иван Иванович";
ПользовательИБ.АутентификацияСтандартная = Истина;
ПользовательИБ.Записать();
Когда мы делаем это вручную через интерфейс программы, система выполняет все эти действия автоматически, обеспечивая полную целостность данных.
Рассмотрим детальный алгоритм создания нового сотрудника в системе «1С:Управление торговлей 11»:
После записи карточки пользователя нам необходимо наделить его правами доступа. Но делать это нужно строго определенным образом.
В современных конфигурациях 1С права настраиваются с помощью специальной двухступенчатой архитектуры: Профили групп доступа и Группы доступа.
Профиль групп доступа — это, по сути, шаблон прав, в котором определяется, какие роли из Конфигуратора доступны данной категории сотрудников. В УТ 11 по умолчанию поставляется множество предопределенных профилей: «Менеджер по продажам», «Бухгалтер», «Кладовщик», «Ревизор» и так далее.
Важное правило: изменять стандартные (предопределенные) профили, поставляемые разработчиками 1С, нельзя. При обновлении конфигурации все ручные изменения в них могут быть затерты. Если вам требуется внести изменения в стандартный набор прав:
Группа доступа — это инструмент, который связывает конкретных Пользователей с выбранным Профилем групп доступа. Именно здесь происходит финальное назначение прав.
Перейдем в список групп доступа (НСИ и администрирование — Настройки пользователей и прав — Группы доступа) и создадим новую группу:
Если мы настроим права таким образом, они никогда не «слетят» при обновлениях системы или изменении конфигурации.
В Сообщении 3 на форуме упоминается механизм ограничения доступа на уровне записей (RLS). Этот инструмент позволяет настроить видимость данных в программе так, чтобы, к примеру, менеджеры филиала в Казани видели только свои заказы и склады, а менеджеры из Екатеринбурга — свои.
Исторически в ранних версиях УТ 11 активация RLS приводила к колоссальному снижению производительности базы данных. При открытии любого списка документов система выполняла сложнейшие SQL-запросы, на лету проверяя права текущего пользователя на каждую строчку таблицы. База данных начинала сильно «тормозить», возникали частые транзакционные блокировки.
Проанализируем, как эта проблема решена на сегодняшний день. Начиная с версии УТ 11.4, разработчики внедрили так называемый производительный режим работы RLS. Рассмотрим разницу между старым и новым режимами:
Для включения производительного режима перейдем в НСИ и администрирование — Настройки пользователей и прав, развернем группу Ограничивать доступ на уровне записей и убедимся, что включен именно производительный вариант работы.
Особую панику у пользователей и администраторов (как в Сообщении 12) вызывает отсутствие привычной формы настройки значений по умолчанию. Вопрос: «Где задать основной склад, основную кассу и основного покупателя для конкретного менеджера, чтобы они автоматически подставлялись в документы?»
Выясним причину этого изменения. Разработчики 1С в интерфейсе «Такси» отказались от старой концепции персональных настроек пользователя по умолчанию, так как на практике жесткая привязка значений приводила к большому количеству ошибок при вводе документов (пользователи забывали менять склад или организацию при оформлении нестандартных сделок).
Вместо этого в современных версиях УТ 11.4 и 11.5 реализованы четыре умных альтернативных механизма автозаполнения:
Программа постоянно анализирует историю работы каждого конкретного пользователя. При создании нового документа система берет последние 5 документов этого же вида, созданные текущим пользователем. Если в 3 или более из них был выбран один и тот же склад (или организация), программа автоматически подставит это значение в новый документ.
Пользователям не нужно ничего настраивать вручную — система сама подстраивается под их текущий рабочий контекст. Если менеджер всю неделю выписывает документы со склада «Центральный», программа сама начнет подставлять его во все новые документы.
Вместо жесткой привязки «основного покупателя» в УТ 11 вся логика продаж строится на соглашениях. При создании документа продажи менеджер выбирает Партнера и действующее Соглашение (типовое или индивидуальное).
В самом соглашении уже четко зафиксированы:
Как только менеджер выбирает соглашение, все реквизиты документа мгновенно заполняются правильными данными автоматически. Это исключает ошибки ручного ввода.
Рассмотрим еще один удобный механизм. Если пользователь заходит в список документов (например, в журнал «Заказы клиентов») и устанавливает в шапке списка быстрый фильтр по конкретному складу или организации, то при нажатии кнопки Создать программа автоматически перенесет эти значения отбора в реквизиты нового создаваемого документа.
Если в группе доступа конкретному пользователю разрешена работа только с одной организацией (например, «ИП Иванов») или только с одним складом (например, «Склад розничной торговли»), то система автоматически заполнит эти реквизиты во всех новых создаваемых документах без возможности выбора альтернативных вариантов.
Резюмируя особенности настройки пользователей в современных конфигурациях 1С, выделим несколько золотых правил для администратора: