Примеры¶

В данном разделе описаны следующие примеры:

Примеры настройки процессов:
- Создание процесса - введение в создание процессов в редакторе бизнес-процессов. Поэтапно описано, как создать и настроить свой процесс с использованием типовых действий. В данном примере все задания отправляются с помощью действия Задание.
- Примеры процессов с применением действий из группы Маршруты - примеры создания и настройки маршрутов с использованием действий из группы Маршруты (т.е. задания согласования, подписания и т.п., аналогичные тем, которые используются в подсистеме маршрутов, описанной в Руководстве Администратора).
  
  Note
  
  Примеры, указанные выше, можно посмотреть в архиве по ссылке.
Прочие примеры:
- Настройка создания ссылок мобильного согласования в уведомлениях о задании.
- Настройка создания записи информации о задании в листе согласования действиями не из группы Маршруты.
- Создание действий - создание новых типов действий для использования их в процессах.
- Создание расширений на проверку доступа к тайлам - пример реализации дополнительной проверки доступа к кнопкам процесса.
- Создание кастомного базового класса процесса.

Создание процесса¶

Далее описывается поэтапное создание процесса для простого согласования, реализованное с использованием стандартных действий. Настоятельно рекомендуется импортировать схему и типы карточек и заданий из архива по ссылке, они будут использоваться в бизнес-процессах.

Important

Реализуемый в данном примере процесс можно настроить более простым способом, используя действия из группы Маршруты. Пример их использования см. в разделе Примеры процессов с применением действий из группы Маршруты.

Этап 1. Создание отправки задания согласования с доработкой¶

В данном примере рассматриваются:

Создание и настройка карточки шаблона процесса
Создание кнопки для запуска процесса
Создание простого процесса
Настройка действий старта процесса, задания, завершения процесса

Для начала необходимо создать новую карточку шаблона бизнес-процесса и заполнить параметры:

Название (например, Согласование (пример)).
Группа (опционально, удобно использовать для разделения шаблонов по логике использования).
Флаги Запуск из карточки и Можно запускать несколько экземпляров (в данном примере рекомендуется оставить по умолчанию).
Типы карточек: Договорной документ.
Расширения проверки состояния для кнопок (плиток): Проверка состояния и Проверка ролей на выполнение.
Доступ на редактирование можно оставить как есть, Доступ на чтение экземпляров - установить Все сотрудники.

После заполнения полей нужно добавить новую кнопку, рекомендуется настроить её по примеру:

Добавив кнопку, нужно сохранить карточку.

После сохранения шаблона в карточке договора можно проверить наличие добавленной кнопки меню системы.

Дальше работа будет в редакторе версии процесса, его необходимо открыть. Для начала необходимо нажать на кнопку с закрытым замком (Заблокировать процесс для редактирования), чтобы получить возможность редактировать версию процесса.

На макет добавляются следующие действия:

Старт процесса - будет использоваться для определения места старта процесса.
Конец процесса - будет использоваться для определения места конца процесса.
Два действия Задание - одно будет использоваться для согласования, а второе - для доработки.

Note

Это пример поэтапного создания процесса со своими настройками, где используется стандартное действие Задание. Однако для заданий согласования и доработки удобно использовать соответствующие действия из группы Маршруты, т.к. в них уже заложено много функциональности, например, запрос дополнительного согласования, делегирование и т.п.

Затем нужно расположить созданные узлы на макете и дать им соответствующие заголовки:

Следующим шагом будет создание связей между узлами. Их нужно добавить между:

Узлом запуска процесса и узлом согласования.
Узлом согласования и концом процесса
Узлом согласования и доработкой (две связи, в обоих направлениях)
Узлом доработки и концом процесса

Новым связям можно задать заголовки, чтобы показать их значение на макете. также можно изменить форму линий, чтобы они не пересекались друг с другом. Получится примерно следующая картина:

Далее настраиваются действия.

Действие Старт процесса дополнительно настраивать не нужно, т.к. по умолчанию оно ожидает сигнал с типом Start, который был указан для кнопки запуска процесса.

Действие Конец процесса также дополнительно настраивать не нужно.

Действие узла Согласование, WorkflowTaskAction, настраивается следующим образом:

Тип задания: Согласование (WfeApprove), чтобы оно отправляло задание с данным типом.
В таблицу Функциональные роли добавляется строка:
- Функциональная роль: Исполнитель
- Режим выбора роли: Список ролей
- Список ролей: Регистраторы
- Отметить флаги Основная и Отображать в задании
Таким образом, задание будет приходить на данную роль.
Автора задания добавлять не обязательно, по умолчанию пропишется текущий сотрудник.
Текст задания. В данном поле можно использовать плейсхолдеры, чтобы отображать данные карточки (например, номер договора).
```
Согласуйте, пожалуйста, договор: {f:DocumentCommonInfo.FullNumber}
```
Длительность, рабочие дни - 3.
В результат записывается то, что попадает в поле Результат в истории заданий. Также поддерживает плейсхолдеры. Например,
```
Завершено {userName}
```
Для примера требуется два варианта завершения:
- При завершении с вариантом Согласовать происходит переход в узел Конец процесса.
- При завершении с вариантом Не согласовать - в узел Доработка.

В итоге мы получаем следующее настроенное действие:

Действие узла Доработка, WorkflowTaskAction, настраивается таким образом:

Тип задания: На доработку (WfeRework).
В данном примере задание на доработку отправляется автору документа. Для реализации такого поведения в таблицу Функциональные роли добавляется строка:
- Функциональная роль: Исполнитель
- Режим выбора роли: Список ролей
- Список ролей: Автор документа
- Отметить флаги Основная и Отображать в задании
Текст задания, Результат и длительность заполняются произвольно.
В этом действии будет два варианта завершения:
- При завершении задания с вариантом Начать новый цикл происходит возврат в узел Согласование.
- При завершении задания с вариантом Отозвать - переход в узел Конец процесса.

Настройка простого согласования завершена. После сохранения процесса его можно использовать в карточке договора.

Этап 2. Последовательное согласование, смена состояния, отправка уведомлений, отзыв с согласования.¶

В данном примере рассматриваются:

Управление версиями процесса
Кнопки для управления процессом
Действия Смена состояния, Уведомление, Управление заданием.
Настройка списка сигналов для обработки
Настройка режима перехода связи

Шаблоны бизнес-процессов поддерживают версионность. Это позволяет изменять процесс так, чтобы активные процессы продолжали функционировать без изменений. Версию процесса можно удалить, но только при условии, что для неё нет активных экземпляров процесса.

Т.к. планируется доработать процесс, то для начала нужно создать новую версию процесса. Для этого нужно выделить строку в таблице Версии бизнес-процесса и нажать на кнопку Копировать в новую версию в нижней части таблицы. В таблице появится новая строка. После сохранения ей выделится номер.

Кнопкой в нижней части таблицы её нужно заблокировать на редактирование и открыть в редакторе.

В первую очередь нужно добавить ещё одно согласование после первого. Это можно сделать несколькими способами:

Просто добавить новое действие типа Задание на связь между узлами Согласование и Конец процесса.
Скопировать узел Согласование и вставить его на ту же связь, что и в первом варианте. Этот вариант позволит перенести ряд настроек действия Задание со скопированного узла.

Из нового узла нужно добавить связь в узел Доработка. Процесс примет следующий вид:

Далее производится настройка добавленного действия задания аналогично тому, как делалось в предыдущем примере. В случае копирования особое внимание следует уделить настройкам переходов по вариантам завершения.

Следующим этапом добавляется действие типа Смена состояния. Данное действие можно вставить между вторым согласованием и узлом Конец процесса, а также между узлами Доработка и Конец процесса. Каждому добавленному узлу в действие смены состояния ChangeStateAction нужно настроить соответствующее состояние.

Также рекомендуется реализовать отправку уведомлений при получении задания на доработку. Это можно сделать, добавив новый узел с действием Уведомление перед узлом Доработка.

Note

В данном примере для наглядности будет использоваться именно этот способ добавления уведомления в процесс, однако это можно сделать и другими способами:

Действие Уведомление можно добавить непосредственно в узел Доработка перед действием задания. Настройка будет аналогична настройке отдельного узла, за исключением того, что в список обрабатываемых сигналов для него необходимо добавить тип сигнала Default, чтобы отправка уведомления производилась только при отправке задания.
В самом действии Доработка есть блок Уведомления о задании, заполнив который, пользователи указанных ФРЗ будут получать уведомления типа, выбранного из справочника. Данный вариант в этом примере не подойдёт, так как используется кастомное уведомление.

Нужно настроить действие WorkfowNotificationAction узла Уведомление.

В качестве роли получателя рекомендуется указать исполнителя задания. Так как в этом примере исполнителем задания на доработку является автор документа, в поле Получатели указывается он.
Затем понадобится текст письма. Можно выбрать готовое уведомление (поле Уведомление) или настроить своё (блок Настраиваемое уведомление)

Настройка действий завершена, итоговую схему рекомендуется сохранить.

Теперь нужно создать и настроить кнопку системного меню для управления процессом на примере простого отзыва.

Для этого необходимо добавить новую строку в таблицу Кнопки бизнес-процесса. Настраивается она следующим образом:

В качестве типа сигнала был введён кастомный тип сигнала Revoke (его можно ввести вручную или добавить в перечисление WorkflowSignalTypes в схеме в рамках проекта).

Теперь необходимо доработать сам процесс. Для этого добавляется новый узел Отзыв типа Управление заданием, из которого будет отправляться сигнал с отзывом задания в узлы согласования. В настройки узла в поле Подписки узла по умолчанию указывается кастомный тип сигнала Revoke.

Cамо действие настраивается так, чтобы оно завершало задание с вариантом Отозвано.

- **Тип управления**: `Завершить задание`
- **Вариант завершения**: `Отозвать`

Из узла Отзыв должны проходить связи в узлы согласования. Для новых связей в настройках в поле Режим перехода указывается значение Никогда не создавать экземпляр узла. Это значит, что обработка произойдет только тогда, когда узел активен (т.е. есть задание на согласование).

Наконец, нужно добавить узел типа Смена состояния и соединить связи так, чтобы из узла Отзыв так же был переход в узел Конец процесса.

Процесс с двумя последовательными согласованиями, сменой состояний, отправкой уведомления и отзывом согласования, готов.

Этап 3. Параллельное согласование, условие перехода, скрипты.¶

В данном примере рассматриваются:

Параметры процесса
Параллельная отправка заданий
Условие переходов
Действия Условие, И, Сценарий
Отмена выполнения действия
Написание простых скриптов

Для начала нужно внести следующие изменения в процесс:

Добавить узел типа Сценарий и назвать его Инициализация.
Добавить новый узел типа Задание и назвать его Согласование 3.
Добавить связь из узла Отзыв в новый узел согласования. Для неё указать настройку перехода Никогда не создавать экземпляр узла.
Все связи, что раньше переходили в первый узел согласования (кроме связи из узла Отзыв), перенести на узел Инициализация.
Добавить связи из узла Инициализация в первый узел согласования и новый узел согласования.
Добавить узлы с типами Условие (он будет называться ИЛИ) и И и настроить связи между ними и узлами согласования следующим образом:
Перенастроить переходы для узлов согласования.

В итоге получаются две параллельные ветви согласования. В одной ветви два задания, в другой - одно. В первой ветви, если первый человек завершил задание с вариантом Не согласовать, второе задание пропускается, но задание на доработку отправляется не сразу. Происходит переход в узел И, действие которого ожидает, пока в него не придут сигналы от всех узлов, которые имеют связи с этим узлом. В данном случае, это вторая ветвь согласования.

Однако сейчас, когда завершатся обе ветви согласования и продолжится выполнение от узла И, система отправит сигнал как по связи Согласовано, так и по связи Не согласовано.

Чтобы отследить данную ситуацию, можно в параметры процесса добавить новый параметр типа Да/Нет, который для примера называется NeedRework. Делается это в настройках процесса (кнопка с шестернёй на тулбаре), где необходимо нажать Редактировать параметры процесса.

Этот параметр будет определять, будет переход на доработку или нет.

В исходящую из узла И связь, в поле Условие выхода из узла, нужно добавить строку Process.NeedRework, для связи Не согласовано, и !Process.NeedRework, для связи Согласовано.

Данный параметр необходимо заполнять при завершении заданий с вариантом Не согласовано и сбрасывать после возврата с доработки.

Для этого в скрипт для действия WorkflowScenarioAction из узла Инициализация нужно добавить строку Process.NeedRework = false;, а в скрипты вариантов завершения Не согласовано для каждого задания - Process.NeedRework = true;

Таким образом, если хоть одно задание завершено с вариантом Не согласовать, устанавливается флаг NeedRework, который проверяется при завершении согласования.

Далее можно добавить условие для перехода во вторую ветвь согласования. В ней будет проверяться сумма договора. Например, если она не задана или меньше, чем 50 000 (в данном примере не рассматривается валюта), то согласование не требуется.

Эту задачу можно сделать различными способами:

Добавить узел с проверкой условия перед второй ветвью согласования и узел после нее, который ожидает сигнал от первого узла с условием или от узла с согласованием.
Отменять действия отправки задания на согласования в предобработке. Это позволяет пропустить выполнение действия Задание и сразу перейти по связи Завершено к узлу И.

Таким образом можно реализовать несложный процесс согласования с двумя параллельными ветвями согласования, при этом одна из них запускается только при определенных условиях.

Рассмотрим еще один пример. На этот раз будет формироваться комментарий задания Доработка из комментариев при не согласовании.

В первую очередь нужно добавить параметр ReworkComment в параметры процесса, в который будут записываться комментарии сотрудников при отказе в согласовании.

Далее в поле Основной скрипт процесса добавляется метод, который записывал бы из задания согласования комментарий в созданный параметр. Также в этот метод можно вынести установку параметра NeedRework = true.

protected void AddReworkComent(CardTask task)
{
    var section = task.Card.Sections.GetOrAdd("WfResolutions");
    string comment = section.RawFields.TryGet<string>("Comment");

    Process.ReworkComment = (string)Process.ReworkComment +
        (!string.IsNullOrEmpty(comment)
        ? string.Format("{0} ({1}): {2}\n", task.UserName , DateTime.Now, comment)
        : string.Format("{0} ({1})\n", task.UserName , DateTime.Now));

    Process.NeedRework = true;
}

Данный метод работает следующим образом:

Получение секции из карточки задания
Получение значения из поля Комментарий из карточки задания
Добавление строки вида <исполнитель> <дата завершения>: <комментарий>, если комментарий задан, или <исполнитель> <дата завершения>, если не задан, в комментарий отзыва.

Во все места, где происходит завершение задания с вариантом Не согласовано, нужно добавить вызов метода AddReworkComent(task).

В узел Инициализация добавляется сброс комментария:

Process.NeedRework = false;
Process.ReworkComment = null;

Далее настраивается привязка параметра Текст задания для задания из узла Доработка к параметру процесса ReworkComment.

Таким образом, сформированный комментарий будет отображаться как текст для задания на доработку.

Этап 4. Дополнительное согласование с возможностью рекурсивной отправки¶

На данном этапе рассматривается использование следующей функциональности:

Привязки к различным источникам данных
Рекурсивная отправка доп. согласований с отзывом дочерних заданий
Обновление родительского задания при завершении дочернего
Действия Группа заданий, Управление группой заданий

Для начала нужно внести следующие изменения в макет процесса

Добавить узел типа Группа заданий. Он будет называться Доп. согласование.
В созданный узел добавить действие типа Управление заданием, переместить его в таблице действий перед группой заданий.
В него же добавить действие типа Управление группой заданий, переместить его в таблице действий перед группой заданий.
Добавить связь из всех узлов Согласование 1-3 в новый узел.
Добавить в новый узел связь на самого себя, установить ей режим перехода Никогда не создавать экземпляр узла.
Добавить связь в новый узел из узла Отзыв.

Получится примерно следующее:

Данный узел будет заниматься обработкой всего дерева доп. согласования, существуя при этом в единственном экземпляре. Добиться этого можно путем добавления новых исполнителей через Управление группой заданий. Но первая отправка должна производиться через действие Группа заданий.

Нужно добавить в узел параметр Draft и установить ему значение true. Данный параметр будет определять состояние узла. Если значение равно true, то задания создаются через Группу заданий, иначе - через Управление группы заданий.

Теперь необходимо настроить действия.

В действии Группа заданий поля настраиваются следующим образом:

Поле Роли настраивается следующим образом:

Нажать на кнопку для открытия формы настройки привязки (иконка в форме гаечного ключа).
Выбрать тип привязки Задание.
Из списка типов заданий выбрать тип задания WfeApprove.
В фильтрах отметить флаги Завершенные задания и Только первое задание, остальные должны быть сняты.
В контроле со структурой задания выбрать секцию WfResolutionPerformers.
Поле Колонка для сортировки автоматически заполнится.
Нажать кнопку ОК, чтобы сохранить настройки привязки для поля Роли.

Поле Текст задания настраивается так же, как и Роли, только в качестве поля для привязки выбирается поле Comment из секции WfResolutions.

Далее необходимо заполнить таблицу вариантов завершения. В ней будут строки с вариантами завершения Согласовать, Не согласовать и Запросить дополнительное согласование. Для каждого варианта завершения указывается Условие выполнения перехода: Одно задание, сразу, в список переходов добавляется связь на себя.

Для вариантов Согласовать и Не согласовать нужно добавить сценарий:

Signal.Revoke = true;

if (task.ParentRowID.HasValue)
{
    var parentTask = await Context.GetTaskAsync(task.ParentRowID.Value, Context.CancellationToken);

    parentTask.Digest += "\n" 
        + task.UserName 
        + " согласовал/не согласовал с комментарием: " 
        + task.Card.Sections["WfResolutions"].RawFields.TryGet<string>("Comment");
    parentTask.Flags |= CardTaskFlags.UpdateDigest;
    parentTask.State = CardRowState.Modified;
}

Параметр сигнала Revoke будет отвечать за отзыв дочерних заданий доп. согласования.

Вторая часть скрипта занимается тем, что дописывает в текст родительского задания информацию о завершении задания: кто завершил, с каким вариантом и каким комментарием.

Действие Управление группой заданий необходимо заполнить следующим образом:

Список обрабатываемых сигналов: Default.
Предобработка:
```
if (Node.Draft || Signal.Revoke == true)
{
    Cancel = true;
}
```
В сценарии предобработки проверяется необходимость в добавлении новых исполнителей в группу заданий и отмена действия, если новые исполнители не должны добавляться (при отзыве заданий).
Поле Новые роли заполняется аналогично тому, как было заполнено поле Роли в действии Группа заданий.

Действие Управление заданием в узле Доп. согласование заполняется следующим образом:

Список обрабатываемых сигналов: Default.
Предобработка:
```
if (Signal.Revoke != true || Task == null)
{
    Cancel = true;
}
```
В сценарии предобработки проверяется необходимость в отзыве заданий группы заданий и отменяется действие, когда отзыв не нужен (добавление новых заданий).
Постобработка:
```
var taskIDs = new List<object>();

async Task FillTasksAsync(Guid taskID)
{
    var card = await this.GetCardObjectAsync();
    foreach(var revokeTask in card.Tasks.Where(t => t.ParentRowID == taskID))
    {
        taskIDs.Add(revokeTask.RowID);
        FillTasksAsync(revokeTask.RowID);
    }
};

await FillTasksAsync(Task.RowID);

Signal.TaskIDs = taskIDs;
```
В сценарии постобработки рассчитывается список ID заданий taskIDs, которые необходимо отозвать. Это необходимо делать в постобработке, т.к. действие управления заданием очищает список заданий taskIDs для обработки (по умолчанию управление применяется ко всем заданиям). Для получения ID завершаемого задания используется свойство Task.
В блоке Постобработка отметить флаг Выполнять на любой сигнал.
Тип управления: Завершить задание.
Вариант завершения: Отозвать.

Данное действие будет заниматься отзывом дерева всех дочерних заданий.

Следующим шагом будет настройка узлов действий Согласование 1-3.

Для этих узлов в варианты завершения Согласовать и Не согласовать нужно добавить переход на узел Доп. согласование, а в сценарий добавить следующее:

Signal.Revoke = true;

Также в эти действия нужно добавить новый вариант завершения Запросить дополнительное согласование с переходом на узел Доп. согласование.

Таким образом при завершении задания с данным вариантом завершения будет осуществлена отправка заданий на доп. согласование на исполнителей, указанных в секции WfResolutionPerformers, а при завершении заданий с другим вариантом завершения будет производиться отзыв отправленных, но не завершенных, заданий доп. согласования.

Пример согласования договора с действиям из группы Маршруты¶

В этом разделе рассматривается пример реализации процесса в Workflow Engine, описанного в примере Инициация нового договора в Руководстве администратора, реализованного с использованием средств подсистемы маршрутов.

Ниже представлена общая схема процесса.

Описание процесса¶

Если договор дороже 100 000, то после запуска процесса он будет отправлен на согласование, если сумма договора не указана, то она считается меньше 100 000. В таком случае он сразу попадёт на подписание.
После успешного согласования он будет переведен в состояние На подписании руководителем и отправлен на подписание руководителю.
Затем договор будет переведен в состояние На подписании контрагенту и отправлен инициатору на организацию подписания контрагентом.
И в самом конце договор получит состояние Подписано сторонами.
Если кто-либо (руководитель или контрагент) не подписали документ, то после доработки документ вновь уйдет на подписание, а не на полный цикл согласования с прохождением всех согласующих.

Пример процесса настроен так, что один и тот же сотрудник выполняет все роли процесса. Это сделано для удобства демонстрации. В реальной жизни все эти роли выполняют разные люди.

После импорта бизнес-процесса его можно проверить, создав карточку довогора. В ней в меню системы появится пункт Согласование договора, который при выборе запускает процесс.

В зависимости от суммы договора он будет отправлен либо на согласование, либо на подписание. В этом примере сумма договора не заполнялась, потому пользователю придёт задание на подписание.

Состояние карточки изменилось на На подписании руководителем. Состояние карточки можно посмотреть на основной вкладке карточки и на вкладке Маршрут.

Когда задание у сотрудника на подписании, он может сделать всё, что предусмотрено возможностями этапа подписания: подписать и отказать в подписании, запросить дополнительные комментарии или делегировать задание. После подписания процесс перейдёт к следующему этапу.

Следующее задание, которое придёт пользователю - задание инициатору на организацию подписания контрагентом. Состояние карточки изменилось на На подписании контрагентом.

При отказе пользователю придёт задание доработки, а состояние карточки изменится на На доработке.

Можно просмотреть содержимое листа согласования. Действия из группы Маршруты формируют такой же лист согласования, как и при использовании подсистемы маршрутов.

После взятия в работу задания доработки и нажатия кнопки Начать новый цикл система начнёт новый цикл согласования, задание снова окажется на подписании руководителем.

Чтобы успешно завершить процесс, нужно взять задание в работу и нажать Подписать в этом задании и в следующем задании на организацию подписания контрагентом. Процесс завершится и состояние карточки изменится на Подписано сторонами.

При инициации договора с большой суммой порядок согласования изменится. Его можно просмотреть через меню системы: Действия -> Процессы -> Согласование договора:

Текущее действие Согласование внутри компании выполняет последовательное согласование ролями Руководитель инициатора и подразделением Финансовый департамент.

Если cогласовать документ, а затем сделать это еще раз в следующем задании, то документ попадёт на этап подписания внутри компании - сначала руководителем, а затем и контрагентом.

Все аспекты этого процесса реализованы при помощи механизма бизнес-процессов.

Создание процесса¶

Рассмотрим процесс создания описанного процесса.

Карточка шаблона бизнес-процесса настроена следующим образом:

Название: Согласование договора.
Группа: Примеры.
Флаги Запуск из карточки и Можно запускать несколько экземпляров оставлены без изменений.
Типы карточек: Договорной документ;
Расширение проверки доступа для кнопок (плиток) Проверка состояния. Это позволяет в кнопке бизнес-процесса указать состояние, при котором она будет доступна;
Кнопка бизнес-процесса настроена следующим образом:

Все узлы схемы данного процесса содержат по одному действию. Соответствие наименования узлов и действий приведено в следующей таблице.

Заголовок узла	Действие
Старт процесса	Старт процесса
Инициализация маршрута	Инициализация маршрута
Управление историей	Управление историей
Сумма договора	Условие
Согласование внутри компании	Согласование
На подписании руководителем, На подписании контрагентом, Подписано сторонами	Смена состояния
Подписание руководителем, Подписание контрагентом	Подписание
Доработка после отказа в согласовании, Доработка после отказа в подписании	Доработка
Конец процесса	Конец процесса

Для действия Инициализация маршрута не задано никаких параметров, отличных от значений по умолчанию.

Все действия типа Управление историей в данном процессе имеют следующие параметры:

Параметры Группа истории заданий и Родительская группа привязаны к параметрам процесса Process.HistoryGroup и Process.ParentHistoryGroup соответственно и имеют следующие значения: Согласование - цикл, Согласование.

Note

Для правильной инициализации маршрута необходимо размещать действие Инициализация маршрута перед любыми действиями из группы Маршруты.
Для корректного формирования истории заданий при переходе к новой итерации, аналогично используемой по умолчанию в подсистеме маршрутов, необходимо размещать действие Управление историей перед действием Доработка.

Для корректного формирования истории заданий на первом цикле, надо перед любым действием, отправляющим задания, добавить действие Управление историей. Действие Управление историей достаточно добавить один раз в начале маршрута, что обеспечит создание группы истории заданий: Согласование → Согласование - цикл 1 (аналог этого действия в маршрутах - этап Управление историей из шаблона этапов Новая итерация согласования).

Более подробно про особенности действий из группы Маршруты см. в разделе Особенности действий.

Для организации ветвления процесса, в зависимости от суммы договора, в процессе присутствует действие типа Условие имеющее два условия перехода:

Сумма договора задана и больше или равна 100 000 или не задана.

Переход в этом случает определяется по сценарию:

#script

if((await this.GetCardObjectAsync()).Sections.TryGetValue("DocumentCommonInfo", out var dCISection))
{
    return dCISection.Fields.TryGet<decimal?>("Amount") >= 100_000;
}

return false;

Сумма договора меньше 100 000.

Для реализации этого условия достаточно установить флаг Выполнять, если все другие условия не выполнены.

Результат показан на следующем рисунке.

Узел Согласование внутри компании включает одно действие типа Согласование. Затем процесс переходит на подписание руководителем. Из-за того, что необходимо выставить специальное состояние документа На подписании руководителем, а не использовать стандартное На подписании, используется действие типа Смена состояния, изменяющее состояние документа на требуемое.

Для реализации подписания руководителем используется действие типа Подписание. Флаг Изменять состояние при старте снят, иначе, при начале выполнения действия, состояние документа изменится на На подписании. Флаг Изменять состояние при завершении снят, т.к. в текущем процессе должно быть выставлено специальное состояние На подписании контрагентом, и он ни на что не влияет.

Действие, реализующее подписание контрагентом, настроено аналогично действию подписания руководителем. После подписания состояние документа изменяется на Подписано сторонами в действии типа Смена состояния.

Для реализации доработки при отклонении на этапе подписания руководителем или контрагентом используется действие типа Доработка, настроенное аналогично действию в узле Доработка после отказа в согласовании.

Note

Бизнес-процессы в TESSA можно настроить разными способами, в том числе используя методы системы и сложные сценарии. С примерами создания и работы таких процессов можно ознакомиться в руководстве разработчика.