Тиражирование единого решения для нескольких дочерних организаций (ДО) с одной стороны ведет к некоторому «утяжелению» решения, ведь его надо сделать подходящим для нескольких организаций одновременно, даже при условии схожести схем их работы. Поэтому и появляются опции, которые используются в одних ДО и не используются в других, дополнительные блоки условий в типовых маршрутах (ТМ). Но, с другой стороны, построение общего механизма работы ведет к разработке универсальных инструментов, которые предусматривают и то и другое и третье.
Рассмотрим ситуацию по определению исполнителей блока на примере процесса согласования заявок на оплату (хотя на его месте может выступать любой другой процесс). Процесс согласования представляет собой рассмотрение согласующими эл. документа «Заявка на оплату» и записи справочника «Счета». Пусть финансовый отдел участвует в согласовании, причем «предоплатные» счета смотрит только Сотрудник 1, счета с условиями оплаты «по факту» смотрит только Сотрудник 2. В другом ДО уже иные требования, например, сотрудники смотрят счета в зависимости от его типа (договорной, бездоговорной), а не от условий оплаты. Писать программный код разработчиком отдельно для каждого ДО и/или добавлять блоки условий в ТМ будет очень трудозатратным, в том числе и при последующей эксплуатации, когда возникнет необходимость внесения модификаций. Оптимальным здесь будет выступать построение некоторого механизма, требующего выполнение только настройки, а не разработки.
Обозначим некоторые общие требованиями к такому механизму вычисления исполнителей: 1) возможность задавать правила типа: «если «Реквизит 1» принимает (больше, меньше и т.д.) «Значение 1», то возвращается «Пользователь 1»». В том числе предусмотреть объединение правил: «если «Реквизит 1» принимает «Значение 1» и «Реквизит 2» принимает «Значение 2», то возвращается «Пользователь 2»». 2. В качестве контекста, от которого будут работать правила, выступает как минимум запись справочника, являющаяся параметром ТМ.
На одном из проектов был реализован один из вариантов данного механизма. Процесс настройки вычисления исполнителей состоял в создании записи справочника «Специальные роли», в котором непосредственно указывался исполнитель по умолчанию и правила:
По кнопке «Правила» устанавливаются одно или несколько правил, каждое из которых описывает при каких значениях реквизита(ов) справочника будет вычисляться конкретный пользователь. Правила хранятся в справочнике «Правила для ролей», запись которого представляет собой:
Здесь, в реквизите «*Параметр задачи» явно указываем имя параметра ТМ, по которому будут производиться вычисления. В табличной части указывается реквизиты справочника, условия (Равно/Не равно/Больше и т.д.) и конкретные значения реквизитов. Правил можно создавать сколько угодно. Если ни одно из правил не выполняется, то будет возвращен пользователь, указанный в реквизите «Исполнитель по умолчанию» (см. справочник «Специальные роли»). Если же несколько правил одновременно являются истинными, то задания получают соответствующее количество пользователей. В нашем примере, если в карточке «Счета» в реквизите «Условия оплаты» установлено значение «Оплата по факту», то задание будет получать Иванов Иван.
Авторизуйтесь, чтобы написать комментарий