Введение

Идея данного решения появилась довольно давно, поскольку в своем большинстве, модификации регламентов ограничиваются добавлением каких-то «кастомных» условий или вычисляемых ролей. Разработка, подобного рода, "однотипного" функционала порой отнимает весомую часть времени, особенно у новичков.

Сократить затраты, на модификации, глобально, можно двумя способами:
1) Подробно описать порядок внесения изменений в регламенты, чтобы разработчик не тратил время на анализ работы регламента и разных схем вызовов того или иного функционала и выполнял свою работу быстрее, что сократит общее время решения задачи.
2) Реализовать решение, которое позволит переложить разработку "типовых" кейсов в плоскость NoCode, т.е. банальной настройки.

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

А еще время! В лучшем случае все стадии, от проектирования, до переноса, можно пройти за "сутки" и это будет почти идеально, а можно и на неделю удовольствие растянуть или больше. То специалисты загружены, то перенос никак не согласуют...
Не мне Вам рассказывать.

Второй NoCode вариант, в техническом плане и универсальности, всегда будет уступать первому, НО при этом имеет несомненный плюс, а именно, сокращение временных затрат.
Разных реализаций, подобного рода решений написано довольно много, это и настроечные справочники, и модификации этапов согласования, целый зоопарк.

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

Описание решения

Решение "Конструктор условий и ролей в регламентах" реализовано по принципу NoCode и представляет собой конструктор позволяющий собрать условие или вычисляемую роль, без написания кода. Фактически, пользоваться решением может любой пользователь, как на этапе внедрения, так и на этапе эксплуатации системы.

Единственное требование - это знание системы, о чем станет понятно ниже из описания.

Логически решение разбито на 2 блока:

• Конструктор условий;
• Конструктор вычисляемых ролей.

Конструктор условий

На обложке модуля "Документооборот" появилась ссылка на справочник "Пользовательские условия."

Рис. Обложка модуля "Документооборот"

Чтобы условием можно было воспользоваться в регламентах, необходимо создать и настроить запись справочника "Пользовательские условия".

Рис. Карточка записи справочника "Пользовательские условия"

На выбор доступно три типа условий:
- Основной документ (для вычислений будут использоваться свойства основного документа регламента);
- Регламент (для вычислений будут использоваться свойства регламента);
- Вложения регламента (проверяется наличие заданных документов в задаче).

Рис. Поле выбора типа условия с доступными вариантами

Тип условия - Основной документ

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

Рис. Диалог добавления условия

Для выбора доступны следующие типы свойств и условий:

• Логическое свойство (Доступные проверки: Да, Нет, Да или Пусто, Нет или Пусто, Пусто);
• Целочисленное или дробное число (Доступные проверки: >, <, ≥, ≤, Равно, Пусто);
• Строковое или текстовое свойство (Доступные проверки: Равно, Не равно, Содержит, Не содержит, Пусто);
• Перечисление (Доступные проверки: Равно, Не равно, Пусто);
• Свойство ссылка на объект (Доступные проверки: Равно, Не равно, Пусто, Дочернее свойство);
• Свойство ссылка с типом Сотрудник или Пользователь (Доступные проверки: Равно, Не равно, Входит в роль, Входит в роль согласования, Есть помощник, Пусто, Дочернее свойство).

Описание проверок:

• Равно - значение свойства совпадает с заданным или выбранным значением;
• Не равно - значение свойства не совпадает с заданным или выбранным значением;
• Пусто - значение свойства равно Null или string.Empty;
• Да - значение логического свойства равно True;
• Нет - значение логического свойства равно False;
• Да или Пусто - значение логического свойства равно True или Null;
• Нет или Пусто - значение логического свойства равно False или Null;
• > - значение числа строго больше заданного значения;
• ≥ - значение числа больше или равно заданному значению;
• < - значение числа строго меньше заданного значения;
• ≤ - значение числа меньше или равно заданному значению;
• Входит в роль - сотрудник/пользователь входит в заданную роль справочника "Роли";
• Входит в роль согласования - сотрудник/пользователь входит в заданную роль согласования регламента;
• Есть помощник - у сотрудника/пользователя указан помощник в справочнике "Ассистенты руководителей";
• Дочернее свойство - позволяет обратиться к свойствам объекта для добавления дочерних (нижестоящих) условий.

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

Ниже в спойлерах приведены примеры диалоговых окон добавления условий.

Рис. Пример заполненного условия
 

Для комбинации группы условий доступно объединение через "И", "ИЛИ".

Рис. Пример группы условий

Условия "первого" уровня комбинируются с использованием свойства "Объединение" на форме карточки. 
Для изменения комбинации дочерних условий нужно открыть головное условие на редактирование.

Рис. Пример редактирования условия
 

Тип условия - Регламент

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

Рис. Простой пример настройки условия из регламента.

Тип условия - Вложения регламента

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

Рис. Добавление условия по группе вложения.

Рис. Пример добавления условия для проверки по типу документа.

Для выбора доступны следующие виды условий:

• Содержит тип документа - проверяет, содержит ли выбранная группа вложений, документ с указанным типом;
• Содержит вид документа - проверяет, содержит ли выбранная группа вложений документ с указанным видом.

К каждому головному условию "Содержит тип/вид документа" можно добавить дочернее условие проверки.

Рис. Пример условий для проверки вложений регламента.

Настройка блока условия регламента

Для выбора настроенного условия в блоке "Условие" правила согласования, в поле "Тип условия" необходимо выбрать значение "Пользовательское условие" и заполнить соответствующее поле нужным значением.

Внимание: доступность блоков условий с типом "Основной документ" фильтруются по типам документов из ВЭД-ов, указанных в поле "Виды документов" правила согласования.

Рис. Пример заполнения блока "Условие" правила согласования

Конструктор вычисляемых ролей

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

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

Рис. Обложка модуля "Документооборот"

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

Рис. Карточка записи справочника "Пользовательские роли согласования"

На выбор доступно два типа вычисления роли:
- Из основного документа (для вычислений будут использоваться свойства основного документа регламента);
- Из регламента (для вычислений будут использоваться свойства регламента).

Рис. Поле выбора типа роли с доступными вариантами

Тип роли - Из основного документа

При добавлении условия по основному документу в диалоге доступны только общие свойства выбранных типов документов.
Если необходимо получить уникальное свойство из конкретного типа документа, то в поле "Типы документов" необходимо выбрать только один тип.

Рис. Диалог добавления блока

Рис. Диалог добавления дочернего блока

Для выбора доступны следующие типы свойств и условия:

• Свойство ссылка на объект;
• Свойство ссылка с типом Сотрудник или Пользователь;
• Свойства коллекции.

Рис. Пример заполненной вычисляемой роли

Тип роли - Из регламента

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

Рис. Пример настройки вычисляемой роли из регламента.

Дополнительно

В поле "Запасной сотрудник" можно указать сотрудника, которому придет задание, если какое-то поле в цепочке вычислений не заполнено и получить исполнителя/исполнителей не удалось.

Настройка этапа регламента

Вычисляемые роли доступны во всех этапах согласования регламента, где есть возможность указать роль согласования: Согласование с руководителем, Согласование, Подписание, Рассмотрение адресатом, Задание и т.д.

Для выбора вычисляемой роли в соответствующем этапе в свойстве "Роль согласования" или "Роли согласования" выбрать значение "Пользовательская роль" и заполнить соответствующее свойство (пример: Пользовательская роль) нужным значением.

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

Ролей с типом "Из основного документа" фильтруются по типам документов из ВЭД-ов, указанных в поле "Виды документов" правила согласования.

Рис. Пример использования вычисляемых ролей в этапе с типом "Задание"

Ограничения

Пройдемся по ограничениям, куда же без них.

1. Типы свойств, недоступные для выбора, в конструкторе условий: Дата, Дата и время, Коллекция, системные типы вроде BinaryData, Component, Image.
2. При настройке ролей, если конечный тип свойства-ссылки является абстрактным, то такие свойства будут недоступны для выбора в диалоге конструктора (Пример: свойство Проект, в карточке документа Приказ). 
3. В конструкторах (особенно в условиях), в списках свойств разных объектов могут попадаться системные реквизиты, чтобы убрать их из списка, нужно перекрыть функцию GetExcludeProperties() соответствующего справочника.
4. Текущая реализация решения работает на версии RX 4.1 и выше (адаптация под версии ниже 4.1 будет позже).

Заключение

На текущий момент это первая версия решения, которая тестируется на проектах СТАРКОВ Групп.
Со временем функционал решения должен расшириться, т.к. начальный backlog развития уже сформирован.

Решение призвано расширить функциональность регламентов и сократить затраты на разработку "однотипного" функционала, в рамках его текущих функциональных возможностей, конечно.

Технические вопросы Вы можете задать в комментариях к статье.
По остальным вопросам, Вы можете обратиться к нашему руководителю отдела продаж Хрусталеву Георгию Викторовичу.
E-mail: hrustalev@starkovgrp.ru
Телефоны: +7 (343) 385-75-85 (106), +7 (922) 119-49-48.

Другие наши решения

Решение "Перенос данных"
Решение "Вспомогательные инструменты" (Service Kit)