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