Пример настройки сложной схемы авторизации для компании "Ивансофт" (на примере версии 2)
В соответствии с постановкой задачи нам нужно настроить схемы авторизации для следующих бизнес-сценариев:
Поездку программиста должен авторизовать его непосредственный руководитель (и в случае обучения, и в случае усиления), а в случае усиления её затем должен авторизовать держатель бюджета. При нарушении ТП её также должен авторизовать директор (в последнюю очередь), если нарушение не связано с отсутствием мест на рейсах или в отелях. В последнем случае генерального директора не подключаем.
Поездки руководителей разработки считаются исключением и нарушением ТП, их должен авторизовать генеральный директор.
Поездки генерального директора не нуждаются в авторизации. Частные поездки всех сотрудников, кроме генерального директора, авторизуются генеральным директором
Соответственно, по каждому грейду сотрудников будет своя логика проведения авторизации:
Правило для программистов
Правило для руководителей разработки
Правило для генерального директора
Мы видим, что, в соответствии с постановкой задачи, в "Правило для программистов" следует также включить специальный механизм при отклонении от тревел-политики.
"При нарушении ТП её также должен авторизовать директор (в последнюю очередь), если нарушение не связано с отсутствием мест на рейсах или в отелях. В последнем случае генерального директора не подключаем".
Прежде всего мы должны активировать сложные схемы авторизации для компании "Ивансофт". Это делается в настройках организации. Также нужно активировать режим командировок, если это не было сделано ранее.
Итак, в рамках этих настроек мы сделали следующее:
Включили пакетирование заказов;
Установили режим авторизации – «всегда» (так как у нас большая часть кейсов требует авторизации, независимо от наличия нарушений ТП);
Активировали сложную политику авторизации;
Поставили опцию «авторизовать, если нет подходящих авторизующих лиц» - специально, для того, чтобы создать экспресс-схему авторизации для заказа гендиректора – в этой схеме не будет авторизующих лиц и сработает это правило.
Далее мы переходим к созданию схем авторизации. Для этого нам надо зайти в соответствующий редактор в настройках:
Авторизация для грейда «Генеральный директор»
Прежде всего нам надо реализовать условие "Для поездок генерального директора нет авторизующих лиц".
Сделать это можно множеством способов.
Самый красивый, пожалуй, такой:
В справочник "Должность" заводим код "Несуществующая должность", который НЕ должен быть привязан ни к одному из сотрудников:
Создаем новую схему при помощи кнопки «Добавить» в списке схем авторизации:
Заполняем название схемы, не забываем активировать «Схема авторизации активна» и устанавливаем только одно условие применения – должность = "Директор", при этом на уровне авторизации (т. е. в правиле выбора авторизующих лиц) у нас будет выборка – должность = "Несуществующая должность" – в этом случае у нас сработает правило «Авторизовать, если не найдены авторизующие лица» из настроек моей организации, так как персон с такой должностью не будет найдено.
Авторизация для грейда «Программист»
Согласно постановке задачи, правило авторизации для поездок программистов такое:
«Поездку программиста должен авторизовать его непосредственный руководитель (и в случае обучения, и в случае усиления), а в случае усиления её затем должен авторизовать держатель бюджета. При нарушении ТП её также должен авторизовать директор (в последнюю очередь), если нарушением не связано с отсутствием мест на рейсах или в отелях. В последнем случае генерального директора не подключаем»
Фактически реализовать это правило надо при помощи двух схем: одна по иерархии (непосредственный руководитель + держатель бюджета), вторая по нарушению ТП –> передача на авторизацию гендиректору.
Рассмотрим её более подробно:
В заказ у нас попадают персонифицированный структурный код «Кост-центр», который определяет, к какому проекту принадлежит программист, а также код «Кто оплачивает» (т. е. центр затрат). Эти коды присутствуют в любой деловой поездке, так как они могут меняться в зависимости от проекта и при этом это определяет правило выбора авторизующих лиц. Мы укажем эти коды в разделе «В заказе должен быть любой код из справочника»:
Так как схема применяется только для сотрудников с должностью "Разработчик", укажем этот признак в разделе условия применения (Должность = Разработчик);
Далее мы должны создать уровни авторизации.
В соответствии с постановкой у нас может быть 1 или 2 уровня:
уровень, который присутствует всегда – непосредственный начальник, т. е. для сотрудника с таким набором кодов:
авторизующим лицом первого уровня будет выбрана персона, у которой код "Кост-центр" совпадает с кодом "Кост-центр", у персоны, которая едет в поездку, а код "Должность" = "Руководитель проекта", т. е. для указанной выше персоны это будет такой сотрудник:
В нашей схеме авторизации это условие записано при помощи следующего правила:
Данное правило говорит системе: «Найти персону, у которой код «Кост-центр» такой же, как код «Кост-центр» у пассажира из данного заказа и должность – «Руководитель разработки».
На втором уровне мы аналогичным образом выбираем руководителя разработки, у которого код «кост центр» совпадает с выбранным пользователем при создании заказа кодом «кто оплачивает»:
Таким образом мы реализуем сразу 2 сценария:
Универсальный сценарий, когда кост-центр, к которому привязан сотрудник, и кост-центр, оплачивающий заказ, разные – в этом случае будет 2 уровня авторизации и 2 разных авторизующих лица;
Вырожденный сценарий – когда заказ оплачивает тот же кост, к которому привязан сотрудник – в этом случае авторизующее лицо на 2-м уровне будет выбрано то же самое, что и на первом, и схема выродится также до 1-го уровня.
Авторизация поездок руководителей разработки
Для руководителей разработки мы создаем очень простое правило: если в заказе присутствует сотрудник с должностью руководитель разработки, то в заказ добавляем авторизующее лицо «генеральный директор»:
Авторизация поездок с нарушением ТП для программистов
Для реализации авторизации при нарушении ТП нам надо создать ещё одну схему. Следует понимать, что заказ может одновременно авторизовываться по нескольким схемам, при этом уровни авторизации этих схем объединяются при помощи правила суперпозиции: т. е. если одно и то же лицо присутствует в нескольких схемах, то в цепочку авторизации оно добавляется один раз на наименьшем из предложенных в этих схемах уровне.
Теперь мы должны реализовать это правило для разработчиков:
«При нарушении ТП её также должен авторизовать директор (в последнюю очередь), если нарушением не связано с отсутствием мест на рейсах или в отелях. В последнем случае генерального директора не подключаем»
Прежде всего, для реализации такой схемы нам нужно иметь справочник бюджетных кодов с признаком «Код причины нарушения тп», значение из которого пользователь будет выбирать при создании заказа, и внести туда значение «Нет мест»:
Не забываем привязывать справочники к организациям-плательщикам (см. справочник используется организациями), иначе он не будет показан при выборе плательщика на шаге создания заказа.
Чтобы создать схему, завязанную на нарушение ТП, мы должны указать его в условиях авторизации:
В заказе должен быть любой код из справочника: Причина нарушения ТП – это заставит схему применяться только в том случае, если в заказе есть код «причина нарушения ТП», а он появится только тогда, когда по заказу была нарушена тревел-политика;
Условия применения – должность = разработчик + причина нарушения ТП != нет мест – заставит схему срабатывать только тогда, когда в заказе есть разработчик и была нарушена тревел-политика, но не из-за того, что нет мест;
Уровни применения – 10, должность = генеральный директор – мы сознательно ставим максимальный уровень, чтобы к директору заказ попадал с нарушением ТП в последнюю очередь, как это указано в постановке:
Авторизация частных поездок
Для того, чтобы сепарировать частные и деловые поездки, мы должны создать специальный тип поездок в разделе «Типы поездок»:
Далее мы привязываем все обычные коды к типу поездки «Деловая поездка», а для частных поездок создадим справочник «Частная поездка», в котором укажем только одно значение – «Да»: в этом случае пользователь, выбрав на странице заказа тип поездки «Частная поездка», не сможет выбрать другой код и в заказ попадет значение «Частная поездка» = «Да», на нем и построим нашу схему авторизации:
Таким образом, схема авторизации будет выглядеть так:
Т. е. схема применится для заказов, в которых есть код «Частная поездка» со значением «Да», при этом будет выбрано авторизующее лицо «Директор». Так как к деловым поездкам справочник «Частная поездка» не привязан, то он в них не применится, и данная схема не будет влиять на авторизацию деловых поездок.