Настройка динамического маршрута согласования
При включенном флажке "Кешировать полный маршрут согласования" все настройки маршрута запоминаются на момент начала процесса согласования. Даже если в ходе согласования эти настройки изменятся, то данный процесс будет выполняться по прежним настройкам, а изменения вступят в силу уже при следующем согласовании.
Параметры, которые используются в запросе и хранимой процедуре
Параметр |
Описание |
|
---|---|---|
TaskID |
ID задачи, в которой запрашивается подпись |
|
StepID |
ID перехода, на котором запрашивается подпись |
|
RequestingUserID |
ID пользователя, от имени которого запрашивается подпись |
|
Stage |
Этап маршрута согласования.
|
Поля, возвращаемые SQL-запросом или процедурой
Процедура может возвращать не все перечисленные ниже параметры. Обязательные параметры отмечены знаком *.
Возвращаемое значение |
Настройка запрошенной подписи |
|
---|---|---|
SignatureID* |
ID подписи, которая будет запрошена |
|
Name |
Название подписи (может быть произвольная строка) |
|
AcceptorsString |
Список ID пользователей-акцептантов через запятую
|
|
MakeAcceptorsSubscribers |
Признак, назначаются ли акцептанты подписчиками задачи |
|
DeadlineTime |
Срок обработки подписи |
|
MinutesToSign |
Количество минут, отведенных на обработку подписи |
|
SmartMinutesToSign |
ID смарт-выражения, которое возвращает количество минут, отведенных на подписание |
|
RequestReason |
Причина запроса подписи |
|
SmartRequestReason |
ID смарт-выражения, которое возвращает причину запроса подписи |
|
SmartFilterID |
ID смарт-фильтра, по которому определяется, надо ли запрашивать подпись |
|
GUID |
GUID |
|
Stage* |
Номер этапа согласования |
|
StoredProcedureName |
Название хранимой процедуры, которая выполняется при запросе подписи |
|
ExcludeAlreadySigned |
Признак, надо ли запрашивать повторно подпись у акцептантов, ранее принявших положительное решение, если согласование запущено повторно |
|
AcceptorsEvalutionBaseUser |
Базовый пользователь, относительно которого выполняется алгоритм определения акцептантов, определяется: 0 — По заказчику; 1 — По исполнителю; 2 — По ответственному исполнителю; 3 — По запросившему; 4 — По смарт-выражению |
|
AcceptorsEvalutionMethod |
Метод определения акцептантов: 0 — По группам; 1 — По параметру; 2 — По руководителям; 3 — По смарт-выражению; 4 — По уровню орг структуры |
|
AcceptorsExtParamID |
Если акцептанты определяются по ДП, то ID ДП |
|
AcceptorsTableName |
Название таблицы для определения акцептантов (если акцептанты определяются по ДП и значения берутся из таблицы) |
|
AcceptorsExtParamValueColumn |
Название колонки значений ДП (в таблице для определения акцептантов, см. выше) |
|
AcceptorsNickColumn |
Название колонки со списком акцептантов для данного значения ДП (в таблице для определения акцептантов, см. выше) |
|
AcceptorsSmartExpressionId |
Если акцептанты определяются смарт-выражением, то ID смарт-выражения |
|
AcceptorsBaseUserSmartExpressionId |
ID смарт-выражения для определения базового пользователя, относительно которого выполняется алгоритм определения акцептанта |
|
SplitForEachAcceptor |
Признак, запрашивается ли подпись у каждого акцептанта отдельно (1 — да, 0 — нет) |
|
ActionIfNotSigned |
Действие при отклонении (0 — Прервать согласование; 1 – Ожидать решения всех участников; 2 – Продолжить согласование) |
|
SetStateIfNotSigned |
ID статуса, переход в который выполняется при отклонении подписи |
|
MakeStepIfNotSigned |
ID перехода, который выполняется при отклонении подписи |
Хранимая процедура выполняется столько раз, сколько этапов на маршруте согласования. Это сделано потому, что подписи, которые запрашиваются на последующих этапах, могут зависеть от резолюций, вынесенных на предыдущих этапах. Например, если на первом этапе юрист акцептовал подпись, то на втором этапе запрашивается подпись финансового директора. Если же на первом этапе юрист вынес другую резолюцию (например, "Подписать с замечаниями"), то на втором этапе запрашивается подпись генерального директора. |
---|
Хранимая процедура может возвращать не только подписи текущего этапа, но и все подписи, которые должны запрашиваться на текущем и всех последующих этапах (иногда такой код получается более простым). В любом случае система определяет минимальный этап среди всех возвращенных и запрашивает подписи только для этого этапа, поэтому минимальным должен быть текущий этап. |
---|
В ходе выполнения динамического маршрута согласования инициируются события, связанные с динамическими подписями: запрос, подписание и отклонение динамической подписи. |
---|
Примеры динамического маршрута согласования
Запрос подписей по матрице согласования
Запрос подписей с формированием списка акцептантов в виде XML