Алгоритм для вычисляемого срока этапов БП - как вызвать из алгоритма?
Коллеги, привет!
Как в бизнес процессах вызвать алгоритм для вычисляемого срока этапов БП - из другого алгоритма? Не в настройке этапа БП.
Поясню. У нас доработка учета задач бизнес подразделения. В рамках доработки от системного типа: ДО. Задача на процессе, унаследован свой тип-потомок.
Этот тип подключен на нужных этапах заданных БП, как Тип объекта генерируемой задачи.
И задачу автоподбора и смены исполнителя решили функцией setTaskExecutor, вызовом из алгоритма на ЖЦ после сохранения типа-потомка от ДО-задачи. Поскольку вызовы алгоритма по выбору Ответственного из настройки этапа происходили раньше, чем создавался объект ручной задачи (пользователю).
Аналогично, алгоритм для вычисляемого срока выполнения этапа, если указать его в настройках этапа, вызывается ДО создания объекта типа-потомка от ДО-задачи.
А нужно, чтобы алгоритм для вычисляемого срока вызывался после создания объекта ручной задачи - этого можно добиться вызовом из алгоритма ЖЦ после сохранения задачи. Но нужна функция для замены вычисляемого срока из алгоритма.
Комментарии
Добрый день! Подготовим ответ
Коллеги, привет! Приложенным СКЛ запросом, кажется, удалось получить все значения полей для обновления планового норм срока. В СКЛ скрипте (Скрипт СУБД (SQL, PL/SQL, T-SQL и др)) были использованы эти расчеты для обновления полей.
Добрый день!
Большое спасибо за Ваш кейс и за предложение по его решению.
Если будет возможность, можете чуть подробнее описать и ответить на вопросы:
1. Каким образом связано назначение исполнителя по задаче и определение нормативного срока?
2. Правильно ли понимаем, что в алгоритме, который выбираете в поле "Алгоритм для вычисляемого срока", нормативный срок зависит от того, кто назначается исполнителем?
3. Если бы исполнитель назначался не с помощью ЖЦ после сохранения, а базовыми настройками, нормативный срок рассчитывался бы корректно?
Ответы на эти вопросы помогут понять нам, нужно ли прорабатывать дополнительные настройки для реализации подобных кейсов прикладными средствами.
Коллеги, привет!
Вероятно, у нас нетипичный кейс. Или особенность архитектуры типов.
В модуле трекаются задачи бизнес-подразделения. С автоподбором исполнителя.
Для этого от системного типа задач в БП (ДО. Задача на процессе, WF_PROCESS_TASK) порожден тип-потомок. Он используется в настройках этапов БП, как Тип объекта генерируемой задачи.
И есть другой тип - Задание, 1 объект на 1 запуск инстанса БП. По сути, это аналог Инициируемый тип объекта для БП (тип тоже есть, с другим набором полей). Задача ссылается на Задание. Задание ссылается на различные справочники.
Особенность нашей реализации в том, что в ЖЦ нашего типа-потомка от Задачи идет основная обработка в алгоритмах. Т.е. без объекта ручной задачи некуда привязать обработку. Поэтому наша реализация привязана к объектам ручных задач.
Нормативный срок зависит не от исполнителя, а от 3-х справочников, к которым привязано Задание.
Назначение нормативного срока базовыми настройками, и алгоритма сервисного действия - идет по другому объекту, нежели ручная задача, и вызывается до создания объекта Задачи - в нашей реализации это не сработает.
Добрый день!
Спасибо за подробное описание. Попробовали сделать аналогичные настройки, есть еще вопрос по тому, каким образом создаете экземпляры типа "задание".
Правильно понимаем, что они создаются автоматически алгоритмом уже в момент создания прикладной задачи с помощью newinstance?
Этот алгоритм тоже добавлен на ЖЦ?