Каждый документ имеет маршрут движения в соответствии с бизнес процессом - Контакты компаний и предприятий на Atlaso.ru

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

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

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

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

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

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

обработку входящей информации;
обработку исходящей информации.

Процессы, связанные с обеспечением деятельности и организационно-распорядительной деятельностью организации, предполагают обработку внутреннего документопотока организации.
В процессе движения документов с использованием систем электронного документооборота (СЭД), например, «1С:Документооборот» , выполняются в общем случае следующие операции:

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

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

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

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

После проведения детального анализа существующего графика документооборота, исключения дублирующих функций и проектирования новой системы документооборота в виде схем/графиков, утверждаемых руководством предприятия, и внедрения автоматизированной системы (СЭД) следует обратить внимание на локальные нормативные документы организации. Отсутствие формализованного документооборота и регламентов для пользователей не заставит их работать. Мало кто любит писать отчеты и быть контролируемым. Поэтому, чтобы добиться результата, надо для работников предприятия четко прописать «правила игры» и утвердить их в виде приказов, положений и инструкций.

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

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

2. Разработка стандартов.
Разработка стандартов позволит стандартизировать процессы в соответствии с последними требованиями законодательства и с учетом специфики деятельности предприятия. Кроме того, она создаст эффективный инструмент работы с конкретным типом документов (например, инструкциями по делопроизводству), поддерживающий процессы и позволяющий в короткие сроки обучать персонал и перераспределять функции между работниками службы документационного обслуживания управления (ДОУ).

3. Разработка регламентов деятельности работников.
По каждому рабочему месту службы ДОУ разрабатывается регламент деятельности конкретных работников, включающий в себя:

перечень функций работника по ведению делопроизводства и документооборота;
перечень и процедуры обработки документов;
перечень формируемых отчетных документов;
сроки получения и предоставления документов.

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

Использование СЭД позволяет к тому же создать простой и эффективный механизм формирования всех видов отчетов, повышает надежность хранения электронных образов входящих, исходящих и внутренних документов, а также — электронный архив документов.

Источник

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

С точки зрения специалистов ИТ-службы документы представляют мощный информационный поток, который можно автоматизировать двумя способами. В первом случае прохождением и хранением документов занимаются специализированные системы. Например, прохождение стандартных бухгалтерских документов может автоматизироваться в управленческой информационной системе (1С, Галактика), работа с конструкторско-технологической документацией — в PLM-системе (Лоцман:PLM, T-FLEX DOCs). Но в компании всегда есть набор документов, которые не «ложатся» в одну из существующих информационных систем (ИС). Это могут быть внутренние отчеты, организационно-распорядительная, проектная и другая документация. В этом случае, движение документов может быть автоматизировано только с помощью специализированных систем электронного документооборота с поддержкой технологии workflow (например, OPTiMA-WorkFlow).

Методологию внедрения подобных систем, созданную на основе опыта специалистов ГК «Современные технологии управления» (biztech.ru) (г. Самара), как консультантов по управлению, и специалистов компании Upscale Soft (upscalesoft.ru), осуществляющих разработку и внередние системы «OPTiMA-WorkFlow» (optima-workflow.ru), мы и предлагаем рассмотреть в этой статье.

Формализация документооборота — способ повысить эффективность внедрения СЭД

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

Директор по разработке и внедрению компании UpScale Soft Ефим Старостин так комментирует сложившуюся на ситуацию: «Внедряя OPTiMA-WorkFlow в крупных организациях, мы часто сталкиваемся с проблемой недостаточного понимания важности формализации документооборота, что приводит к различным негативным последствиям, например, к частой переделке маршрутных схем движения документов… В редких случаях мы опираемся на готовые модели бизнес-процессов, созданные на базе систем бизнес- моделирования, благодаря чему резко сокращаются сроки внедрения и возрастает отдача от системы документооборота…»

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

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

К сожалению, важный этап по формализации документооборота является самым «нелюбимым» у ИТ-специалистов, что проявляется в сдвиге этого этапа в середину проекта и концентрации на сугубо «технических» аспектах. Действительно, приобретение и ввод в эксплуатацию серверов, установка и настройка программного обеспечения уже не вызывает сложностей, а проведение обследования своей собственной компании еще вызывает проблемы. Это связано с незнанием формальных методологий формализации документооборота, а также с тем, что еще не каждая компания имеет в штате бизнес-аналитиков — специалистов по этому виду деятельности.

Подходы к формализации документооборота

Выбор способа формализации документооборота зависит от стратегии развития ИТ-службы и от уровня зрелости компании в целом. Можно выделить два подхода к описанию маршрутов прохождения документов: «от документов» и «от процессов».

Описание документооборота «от документов» исторически является наиболее распространенным и широко используется при внедрении СЭД. При таком подходе во главу угла ставится сам документ и его перемещение между исполнителями. Описание маршрута прохождения внутреннего документа, как правило, выглядит следующим образом: Разработка проекта документа — Согласование документа — Доработка документа -Отправка (или Сдача в архив) документа. Причем стадии «Согласование документа» и «Доработка документа» могут повторяться до тех пор пока не будут устранены все замечания.

Для формализации таких маршрутов могут использоваться любые доступные средства — все должно определяться принципом достаточности для решения поставленной задачи. Самым простым вариантом является разработка схем движения документов в виде обычных графических блок-схем (Рис. 1). Каждая компания может разработать свой собственный способ отображения или заимствовать его у компании, оказывающей услуги по внедрению СЭД, главное — чтобы схемы были понятны сотрудникам компании и позволяли в дальнейшем провести настройку системы.

Плюсами такого подхода является минимальное время разработки методологии формализации документооборота, легкое понимание сотрудниками компании формализованных схем движения документа. Но, если компания планирует внедрение автоматизированных систем управления бизнес-процессами с помощью технологии Workflow, то необходимо использование уже более мощных средств описания маршрутов. В качестве такого средства можно использовать нотацию графического моделирования IDEF3, позволяющую описать сценарий обработки документа с большой точностью. Нотация IDEF3 содержит все необходимые графические элементы для отображения параллельной или последовательной работы с документом, а также дополнительных условий, например, таких как: «выполнение следующих функций должно начаться строго одновременно» или «может начать выполняться только одна из следующих функций».

Минусом применения этой нотации является то, что на самой диаграмме не видно, кто из сотрудников выполняет ту или иную функцию по обработке документа. Чтобы выйти из этой ситуации, можно название должностей сотрудников указывать непосредственно в названии функции (Рис 2). Также, к сожалению, практика показала, что эта нотация, идеальная с точки зрения ИТ-специалистов, является слишком сложной для сотрудников предприятия. Это может привести к формальному утверждению технического задания на внедрение СЭД, но в последствии — к корректировке маршрутов движения документов уже на этапе внедрения системы.

Применение технологий бизнес-моделирования

Описанный подход позволяет внедрить СЭД и минимизировать затраты и риски проекта, проектная документация ИТ-службы при этом пополняется еще одним документом, содержащим еще один срез описания деятельности компании. Главным недостатком такого подхода при его несомненной простоте является отсутствие информации о самом бизнес-процессе, который призван поддержать рассматриваемый документ. Поэтому полученной информации, нужной и достаточной для внедрения СЭД, начинает не хватать, когда возникают задачи изменить содержание документа, оптимизировать маршрут прохождения документа или вообще отказаться от его использования. Это невозможно сделать без анализа дополнительной информации, для этого необходимо знать:

Какие еще документы используются в бизнес-процессе;
Какие функции, помимо функций обработки документа, входят в бизнес-процесс;
Какие сотрудники задействованы при выполнении всех функций бизнес-процесса.

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

Анализ и принятие взвешенного решения о способе автоматизации бизнес-процессов компании. Возможными способами могут стать, как уже говорилось выше: автоматизация с помощью управленческой информационной системы, внедрение PLM-системы, системы документооборота или workflow или вообще отказ от автоматизации, если решить задачу можно за счет простого изменения бизнес-процесса;
Формирование маршрутов документооборота, на основе содержащейся в модели информации;
Разработка технических заданий на внедрение информационных систем с использованием диаграмм бизнес-процессов;
Формирование инструкций пользователя по работе с информационной системой путем дополнения бизнес-процессов функциями по работе в ИС (занесение данных в систему, получение отчета, и т. п.). В результате становится возможным получение реестра функций ИС и включение регламента работы с ИС непосредственно в должностные инструкции исполнителей.

Система бизнес-моделирования Business Studio

На сегодняшний день для создания модели деятельности компании целесообразно использовать специализированные системы бизнес-моделирования, позволяющие решать широкий круг задач: описание бизнес-процессов и организационной структуры, создание реестра документов компании, формирование отчетов и регламентных документов, в том числе и отчета по документообороту. Например, в системе бизнес-моделирования Business Studio (businessstudio.ru) описание бизнес-процессов и документооборота происходит одновременно. Если в рамках процесса происходит работа с документом (создание, изменение, использование), то документ указывается с помощью входящей или исходящей из функции стрелки, а исполнитель функции закрепляется автоматически при расположении функции в соответствующей дорожке на кросс-функциональной диаграмме (Рис. 3).

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

Процесс	Ответственный	Требования к срокам	Поступления	Передача
Процесс	Ответственный	Процесс	Ответственный
A2.1.1.8 Поставка инструмента	Поставщик	Согласно условиям договора			A2.1.1.9 Получение инструмента и сопроводительной документации. Проверка инструмента на соответствие требованиям	Менеджер по инструменту
A2.1.1.9 Получение инструмента и сопроводительной документации. Проверка инструмента на соответствие требованиям	Менеджер по инструменту	Согласно условиям договора	A2.1.1.8 Поставка инструмента	Поставщик	A2.1.2.1 Формирование приходного материального ордера. Подписание накладной на инструмент	Кладовщик
A2.1.2.1 Формирование приходного материального ордера. Подписание накладной на инструмент	Кладовщик	В течение 20 мин.	A2.1.1.9 Получение инструмента и сопроводительной документации. Проверка инструмента на соответствие требованиям	Менеджер по инструменту		Бухгалтер
A2.1.2.3 Регистрация приходного ордера	Бухгалтер	В течение одного часа.	A2.1.2.1 Формирование приходного материального ордера. Подписание накладной на инструмент	Кладовщик
A2.1.2.4 Прием инструмента на склад. Отметка о приеме в журнале учета движения инструмента	Кладовщик	Не более 20 мин.	A2.1.2.1 Формирование приходного материального ордера. Подписание накладной на инструмент	Кладовщик

Таблица 1. Регламент прохождения документа «Гарантийный талон», сформированный в системе Business Studio

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

№	Изменения в бизнес-процессах	Отражение в документообороте
1	Изменен ответственный за выполнение функции.	В маршруте движения документа необходимо изменить исполнителя.
2	Изменена структура бизнес-процесса.	Изменился маршрут прохождения документа.
3	Документ перестал использоваться в компании.	Исключение документа из документооборота.
4	Появился новый бизнес-процесс, что повлекло за собой появление нового документа.	Разработка и ввод в действие: Формы документа; Маршрута документа.

Таблица 2. Изменения в бизнес-процессах и их отражение в документообороте

Все произошедшие изменения необходимо отразить в регламентных документах компании и провести настройку СЭД. Компаниям, которые изначально пошли по пути создания модели бизнес-процессов, отреагировать на такие изменения значительно проще — достаточно актуализировать модель и заново сформировать отчет о документообороте и другие регламентные документы. В случае же, когда подсистема документооборота рассматривается отдельно, необходимо спроектировать новые маршруты движения документов вручную, что обычно приводит к дополнительным затратам времени и непредсказуемому качеству результата.

Недостатками этого подхода являются более высокая трудоемкость описания, так как требуется описать все функции бизнес-процесса, а не только функции, связанные с обработкой документа, и возможность применения в условиях достаточно зрелой организации, в которой существуют устоявшиеся бизнес-процессы. Преимуществом же является получение одной связанной модели системы управления компанией, включающей бизнес-процессы, организационную структуру, документы и используемые информационные системы. Такая модель, разработанная в Business Studio, позволит более эффективно осуществить выбор и настройку СЭД, а на этапе внедрения автоматически сформировать и передать пользователям регламенты работы в информационной системе. Также полученная модель поможет ИТ-службе хорошо изучить работу своей компании, а значит и общаться с руководителями и сотрудниками других подразделений на одном языке.

Компаниям, задумывающимся о внедрении систем электронного документооборота и стремящимся формализовать работу с документами, можно порекомендовать изначально ставить задачу более широко — полностью формализовать свою деятельность, а не только документооборот. Конечно, на это потребуется больше времени, но и эффекта от такого подхода будет значительно больше: ИТ-специалисты получат описание документооборота компании для настройки СЭД, топ-менеджеры — формализованную систему управления, а сотрудники компании — актуальные регламентные документы.

Опубликовано по материалам:
Журнал «BYTE / Россия», № 6 2006

Июнь 2006 г.

13.1. Основные понятия

Бизнес-процессы в системе «1С:Предприятие» предназначены для объединения отдельных операций в цепочки взаимосвязанных действий, приводящих к достижению конкретной цели. Например, цепочку по выписке счета, приему наличной оплаты и отпуску товара со склада можно представить как бизнес-процесс Продажа товара за наличный расчет.

Бизнес-процессы в системе «1С:Предприятие» позволяют формализовать процедуры обработки тех или иных событий, возникающих в деятельности организации, и обеспечить участие в них исполнителей.

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

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

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

Цепочки взаимосвязанных действий бизнес-процесса представляются с помощью карты маршрута бизнес-процесса. Карта маршрута описывает логику бизнес-процесса и весь его жизненный цикл от точки старта до точки завершения в виде схематического изображения последовательности прохождения взаимосвязанных точек маршрута.

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

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

Задачи в системе «1С:Предприятие» позволяют вести учет заданий по исполнителям и служат отражением продвижения бизнес-процессов по точкам маршрута. При этом задачи могут создаваться не только бизнес-процессами, но и другими объектами информационной базы, и непосредственно пользователями.

13.2. Общая часть

Механизм бизнес-процессов в системе «1С:Предприятие» обеспечивается сразу несколькими объектами конфигурирования:

● Бизнес-процессы,

● Задачи,

● Регистр сведений,

● Параметр сеанса.

Как правило, типы реквизитов адресации задачи и измерений регистра сведений имеют ссылочный тип (например, СправочникСсылка, поэтому к четырем вышеперечисленным видам добавляются еще справочники).

Рис. 425. Схема бизнес-процессов

Основные объекты ‑ бизнес-процессы и задачи ‑ взаимодействуют друг с другом (например, бизнес-процесс создает задачи, а задача в процессе выполнения приводит к продвижению его по маршруту).

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

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

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

13.3. Маршрутизация

Бизнес-процессы в системе «1С:Предприятие» допускают следующие виды маршрутизации:

● Жесткая. Бизнес-процесс имеет строгую карту маршрута, не включающую в себя условных и параллельных переходов, с жестко определенными адресатами для каждой точки маршрута. Данный вид не допускает свободной и условной маршрутизации.

● Свободная. Адресаты точки карты маршрута бизнес-процесса не установлены и определяются программно или интерактивно в течение жизненного цикла бизнес-процесса.

● Условная. Карта маршрута предусматривает проверку условий и переход по соответствующим ветвям. Переходы могут быть как бинарными (условие), так и множественными (выбор варианта).

● Параллельная. Карта маршрута предусматривает разделение бизнес-процесса на параллельные ветви с возможностью последующего слияния (ожидания). Продвижение бизнес-процесса по каждой из параллельных ветвей происходит независимо по мере выполнения соответствующих задач.

Как правило, в реальных картах бизнес-процессов встречаются все эти типы маршрутизации.

13.4. Система адресации

Ключевым понятием в механизме бизнес-процессов и задач в «1С:Предприятии» является система адресации. Основное назначение системы адресации ‑ обеспечить возможность не только персональной, но и ролевой адресации задач участникам бизнес-процессов.

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

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

Определение конкретного исполнителя осуществляется с помощью свойств задачи ‑ Адресация, Основной реквизит адресации и Текущий исполнитель.

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

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

Один из реквизитов адресации задачи является основным и означает конкретного сотрудника ‑ исполнителя заданий.

Рис. 426. Схема адресации

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

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

Роль	Сотрудник
Кассир	Иванов
Менеджер	Петров

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

Свойство задачи	Значение
Наименование	Принять наличную оплату
Роль	Кассир
Сотрудник	–

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

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

1. Будем исходить из того, что выбрана 3-мерная система адресации ‑ сотрудник, роль, подразделение.

2. Создадим справочники для каждого из планируемых измерений адресации (Сотрудники, Роли, Подразделения) и заполним их предопределенными значениями:

Сотрудники	Роли	Подразделения
Иванов	Кассир	Бухгалтерия
Петров	Менеджер	Отдел продаж
Сидоров	Руководитель отдела	Склад
	Кладовщик

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

Измерение	Тип
Сотрудник	СправочникСсылка.Сотрудники
Роль	СправочникСсылка.Роль
Подразделение	СправочникСсылка.Подразделения

4. Создадим параметр сеанса ТекущийИсполнитель и установим ему тип СправочникСсылка.Сотрудники.

5. Проинициализируем параметр сеанса при запуске системы:

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    Пользователь = Справочники.Сотрудники.
                    НайтиПоНаименованию(ИмяПользователя());
    ПараметрыСеанса.ТекущийИсполнитель = Пользователь;
КонецПроцедуры

1. Создадим задачу.

2. Установим созданный ранее регистр сведений в свойство задачи Адресация.

3. Добавим к задаче реквизиты адресации аналогично измерениям регистра сведений:

● Сотрудник,

● Роль,

● Подразделение.

4. Установим для созданных реквизитов адресации задачи тип в виде ссылки на соответствующий справочник и в свойстве Реквизиты адресации установим ссылку на измерение регистра сведений.

Реквизит адресации	Тип	Измерение адресации
Сотрудник	СправочникСсылка.Сотрудники	Сотрудник
Роль	СправочникСсылка.Роль	Роль
Подразделение	СправочникСсылка.Подразделения	Подразделение

5. Выберем реквизит Сотрудник в качестве основного реквизита адресации, установив его в соответствующем свойстве задачи.

6. Создадим первый бизнес-процесс и установим у него ссылку на созданную ранее задачу (свойство Задача).

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

Рис. 427. Карта бизнес-процесса

7. Создадим следующий бизнес-процесс и установим у него ссылку на эту же задачу.

8. Спроектируем маршрутную карту созданного бизнес-процесса. И так далее.

В дальнейшем будем использовать этот пример для комментирования ключевых особенностей бизнес-процессов в системе «1С:Предприятие».

Рассмотрим подробнее несколько ключевых особенностей механизма бизнес-процессов.

13.5. Старт бизнес-процесса

Бизнес-процесс стартует при вызове метода Старт() или нажатии кнопки Стартовать и закрыть в форме объекта.

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

БП = БизнесПроцессы.Согласование.СоздатьБизнесПроцесс();
БП.Дата = ТекущаяДата();
БП.Записать();
БП.Старт();

При старте выполняется следующая последовательность действий.

№	Внутренний механизм	Обработчики на встроенном языке
1		Вызов обработчика ПередСтартом у точки старта
2	Продвижение по карте маршрута до точки действия
3	Формирование задач (см. здесь)

Бизнес-процесс может быть записан, но не стартован. Это может оказаться полезным, если создание бизнес-процесса и его старт разделены во времени. Например, когда бизнес-процесс стартует при наступлении некоторого события.

13.6. Выполнение задач

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

№	Внутренний механизм	Обработчики на встроенном языке
1	Начало транзакции
2		Вызов обработчика ПередВыполнением у задачи
3		Вызов обработчика ПередВыполнением у соответствующей точки маршрута
4	Установка свойства Выполнена у задачи равным Истина
5		Вызов обработчика ПриВыполнении у задачи
6	Запись объекта задачи
7		Вызов обработчика ПриВыполнении у соответствующей точки маршрута
8	Переход бизнес-процесса на следующую точку маршрута
9	Формирование задач по новой точке маршрута (см. здесь)
10	Завершение транзакции

13.7. Разделение и слияние

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

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

Допускается вложенное разделение и слияние. При этом каждая точка слияния будет синхронизировать только ветки «своей» точки разделения.

ВНИМАНИЕ! Разделение может быть и без слияния. В этом случае бизнес-процесс будет иметь несколько параллельных ветвей до своего завершения.

Слияние без разделения не допускается, о чем выдается соответствующее сообщение при проверке карты маршрута: Не все линии, вошедшие в точку слияния, вышли из точки разделения.

13.8. Ручное управление

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

13.8.1. Признак завершенности бизнес-процесса

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

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

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

13.8.2. Признак выполнения задачи

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

Ручная установка признака выполнения может привести к остановке бизнес-процесса ‑ он не будет завершен, но по нему не будет ни одной невыполненной задачи.

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

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

13.8.3. Удаление задач

Если удалить невыполненные задачи незавершенного бизнес-процесса, то он может остановиться. Такой бизнес-процесс будет незавершенным, но по нему не будет ни одной активной (невыполненной) задачи.

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

Удаление всех задач для незавершенного бизнес-процесса переводит его в статус нестартованного.

13.8.4. Добавление задач

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

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

Создание новой задачи для уже стартовавашего и незавершенного бизнес-процесса приводит к его распараллеливанию.

13.9. Условный переход

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

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

Обработчик проверки условия может, например, иметь такой вид:

Процедура ОграничениеСкидкиПроверкаУсловия(ТочкаМаршрутаБП, Результат)
    Если ПолучитьСкидкуПоСчету() > ПолучитьОбычнуюСкидку() Тогда
        Результат = Истина;
    Иначе
        Результат = Ложь;
    КонецЕсли;
КонецПроцедуры

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

13.10.Выбор варианта

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

Этот обработчик должен установить параметр Результат равным одному из предусмотренных вариантов. Процедура-обработчик может иметь примерно такой вид:

Процедура ВыборВарианта (ТочкаВыбораВарианта, Результат)
    Если ВидОплаты = Перечисления.ВидОплаты.Наличная Тогда
        Результат = ТочкаВыбораВарианта.Варианты.Наличная;
    ИначеЕсли ВидОплаты = Перечисления.ВидОплаты.Безналичная Тогда
        Результат = ТочкаВыбораВарианта.Варианты.Безналичная;
    ИначеЕсли ВидОплаты = Перечисления.ВидОплаты.Взаимозачет Тогда
        Результат = ТочкаВыбораВарианта.Варианты.Взаимозачет;
    ИначеЕсли ВидОплаты = Перечисления.ВидОплаты.Кредит Тогда
        Результат = ТочкаВыбораВарианта.Варианты.Кредит;
    КонецЕсли;
КонецПроцедуры

В этом обработчике ВидОплаты ‑ реквизит бизнес-процесса.

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

13.11.Формирование задач

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

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

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

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

Сотрудник	Роль	Подразделение
Иванов	Кассир
Петров	Кассир

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

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

№	Внутренний механизм	Обработчики на встроенном языке
1	Начало транзакции
2		Вызов обработчика ПередСозданиемЗадач()
3	Формирование списка задач
4		Вызов обработчика ПриСозданииЗадач()
5	Запись всех сформированных задач
6		Вызов обработчика ПередЗаписью() у задачи
7	Запись задачи
8		Вызов обработчика ПриЗаписи() у задачи
9	Завершение транзакции

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

На третьем шаге бизнес-процесс проверяет, вернул ли предыдущий обработчик СтандартнаяОбработка = Истина. Если да, то производится разыменование установленных в точке маршрута реквизитов адресации и формируется одна задача или список задач (для групповой точки) по количеству результатов разыменования (например, количество сотрудников отдела). При этом каждой сформированной задаче устанавливается наименование, ссылка на бизнес-процесс и точку маршрута и соответствующие реквизиты адресации.

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

На пятом шаге проверяется нормальное завершение обработчика ПриСозданииЗадач(). Если обработчик в параметре Отказ вернул значение Истина, то процесс создания задач прерывается и вызывается исключение. В нашем случае это приведет к отмене выполнения метода Старт(). Если же Отказ = Ложь, то производится запись всех задач из сформированного массива с вызовом обработчиков ПередЗаписью() и ПриЗаписи() у каждой отдельной задачи (шаги 6 и 8 соответственно).

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

● Наименование устанавливается равным наименованию соответствующей точки маршрута, например Выписка счета.

● Ссылка на экземпляр бизнес-процесса, породившего эту задачу.

● Ссылка на точку маршрута бизнес-процесса.

● Реквизиты адресации задачи устанавливаются равными реквизитам адресации соответствующей точки маршрута. Например, если точка маршрута адресована роли Кассир, то в реквизит адресации задачи Роль будет установлено Кассир.

13.12.Проверка выполнения

Выполнение задач может осуществляться не только пользователями, но и автоматизированными процедурами. Например, если задача предусматривает проведение документа, то автоматическая процедура слежения за такими задачами может определять, что нужный документ уже проведен, и помечать задачу как выполненную путем вызова у нее метода Выполнить().

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

Рассмотрим последовательность действий, которая произойдет в результате работы следующего кода на встроенном языке.

Если Задача.ПроверитьВыполнение() Тогда
    Задача.ВыполнитьЗадачу();
КонецЕсли

№	Внутренний механизм	Обработчики на встроенном языке
1	Обработка вызова метода ПроверитьВыполнение()
2		Вызов обработчика ОбработкаПроверкиВыполнения() у задачи. Если Результат равен Ложь, то метод ПроверитьВыполнение() сразу возвращает Ложь
3		Вызов обработки ОбработкаПроверкиВыполнения() у соответствующей точки маршрута
4	Возврат результата вызова обработчика из предыдущего пункта и, если он равен Истина, вызов метода ВыполнитьЗадачу()

Описание одного из способов использования автоматизированного выполнения задач см. здесь.

13.13.Выполнение вложенных процессов

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

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

№	Внутренний механизм	Обработчики на встроенном языке
1	Начало транзакции
2		ПередСозданиемВложенныхБизнесПроцессов()
3		Вызов обработчика ПередСозданиемЗадач() для точки маршрута
4	Если СтандартнаяОбработка, то формируется массив задач
5		ПриСозданииЗадач()
6	Запись массива сформированных задач и создание массива вложенных бизнес-процессов
7		ПриСозданииВложенныхБизнесПроцессов()
8	Запись и старт сформированных бизнес-процессов
9	Завершение транзакции

Рассмотрим подробнее.

На втором шаге происходит вызов обработчика ПередСозданиемВложенныхБизнесПроцессов(), в котором можно добавить свои бизнес-процессы в массив формируемых бизнес-процессов (по умолчанию массив приходит пустым). Если были добавлены бизнес-процессы в массив, то стандартная механика генерации бизнес-процессов будет отменена.

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

На пятом шаге можно «донастроить» сформированные задачи и добавить к ним новые в случае необходимости.

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

На седьмом шаге происходит вызов обработчика ПриСозданииВложенныхБизнесПроцессов(). Обработчик этого события может «донастроить» автоматически сформированные бизнес-процессы (их количество равно количеству задач после обработчика ПриСозданииЗадач()) или удалить некоторые из них, а также добавить к ним новые бизнес-процессы. Запись списка бизнес-процессов будет осуществлена после завершения обработчика.

13.14.Завершение бизнес-процесса

Завершение является последним этапом в жизненном цикле бизнес-процесса. Бизнес-процесс автоматически становится завершенным (свойству Завершен устанавливается значение Истина) при достижении точки завершения и при условии отсутствия невыполненных задач по этому бизнес-процессу.

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

При переходе на точку завершения вызывается обработчик ПриЗавершении(). Если он установит Отказ равным Истина, например, если не выполнены все необходимые условия завершения бизнес-процесса, то обработка прерывается. Задача по точке маршрута, выполнение которой привело к переходу на точку завершения, при этом остается невыполненной.

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

13.15.Стандартные реквизиты бизнес-процессов и задач

В таблицах перечислены предопределенные поля бизнес-процессов и задач.

Стандартные реквизиты бизнес-процессов:

Реквизит	Тип
ПометкаУдаления	Булево
Номер	Строка или Число
Дата	Дата
Завершен	Булево
ВедущаяЗадача	ЗадачаСсылка.<Имя задачи>
Ссылка	БизнесПроцессСсылка.<Имя бизнес-процесса>

Стандартные реквизиты задач:

Реквизит	Тип
ПометкаУдаления	Булево
Номер	Строка или Число
Дата	Дата
Наименование	Строка
Выполнена	Булево
БизнесПроцесс	БизнесПроцессСсылка.<Имя бизнес-процесса>
ТочкаМаршрута	БизнесПроцессСсылка.<Имя бизнес-процесса>
Ссылка	ЗадачаСсылка.<Имя задачи>

13.16.Бизнес-процессы с несколькими точками старта

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

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

Если бизнес-процесс имеет несколько точек старта, то при вызове метода Старт() необходимо указать конкретную точку. В противном случае будет выдано сообщение об ошибке. Поэтому при создании бизнес-процесса с несколькими точками старта необходимо сделать следующее:

● определить интерактивные команды старта для указания корректной точки старта в каждом случае старта бизнес-процесса.

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

Пример:

Процедура ВложенноеСогласованиеПриСозданииВложенныхБП(ТочкаМаршрутаБП, ФормируемыеПроцессы, Отказ)
    Для каждого БизнесПроцесс из ФормируемыеПроцессы Цикл
        БизнесПроцесс.Записать();
        Точки = БизнесПроцессы.СогласованиеДокумента.ТочкиМаршрута;
        БизнесПроцесс.Старт(Точки.УпрощенноеСогласование);
    КонецЦикла
КонецПроцедуры

В остальном использование бизнес-процессов с несколькими точками старта ничем не отличается от обычных бизнес-процессов.

13.17.Обратная связь

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

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

Важной особенностью механизма бизнес-процессов в системе «1С:Предприятие» является то, что он не требует существенного изменения используемых прикладных решений. Поэтому реакция бизнес-процессов и задач на изменение других объектов информационной базы может настраиваться без существенного изменения этих объектов.

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

Для этого последовательно выполним следующие действия:

● Добавим оповещение о проведении в форму документа:

Процедура ПослеЗаписи(Отказ)
    Если БылоПроведение Тогда
        Оповестить("ПроведениеДокумента", , ЭтотОбъект.Ссылка);
    КонецЕсли;
КонецПроцедуры

● Зарегистрируем обработчик оповещения. Это можно сделать в обработчике ПриНачалеРаботыСистемы() модуля управляемого приложения:

ПодключитьОбработчикОповещения("ОбработчикОповещения");

● Из обработчика оповещения вызовем метод серверного общего модуля (например, РаботаСБизнесПроцессами), который выполнит необходимые проверки и задачу:

// Обработчик оповещения в модуле управляемого приложения
Процедура ОбработчикОповещения(ИмяСобытия, Параметр, Источник) Экспорт
    Если ИмяСобытия = "ПроведениеДокумента" Тогда
        РаботаСБизнесПроцессами.ВыполнитьЗадачуПоДокументу(Источник);
    КонецЕсли;
КонецПроцедуры
...
&НаСервере
// Метод серверного общего модуля РаботаСБизнесПроцессами
Процедура ВыполнитьЗадачуПоДокументу(ДокументСсылка) Экспорт
        Запрос = Новый Запрос;
        Запрос.УстановитьПараметр("Парам", ДокументСсылка);
        Запрос.Текст =
                "ВЫБРАТЬ
                |Ссылка
                |ИЗ
                |Задача.Задача.ЗадачиПоИсполнителю
                |
                |ГДЕ
                |Документ = &Парам";
        Выборка = Запрос.Выполнить().Выбрать();
        Пока Выборка.Следующий() Цикл
            ТекущаяЗадача = Выборка.Ссылка.ПолучитьОбъект();
            Если ТекущаяЗадача.ПроверитьВыполнение() Тогда
                ТекущаяЗадача.ВыполнитьЗадачу();
            КонецЕсли;
        КонецЦикла;
КонецПроцедуры

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

Рассмотрим специфические особенности конфигурирования объектов бизнес-процессов и задач.

13.18.Карта маршрута

Карта маршрута описывает логику бизнес-процесса и весь его жизненный цикл от точки старта до точки завершения в виде схематического изображения последовательности прохождения взаимосвязанных точек маршрута.

Для редактирования карты маршрута на закладке Прочее окна редактирования бизнес-процесса нужно нажать кнопку Карта маршрута (подробнее см. здесь).

13.19.Редактирование бизнес-процесса

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

Конфигуратор позволяет описать структуру бизнес-процесса, создать формы и карту маршрута бизнес-процесса.

Свойства бизнес-процессов редактируются в палитре свойств или окне редактирования объекта (см. здесь).

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

Свойство Задачи определяет ссылку на сконфигурированный ранее объект задачи. Бизнес-процессу обязательно должна быть назначена одна задача из числа уже существующих в конфигурации. Задачи используются бизнес-процессом для формирования заданий по исполнителям или для запуска вложенных бизнес-процессов. Если задача не назначена, то при сохранении конфигурации базы данных будет выдана ошибка: Не выбрана задача бизнес-процесса.

Автонумерация. Установка свойства приводит к тому, что вновь введенному бизнес-процессу номер будет присваиваться автоматически. Автоматически присвоенный номер можно исправить.

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

Тип номера. Свойство позволяет выбрать тип значения для номера бизнес-процесса ‑ Число или Строка. Это свойство аналогично свойству Тип номера документа.

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

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

Периодичность. Свойство устанавливает пределы контроля уникальности номеров бизнес-процессов и период повторяемости номеров. Если установлено свойство Контроль уникальности, то в свойстве Периодичность указывается, в каких пределах будет осуществляться этот контроль.

При установленном свойстве Автонумерация система «1С:Предприятие» будет присваивать очередной порядковый номер каждому новому бизнес-процессу. После завершения периода, установленного в свойстве Периодичность, нумерация бизнес-процессов начнется с 1.

На закладке Права имеется возможность установки привилегированного режима при создании задач (свойство Привилегированный режим при создании задач):

● Если свойство установлено, то все действия по формированию задач система будет выполнять в привилегированном режиме (при исполнении на стороне сервере и в файловом варианте). Однако привилегированный режим не будет установлен, если формирование задач выполняется в клиент-серверном варианте на стороне толстого клиента.

● При создании новых бизнес-процессов свойство установлено в значение Истина, если в свойствах конфигурации указан основной режим запуска ‑ управляемое приложение, и в значение Ложь, если основным режимом запуска указан обычный.

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

Если объект предметной области, которой соответствует бизнес-процесс, имеет не только такие «простые» свойства, как, например, дату, номер, важность или контрольный срок, но и составные (списочные) свойства, как, например, список документов на согласование, список резолюций, список участников бизнес-процесса, для бизнес-процесса может быть создан набор табличных частей.

13.20.Редактирование задачи

Объекты типа Задачи предназначены для выдачи и исполнения заданий пользователями системы. Задания могут формироваться как самими пользователями, так и конкретными бизнес-процессами.

Задачи могут применяться самостоятельно или использоваться для обеспечения функционирования бизнес-процессов разного вида.

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

Описываемые в конфигурации структура и свойства задачи определяются особенностями автоматизируемой предметной области.

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

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

Свойства задачи редактируются в палитре свойств или окне редактирования объекта (см. здесь).

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

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

Основной реквизит адресации. Один из реквизитов адресации задачи может быть назначен основным. В этом случае именно в этом реквизите адресации необходимо будет указывать конкретного исполнителя задания. Если исполнитель не будет указан, то значение этого реквизита адресации будет определяться из связанного с задачей регистра сведений (см. свойство Адресация).

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

Автопрефикс номера задачи. Может принимать значения Не использовать и Номер бизнес-процесса. Если это свойство установлено в значение Номер бизнес-процесса, то при создании новой задачи ее номер автоматически дополняется номером соответствующего ей бизнес-процесса.

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

Длина номера. Устанавливает максимальную длину номера задачи.

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

Контроль уникальности. Если это свойство установлено, то при вводе новой задачи ее номер проверяется на уникальность.

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

Если объект предметной области, которой соответствует задача, имеет не только такие «простые» свойства, как, например, дату, номер, важность или контрольный срок исполнения, но и составные (списочные) свойства, как, например, список документов для согласования, то может быть создан набор табличных частей.

Источник

1. Основное правило подсчета документов при определении объема документооборота – это…

2. Реквизит документа – это …

*значок, проставленный на документе для его распознавания

*обязательный элемент официального документа

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

*логотип на официальном документе

3. Установите соответствие между видами номенклатур и их определениями:

A. Номенклатура конкретного предприятия

B. Типовая номенклатура

C. Примерная номенклатура

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

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

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

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

*При свободном согласовании исполнитель получает уведомление о заданиях и сам определяет дальнейший маршрут документа. При согласовании по регламенту последовательность операций в маршруте для согласования документов уже заложена. Служебная записка на получение средств имеет в компании установленный маршрут: непосредственный руководитель – бухгалтер – высший руководитель. Поэтому здесь рекомендуется выбрать согласование документа по регламенту

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

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

5. Система документации определяется как …

*совокупность документов, отражающих организационную и распорядительную деятельность

*совокупность документов, взаимосвязанных по признакам происхождения, назначения, вида, сферы деятельности, единых требований к их оформлению

*письменные документы, в которых фиксируются решения административных и организационных вопросов, а также вопросов управления

6. Расставьте в правильной последовательности операции по распознаванию документа:

1 предварительная обработка изображений

2 нахождение полей документа

3 проверка распознанной информации

4 ввод данных в информационную базу

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

*Все входящие документы сначала направляются руководству организации, потом 15–20 %направляются руководителям структурных подразделений, остальные – специалистам, выполняющим определенные функциональные обязанности

*15–20 % входящих документов направляются руководству организации, 15–20 % – руководителям подразделений, остальные –специалистам, выполняющим определенные функциональные обязанности

*15–20 % входящих документов направляются руководству организации, остальные – руководителям структурных подразделений, которые направляют их специалистам, выполняющим определенные функциональные обязанности

8. Установите последовательность обработки внутренних документов:

1 подготовка проекта внутреннего документа

2 обеспечение согласования документа

3 утверждение

4 регистрация

5 рассылка по подразделениям

6 контроль исполнения документа

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

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

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

10. В объеме документооборота следует учитывать …

*только входящие и исходящие документы

*все входящие, исходящие и внутренние документы, а также все копии

*только внутренние документы, а также все копии

*все входящие и исходящие документы за определенный период времени

11. Установите последовательность обработки исходящих документов:

1 разработка проекта документа в структурном подразделении

2 согласование проекта документа в структурных подразделениях

3 утверждение документа руководством

4 регистрация документа

5 экспедиционная обработка документа

6 отправка документа

12. Длина ключа электронной подписи (по ГОСТу) равна …

*256 байт

*256 бит

*2256 бит

*1077 бит

13. Установите соответствие между видами срокового контроля и их определениями:

A. Итоговый контроль

B. Текущий контроль

C. Предупредительный контроль

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

E. подготовка сведений о документах, срок исполнения которых истекает сегодня

F. подготовка сведений о документах, срок исполнения которых истекает через 2–3 дня

14. Документооборот – это …

*движение документов в организации от руководителя к исполнителям

*технологический процесс архивного хранения документов

*сложный технологический процесс, который включает все операции по приему, передаче, составлению, согласованию, оформлению, удостоверению и отправке документов

*процесс подписания и передачи документа в организации

15. К основным видам срокового контроля относят … контроль

*ежемесячный

*текущий

*предупредительный

*ежеквартальный

*итоговый

16. Установите соответствие между реквизитами документов и их характеристиками:

A. Адресат

B. Справочные данные об организации

C. Текст

D. реквизит документа, включающий наименование получателя документа

E. реквизит, характерный только для бланка письма

F. реквизит, отражающий основное содержание документа

17. Существует два типа реквизитов, такие как …

*стандартные

*постоянные

*обязательные

*переменные

18. Установите последовательность этапов заполнения регистрационной карточки при работе с входящими документами:

1занесение информации о документе

2 внесение резолюции

3 постановка на контроль

4 отслеживание хода исполнения

5 внесение номера дела

19. Криптография предполагает наличие трех компонент, в частности …

*данных

*пароля

*ключа связи

*криптографического преобразования

*сертификата

20. Распознавание документа в настоящее время осуществляется с помощью следующих систем распознавания текстов: OCR, ICR и OMR. OCR – это технология оптического распознавания печатных символов. ICR – это технология распознавания раздельных печатных символов, написанных от руки. OMR – это технология распознавания отметок. Организации используют данные технологии при приеме документов. Поясните, какую технологию использует государственная организация при приеме заявлений на получение паспорта.

*Используется технология распознавания раздельных печатных символов, написанных от руки (ICR), потому что заявление заполнено самим гражданином от руки.

*Используется технология оптического распознавания печатных символов (OCR), потому что документ создан самим гражданином на компьютере и распечатан.

*Используется технология распознавания отметок (ICR), потому что гражданин галочками отмечает необходимые пункты.

21. Общий бланк – это …

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

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

*лист бумаги, содержащий одинаковый набор реквизитов для всех видов документов

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

22. Определите последовательность работ, производимых с входящими документами:

1 прием

2 первичная обработка

3 предварительное рассмотрение

4 распределение

5 регистрация

23. Установите соответствие между форматом потребительских бумаги размерами страницы:

A. A3

B. A4

C. A5

D. 148 x 210 мм

E. 297 x 420 мм

F. 210 x 297 мм

24. Определите последовательность расположения элементов реквизита Адресант в бланке письма:

1 эмблема организации

2 наименование организации

3 справочные элементы

4 дата и регистрационный номер

5 ссылка на регистрационный номер и дату

25. Основной структурной единицей форматированного документа при распознавании считается … документа

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

*Дата

*Подпись

*Наименование организации

*Приложение

*Резолюция

*Регистрационный номер

27. Период использования секретного ключа для подписания электронных документов определяется … ключа

28. По отношению к управленческому объекту выделяют такие документопотоки, как …

*входящий

*восходящий

*исходящий

*внешний

*внутренний

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

*описание настройки системы

*сканирование

*контроль качества

*возможное повторное сканирование

*нахождение полей

30. Бланки документов могут изготавливаться на стандартных листах бумаги формата …

*А1

*А2

*А3

*А4

*А5

31. При проверке электронной подписи проверяющий должен иметь …

*открытый ключ абонента

*закрытый ключ абонента

*алгоритм создания ключа

*электронный документ

32. … документ – это документ, в котором информация представлена в электронно-цифровой форме

33. При регистрации документа в компании заполняется регистрационная карточка, в которую заносятся основные реквизиты документа. В карточке входящего документа присутствуют поля: Дата получения, Входящий номер, Дата документа, № документа. Поясните, чем отличаются эти поля и когда они заполняются.

*Дата получения и Входящий номер проставляются в момент регистрации полученного документа в компании. Дата документа и № документа проставлены в документе в момент его отправления из компании адресанта

*Дата получения и Дата документа – это одинаковые поля, куда проставляется дата получения документа компанией. Входящий номер ставится при получении документа в компании, № документа ставится при передаче его исполнителю

*Дата получения и Входящий номер проставляются в момент регистрации полученного документа в компании. Дата документа и № документа ставится при передаче его исполнителю

34. Расставьте в правильной последовательности мероприятия по защите ключей цифровой подписи от несанкционированного использования:

1 генерация

2распределение

3 хранение

4 использование

5 выведение из действия

35. Расставьте в правильной последовательности операции процесса подписания документа электронной подписью:

1 считывание

2 создание хеш-функции

3 шифрование хеш-функции

4 создание электронной подписи

5 присоединение подписи

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

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

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

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

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

38. Соотнесите виды электронной подписи с процессом их формирования:

A. Квалифицированная электронная подпись

B. Простая электронная подпись

C. Неквалифицированная электронная подпись

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

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

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

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

*Текущий контроль исполнения документа проводится каждый день посредством подготовки списка всех документов, а предупредительный – за 2–3 дня до окончания срока исполнения документа посредством подготовки списка документов, срок исполнения которых заканчивается через 2–3 дня

*Текущий контроль проводится на момент окончания срока исполнения документа посредством подготовки списка документов, срок исполнения которых заканчивается на данный момент, а предупредительный контроль проводится за 2–3 дня до окончания срока исполнения документа также посредством подготовки списка документов, срок исполнения которых заканчивается через 2–3 дня

40. Объем документооборота выражается общим количеством документов, … за определенный период времени

*поступивших в организацию

*поступивших или созданных организацией

*созданных в организации

41. … – это средство для выработки электронной подписи

*Криптопровайдер

*Открытый ключ

*Закрытый ключ

*Аутентификация

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

43. Установите соответствие между названиями систем электронного документооборота и их производителями:

A. «Ефврат»

B. «Дело»

C. Company Media

D. LanDocs

E. компания Cognitive Technologies

F. ЗАО «Электронные офисные системы»

G. компания InterTrust

H. АО «Ланит»

44. Механизм разграничения доступа к данным и функциям системы – это …

45. В качестве количественной характеристики документооборота выступает … документооборота

46. Установите соответствие понятий с их определений:

A. Электронная подпись

B. Ключ

C. Открытый ключ

D. присоединяемое к тексту его криптографическое преобразование

E. конкретное секретное значение набора параметров криптографического алгоритма

F. средство для определения автора подписи и достоверности электронного документа

47. … – это систематизированный перечень наименований дел, заводимых в организации, с указанием сроков их хранения, оформленный в установленном порядке

48. В любой компании обязательно проводится контроль за исполнением документов. Существует два вида контроля: контроль по существу решения вопроса и контроль за сроками исполнения задания. Имеется небольшая компания, в составе которой есть руководитель, секретарь и 15 исполнителей. Как в данном случае организовать контроль за исполнением документов?

*Контроль по существу – это оценка того, насколько правильно, удачно, полно решен вопрос. Руководитель должен взять на себя эту функцию. Контроль за сроками исполнения – чисто формальная процедура, которую исполняет секретарь.

*Контроль по существу позволяет проверить наличие документа на данный момент, этим должен заниматься секретарь. Контроль за сроками исполнения осуществляет руководитель.

*Контроль по существу – это оценка правильности решения вопросов документа, эта функция распределяется между сотрудниками. Контроль за сроками исполнения документов осуществляет секретарь.

49. Аутентификация – это …

*способность подтвердить личность пользователя

*предоставление доступа к определенным данным или операциям, при условии что пользователь – тот, за кого он себя выдает

*механизм разграничения доступа к данным и функциям системы

поиск и исследование математических методов преобразования информации

50. Под электронной подписью понимается …

*отсканированная традиционная рукописная подпись, содержащая информацию об отправителе сообщения

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

*средство защиты от подделок или потери данных в рукописных документах

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

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

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

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

*Большинство документов, приходящих в организацию, имеют стандартные формы, для которых характерно то, что для каждого реквизита определено место на документе, т.е. поле. Для корректного распознавания информации каждое поле должно быть описано в трех аспектах: тип поля, способ ввода информации в поле и объем.

52. Регистрация документа – это …

*запись учетных данных о документе по установленной форме, фиксирующая факт создания, отправления или получения документа

*учет документов, контроль за их исполнением и справочная работа по документам

*снятие с документа показателей (реквизитов) и занесение их в определенную регистрационную форму

*прием и первичная обработка документов

53. Существует два варианта расположения реквизитов на бланках организации, в частности, …

*продольный

верхний

**центральный

*угловой

54. Каждый документ можно разделить на три основные части, такие как …

*вводная

*заголовочная

*основная

*заключительная

*оформляющая

55. … – это элемент оформления документа

*Реквизит

*Бланк

*Список

*Резолюция

Источник

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

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

Управленческий аспект согласования

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

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

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

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

Согласование способствует развитию командности, духа сотрудничества и товарищеского взаимодействия, т.к. в регламентированной процедуре на первый план выступают отношения и роли (функции подразделений) в рамках общего трудового процесса, создаются доброжелательная рабочая среда и позитивный стиль общения. Эта процедура помогает также формировать обязательность и уважение интересов друг друга, честность в принятии решений (правило «честной игры»). Отметим еще один важный этический аспект процедуры согласования, отражающий влияние личности первого руководителя на процесс управления. Управленческие решения, оформляемые в документах, которые подписывает руководитель, всегда «работают» на формирование его личного стиля управления, его «образа» как руководителя и лидера, показывают ценность его вклада в достижение стратегических целей организации. Поэтому решения должны быть точны, понятны, исполнимы, а приказы и распоряжения – безупречно изложены и оформлены.

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

Три «золотых» правила согласования

Обратим внимание на правила организационного поведения, которые составляют основу для разработки процедуры согласования документов и в делопроизводственном (технологическом), и в управленческом аспектах. Изучение лучших практик современных организаций показывает, что именно эти правила можно назвать собственно «правилами согласования».

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

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

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

Пример 1

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

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

Пример 2

Служба главного бухгалтера не может проставить визу «Не согласовано» из-за выявленных ею грамматических ошибок в тексте, поскольку прямая зона ответственности данной службы – обеспечение правильности бухгалтерского и налогового учета. А в требованиях к оформлению реквизитов документов и грамматической правильности текста служба делопроизводства и служба главного бухгалтера всегда найдут взаимопонимание.

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

Роли подразделений

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

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

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

Есть подразделения, которые на предприятии отвечают за выполнение общих, так называемых «штабных» функций, или централизованно выполняющие функции административной поддержки и материально-технического обеспечения. К их числу обычно относят не дирекцию и аппарат помощников, а службы: делопроизводства, кадровую, юридическую, безопасности, информационно-технологического обеспечения, главного бухгалтера, планово-экономическую и т.п. В системе согласования такие подразделения являются «системообразующими», т.е. подразделениями обязательного согласования, т.к. в зоне их ответственности находятся основные юридические, финансовые, налоговые и операционные риски организации в целом.

Зоны ответственности подразделений

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

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

Пример 3

А иные подразделения, участвующие в процедуре согласования (по специальным видам деятельности организации), а также заместители первого руководителя организации, «курирующие» деятельность этих подразделений по системе делегирования полномочий, отвечают за выявление и оценку рисков по закрепленному за ними виду деятельности, направлению бизнеса и т.п., за контроль соответствия проектов решений требованиям специального (отраслевого) законодательства и контролирующих / регулирующих органов, за соблюдение внутренних нормативных документов организации, регламентирующих соответствующие виды деятельности.

Условия успешной реализации процедуры согласования

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

Необходимым условием начала процедуры согласования является наличие «выпускающей» визы вышестоящего руководителя подразделения-инициатора (т.е. не только исполнители, но и руководители должны изучить и принять правила согласования документов).

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

Отсутствие визы подразделения, участвующего в процедуре согласования, не позволяет считать документ согласованным «по умолчанию» (даже при нарушении типовых сроков согласования). К сожалению, это условие не всегда соблюдается даже на уровне федеральных органов исполнительной власти, о чем свидетельствуют факты несогласованных действий государственных органов. Надеемся, что минимизировать риски подобной несогласованности поможет система межведомственного электронного документооборота, положение о которой в конце 2009 года утверждено постановлением Правительства РФ.

Еще одним условием является установление перечня подразделений, с которыми согласование проектов документов Корпорации является обязательным, и закрепление их зон ответственности в процедуре согласования (возможный вариант подобного перечня мы привели в Примере 3).

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

Пример 4

В рамках процедуры согласования могут быть предоставлены следующие права:

потребовать от инициатора проекта дополнительно согласовать проект документа с подразделениями, участвующими в разработке управленческого решения, бизнес-схем, выполнении операций или подразделениями, контролирующими их выполнение;
не согласовывать (отклонить) проект документа с обоснованием причин (в листе согласования или специальной служебной записке);
продлить установленный срок согласования в зависимости от объема и содержания документа, но не более чем на конкретный регламентированный срок, например, пять дней;
не принимать на рассмотрение документы, согласование которых в этом подразделении не предусмотрено утвержденной схемой или маршрутом (проект документа в данном случае визируется, но с комментарием, что согласование документа с подразделением не предусмотрено);
не принимать от подразделений замечания без обоснования причин, если замечания не относятся к предметной области и зоне ответственности представившего замечания согласовывающего подразделения;
направить документ на согласование по процедуре, отличающейся от установленной в организации, если она санкционирована первым руководителем организации или его заместителем и вызвана срочностью и важностью решения вопроса.

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

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

Алгоритм и способы согласования

Анализ показывает, что независимо от степени автоматизации документооборота маршрут движения проекта документа в процессе согласования как правило, следующий:

1 этап.

Получение подписи руководителя подразделения-инициатора и согласование с вышестоящим руководителем подразделения-инициатора (получение «выпускающей» визы «курирующего» заместителя первого руководителя).

2 этап.

Согласование с подразделениями, участвующими в выполнении операций, которые затрагиваются проектом разрабатываемого документа, а также с подразделениями обязательного согласования, с подразделениями, контролирующими риски, с подразделениями, обязательность согласования с которыми устанавливается для данного вида документа централизованно в регламенте согласования или самим инициатором. Маршрут проекта документа в процессе согласования определяется видом и содержанием документа. Но даже при утвержденной схеме обязательного согласования проекта документа данного вида / разновидности в зависимости от значимости вопроса и подготовленного проекта управленческого решения выбор маршрута зависит от инициатора процедуры согласования.

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

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

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

Комбинированный способ согласования (на практике – самый распространенный) предполагает сочетание маршрутов направления проекта документа. Например, в начале процедуры инициатор получает визу подразделения-соисполнителя, а затем – параллельно направляет проект подразделениям-контролерам соответствующих рисков. Этот способ является основным в маршруте, когда условием начала процесса согласования является «выпускающая» виза вышестоящего руководителя подразделения-инициатора. Все знают, что «курирующие» вышестоящие руководители подразделений изучают подготовленные проекты документов и вносят свои изменения в представленные на их рассмотрение первоначальные проекты решений.

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

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

Сроки согласования

Практика показывает, что общий срок согласования одного проекта документа одним подразделением, как правило, составляет 5 дней и исчисляется с даты проставления на листе согласования «выпускающей» визы вышестоящего руководителя подразделения-инициатора.

В конкретных инструкциях по делопроизводству сроки согласования документов рекомендуем уточнять в зависимости от вида / разновидности документа и его содержания, например, «пять рабочих дней», «пять календарных дней, не считая даты получения документа» и т.п. Кроме того, рекомендуем более тщательно разрабатывать и регламентировать сроки при проведении процедуры внешнего согласования, если организация не направляет проекты документов на согласование в сторонние заинтересованные или контролирующие органы, а сама является участником процесса согласования.

Для рассмотрения и согласования проектов документов конкретных видов могут устанавливаться очень оперативные сроки, например: «в течение дня получения», «не позднее следующего дня с даты получения» и т.п.

При установлении конкретных сроков согласования рекомендуем эти сроки соотносить также с утвержденными (типовыми) сроками исполнения конкретных видов и разновидностей документов и поручений в зависимости от содержащихся в них вопросов, т.е. возможно в работу исполнителей с документами внедрять те же контрольные 3, 5, 10 и не более 30 дней. Оптимальным является срок согласования проекта документа от 2-3 и до 5 дней, соблюдение которого обеспечивают параллельный или комбинированный способы согласования, реализованные в системе электронного документооборота.

Схемы и маршруты согласования

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

Пример 5

Схема маршрутов согласования проектов документов может быть оформлена, например, следующим образом (при параллельном способе согласования очередность подразделений и должностных лиц не является принципиальной, только службе делопроизводства можно рекомендовать быть «последней» инстанцией согласования, оценивающей качество составления и оформления подготовленного проекта документа в целом):

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

обоснование необходимости разработки (подписания, утверждения) нового документа, заключения договора или внесения изменений в действующие документы;
обоснование финансовых параметров или изменений финансовых условий договоров по сравнению с действующими;
договоры и соглашения, являющиеся основными или первичными по отношению к направляемым на согласование документам;
пояснения к «схемам» договоров и сделок;
материалы проведенных тендеров / конкурсов;
выписки из протоколов заседаний коллегиальных органов управления, во исполнение которых был подготовлен проект документа;
приложения, на которые даются ссылки в проекте документа.

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

Оформление результатов согласования

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

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

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

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

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

При проведении процедуры внешнего согласования ее результаты оформляются соответствующей перепиской (письмами о согласовании).

После получения виз от всех подразделений, причем даже в процессе внутреннего согласования возможно проставление виз по форме: «СОГЛАСОВАНО» («СОГЛАСОВАНО с замечаниями»), исполнитель:

оформляет окончательную редакцию проекта документа, к которой прикладывает экземпляр полностью согласованного проекта с визами и замечаниями («визовой» экземпляр) или лист согласования и
проставляет отметку об учете замечаний, которая является документальным подтверждением процедуры доработки проекта документа. Отметка об учете замечаний к окончательной редакции документа, оформленная на «визовом» экземпляре проекта или листе согласования, должна быть датирована и заверена подписью руководителя подразделения-инициатора;
после завершения согласования проект документа направляется руководителю или уполномоченному им должностному лицу для утверждения или подписания централизованно через службу делопроизводства. Направление на подписание возможно осуществить в бумажном или электронном виде.

Рекомендуем также обратить внимание, что Методические рекомендации при оформлении виз и грифа согласования как реквизитов документа вводят некоторые новации. Интересно, что «допускается полистное визирование документа и его приложений», что предполагает возможность использования не всех элементов визы как реквизита, состоящего из наименования должности, личной подписи, расшифровки подписи и даты визирования, а только одного его элемента – личной подписи (парафа), который широко применяется в нотариальном делопроизводстве и при оформлении гражданско-правовых документов для обеспечения их целостности. А если согласование проекта документа проводится с использованием листа согласования, то на документе под реквизитом «подпись» ближе к нижнему полю Методические рекомендации допускают вместо грифов согласования (на площади, предусмотренной для них на листе бумаги) оформление специальной отметки «Лист согласования прилагается».

Контроль согласования

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

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

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

В заключение приведем пример оформления листа согласования документа. Эта форма удобна и для электронного заполнения, и для применения в бумажном виде.

Пример 6

Источник

Маршруты документов¶

Введение в маршруты¶

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

Как подключить подсистему маршрутов для типа карточки/типа документа описано в разделе Использование маршрутов.

Основные компоненты подсистемы маршрутов¶

Маршрут — это последовательность этапов различных типов, которые выполняются в указанной последовательности. Маршрут строится на основании различных настроек, заданных администратором, а также может быть изменен пользователем в пределах, разрешенных его правами доступа и настройками маршрутов. Возможность для пользователя изменять маршрут, а для администратора — управлять и контролировать этот процесс — уникальная особенность подсистемы маршрутов платформы TESSA.
Этап маршрута — основной элемент построения маршрута. Этапы могут быть различных типов, предназначенные для различных целей. С платформой поставляется большой набор этапов для различных целей, например этапы для согласования, исполнения, смены состояния и т.д. С их помощью можно простыми средствами построить сложные последовательности действий. Также можно создавать собственные типы этапов (для этого требуется программирование), которые будут прозрачно встроены в общую систему.

Компоненты, настраиваемые администратором¶

Шаблон этапа — это специальная карточка, которая содержит в себе один или несколько заранее настроенных этапов маршрута. Подсистема строит маршрут документа, собирая этапы из различных шаблонов. Карточка содержит целый ряд настроек, управляющих правилами подстановки или пропуска этого шаблона по различным условиям. У каждого этапа в составе карточки шаблона также есть ряд настроек, позволяющих управлять его подстановкой в маршрут, а также организовывать различные действия при выполнении этапа.
Группа шаблонов — это также специальная карточка, объединяющая несколько шаблонов этапов в одну группу, и позволяющая управлять их подстановкой и выполнением в маршруте как единым целым. Маршрут любой карточки будет состоять из одной или нескольких групп, выполняемых последовательно.
Кнопка процесса — это карточка, позволяющая описывать новые кнопки (тайлы) в контекстной (левой) или глобальной (правой) панели приложения системы. С кнопкой можно связать группу шаблонов, которая должна выполниться по ее нажатию или указать дополнительные параметры управления процессом.
Сценарии (скрипты) — при помощи простых скриптов можно чрезвычайно сильно расширить возможности подсистемы маршрутов. Для скриптов используется синтаксис C#, и в различных объектах системы вы с их помощью можете модифицировать маршруты и их поведение, манипулировать данными карточек, организовывать циклы и сложные связи между различными этапам, управлять условиями подставки и пропуска этапов. Далее будет приведено большое количество примеров таких условий и скриптов, вы увидите, что это несложно. Обычный администратор, владеющий базовыми навыками скриптинга, легко сможет использовать их в работе.
Методы расширений — это карточка, позволяющая определить библиотеку различных вспомогательных методов (скриптов), которые в дальнейшем использовать в скриптах и условиях. Методы расширений позволяют сильно упростить скрипты и не дублировать одинаковые действия.

Виды процессов маршрутов, расчет маршрута и его выполнение¶

Существуют два вида процессов маршрутов: основной процесс и второстепенный процесс.

Основной процесс – это главный процесс маршрута по карточке. Его вы можете видеть на вкладке Маршрут.
Второстепенный или вторичный процесс – это процессы, которые стартуют по различным внешним событиям, в основном по тайлам. Эти процессы обычно синхронные — они запускаются, выполняют какие-то действия (меняют состояние, выполняют переход в основном процессе и т.д.) и завершаются. Но могут быть и вторичные процессы, которые отправляют задания и, соответственно, “замирают” и ждут завершения заданий для своего завершения. Такие процессы называются асинхронными. Вторичные процессы не видны на вкладке маршрут, и, соответственно, не могут быть явным образом изменены пользователем.

Также различают два вида процессов по синхронности этапов, входящих в маршрут.

Асинхронный процесс – процесс, некоторые этапы которого асинхронные, т.е. не могут выполниться сразу, а ждут чего-то от пользователя или внешней системы. Например, отправка задания – это асинхронный этап. Система отравляет задание и ждет, когда пользователь завершит его. Только тогда процесс идет дальше.
Синхронный процесс – это процесс, все этапы которого выполняются сразу же. Такой процесс рассчитывается и выполняется целиком в памяти.

Расчет маршрута или его части выполняется в следующих ситуациях:

Запуск процесса. В этом случае система полностью строит маршрут – вычисляет последовательность групп, и в них последовательность этапов (через шаблоны этапов). Подробно все эти ситуации описаны ниже.
“Вход” в группу. Когда при выполнении процесса маршрут дошел до какой-то группы, то перед началом выполнения система перестраивает группу.
При достижении этапа “Пересчет маршрута”. Если в состав какой-нибудь группы входит этап “Пересчет маршрута”, то при выполнении этого этапа система полностью пересчитает состав текущей группы после этапа “Пересчет маршрута”.
При нажатии кнопки “Пересчитать маршрут” на вкладке “Маршрут”.

При расчете маршрута основного процесса система включает в маршрут:

Группы, не связанные с кнопками/тайлами и удовлетворяющие ограничениям при пересчёте:
- тип соответствует типу текущей карточки/документа
- роль соответствует одному из значений: владельцу текущего процесса, если он задан, иначе инициатору текущего процесса, если он задан, иначе текущему сотруднику
Затем выполняются сценарии инициализации всех групп (построение маршрута)
Затем выполняются условия включения группы в маршрут (построение маршрута), у подтвержденных групп, которые останутся в маршруте (условие истинно), устанавливается флаг Confirmed = true в контексте.
Затем для каждой подтвержденной группы (условие включения в маршрут истинно) по очереди:
- Вычисляются шаблоны этапов, которые включены в эту группу И которые по типу документа И роли соответствуют текущему типу документа и сотруднику – владельцу текущего процесса, если задан, иначе инициатору текущего процесса, если задан, иначе текущему сотруднику
- выполняются сценарии инициализации этих шаблонов этапов
- выполняются условия включения в маршрут этих шаблонов этапов. У подтвержденных шаблонов, этапы которых останутся в маршруте (условие истинно), устанавливается флаг Confirmed = true в контексте.
- строится маршрут по этой группе по подтвержденным этапам
- выполняются сценарии постобработки для всех шаблонов, в т.ч. неподтвержденных
Затем для всех групп выполняются сценарии постобработки (построение маршрута), в том числе для неподтвержденных.
Далее система приступает к выполнению первой группы маршрута с выполнением ее пересчета. Пересчет группы выполняется по тем же правилам, что и для всего маршрута.

Например

В маршруте участвуют три группы: Группа 0 (условие ложно), Группа 1 (условие истинно), Группа 2 (условие истинно).
Терминология:
* Before - сценарий инициализации группы или шаблона этапа
* Condition - условия включения в маршрут (построение маршрута) группы или шаблона этапа
* After - сценарий постобработки группы (построение маршрута) или шаблона этапа

1. Выполняем Before для всех трех групп
2. Выполняем Condition для всех групп
2.0 Не берем шаблоны для группы 0, т.к. Condition = false
2.1 Берем шаблоны для группы 1
2.1.1 Выполняем Before для всех шаблонов группы 1
2.1.2 Выполняем Condition для всех шаблонов группы 1
2.1.3 Строим маршрут для группы 1 на основе подтвержденных в п 2.1.2
2.1.4 Выполняем After для всех шаблонов группы 1. Маршрут, построенный в 2.1.3 доступен в контексте.
2.2 Берем шаблоны для группы 2
2.2.1 Выполняем Before для всех шаблонов группы 2
2.2.2 Выполняем Condition для всех шаблонов группы 2
2.2.3 Строим маршрут для группы 2 на основе подтвержденных в п 2.2.2
2.2.4 Выполняем After для всех шаблонов группы 2. Маршрут, построенный в 2.2.3 доступен в контексте.
3. Выполняем After для всех трех групп. На этом моменте доступен полный маршрут по всем группам

При расчете маршрута вторичного процесса, связанного с кнопкой/тайлом система включает в маршрут:

Группы, которые непосредственно связаны с этим тайлом И
- проверяется вхождение текущего сотрудника в роли, указанные в поле “Роли” группы
- если тайл глобальный (правая панель), то поле “Тип документа” группы игнорируется
- если тайл контекстный (левая панель), то в маршрут попадают только группы, у которых в поле “Тип документа” присутствует тип текущего документа.
Далее маршрут считается по общим правилам.

Пересчет группы при начале ее выполнения выполняется системой по аналогии с полным перестроением маршрута:

Сначала выполняется сценарий инициализации (построение маршрута) группы.
Затем выполняется условие включения в маршрут (построение маршрута) группы.
- Если условие истинно, то вычисляются шаблоны этапов, которые включены в эту группу И которые по типу документа И роли соответствуют текущему типу документа и сотруднику — владельцу текущего процесса, если задан, иначе инициатору текущего процесса, если задан, иначе текущему сотруднику
- выполняются сценарии инициализации этих шаблонов этапов
- выполняются условия включения в маршрут этих шаблонов этапов. У подтвержденных шаблонов, этапы которых останутся в маршруте (условие истинно), устанавливается флаг Confirmed = true в контексте.
- строится маршрут по этой группе по подтвержденным этапам
- выполняются сценарии постобработки для всех шаблонов, в т.ч. неподтвержденных
Затем для группы выполняется сценарий постобработки (построение маршрута).
Далее система приступает к выполнению этой группы маршрута.

Владелец процесса – это персональная роль, от имени которой выполняется пересчёт основного маршрута. Для её получения или задания следует использовать свойство IKrScript.ProcessOwner или IKrScript.WorkflowProcess.ProcessOwner.

Владелец текущего процесса – это персональная роль, от имени которой выполняется пересчёт текущего маршрута. Для основного процесса совпадает с владельцем процесса. Для её получения или задания следует использовать свойство IKrScript.WorkflowProcess.ProcessOwnerCurrentProcess.

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

Пересчет части маршрута этапом “Пересчет маршрута” выполняется следующим образом:

Система полностью пересчитывает текущую группу, так же, как и при входе в группу.
Если в пересчитанной группе этапа “Пересчет маршрута” нет – выдается ошибка.
Если в пересчитанной группе ранее этапа “Пересчет маршрута” есть новые этапы – выдается ошибка.
Если всё в порядке, управление передается на следующий этап в группе.

Правила выполнения маршрута:

Система выполняет маршрут в глобальном порядке групп, входящих в него.
При “входе” в группу, т.е. перед выполнением первого этапа, входящего в эту группу, система выполняет и проверяет рантайм-условие (выполнение маршрута). Если условие ложно, система переходит к следующей группе в маршруте.
Если рантайм-условие истинно, то выполняется сценарий рантайм-инициализации (выполнение маршрута) группы.
Далее система по очереди выполняет этапы, входящие в группу, при этом для каждого этапа по очереди:
- вычисляется условие
- если условие истинно, то выполняется сценарий инициализации и выполняется собственно этап
- при завершении этапа выполняется сценарий постобработки
После завершения последнего этапа, входящего в группу, выполняется сценарий рантайм-постобработки группы (выполнение маршрута).
Система проверяет, не появилось ли новых групп, которые должны выполняться между завершенной и следующей группой. Для этого она:
- Формирует список групп, подходящих по типу документа и роли сотрудника, которые по порядку (поле “Порядок”) должны выполняться между текущей завершенной группой и следующей.
- Если такие группы есть, для них выполняется полный пересчет маршрута по общим правилам.

Особенности работы маршрутов при удалении или изменении шаблонов этапов¶

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

При запуске процесса.
При входе в группу.
При достижении этапа “Перечсёт маршрута”.
При нажатии кнопки “Пересчитать” на вкладке “Маршрут”.

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

Если в шаблоне есть этап с вычисляемыми исполнителями, то при удалении такого шаблона/этапа карточки, где должен выполниться этот этап, сломаются. Система будет пытаться вычислить SQL исполнителей, но не сможет, т.к. такой шаблон/этап уже не существует. Чтобы избежать таких проблем рекомендуется не удалять такие шаблоны/этапы, а сделать шаблон недоступным для новых карточек (например, прописав в условии старта шаблона, скрипт false) и желательно переименовать/добавить описание, чтобы в будущем не забыть, что это шаблон для поддержания старых карточек. А новые карточки пойдут уже по новому маршруту.

Примеры маршрутов¶

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

Note

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

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

Примеры, которые мы рассмотрим:

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

Инициация нового договора (пример)¶

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

После инициации договор будет отправлен на согласование, если он дороже 100 000.

После успешного согласования он будет переведен в состояние “На подписании руководителем” и отправлен на подписание руководителю.

Затем договор будет переведен в состояние “На подписании контрагенту” и отправлен инициатору на организацию подписания контрагентом.

И в самом конце договор получит состояние “Подписано сторонами”.

Интересным аспектом этого процесса является собственный этап доработки, который включен в подписание. Если кто-либо (руководитель или контрагент) не подписали документ, то после доработки документ вновь уйдет на подписание, а не на полный цикл согласования с прохождением всех согласующих.

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

В правой панели нажмите тайл “Инициировать договор”.

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

Давайте попробуем отправить договор на согласование не внося изменений в сумму. Она меньше 100 000 и это значит, что договор должен сразу попасть на подписание.

Нажмем в левой панели кнопку “Запустить процесс”. Мы запустили маршрут прохождения документа.

Запустился процесс и нам сразу же пришло задание на подписание, минуя согласование.

Обратите внимание на сформированный маршрут на вкладке “Маршрут”.

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

Вернемся к процессу. В задании на подписание нажмите кнопку “В работу”, чтобы взять задание в работу.

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

Нажмите кнопку “Подписать”, вы увидите поле для ввода комментария. Нажмите “Подписать” еще раз для подтверждения завершения задания.

Нам сразу же приходит следующее задание. Это задание инициатору на организацию подписания контрагентом.

Обратите внимание, что состояние карточки изменилось и теперь оно “На подписании контрагентом”.

Давайте откажем в подписании. Нажмите кнопку “В работу”. Затем нажмите кнопку “Отказать”, введите комментарий (при отказе в подписании он обязательный) и нажмите еще раз “Отказать”.

И нам сразу же приходит задание редактирования/доработки. Состояние карточки изменилось на “На редактировании”.

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

Давайте посмотрим на содержимое листа согласования. Лист согласования — это специальный виртуальный файл, который для вашего удобства система формирует у каждой карточки, участвующей в согласовании. В нем в удобном для просмотра, печати или, например, отправки почтой, в табличном виде представлен маршрут согласования и подписания документа. Файл “Лист согласования” всегда актуальный, так как формируется системой автоматически в момент запроса содержимого и физически в карточке не хранится.

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

Давайте инициируем новый цикл согласования. Возьмите в работу задание редактирования и нажмите кнопку “Начать новый цикл”.

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

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

Процесс завершится и состояние карточки изменится на “Подписано сторонами”.

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

Теперь давайте инициируем договор с большей суммой. Еще раз нажмите в правой панели кнопку “Инициировать договор”.

В открывшейся карточке договора введите сумму 200 000.

И опять в левой панели нажмите тайл “Запустить процесс”.

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

Посмотрим на вкладку “Маршрут”. Появился новый этап “Согласование внутри компании”. Он состоит из последовательного согласования ролями “Руководитель инициатора” и подразделением “Финансовый департамент”.

Если вы согласуете документ (возьмите в работу задание, и нажмите “Согласовать”), а затем сделаете это еще раз в следующем задании, то попадете опять на этап подписания внутри компании — сначала руководителем, а затем и контрагентом. Поэкспериментируйте с выполнением процесса. Попробуйте различные варианты.

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

Подготовка, согласование и исполнение служебной записки/заявки (пример)¶

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

Давайте посмотрим на схему процесса.

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

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

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

Если заявка является финансовой:

После отправки на согласование будет предложено предоставить финансовое обоснование или ввести комментарий.
Когда заявка инициирована и приложено обоснование, она отправляется на согласование. В нем участвуют роли: “Руководитель инициатора”, “Финансовый департамент” и “Главный бухгалтер”. Интересно, что времени на согласование система будет давать всё меньше с каждым новым циклом согласования.

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

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

Давайте создадим новую служебную записку. Нажмите тайл “Обычная СЗ” в группе тайлов “СЗ” на правой панели.

Будет открыто диалоговое окно содержащее сформированный по шаблону документ. Если вы хотите отредактировать документ, нажмите правой кнопкой на файле, выберите “Редактировать”, в открывшемся приложении отредактируйте документ, сохраните и закройте приложение.

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

Посмотрим, как выглядит сформированный маршрут документа на вкладке “Маршрут”. В настоящий момент активен этап “Исполнение обычной СЗ”.

Как видите, в задании уже написано, что нам нужно сделать.

Теперь нажмите кнопку “В работу” в задании.

Теперь вам доступны все возможности работы с этим заданием. Задание можно просто завершить. Еще вы можете отправить задание другому сотруднику или сотрудникам, вы можете создать подчиненное задание, чтобы получить какие-то дополнительные материалы и данные. Возможностей очень много и они подробно описаны в руководстве пользователя в разделе “Работа с задачами”.

Давайте завершим задание, чтобы сообщить системе что заполнение заявки вами завершено и можно продолжить маршрут. Нажмите кнопку “Завершить” в задании. Далее на форме завершения задания нажмите кнопку “Завершить” еще раз для подтверждения. Комментарий можно оставить пустым.

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

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

Давайте вернемся в карточку и заполним поле “Категория документа”. Выберите “Прочие СЗ” из выпадающего списка и опять отправьте на согласование.

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

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

Состояние карточки изменилось на “На исполнении”. Часто со сменой состояния также настраивают изменения прав доступа на карточку, например, чтобы инициатор имел права на изменение данных и файлов карточки, только пока она в состоянии “Проект”.

Давайте возьмем задание в работу. Нажмите кнопку “В работу”. Опять, как и в задании на заполнение, нам становится доступно множество возможностей. На этапе исполнения они могут быть полезны. Например, исполнитель может отправить задание другому сотруднику с возвратом после завершения, чтобы проконтролировать исполнение заявки до того, как система отправит ее инициатору.

Например, так:

И назад при завершении оно придёт так:

Мы же просто завершим задачу — заявка исполнена. Нажмите кнопку “Завершить” в задании и подтвердите завершение.

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

Возьмем задание в работу. Нажмите кнопку “В работу”. Обратите внимание, что это другое задание. В нем нам доступны только два варианта завершения “Выполнено” и “Не принято”. Эти варианты специально настроены под данный шаг маршрута.

Давайте не примем выполнение. Мы чем-то недовольны. Нажмите кнопку “Не принято”, заполните комментарий и еще раз нажмите “Не принято” для подтверждения завершения.

И мы опять переходим на этап выполнения заявки. Система вновь отправила задание исполнителю с комментарием инициатора.

Давайте опять возьмём задание в работу и затем завершим его. Нажмите “В работу”, затем нажмите “Завершить” и на форме завершения задания еще раз нажмите “Завершить”.

Система вновь присылает нам задание на подтверждение. Возьмите его в работу, и нажмите “Выполнено”.

Исполнение заявки принято, процесс завершен, карточка перешла в состояние “Исполнен”.

На вкладке “История заданий” вы всегда можете увидеть полную историю всех заданий, отправлявшихся и завершавшихся в рамках процесса.

А в рабочем месте “Пользователь” в представлении “Мои документы” вы всегда можете увидеть список всех инициированных вами документов и их текущее состояние.

А теперь давайте инициируем финансовую заявку, чтобы посмотреть на работу согласования. Нажмите в правой панели тайл “Финансовая СЗ”.

Вновь система создала карточку заявки и открыла её в диалоговом окне. Система запустит процесс и отправит задание на роль “Инициатор”.

Задание уже взято в работу. Нажав на кнопку “Приложить обоснование” откроется диалоговое окно, где можно добавить файл или указать комментрий. Нажмите на панели инструментов кнопку “Отправить” для завершения задания.

Документ отправится дальше по маршруту.

Для примера, система настроена таким образом, что приложенные в диалоге “Предоставление обоснования” файлы прикладываются в карточку документа и введённый комментарий к финансовому обоснованию записывается в поле “Комментарий к обоснованию”:

Согласно схеме процесса, нам, а точнее нашей роли “Руководитель инициатора”, приходит задание на согласование заявки. Срок задания составляет 5 рабочих дней.

Возьмите задание в работу. Это задание этапа согласования и оно предоставляет множество возможностей. Вы можете его делегировать, можете запрашивать комментарии у различных сотрудников (например, уточнить что-то у инициатора), можете делать дочерние согласования. Это подробно описано в руководстве пользователя в разделе “Согласование документов”.

Давайте не согласуем заявку. Нажмите “В работу”, далее “Не согласовать”, введите комментарий и далее еще раз нажмите “Не согласовать” для подтверждения.

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

Задача инициатора скорректировать заявку в связи с замечаниями. Давайте сделаем вид, что мы это сделали и начнем сразу новый цикл согласования. Нажмите “В работу” и затем “Начать новый цикл”.

Система снова отправляет задание на предоставление обоснования, где Инициатор в диалоговом окне может приложить файл или указать комментарий.

После завершения задания на предоставление обоснования система вновь отправляет задание первому из согласующих — роли “Руководитель инициатора”. Обратите внимание, что срок задания уменьшился и составляет уже 4 дня! Все работает так, как мы и предполагали. Если дальше не согласовывать документ, то с каждым новым циклом срок будет уменьшаться, пока не составит 1 день.

Теперь давайте согласуем документ. Нажмите “В работу”, затем “Согласовать” и еще раз “Согласовать” в форме завершения. Система сразу же отправляет следующее задание согласования на роль “Финансовый департамент” (и это опять мы — для удобства).

Если завершить и это задание, согласовав документ, мы попадем на этап согласования финансового обоснования главным бухгалтером. Укажем результат проверки и согласуем финансовое обоснование.

Мы попадаем на уже знакомый нам этап исполнения заявки, только исполнителем будет другая роль, потому что категория заявки “Финансовая СЗ”.

Дальнейший процесс мы подробно проходили в первой части этого примера. Обратите внимание, сколько мелких нюансов реализовано в этом процессе и при этом он остался чрезвычайно простым в настройке. Посмотреть, как устроен маршрут, вы можете в рабочем месте “Администратор” в папке “Маршруты”. Там вы найдете все объекты, связанные с маршрутом.

Последовательное согласование договора купли-продажи по списку участников, заданных непосредственно в карточке (пример)¶

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

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

Давайте создадим карточку договора купли-продажи. В правой панели нажмите тайл “Договор купли-продажи” в группе “Создать”.

Откроется новая карточка договора купли-продажи. Заполните ее, указав нескольких сотрудников в поле “Исполнители”. Создать нового сотрудника вы можете в правой панели в группе тайлов “Создать → Роли → Персональная роль (сотрудник)”, если у вас есть административные права.

Теперь давайте запустим процесс. В левой панели нажмите кнопку “Запустить процесс”. Кстати, тайл запуска процесса может называться как угодно для разных процессов, типов документов и даже сотрудников. Это все настройки маршрутов.

В моем случае после запуска карточка выглядит вот так.

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

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

На вкладке “Администратор” в представлении “Пользователи” найдите этого сотрудника и двойным щелчком мыши откройте его карточку. Далее на вкладке “Мои замещения” под таблицей “Кто меня замещает” нажмите кнопку “Добавить” и укажите себя (текущего сотрудника) как постоянного заместителя во всех ролях и подразделениях.

Далее сохраните карточку сотрудника нажатием тайла “Сохранить” в левой панели или сочетанием [Ctrl]+[S]. Обратите внимание, что заместитель должен появиться в поле “Сотрудники” группы “Состав роли” карточки сотрудника. Это может произойти с небольшой задержкой, т.к. за пересчет замещений отвечает служба Chronos, входящая в состав платформы, которой может быть нужно небольшое время.

Теперь вернемся к карточке протокола и в левой панели нажмем тайл “Обновить” или просто [F5]. Теперь мы можем исполнить задание. В форме задания написано, что мы его видим как заместитель исполнителя (справа от фамилии исполнителя).

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

Действительно, цикл работает. Вкладка “Маршрут” содержит всего несколько этапов, которые организуют инициализацию и выполнение цикла. Полностью посмотреть их настройки вы можете в рабочем месте “Администратор” в папке “Маршруты”.

Создание уже зарегистрированного документа (пример)¶

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

В данном случае система по нажатию глобального тайла:

Создаст карточку входящего по шаблону.
Выполнит для нее регистрацию.
Откроет карточку в рабочем месте пользователя.

Регистрация — это стандартная возможность системы. Обычно это тайл в карточке, по нажатию на который система выделяет для карточки постоянный номер и меняет состояние карточки на “Зарегистрировано”.

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

В правой панели нажмите тайл “Зарегистрировать входящий”.

Откроется карточка входящего. Обратите внимание, что на вкладке “История заданий” указано, что регистрация уже выполнена.

Полностью посмотреть настройки этого маршрута вы можете в рабочем месте “Администратор” в папке “Маршруты”.

Пример передачи данных между процессами¶

Пример передачи данных будет рассмотрен на примере задания значения в задании отправляемого этапом “Типизированное задание”.

В процессе “отправителе” выполняется создание задания и сохранение передаваемого значения в состоянии выполняющегося процесса.

В процессе “получателе” выполняется получение значения сохранённого в хранилище состояния процесса “отправителя”.

Warning

Для работы примеров необходимо в типовом решении указать тип задания “RsTestTask (RsTestTask)” в настройке “Расширенные настройки типов заданий, используемых в подсистеме маршрутов”

Note

Примеры выполняются на карточке типа “Дополнительное соглашение”.

Передача данных из основного процесса во вторичный процесс¶

Сохранение значения в хранилище пользовательской информации основного процесса.

Создадим новый шаблон этапов и настроим его:

Шаблон этапов содержит один этап “Типизированное задание” настроенный следующим образом:
- Тип задания: RsTestTask
- Сценарий инициализации:
```
this.ProcessInfoStorage["Comment"] = Guid.NewGuid().ToString();
```
Получение значения из хранилища с дополнительной информацией основного процесса в вторичном процессе.

Создадим вторичный процесс настроенный следующим образом:

Маршрут содержит этап “Сценарий” в котором задан скрипт инициализации:
```
// Получение значения из хранилища с дополнительной информацией основного процесса.
var processInfo = await this.GetPrimaryProcessInfoAsync();
var comment = processInfo.Get<object>("Comment");

// Получение модифицируемого задания.
var task = ((CardStoreTaskExtensionContext) this.CardContext).Task;

// Установка значения в карточке задания.
task.Card.Sections[KrConstants.KrTask.Name].Fields[KrConstants.KrTask.Comment] = comment;
```

Передача данных между вторичными процессами¶

Сохранение значения в хранилище пользовательской информации первого вторичного процесса.

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

Маршрут вторичного процесса содержит один этап “Типизированное задание” настроенный следующим образом:
- Тип задания: RsTestTask
- Сценарий инициализации:
```
this.ProcessInfoStorage["Comment"] = Guid.NewGuid().ToString();
```

Получение значения из хранилища с дополнительной информацией основного процесса в вторичном процессе.

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

Маршрут вторичного процесса содержит этап “Сценарий” в котором задан скрипт инициализации:

// Получение модифицируемого задания.
var task = ((CardStoreTaskExtensionContext) this.CardContext).Task;

// Получение идентификатора вторичного процесса по идентификатору задания.
var secondaryProcessID = await this.Db
    .SetCommand(
        this.DbScope.BuilderFactory
            .Select()
                .C("wt", "ProcessRowID")
            .From("WorkflowTasks", "wt").NoLock()
            .Where()
                .C("wt", "RowID").Equals().P("TaskRowID")
            .Build(),
        this.Db.Parameter("TaskRowID", task.RowID))
    .LogCommand()
    .ExecuteAsync<Guid>(this.CancellationToken);

if(secondaryProcessID == Guid.Empty)
{
    this.AddError($"Не найден вторичный процесс для задания с ИД = {task.RowID:B}.");
    return;
}

// Получение значения из хранилища с дополнительной информацией по найденному вторичному процессу.
var processInfo = await this.GetSecondaryProcessInfoAsync(secondaryProcessID);
var comment = processInfo.Get<object>("Comment");

// Установка значения в карточке задания.
task.Card.Sections[KrConstants.KrTask.Name].Fields[KrConstants.KrTask.Comment] = comment;

Установка примеров¶

Warning

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

Загрузите библиотеку примеров по ссылке RoutingSamples.zip.

Для ее установки нужно:

Установить библиотеки схемы “ExamplesBase” и “RoutingSamples” из папки “Scheme”.
Импортировать типы карточек из папки “Types”, представления из папки “Views” и рабочие места из папки “Workplaces”.
Установить библиотеку карточек “RoutingSamples.cardlib” из папки “Cards”. Она включает в себя все необходимые маршруты, кнопки, шаблоны и подразделения.

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

Убедитесь, что сотрудник, от которого выполняются примеры — входит в какое-нибудь подразделение, и у этого подразделения задан руководитель. В сценариях прохождения примеров мы рассчитываем, что все роли выполняет один и тот же человек (для удобства и простоты), но вы разумеется, можете включить любых пользователей в процесс.
Убедитесь, что в справочнике сотрудников есть сотрудник “Admin” (с идентификатором “3db19fa0-228a-497f-873a-0250bf0a4ccb”), который автоматически создается при установке системы на новую БД. При импорте некоторых объектов, таких как шаблоны карточек — он указан как владелец шаблона.
Проверьте, что для типа карточки “Протокол” (правая панель → Настройки → Типовое решение) в настройках типового решения и для типа документа “Служебная записка” (рабочее место Администратор → Типовое решение → Типы документов → Служебная записка) установлен флажок “Использовать маршруты”.
При импорте библиотеки карточек для примеров, у вас создадутся несколько подразделений, которые используются в настройках маршрутов. Если вы не хотите их использовать, то:
- В карточке шаблона этапов “st: СЗ согласование” в этапе “Согласование с руководителем и фин. департаментом” укажите вместо подразделения “Финансовый департамент” (т.к. у вас не существует подразделения с таким идентификатором) — любое подразделение или роль, существующие в вашей системе.
- В карточке шаблона этапов “st: СЗ исполнение” укажите в этапах “Исполнение финансовой СЗ” и “Исполнение обычной СЗ” любых исполнителей вместо указанных в них ролей “Департамент обеспечения” и “ДИТ” (т.к. у вас не существует подразделения с таким идентификатором).
Добавьте в настройки типового решения тип карточки Мероприятие:

В настройках типа карточки выставьте настройки, как на рисунке ниже:

Настройка маршрутов пользователем¶

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

Добавление новых этапов в маршрут.
Изменение существующих этапов.
Изменение порядка этапов.
Пропуск этапов.

Изменение маршрута выполняется на вкладке “Маршрут” карточки документа. Чтобы определить, какие возможности есть у пользователя, система проверяет следующие правила:

Наличие права “Редактирование маршрута”, согласно правилам доступа — для текущего типа и состояния карточки. Обратите внимание, что для объектов в состоянии отличном от “Проект”, необходимо сначала нажать тайл “Редактировать”. Если права “Редактирование маршрута” у пользователя нет — никакие возможности изменения маршрута не доступны. Если есть, то появляются описанные далее возможности.
В настройках группы этапов может быть указано, что группа нередактируемая. Тогда пользователь не сможет добавить новых этапов в эту группу и не сможет поменять настройки или порядок существующих этапов.
Если в настройках группы этапов указано, что группа редактируемая, то пользователь может добавить в эту группу новые этапы, согласно настройкам в справочнике настроек типового решения (см. далее).
Если в настройках группы указано, что группа редактируемая, то возможность редактирования или изменения порядка этапов, заданных в шаблонах этапов, будет зависеть от настроек, заданных в шаблоне этапов.

Справочник настроек этапов маршрута¶

Этот справочник позволяет настроить — каким пользователям в какие группы этапов и что (какие этапы) можно добавлять. Например, логично разрешить в группу этапов “Согласование” добавлять только этапы согласования. Редактировать справочник может только администратор.

Справочник расположен в справочнике настроек типового решения (правая панель → Настройки → Типовое решение) на вкладке “Дополнительно”.

Каждая строка в справочнике задает одно правило. В правиле можно указать:

Типы документов — для каких типов документов работает правило.

Группы этапов — в какие группы этапов будет разрешено добавлять этапы. Пользователь увидит эти группы этапов в диалоге добавления этапа.

Типы этапов — какие типы этапов разрешено добавлять в указанные выше группы. Пользователь увидит список этих типов этапов в диалоге добавления этапа.

Роли — любые роли в системе, кроме контекстных. Это поле определяет, кому именно разрешено добавлять указанные выше типы этапов. Если пользователь входит хотя бы в одну из перечисленных тут ролей, данное правило будет для него работать.

Когда пользователь нажимает кнопку “Добавить” на вкладке “Маршрут” система проверяет, разрешено ли ему добавлять этапы вообще (согласно вышеописанным правилам), а затем покажет список доступных для добавления групп и типов этапов, рассчитанный согласно настройкам, заданным в данном справочнике.

Tip

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

Настройка маршрутов администратором¶

Различные объекты подсистемы маршрутов доступны администратору системы в рабочем месте “Администратор” в папке “Маршруты”.

Карточка “Группа этапов”¶

Группа этапов объединяет несколько связанных по смыслу шаблонов этапов в группу маршрута. Обычно группы представляет крупные части маршрута, например “Подготовка”, “Согласование” или “Исполнение”.

Создать карточку группы этапов мы можете через правую панель “Создать карточку → Маршруты → Группа этапов” или нажав на кнопку на панели пейджинга в представлении “Шаблоны этапов”.

Основная информация.

Название — название карточки для отображения в списках.
Описание — подробный комментарий к группе.
Порядок — целое число, которое определяет положение данной группы в общем маршруте. Должно быть уникальным. Система при построении маршрута упорядочивает группы именно по этому числу.
Все этапы нередактируемые — если флажок установлен, то пользователь при работе с маршрутом на вкладке “Маршрут” не сможет менять этапы в этой группе.
Игнорировать при пересчёте — если флажок установлен, данная группа этапов будет игнорироваться при пересчёте.
Вторичный процесс — ссылка на тайл процесса, с которым связана группа. Если ссылка установлена, то группа не попадает в основной маршрут карточки. Она будет подставлена в маршрут, выполняемый по нажатию соответствующего тайла. С одним тайлом может быть связано сколько угодно групп.

Ограничения при пересчете.

Типы — перечисление типов документов или карточек, в маршрут которых может быть подставлена данная группа. Если не указаны, то для всех типов. Если группа связана с глобальным тайлом, то значение этого поля игнорируется.
Роли — группа будет подставлена в маршрут, если текущий пользователь (который нажимает тайл или запускает процесс) входит в любую из указанных ролей. Если роли не указаны, они не проверяются.

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

Построение маршрута. В данной группе находятся условия и сценарии, выполняемые в момент построения маршрута.

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

SQL условие — позволяет задать условие подстановки группы в маршрут при помощи sql-скрипта. Вычисляется при построении маршрута.

Запрос должен возвращать ноль или одну строку и строго одну колонку. Истинным значением считается запрос, возвращающий 1. Ложным значением считается запрос, вернувший 0 строк или строку со значением 0 или NULL. Запрос, возвращающий более одной строки и более одного столбца, является некорректным.

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

#user_id — идентификатор текущего пользователя.
#user_name — имя текущего пользователя.
#card_id — идентификатор карточки, для которой производится расчет.
#card_type_id — идентификатор типа карточки, для которой производится расчет.
#doc_type_id — идентификатор типа документа текущей карточки или значение null, он не задан для карточки.
#type_id — идентификатор типа документа текущей карточки, если он не известен, то идентификатор типа карточки.
#doc_state — целое число, идентификатор состояния текущей карточки.
#stage_group_id — идентификатор текущей группы.

Условное выражение — позволят задать условие подстановки группы в маршрут по правилам написания логических выражений языка C#. Доступные в контексте поля и объекты описаны в разделе Особенности работы сценариев и рекомендации по их использованию. Чаще всего используется объект Tessa.Cards.Card, возвращаемый методом IKrScript.GetCardObjectAsync(), через который можно проверить (а в обычных сценариях и поменять) данные текущей карточки.

Инициализация — это сценарий, выполняемый перед построением маршрута.

Постобработка — это сценарий, выполняемый после того, как маршрут построен.

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

На вкладке Условие можно задать условие, которое определяет, выполнится ли эта группа, когда маршрут до нее дойдет.

SQL условие — условие можно задать в форме запроса SQL.
Условное выражение — в этом поле можно задать условие в синтаксисе C#.

Инициализация — это сценарий, выполняемый перед выполнением этапов группы.

Постобработка — это сценарий, выполняемый после того, как этапы группы выполнены.

Порядок построения маршрута и выполнения сценариев и проверки условий описан в данном разделе. Подробно про написание условий и сценариев для объектов маршрута рассказано в данном разделе.

Карточка “Шаблон этапов”¶

Новая карточка шаблона этапов создается из правого меню Создать карточку → Маршруты → Шаблон этапов. В новой вкладке будет открыта карточка:

Описание полей карточки:

Вкладка Карточка:

На данной вкладке указываются основные настройки и условия для подстановки этапов из текущего шаблона в карточку документа.

Название — уникальное название карточки шаблона этапов.
Описание — описание карточки, указывается при необходимости.
Положение относительно этапов, добавленных вручную — указывается, в начало или в конец маршрута в карточке документа добавить этапы из данного шаблона.
- “В начале группы” — этапы этого шаблона в маршруте документа будут всегда в начале своей группы. Добавленные пользователем вручную этапы будут всегда идти после них.
- “В конце группы” — то этапы из этого шаблона в карточке документа фиксируются в конце своей группы и, даже если пользователь после пересчета вручную будет добавлять новые этапы, они добавятся не в конец списка (как это привычно), а будут расположены в списке перед этапами из шаблона.
Порядок — номер порядка для данного шаблона. Актуально, если есть несколько шаблонов с одинаковыми настройками, тогда этапы из этих шаблонов будут добавляться в указанном порядке, т.е.: сначала этапы из шаблона с порядком 0, потом из шаблона с порядком 1 и т.д.

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

Шаблон 1: положение — в конце группы, порядок = 0, можно перемещать = нет;
Шаблон 2: положение — в конце группы, порядок = 1, можно перемещать = нет.

Пересчитываем маршрут в карточке договора и в результирующем маршруте порядок этапов такой:

Этап, добавленный вручную.
Шаблон 1.
Шаблон 2.

Мы видим, что добавился сначала этап из шаблона с порядком 0, после него этап из шаблона с порядком 1. Оба они в конце маршрута относительно этапов, добавленных пользователем вручную.

Однако, если в Шаблоне 1 мы выставим флаг “Можно перемещать” и пересчитаем маршрут в карточке договора, увидим, что результирующий маршрут изменился:

Этап, добавленный вручную.
Шаблон 2.
Шаблон 1.

Это связано с тем, что указанный в шаблонах порядок используется системой для сортировки этапов только в случае, когда настройки в полях “Положение” и “Можно перемещать” — одинаковы. В примере выше в одном из шаблонов мы изменили настройку “Можно перемещать” и система отсортировала этапы в соответствии с заложенным алгоритмом:

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

В пределах каждой подгруппы этапы сортируются по значению поля “Порядок”.

Этапы нередактируемые — при выставленном флаге сотрудник не сможет редактировать параметры этапов, которые были добавлены в карточку документа автоматически на основании данного шаблона (даже если у сотрудника, в соответствии с настроенными правилами доступа, есть разрешение на редактирование маршрута). Администратору также будет недоступно редактирование таких этапов в карточке документа.

Можно перемещать — при выставлении флага сотрудник сможет перемещать этапы, которые были добавлены в карточку документа автоматически из данного шаблона (при наличии прав доступа на редактирование маршрута).

Warning

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

Группа — группа, в которую входит этап. Каждый этап должен входить в группу.

Типы — список типов карточек, для которых данный шаблон этапов включается в маршрут. Если поле не заполнено, то данный шаблон будет действовать для всех типов документов.

Список ролей — список ролей, которым будет доступен данный шаблон этапов. Т.е. только для указанных сотрудников при расчете маршрута или его части будут подставляться этапы из данного шаблона (при выполнении всех других условий шаблона). Если поле не заполнено, то данный шаблон будет действовать для всех пользователей.

В поле можно указать как конкретных сотрудников, так и роли или подразделения.

SQL-условие — условие, задаваемое через SQL-запрос. Вычисляется при построении маршрута.

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

#user_id — идентификатор текущего пользователя.
#user_name — имя текущего пользователя.
#card_id — идентификатор карточки, для которой производится расчет.
#card_type_id — идентификатор типа карточки, для которой производится расчет.
#doc_type_id — идентификатор типа документа текущей карточки или значение null, он не задан для карточки.
#type_id — идентификатор типа документа текущей карточки, если он не известен, то идентификатор типа карточки.
#doc_state — целое число, идентификатор состояния текущей карточки.
#stage_template_id — идентификатор текущего шаблона этапов.
#stage_group_id — идентификатор текущей группы.
#stage_type_id — идентификатор типа этапа.

Условное выражение. Пишется по правилам написания логических выражений языка C#. Доступные в контексте поля и объекты описаны в разделе Особенности работы сценариев и рекомендации по их использованию. Чаще всего используется объект Tessa.Cards.Card, возвращаемый методом IKrScript.GetCardObjectAsync(), через который можно проверить (а в обычных сценариях и поменять) данные текущей карточки.

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

Вкладка Маршрут:

На вкладке настраиваются этапы, которые будут подставлены в маршрут документа при выполнении всех условий данного шаблона.

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

Доступные типы этапов описаны в разделе Типы этапов.

Вкладка Результат компиляции.

На данной вкладке отображается информация (т.е. лог) по выполнению компиляции текущего шаблона и всех шаблонов и методов. Компиляцию можно выполнить, нажав на нужной вкладке кнопку “Выполнить компиляцию” или на кнопку “Проверить скрипты”, расположенную в левом меню системы (по данной кнопке выполняется компиляция всех шаблонов и методов).

“Частичная” компиляция (т.е. компиляция на вкладке “Этот сценарий”) используется для проверки сценариев из этого шаблона, а также из всех методов расширений. “Полная” сборка (вкладка “Все сценарии”) компилирует все шаблоны и все методы.

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

При компиляции не выполняется проверка SQL запросов.

Карточка “Вторичный процесс”¶

При помощи карточки “Вторичный процесс” можно описать новый процесс, который можно запускать в карточке независимо от основного, отображенного на вкладке “Маршрут”, или глобально, т.е. вне контекста карточки. Такой маршрут может выполнять любые действия — управлять основным процессом (отозвать, выполнить переход и т.п.), манипулировать данными текущей карточки, запускать новые процессы, отправлять задания и так далее.

Вторичный процесс поддерживает несколько режимов:

Простой процесс — процесс, который можно запускать в расширениях или скриптах.
Кнопка — процесс, запускаемый по плитке в левой (локальной) или в правой (глобальной) панели.
Действие — процесс, запускаемый по какому-либо событию

Основные настройки и выбор режима:

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

Описание — подробное описание нюансов этого вторичного процесса. Полезно для комментирования.

Режим — выбор режима вторичного процесса. В зависимости от режима отображаются специфичные настройки.

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

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

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

Группы этапов вторичного процесса — список, показывающий все группы, относящиеся к данному вторичному процессу. Список является неизменяемым, вторичный процесс для группы устанавливается в настройках карточки группы.

Сообщение при недоступности для выполнения — сообщение, которое выводится пользователю, если проверка при запуске процесса выполнилась неуспешно. При запуске процесса проверяется тип карточки (поле Типы), состояние карточки (поле Состояния карточек), различные роли (поля Роли, Контекстные роли) и сценарии из группы Дополнительные настройки выполнения (SQL условие и условное выражение C#). Например, Выполнить это действие может только инициатор процесса. Обратитесь к Васильеву В.В..

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

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

Роли — текущий пользователь должен входить в одну из этих ролей, чтобы запустить процесс. Доступны только роли, имеющие постоянный состав: сотрудник, подразделение, группа, динамическая роль. Позволяет ограничить видимость тайла. Проверки контекстных ролей, например “Инициатор”, выполняются при запуске процесса (см. поле Доступно ролям). Это сделано для того, чтобы гарантировать быстрое открытие карточки или клиента. Вычисление контекстных ролей может занимать какое-то время и замедлять открытие карточки. Выполнять их каждый раз при открытии неэффективно.

Состояния карточек — в каких состояниях карточек процесс доступен для запуска (видима кнопка). Применимо только к контекстным процессам и игнорируется для глобальных.

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

Режим “Простой процесс”¶

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

Проверять ограничения при пересчете — необходимо ли проверять ограничения, указанные в блоке “Ограничения при пересчете”. Настройка актуальна, только если запуск с клиента запрещен.

Режим “Кнопка”¶

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

Это очень удобно, если маршрут написан так, что отправляет текущему пользователю какое-то задание. Сразу после выполнения пользователь увидит, что ему пришло новое задание.

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

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

Значок — алиас иконки для этого тайла. Доступные иконки вы можете увидеть в файле Thin Icons.png в папке с документацией в архиве с релизом платформы.

Сочетание клавиш — горячие клавиши, при нажатии на которые происходит выполнение действия плитки.

Размер плитки — размер плитки.

Порядок — определяет порядок сортировки плиток. Плитки сортируются в порядке возрастания номера.

Текст подтверждения — вопрос, который нужно задать пользователю. Подтверждение будет показано, только если установлен флажок Спрашивать подтверждение.

Всплывающая подсказка — подсказка, которую увидит пользователь, если задержит мышь на тайле на полсекунды.

Группировать в “Действия” — тайл (вместе с группой, если она задана), будет отображаться в группе “Действия” контекстной панели. Применимо только для контекстных тайлов.

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

Дополнительные настройки видимости — SQL условие и условное выражение C# определяющие видимость тайла вторичного процесса.

Режим “Действие”¶

Тип события — событие, по которому будет запущен маршрут. Доступны следующие события:

Создание карточки — запуск маршрута при создании карточки.

Аналогично методу расширения CardNewExtension.AfterRequest.

Тип значения свойства IKrScript.CardContext: ICardNewExtensionContext.

Созданную карточку можно получить следующим образом: IKrScript.GetCardObjectAsync().
Перед сохранением карточки — запуск маршрута перед сохранением карточки.

Аналогично методу расширения CardStoreExtension.BeforeRequest.

Тип значения свойства IKrScript.CardContext: ICardStoreExtensionContext.

Карточку можно получить следующим образом: IKrScript.GetCardObjectAsync(). В пакете карточки присутствуют только изменения.

Данный тип события может быть полезен для проверок и дополнительной валидации данных.
Сохранение карточки — запуск маршрута при сохранении карточки.

Аналогично методу расширения CardStoreExtension.BeforeCommitTransaction.

Тип значения свойства IKrScript.CardContext: ICardStoreExtensionContext.

Карточку можно получить следующим образом: IKrScript.GetCardObjectAsync(). Выполнение указанного метода приведёт к загрузке карточки, если она до этого не выполнялась.

В данном событии можно запускать более сложные маршруты, в т.ч. отправляющие задания.
Перед завершением задания — запуск маршрута при завершении задания (выборе одного из варианта завершения, в т.ч. с выставленным флажком “Не удалять задание”).

Аналогично методу расширения CardStoreTaskExtension.StoreTaskBeforeRequest.

Тип значения свойства IKrScript.CardContext: ICardStoreTaskExtensionContext.

Получить задание можно следующим образом:
```
var task = ((ICardStoreTaskExtensionContext) this.CardContext).Task;
```
Карточку можно получить следующим образом: IKrScript.GetCardObjectAsync(). В пакете карточки присутствуют только изменения.
Завершение задания — запуск маршрута при завершении задания (выборе одного из вариантов завершения, в т.ч. с выставленным флажком “Не удалять задание”).

Аналогично методу расширения CardStoreTaskExtension.StoreTaskBeforeCommitTransaction.

Тип значения свойства IKrScript.CardContext: ICardStoreTaskExtensionContext.

Получить задание можно следующим образом:
```
var task = ((ICardStoreTaskExtensionContext) this.CardContext).Task;
```
Карточку можно получить следующим образом: IKrScript.GetCardObjectAsync(). Выполнение указанного метода приведёт к загрузке карточки, если она до этого не выполнялась.
Перед созданием задания — запуск маршрута при создании задания.

Аналогично методу расширения CardStoreTaskExtension.StoreTaskBeforeRequest.

Получить задание можно следующим образом:
```
var task = ((ICardStoreTaskExtensionContext) this.CardContext).Task;
```
Карточку можно получить следующим образом: IKrScript.GetCardObjectAsync(). В пакете карточки присутствуют только изменения.
Создание задания — запуск маршрута при создании задания.

Аналогично методу расширения CardStoreTaskExtension.StoreTaskBeforeCommitTransaction.

Получить задание можно следующим образом:
```
var task = ((ICardStoreTaskExtensionContext) this.CardContext).Task;
```
Карточку можно получить следующим образом: IKrScript.GetCardObjectAsync(). Выполнение указанного метода приведёт к загрузке карточки, если она до этого не выполнялась.

Далее следуют скрипты, определяющие возможность выполнения процесса, а также видимости кнопки (если для вторичного процесса указан режим “Кнопка”).

SQL условие — запрос, вычисляющийся при расчете видимости плитки или выполнения вторичного процесса. Запрос должен возвращать ноль или одну строку и строго один столбец. Истинным значением считается запрос, возвращающий 1. Ложным значением считается запрос, вернувший 0 строк или строку со значением 0 или NULL. Запрос, возвращающий более одной строки и более одного столбца, является некорректным.

Список доступных для всех видов процессов плейсхолдеров:

#user_id — идентификатор текущего пользователя.
#user_name — имя текущего пользователя.
#button_id — идентификатор карточки, текущего вторичного процесса.

Следующие плейсхолдеры доступны только в контекстных процессах:

#card_id — идентификатор карточки, для которой производится расчет.
#card_type_id — идентификатор типа карточки, для которой производится расчет.
#doc_type_id — идентификатор типа документа текущей карточки или значение null, он не задан для карточки.
#type_id — идентификатор типа документа текущей карточки, если он не известен, то идентификатор типа карточки.
#doc_state — целое число, идентификатор состояния текущей карточки.

Условное выражение — условное выражение в синтаксисе C#. Если истинно, то тайл будет виден или процесс запущен. Например, тайл, который виден, если сумма договор больше 100000.

(await GetCardAsync()).DocumentCommonInfo.Amount > 100000

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

Обращаем ваше внимание, что сценарии предназначены именно для проверки видимости или возможности выполнения процесса. Если вы хотите по нажатию на тайл выполнить какой-то сценарий, правильнее сделать маршрут из одного этапа “Сценарий” и выполнять его по нажатию тайла.

Карточка “Метод расширения”¶

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

Новая карточка метода расширения создается из правого меню Создать карточку → Маршруты → Метод расширения. В новой вкладке будет открыта карточка:

Описание полей карточки:

Вкладка Карточка:

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

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

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

#using System.Threading;
#using Tessa.Notices;

public const string MessageFormat = @"
<html>
<body>
  Это письмо предназначено для {0}.
</body>
</html>
";

public async Task SendNotificationExampleAsync(CancellationToken cancellationToken = default)
{
  IMailService service = this.Resolve<IMailService>(MailServiceNames.WithoutTransaction);

  var query =
    this.DbScope
      .BuilderFactory
      .SelectDistinct()
      .C("pr", "Email")
      .From("PersonalRoles", "pr").NoLock()
      .InnerJoin("RoleUsers", "ru").NoLock()
      .On().C("ru", "ID").Equals().C("pr", "ID")
      .InnerJoin("DocumentCommonInfo", "dci").NoLock()
      .On().C("dci", "AuthorID").Equals().C("ru", "ID")
      .Where()
      .C("dci", "ID").Equals().P("cardID")
      .And()
      .C("pr", "Email").IsNotNull()
      .Build();

  this.Db.SetCommand(query, Db.Parameter("cardID", CardID));
  var emails = await this.Db.ExecuteListAsync<string>(cancellationToken);
  Show(emails.Count.ToString());
  foreach (var email in emails)
  {
    await service.PostMessageAsync(email, "Важное письмо", string.Format(MessageFormat, email), this.ValidationResult, cancellationToken: cancellationToken);
  }
}

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

...
await this.SendNotificationExampleAsync(this.CancellationToken);
...

Обратите внимание, что отправлять уведомления лучше с использованием стандартного этапа “Отправка уведомления” и карточки “Уведомление” (см соответствующий раздел документации).

Вкладка Результат компиляции

На данной вкладке отображается информация (т.е. лог) по выполнению компиляции текущего метода и всех шаблонов и методов. Компиляцию можно выполнить нажав на нужной вкладке кнопку “Выполнить компиляцию” или на кнопку “Проверить скрипты”, расположенную в левом меню системы (по данной кнопке выполняется компиляция всех шаблонов и методов).

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

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

Карточки маршрутов, входящие в типовую конфигурацию¶

В типовую конфигурацию Tessa входят следующие карточки маршрутов:

Вторичные процессы
- Вернуть документ на доработку — кнопка для прерывания основного процесса и возврата в начало группы (в типовой конфигурации это формирование нового цикла согласования и отправка задания на доработку).
- Ветка протокола — вторичный процесс, вызываемый из вторичного процесса “Разослать задачи по решениям”. Отправляет задачи по таблице “Решения” карточки протокола.
- Запустить процесс — кнопка запуска основного процесса.
- Зарегистрировать документ — регистрирует документ, отзывает активные задания, выполняет переход на следующую группу — всё это выполняется в основном процессе.
- Отменить процесс — кнопка для прерывания основного процесса и перехода в состояние “Отмена”.
- Отменить регистрацию — кнопка отмены регистрации.
- Отозвать процесс — кнопка для прерывания основного процесса и перехода в состояние “Проект”.
- Разослать задачи по решениям — кнопка для запуска вторичного процесса рассылки задач по Протоколу.
Группы этапов
- Согласование — типовая группа, которая по умолчанию доступна пользователям для добавления этапов. В эту группу входят все типовые шаблоны этапов.
Шаблоны этапов
- Возврат на доработку — шаблон этапов, обычно расположен в конце группы. Выполняет проверку, были ли отрицательные визы на каком-либо этапе Согласования или Подписания в текущей группе и если были, выполняет возврат в начало текущей группы.
- Доработка — шаблон этапов, обычно расположен в начале группы (но после шаблона “Новая итерация согласования”), содержащий этап Доработки. Необходим для отправки задания доработки по документу в случае несогласования или неподписания документа.
- Новая итерация согласования — шаблон этапов, обычно расположен в начале группы (перед шаблоном “Доработка”), необходим для корректной группировки записей в истории заданий по циклам, а именно для формирования нового цикла процесса в случае возврата на доработку.

Состояние процесса, состояние этапа и настройки этапа¶

Состояние процесса — это набор параметров, предназначенных для использования в качестве универсального хранилища любых данных, нужных при работе процесса — сценариям, этапам, группам и т.д. Технически это hash, т.е. набор элементов вида “Ключ: Значение”, где значением может быть скаляр, массив или вложенный хэш, что позволяет хранить там данные любой сложности и вложенности. Обращаться к этим данным могут любые этапы и сценарии. У каждого процесса маршрута, первичного или вторичного, своё отдельное состояние. Оно создается в момент первого обращения к нему и далее системой никогда не очищается. Хранится состояние процесса в сериализованном в json виде в поле ApprovalCommonInfo.Info.

Например:

{
  "Cycle::int":3,
  "CurrentPerformer::int":1,
  "TotalPerformers::int":1
}

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

{
  // Добавим параметр "HasFinancialGroud" и установим ему значение
  ProcessInfo.HasFinancialGround = false

  // Проверка значения
  if (ProcessInfo.HasFinancialGround == false)
  {
    ...
  }
}

Состояние этапа — аналогично состоянию процесса, это hash, но относится он к конкретному этапу процесса. Создается он в момент добавления этапа в маршрут и далее никогда не очищается. При этом, разумеется, если этап в какой-то момент был удален из маршрута, а потом добавлен заново — у него будет новое состояние. Как и состояние процесса, состояние этапа доступно из сценариев данного этапа (а при необходимости и из любых других сценариев маршрута) и предназначено для хранения информации, специфичной для конкретного этапа и его сценариев. Также, через состояние этапа он может обмениваться полезной информацией со сценариями в этом этапе. Состояние этапа хранится в сериализованном виде в json формате в поле KrStages.Info.

Например, этап создания карточки записывает идентификатор только что созданной карточки в состояние этапа в поле с именем “cardID” и сценарий постобработки может обратиться к этой информации:

// Выведем идентификатор созданной карточки в отладочное сообщение.
Show((Guid)StageInfo.cardID);

Настройки этапа — это тоже hash, в котором хранятся все настройки этапа, которые доступны в пользовательском интерфейсе. Абсолютно все поля и параметры, которые там можно задать — хранятся в настройках этапа. Как и состояние, настройки этапа доступны для чтения и изменения любым сценариям. Типичное их использование — это в сценарии инициализации динамически рассчитать и задать какие-то параметры этапа, которые было невозможно сразу задать в пользовательском интерфейсе. Изменять можно абсолютно все параметры, которые вы видите в пользовательском интерфейсе этапа.

Вот пример сценария, который меняет текст задания перед его отправкой в этапе “Задача”.

Stage.Settings.KrResolutionSettingsVirtual__Comment = "Не забудьте приложить файл.";

В базе данных настройки этапа тоже хранятся в сериализованном в json виде в поле KrStages.Settings.

Note

Чтобы узнать, как называется тот или иной параметр, поменяйте его в интерфейсе этапа, закройте форму этапа и нажмите [Ctrl]+[G] для просмотра структуры изменённой карточки. На изображении ниже приведен пример того, что вы увидите, если измените состояние флажка “Отдельная задача каждому исполнителю” в этапе Задача. В настройках этот флажок доступен по имени “KrResolutionSettingsVirtual__MassCreation”.

Обратите внимание на тот факт, что некоторые из настроек доступны не в объекте Stage.Settings, а напрямую в текущем контексте. Например, чтобы изменить срок задания, можно написать просто TimeLimit = 3;. Подробности описаны в следующем разделе.

Особенности работы сценариев и рекомендации по их использованию¶

Сценарии в системе маршрутов могут быть следующие:

В тайле можно задать сценарий (условие) видимости и сценарий, который выполняется при нажатии на тайл.

Сценарии, выполняемые при построении маршрута:

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

Сценарии, выполняемые при прохождении маршрута:

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

Все сценарии выполняются на серверной стороне.

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

Warning

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

Если при выполнении не удаётся найти класс содержащий сценарий относящийся к запрашиваемому объекту, то, в этом случае, создаётся исключение с текстом ошибки:

Пример текста ошибки при отсутствии класса содержащего скрипт объекта

Класс KrRuntime_Stage_4fe70ef042a94f809d2a07be17a46512 не найден. Проверьте наличие указанного объекта в системе.
Более подробно см. Руководство администратора -> Маршруты документов -> Особенности работы сценариев и рекомендации по их использованию.
Проверьте вывод компилятора на наличие ошибок компиляции.

Имя класса имеет следующий формат: <Префикс объекта>_<Алиас объекта>_<Идентификатор объекта>.

Идентификаторы используемые при компиляции скриптов маршрутов содержатся в классе Tessa.Extensions.Default.Server.Workflow.KrCompilers.SourceBuilders.SourceIdentifiers.

Доступные префиксы объектов:

SourceIdentifiers.KrStageCommonClass – Имя базового класса для классов, содержащий методы расширения.
SourceIdentifiers.KrDesignTimeClass – Имя класса, содержащего сценарий построения маршрута.
SourceIdentifiers.KrRuntimeClass – Имя класса, содержащего сценарий выполнения маршрута.
SourceIdentifiers.KrVisibilityClass – Имя класса, содержащего сценарий условия видимости.
SourceIdentifiers.KrExecutionClass – Имя класса, содержащего сценарий условия выполнимости процесса.

Доступные алиасы объектов:

SourceIdentifiers.StageAlias – Алиас генерируемого класса, содержащего скрипты этапа.
SourceIdentifiers.TemplateAlias – Алиас генерируемого класса, содержащего скрипты шаблона этапов.
SourceIdentifiers.GroupAlias – Алиас генерируемого класса, содержащего скрипты группы этапов.
SourceIdentifiers.SecondaryProcessAlias – Алиас генерируемого класса, содержащего скрипты вторичного процесса.

Идентификатор объекта.

Уникальный идентификатор объекта: этапа в карточке шаблона этапов, шаблона этапов, группы этапов или вторичного процесса.

Можно выделить следующие основные рекомендации и нюансы работы сценариев.

Сценарии, выполняемые при расчете маршрута:

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

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

Постобработка выполняется при построении маршрута, получает маршрут и может его как угодно изменять. Например, удалить повторяющихся согласующих в случае, если несколько шаблонов с одним и тем же согласующим сработали сразу. Или динамически вычислить и добавить этап в маршрут согласования. Или удалить лишние этапы.
При расчете условий сначала выполняется “Условное выражение”, если оно успешно (или не задано), то после выполняется SQL-условие, и в случае, если и оно успешно (или не задано) — этапы из шаблона будут добавлены.

Т.е. шаблон/группа “сработает” и добавит этапы в карточку документа только в случае успешного выполнения и C# условия, и SQL-условия или если данные поля (или поле) пустые.
Постобработка выполняется всегда, включая случаи, когда шаблон не подтвержден (т.е. если не выполнено C# или SQL условия). Это может использоваться для принятия каких то решений в зависимости от подтверждения самого шаблона: если подтвержден выполнить какое-то действие, если не подтвержден — другое.

Сценарии, выполняемые при проходе маршрута.

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

Сценарии в тайлах:

Сценарий видимости должен работать как можно быстрее. В нем запрещено выполнять какие-либо сложные или длительные действия, т.к. это влияет на скорость и даже возможность открытия карточки.
Сценарии проверки при нажатии предназначен для более сложных проверок, которые неоптимально делать при загрузке карточки. Но тем не менее, не перегружайте его функциональностью. Если вам нужно выполнить что-то сложное при нажатии на тайл — свяжите с тайлом маршрут и выполните нужные вам действия в этапе “Сценарий” в этом маршруте.

В любой ситуации, если хотите отменить текущую операцию (построение маршрута, запуск процесса, завершение этапа), выполните сценарий примерно такого вида:

AddError("Пожалуйста, заполните категорию!");

Также все приведённые ниже свойства и методы описаны в интерфейсе IKrScript в расширениях типового решения в файле Source/Extensions/Tessa.Extensions.Default.Server/Workflow/KrCompilers/UserAPI/IKrScript.cs и в документации по API: IKrScript.

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

if (Stage.State == KrStageState.Inactive)
{
  Show("Отозвано");
}
else if (Stage.State == KrStageState.Skipped)
{
  Show("Пропущено");
}
else if (Stage.State == KrStageState.Completed)
{
  Show("Завершено");
}

Отозвано может быть при отзыве/отмене
Пропущено при регистрации с активным этапом
Завершено при согласовании/несогласовании

Написание сценариев для объектов маршрута¶

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

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

Для проверки скриптов на ошибки необходимо нажать тайл “Проверить скрипты” в левой панели, сочетание клавиш [Ctrl]+[Alt]+[B] или нажать кнопку “Выполнить компиляцию” на вкладке “Результат компиляции”.

В случае успешной компиляции:
В случае наличия ошибок компиляции:

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

Обратите внимание, что если при попытке открыть карточку или запустить процесс появляется сообщение об ошибке “Сборка не найдена. Проверьте вывод компилятора на наличие ошибок компиляции.”, то для поиска точного местоположения ошибки необходимо перейти на вкладку “Результат компиляции” любой карточки, содержащей данную вкладку, а затем выбрать вкладку “Все сценарии” и нажать кнопку “Выполнить компиляцию”. Будет произведена компиляция всех скриптов в системе и выведены ошибки.

Ниже информация о свойствах контекста, которые доступны во всех скриптах:

Информация о выполняемом этапе

Stage (тип значения Stage) — объектная модель текущего выполняемого этапа. В ней содержится полная информация о текущем выполняемом этапе, включая его настройки. Более подробная информация об объекте этапа.
StageInfo (тип значения dynamic) — алиас для Stage.Info.

Информация о процессе

ProcessID (тип значения Guid) — идентификатор процесса. Используется только для асинхронных процессов.
ProcessTypeName (тип значения string) — тип процесса. Может принимать значения KrProcess и KrSecondaryProcess.
WorkflowProcess (тип значения WorkflowProcess) — объектная модель процесса. Более подробная информация об объекте процесса.
Stages (тип значения SealableObjectList<Stage>) — список этапов в процессе. Алиас для WorkflowProcess.Stages.
CurrentStages (тип значения Stage) — подсписок этапов в маршруте. В зависимости от контекста выполнения содержит разные выборки. Данный массив является неизменяемым, однако его элементы могут быть отредактированы.
- Скрипт этапа — массив из одного элемента (текущий этап).
- Скрипт шаблона этапов — массив из этапов текущего шаблона.
- Скрипт группы этапов — массив из этапов текущей группы.
ProcessInfo (тип значения dynamic) — состояние процесса. Алиас для WorkflowProcess.Info.
GetCycleAsync() (тип возвращаемого значения int) и SetCycleAsync(int newValue) — методы позволяющие получить или задать номер текущего цикла. Представляют собой типизированный интерфейс для получения/записи значения в ProcessInfo для основного процесса или для доступа к контекстуальному сателлиту в котором хранится значение для остальных типов процессов. Важно отметить, что номер цикла хранится в состоянии основного процесса, однако доступ к номеру цикла может быть осуществлён и во вторичных процессах, что приводит к десериализация и сериализация состояния основного процесса. Поэтому обращение к номеру цикла вне основного процесса является дорогостоящей операцией и должно быть максимально сокращено.
Initiator (тип значения Author) — сотрудник, инициатор (автор) процесса.
InitiatorComment (тип значения string) — комментарий к циклу согласования, указанный в карточке.

Информация о выполняемом шаблоне

TemplateID (тип значения Guid) — идентификатор карточки шаблона этапа.
TemplateName (тип значения string) — название карточки шаблона этапа.
Order (тип значения int) — позиция карточки шаблона этапа.
Position (тип значения GroupPosition) — положение относительно этапов, добавленных вручную. Может принимать значения:
- GroupPosition.AtFirst — для шаблонов в начале маршрута,
- GroupPosition.AtLast — для шаблонов в конце маршрута.
CanChangeOrder (тип значения bool) — флаг “Можно перемещать”.
IsStagesReadonly (тип значения bool) — флаг “Этапы нередактируемые”.

Информация о карточке

Карточка:

GetCardObjectAsync() (тип значения Tessa.Cards.Card) — асинхронно возвращает объект карточки, содержащий идентификатор, секции и другую информацию. Для получения полей строковых секций удобно использовать метод GetCardAsync() (см. ниже).
CardID (тип значения Guid) — идентификатор карточки.
CardTypeID (тип значения Guid) — идентификатор типа карточки.
CardTypeName (тип значения string) — название типа карточки.
CardTypeCaption (тип значения string) — название типа карточки (отображаемое).
GetVersionAsync() (тип значения int) — асинхронно возвращает версию карточки.

Поля в карточке, файлы:

GetCardAsync() (тип значения dynamic) — представление строковых секций карточки посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

Через данный метод удобно получать значения конкретных полей в строковых секциях карточки, например: (await GetCardAsync()).DocumentCommonInfo.Amount.
GetCardTablesAsync() (тип значения dynamic) — представление табличных секций карточки посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

Данный метод позволяет удобно получать строки из коллекционных секций, а также значения полей в строках, например: (await GetCardTablesAsync()).Recipients[0].UserID.
GetFilesAsync() (тип значения ListStorage<CardFile>) — асинхронно возвращает список файлов в карточке.

Задание:

CardTask — текущее завершаемое задание. Доступно, только если продвижение маршрута связано с завершением задания.

Сохранение, загрузка, валидация:

CardContext (тип значения: производные от ICardExtensionContext) — контекст сохранения или загрузки карточки, в зависимости от причины инициировавшей выполнение скриптов.
ValidationResult (тип значения IValidationResultBuilder) — результат валидации.

В него можно записывать данные, которые будут отображены пользователю после пересчета. Если указать результат валидации с уровнем Error, то пересчет будет считаться неудачным.
Info (тип значения Dictionary<string, object>) — дополнительная структура данных, которую можно использовать для хранения полезной информации.

Зависимости

Session (тип значения ISession) — сессия текущего пользователя. Используйте Session.User.ID, чтобы получить идентификатор текущего пользователя.
Db (тип значения DbManager) — объект, используемый для выполнения SQL-запросов к текущей БД.
- По умолчанию уже открыто соединение к основной БД системы, но посредством вызова using (DbScope.CreateNew("connectionAlias")) { ... } можно изменить базу данных, доступную по свойству Db, может быть изменена.
- Пример выполнения запроса: int result = await Db.SetCommand("select @Result", Db.Parameter("Result", 42)).LogCommand().ExecuteAsync<int>(CancellationToken);.
- Следует учесть, что Db.Parameter("Result", 0) ведет себя нелогично и определит параметр типа nvarchar со значением DbNull, т.к. будет использована некорректная перегрузка метода Db.Parameter(). В связи с этим добавьте преобразование типа значения к object: Db.Parameter("Result", (object)0).
DbScope (тип значения IDbScope) — объект, обеспечивающий доступ к базам данных.
- Позволяет открывать соединение к другим БД: await using (DbScope.CreateNew("connectionAlias")) { ... }.
- Также определяет тип СУБД, которая используется системой: DbScope.Dbms.
- Вместо вызова DbScope.Db для простоты рекомендуется использоваться свойство Db, описанное выше.
UnityContainer (тип значения IUnityContainer) — IoC-контейнер для получения любых необходимых зависимостей в рамках системы. Для более удобного использования есть метод Resolve<T>() о котором написано ниже.
CardMetadata (тип значения ICardMetadata) — содержит метаинформацию, необходимую для использования типов карточек совместно с пакетом карточек.
CardCache (тип значения ICardCache) — потокобезопасный кэш с карточками и дополнительными настройками.
KrTypesCache (тип значения IKrTypesCache) — кэш по типам карточек и документов, содержащих информацию по типовому решению.
KrScope (тип значения IKrScope) — объект, предоставляющий методы для работы с текущим контекстом подсистемы маршрутов, содержащим разделяемые карточки.
- Exists (тип значения bool) — признак того, что в данный момент существует KrScope.
- CurrentLevelID (тип значения Guid) — идентификатор текущего уровня вложенности.
- GetMainCardAsync(Guid mainCardID, IValidationResultBuilder validationResult = default, bool withoutTransaction = default, CancellationToken cancellationToken = default) (тип значения Card) — асинхронно возвращает основную карточку из Scope. Разрешено использовать только в BeforeCommitTransaction или позже. При первом обращении карточка будет загружена полностью, далее ее объект будет кэширован и после завершения обработки автоматически сохранен.
- GetKrSatelliteAsync(Guid mainCardID, IValidationResultBuilder validationResult = default, CancellationToken cancellationToken = default) (тип значения Card) — асинхронно возвращает основной сателлит Kr процесса. Рекомендуется использовать во всех расширениях на карточки, включенные в типовое решение вместо явной загрузки через ICardRepository.
- GetSecondaryKrSatelliteAsync(Guid processID, CancellationToken cancellationToken = default) (тип значения Card) — асинхронно возвращает сателлит вторичного процесса по идентификатору вторичного процесса.

Контроль выполнения шаблона

Confirmed (тип значения bool) — свойство, принимающее true, если этап был подтвержден (оба условия выполнились. Имеет смысл только в постобработке скриптов построения маршрута.
KrScriptType (тип значения KrScriptType) — свойство, описывающее текущее выполняемое действие. Может принимать следующие значения:
- KrScriptType.Before
- KrScriptType.Condition
- KrScriptType.After
- KrScriptType.ButtonVisibility
- KrScriptType.ButtonExecution

Методы, доступные в контексте¶

CardRowsAsync(string sectionName) (тип значения ListStorage<CardRow>) — асинхронно возвращает строго типизированную коллекцию строк из секции основной карточки.

Пример
```
foreach(var row in await CardRowsAsync("Recipients"))
{
  ...
}
```

IsMainProcess() (тип значения bool) — получить признак того, что текущий процесс является основным KrProcess.

Пример

if (IsMainProcess())
{
  // Основной процесс. Маршрут отображается на вкладке "Маршрут", если она не скрыта.
}
else
{
  // Вторичный процесс.
}

IsMainProcessStartedAsync() (тип значения bool) — асинхронно возвращает признак, показывающий, что для текущей карточки запущен основной процесс (KrProcess).
RunNextStageInContextAsync(Guid cardID, bool wholeCurrentGroup = false, IDictionary<string, object> processInfo = null) — асинхронно выполнить следующий этап в контексте другой карточки. Данный метод имеет смысл только при выполнении маршрута. Если метод вызвать в скрипте инициализации, тогда текущий этап будет выполнен в другом контексте, иначе, если в постобработке, то следующий этап. Для карточки с идентификатором cardID будет запущен вторичный синхронный процесс, состоящий из текущего этапа или всех оставшихся этапов до конца текущей группы (wholeCurrentGroup == true). Для создаваемого синхронного процесса можно опционально передать ProcessInfo.
ContextChangePending() (тип значения bool) — возвращает признак того, что была запланирована смена контекста с помощью метода RunNextStageInContextAsync.
DoNotChangeContext() — отмена смены контекста.
Resolve<T>(string name = null) (тип значения T) — возвращает зависимость из IoC-контейнера с опциональным указанием имени (если зависимость является именованной, например, ICardRepository).

Пример
```
var cardRepository = Resolve<ICardRepository>(CardRepositoryNames.Default);
```
AddStageAsync(string name, StageTypeDescriptor descriptor, int position) (тип значения Stage) — добавляет новый этап в маршрут с именем name и положением position. По умолчанию position — в конец.

Особенности метода:
- Если этап не был добавлен скриптом при предыдущих пересчетах, он будет создан с новым RowID.
- Если этап был добавлен ранее, то RowID будет перенесен, но все значения изменены на стандартные.
- Если этап был добавлен ранее и изменен пользователем, то возвращается null.
- Можно использовать только в скрипте построения шаблона этапов.
  
  Пример
```
var stage = await AddStageAsync("ПримерЭтапа", StageTypeDescriptors.ApprovalDescriptor, 1);

if(stage != null)
{
  stage.Name = "Пример этапа";
}
else
{
  // При этом положение измененного пользователем этапа не специфицируется.
  // Для удержания этапа на том же месте необходимо использовать GetOrAddStageAsync.
  AddWarning("Этап изменен вручную");
}
```
GetOrAddStageAsync(string name, StageTypeDescriptor descriptor, int position) (тип значения Stage) — возвращает или добавляет этап в маршруту с указанным именем name, типом, описываемым через descriptor, и положением position. По умолчанию position — в конец.

Особенности метода:
- Если этап не был добавлен скриптом при предыдущих пересчетах, он будет создан с новым RowID.
- Если этап был добавлен ранее, то RowID будет перенесен, но все значения изменены на стандартные.
- Если этап был добавлен ранее и изменен пользователем, то возвращается этот этап.
- Можно использовать только в скрипте построения шаблона этапов.
  
  Пример
```
var stage = await GetOrAddStageAsync("ПримерЭтапа", StageTypeDescriptors.ApprovalDescriptor, 1);

// Даже если этап установлен пользователем, 
// его положение относительно других этапов из шаблона будет 1

if(!stage.RowChanged)
{
  stage.Name = "Пример этапа";
}
else
{
  AddWarning("Этап изменен вручную");
}
```
RemoveStage(string name) (тип значения bool) — удаляет этап из маршрута, добавленный через скрипт (доступен только в скрипте построения шаблона этапов).
SetSinglePerformer(Guid id, string name, Stage intoStage, bool ignoreManualChanges = false) — устанавливает исполнителя в этапе. Применимо только для типов этапов с одиночными исполнителями (доступно только в скрипте постороения шаблона этапов).
SetSinglePerformer(string id, string name, Stage intoStage, bool ignoreManualChanges = false) — перегрузка для SetSinglePerformer(Guid, string, Stage, bool).
AddPerformer(Guid id, string name, Stage intoStage, int pos = int.MaxValue, bool ignoreManualChanges = false) (тип значения Performer) — добавляет исполнителя в этап intoStage на место position. По умолчанию в конец. Возвращает null, если этап изменен. Применимо только для типов этапов с множественными исполнителями (доступен в скрипте выполнения этапа и построения шаблона этапов).

Пример
```
var stage = await AddStageAsync("ПримерЭтапа", StageTypeDescriptors.ApprovalDescriptor);

if(stage != null) {
  var approver = AddPerformer(perfID, perfName, stage);
}
```
AddPerformer(string id, string name, Stage intoStage, int pos = int.MaxValue, bool ignoreManualChanges = false) (тип значения Performer) — перегрузка для AddPerformer(Guid, string, Stage, int, bool).
RemovePerformer(Guid performerID, Stage stage, bool ignoreManualChanges = false) — удаляет исполнителя по идентификатору указанной роли для этапа с режимом множественных исполнителей.
RemovePerformer(string performerID, Stage stage, bool ignoreManualChanges = false) — перегрузка для AddPerformer(Guid, Stage, bool).
RemovePerformer(int index, Stage stage, bool ignoreManualChanges = false) — удаляет исполнителя расположенному по указанному порядковому индексу для этапа с режимом множественных исполнителей.
ForEachStage(Action<CardRow> rowAction) — выполняет указанное действие над строкой (из коллекционной секции KrStages) этапа текущего процесса в обход объектной модели.

Пример
```
ForEachStage(row =>
{
  ...
});
```
ForEachStageInMainProcessAsync(Func<CardRow, Task> rowActionAsync, bool withNesteds = false) — асинхронно выполняет указанное действие над строкой (из коллекционной секции KrStages) этапа основного процесса карточки в обход объектной модели.

Пример
```
await ForEachStageInMainProcessAsync(row =>
{
  ...
});
```
SetStageStateAsync(CardRow stage, KrStageState stageStates) — асинхронно изменяет состояние этапа, заданного строкой секции карточки, а не объектной моделью. Полезно, когда нужно изменить состояние этапа из другого процесса.

Пример
```
await ForEachStageInMainProcessAsync(row => SetStageStateAsync(row, KrStageState.Inactive));
```
AddTaskHistoryRecordAsync( Guid typeID, string typeName, string typeCaption, Guid optionID, string result = null, Guid? performerID = null, string performerName = null, int? cycle = null, Func<CardTaskHistoryItem, Task> modifyActionAsync = null) — асинхронно добавляет запись в текущую группу истории заданий.
AddTaskHistoryRecordAsync( Guid? taskHistoryGroup, Guid typeID, string typeName, string typeCaption, Guid optionID, string result = null, Guid? performerID = null, string performerName = null, int? cycle = null, int? timeZoneID = null, TimeSpan? timeZoneUTCOffset = null, Func<CardTaskHistoryItem, Task> modifyActionAsync = null) — асинхронно добавляет запись в указанную группу истории заданий.
Методы для вывода пользовательской информации в ValidationResult.
- AddError(string text)
- AddWarning(string text)
- AddInfo(string text)
Методы для вывода отладочной информации в ValidationResult. При передаче одиночных объектов подробная информация выводится сразу, при передаче перечисления IEnumerable<T> подробная информация выводится в деталях ValidationResult.
- Show(object obj)
- Show(string message, string details)
- Show(Stage stage)
- Show(IEnumerable<Stage> stages)
- Show(Performer approver)
- Show(IEnumerable<Performer> approvers)

Подробнее об объектах для маршрута¶

Тип GroupPosition

Тип данных GroupPosition хранит информацию о значении поля “положение относительно этапов, добавленных вручную”. В типе определено два свойства — ID и Name. Создавать новые объекты типа нельзя. Существует три предопределенных объекта:

Название	Идентификатор	Имя
Unspecified	null	null
AtFirst	0	AtFirst
AtLast	1	AtLast

Тип WorkflowProcess

Класс содержит в себе полную информацию о текущем маршруте. Определение класса и полная информация о нем содержится в файле типового решения Source/Extensions/Tessa.Extensions.Default.Server/Workflow/KrObjectModel/WorkflowProcess.cs

Author (тип значения Author) — автор (инициатор) основного процесса.
AuthorCurrentProcess (тип значения Author) — автор (инициатор) текущего процесса. При выполнении в основном процессе: возвращаемое значение соответствует значению возвращаемому свойством Author; изменение свойства приводит к синхронному изменению свойства Author и наоборот.
ProcessOwner (тип значения Author) — владелец основного процесса.
ProcessOwnerCurrentProcess (тип значения Author) — владелец текущего процесса. При выполнении в основном процессе: возвращаемое значение соответствует значению возвращаемому свойством ProcessOwner; изменение свойства приводит к синхронному изменению свойства ProcessOwner и наоборот.
AuthorComment (тип значения string) — комментарий к циклу согласования.
State (тип значения Tessa.Extensions.Default.Shared.Workflow.KrProcess.KrState) — состояние документа. Все стандартные состояния указаны в KrState статическими полями. При добавлении новых состояний в перечисление KrDocState с помощью редактора схемы для удобной работы в исходном коде с состоянием рекомендуется вынести новые состояния в отдельный статический класс в Shared-расширениях.

Пример:
```
public static class CustomDocStates 
{
  // Строка со значением ID = 1000 Name = "CustomState" добавлена в перечисление KrDocState
  // Использовать идентификаторы ниже 1000 крайне не рекомендуется во избежание конфликта с состояниями типового решения
  public static readonly KrState CustomState = new KrState(1000);   
}
```
Теперь для изменения состояния карточки в скрипте достаточно:
```
#using Tessa.Extensions.Shared.CustomHelpers
WorkflowProcess.State = CustomDocStates.CustomState;
```
Stages (тип значения SealableObjectList<Stage>) — список этапов в маршруте. Более подробная информация об объекте этапа.
Info (тип значения dynamic) — состояние процесса. Персистентное хранилище ключ-значение, позволяющее хранить произвольные данные, полезные при выполнении процесса и любых скриптов в рамках процесса. Алиасом поля в объекте этапа является свойство ProcessInfo в контексте скрипта.

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

Например:
```
// Постскрипт этапа
ProcessInfo.StageResult = "Успешно";

// ...
// Условие группы
ProcessInfo.StageResult == "Успешно" && ...
```

Тип Stage

Здесь перечислены основные свойства модели этапа. Определение класса и полная информация о нем содержится в файле типового решения Source/Extensions/Tessa.Extensions.Default.Server/Workflow/KrObjectModel/Stage.cs

ID (тип значения Guid) — идентификатор этапа. Для шаблонных этапов это RowID этапа в шаблоне, а для этапов, добавленных вручную в карточке документа, это RowID строки в документе. Таким образом, при пересчетах и подстановках идентификатор строки будет сохраняться, что позволит использовать один и тот же идентификатор в скриптах.
StageTypeID (тип значения Guid) — идентификатор типа этапа. Каждый тип этапа описывается дескриптором, все дескрипторы стандартных типов этапов располагаются в Tessa.Extensions.Default.Shared.Workflow.KrProcess.StageTypeDescriptors.

Пример
```
Stage.StageTypeID == StageTypeDescriptors.ApprovalDescriptor.ID
```
TemplateID (тип значения Guid) — идентификатор карточки шаблона этапа KrStageTemplate.
StageGroupID (тип значения Guid) — идентификатор карточки группы этапов KrStageGroup, к которой принадлежит текущий этап.
Name (тип значения string) — название этапа.
TimeLimit (тип значения double?) — срок выполнения этапа, указываемый в UI. Настройка доступна только для тех типов этапов, в дескрипторе которых UseTimeLimit выставлено в true
Performer (тип значения Performer) — одиночный исполнитель этапа. Используется для тех типов этапов, в дескрипторе которых PerformerUsageMode выставлен в PerformerUsageMode.Single. Более подробная информация об объекте исполнителя.
Performers (тип значения ListStorage<Performer>) — список исполнителей этапа. Используется для тех типов этапов, в дескрипторе которых PerformerUsageMode выставлен в PerformerUsageMode.Multiple. Более подробная информация об объекте исполнителя.

Settings (тип значения dynamic) — настройки этапа, задаваемые через UI настройки. Набор настроек определяется структурой секций карточки настроек, связанной с типом этапа.

Пример работы с настройками в Settings:

// Название строковых полей формируется по шаблону "ИмяСекции__ИмяПоля"
var comment = Stage.KrApprovalSettingsVirtual__Comment;
comment = comment.Replace("пожалуйста", "немедленно");
Stage.KrApprovalSettingsVirtual__Comment = comment;

// Название строковых секций образуется с использованием суффикса __Synthetic
var firstRow = Stage.KrUniversalTaskOptionsSettingsVirtual__Synthetic[0];

Info (тип значения dynamic) — состояние этапа. Персистентное хранилище ключ-значение, позволяющее хранить произвольные данные, полезные при выполнении этапа и его скриптов. Алиасом поля в объекте этапа является свойство StageInfo в контексте скрипта.

Для примера, будем хранить в Info количество выполнений этапа. В скрипте инициализации запишем:
```
if (StageInfo.ExecutionCount == null)
{
  StageInfo.ExecutionCount = 0;
}

StageInfo.ExecutionCount = StageInfo.ExecutionCount + 1;
```
Затем, в постскрипте выведем это количество:
```
if (StageInfo.ExecutionCount != null)
{
  Show(StageInfo.ExecutionCount.ToString());
}
```
OrderChanged — признак того, что порядок менялся пользователем. Не зависит от изменения порядка в коде.
RowChanged — признак того, что этап менялся пользователем. Не зависит от изменений в коде.

Тип Performer

RowID (тип значения Guid) — RowID согласующего в таблице согласующих KrApprovers. Если согласующий попал в маршрут из шаблона, то RowID это ID для шаблонного согласующего. Если согласующий создан вручную, то RowID — это RowID для маршрута карточки.
ID (тип значения Guid) — идентификатор роли согласующего.
Name (тип значения string) — имя роли согласующего.
IsSql (тип значения bool) — признак того, что исполнитель подставлен через SQL запрос. Актуально только для множественных исполнителей.

Типы этапов¶

В этом разделе описаны все доступные “из коробки” типы этапов маршрута. Так как подсистема маршрутов расширяемая, то в вашей конфигурации могут быть добавлены новые типы этапов.

Общие настройки этапов¶

У всех этапов, независимо от типа, есть некоторые общие настройки (помимо названия).

Не показывать в маршруте — признак того, что в маршруте документа этап не будет отображаться, даже если попадает в маршрут. Посмотреть скрытые этапы можно с помощью плитки Другие → Показать скрытые этапы или с помощью сочетания клавиш [Ctrl]+[Alt]+[H]. Скрытые этапы будут выделены серым цветом.

Разрешён пропуск — признак того, что Пользователь может пропускать данный этап в маршруте документа. Это делается путём нажатий кнопки “Удалить”, расположенной под таблицей этапов маршрута. При этом этап становится скрытым. Пропускать можно только неактивные этапы и если это разрешено правилом доступа “Пропуск этапов”.

Для активации пропущенного этапа необходимо в режиме отображения скрытых этапов, если пользователь является администратором или в режиме отображения пропущенных этапов (тайл Другие → Показать пропущенные этапы или с помощью сочетания клавиш [Ctrl]+[Alt]+[H]), если у пользователя обычный уровень доступа, нажать кнопку “Активировать” или выбрать одноимённый пункт контекстного меню. Активировать этап можно только, если это разрешено правилом доступа “Редактирование маршрута”.

Условие — тут можно либо в виде SQL запроса, либо в виде C# выражения (как на примере) задать условие выполнения данного этапа. Если это условие не выполняется в момент, когда до этапа доходит выполнение маршрута, то этап будет пропущен.

SQL условие. Истинным значением считается запрос, возвращающий 1. Ложным значением считается запрос, вернувший 0 строк или строку со значением 0 или NULL.

Запрос, возвращающий более одной строки и более одного столбца, является некорректным.

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

#user_id — идентификатор текущего пользователя.
#user_name — имя текущего пользователя.
#card_id — идентификатор текущей карточки.
#card_type_id — идентификатор типа текущей карточки.
#doc_type_id — идентификатор типа документа текущей карточки или значение null, он не задан для карточки.
#type_id — идентификатор типа документа текущей карточки, если он не известен, то идентификатор типа карточки.
#doc_state — целое число, идентификатор состояния текущей карточки.
#stage_template_id — идентификатор текущего шаблона этапов.
#stage_rowid — идентификатор строки этапа в маршруте.
#stage_group_id — идентификатор текущей группы этапов.
#stage_type_id — идентификатор типа этапа.

Условное выражение. Пишется по правилам написания логических выражений языка C#. Доступные в контексте поля и объекты описаны в следующем разделе. Чаще всего используется объект Card, через который можно проверить (а в обычных сценариях и поменять) данные текущей карточки.

Пример условия, проверяющего сумму договора.

(await GetCardAsync()).DocumentCommonInfo.Amount > 100000

Инициализация. В этом поле задается сценарий, выполняемый перед выполнением этапа.

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

В сценарии постобработки можно получить завершаемое задание, обрабатываемое текущим этапом, следующими способами:

Из карточки документа:

var tasks = ((ICardStoreExtensionContext) this.CardContext).Request.Card.Tasks;

Из свойства:
```
var task = this.WorkflowTaskInfo.Task;
```

Из состояния этапа.

При завершении задания этап сохраняет копию завершаемого задания в коллекцию, расположенную в Stage.InfoStorage по ключу KrConstants.Keys.Tasks. Элемент коллекции – это словарь типа Dictionary<string, object>, являющийся хранилищем объекта CardTask.

Пример получения задания из StageInfo.Tasks

// Обратиться к конкретному элементу коллекции можно по его индексу, например:
StageInfo.Tasks[i]

// Если задание одно, в коллекции будет всегда один элемент.
StageInfo.Tasks[0]

По умолчанию сохраняется только основная информация по заданию. Не сохраняется информация о: CardTask.SectionRows, CardTask.Card, CardTask.Info. Для сохранения всей информации в сценарии инициализации этапа необходимо указать:

this.Stage.WriteTaskFullInformation = true;

Пример сохраняемых данных

При Stage.WriteTaskFullInformation = false:

{
    ".flags": 44052,
    ".state": 0,
    ".storedState": 1,
    "Action": 3,
    "AuthorID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "AuthorName": "Admin",
    "AuthorPosition": null,
    "Digest": "{$KrMessages_Stage}: Согласование",
    "GroupRowID": null,
    "HistoryItemParentRowID": null,
    "InProgress": "2021-06-22T15:04:49.433Z",
    "OptionID": "8cf5cf41-8347-05b4-b3b2-519e8e621225",
    "ParentRowID": null,
    "Planned": "2021-06-24T06:00:00Z",
    "PlannedQuants": 33,
    "PlannedType": 0,
    "PostponeComment": null,
    "Postponed": null,
    "PostponedTo": null,
    "ProcessID": null,
    "ProcessKind": null,
    "ProcessName": null,
    "Result": null,
    "RoleID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "RoleName": "Admin",
    "RoleTypeID": "929ad23c-8a22-09aa-9000-398bf13979b2",
    "RowID": "2f0cd55f-2cf5-42c0-8d24-8a27d2dd1fa8",
    "Settings": {},
    "TimeZoneID": 0,
    "TimeZoneUtcOffsetMinutes": 180,
    "TypeCaption": "$CardTypes_TypesNames_KrApprove",
    "TypeID": "e4d7f6bf-fea9-4a3b-8a5a-e1a0a40de74c",
    "TypeName": "KrApprove",
    "UserID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "UserName": "Admin"
}

При Stage.WriteTaskFullInformation = true:

{
    ".flags": 44052,
    ".state": 0,
    ".storedState": 1,
    "Action": 3,
    "AuthorID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "AuthorName": "Admin",
    "AuthorPosition": null,
    "Card":
    {
        "Created": "2021-06-22T15:02:17.03Z",
        "CreatedByID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
        "CreatedByName": "Admin",
        "Files": null,
        "Flags": 0,
        "ID": "7b2fe4eb-7942-4bef-85ec-602d6bd6b54b",
        "Info": null,
        "Modified": "2021-06-22T15:02:18.49Z",
        "ModifiedByID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
        "ModifiedByName": "Admin",
        "Permissions":
        {
            "CardPermissions": 87381,
            "FilePermissions": null,
            "Sections": null
        },
        "Sections":
        {
            "KrAdditionalApproval":
            {
                "Fields":
                {
                    "Comment": null,
                    "FirstIsResponsible": false,
                    "TimeLimitation": 1.0
                }
            },
            "KrAdditionalApprovalInfo":
            {
                ".table": 1,
                "Rows": null
            },
            "KrAdditionalApprovalInfoVirtual":
            {
                ".table": 1,
                "Rows": []
            },
            "KrAdditionalApprovalUsers":
            {
                ".table": 1,
                "Rows": null
            },
            "KrCommentators":
            {
                ".table": 1,
                "Rows": null
            },
            "KrCommentsInfo":
            {
                ".table": 1,
                "Rows": null
            },
            "KrCommentsInfoVirtual":
            {
                ".table": 1,
                "Rows": []
            },
            "KrTask":
            {
                "Fields":
                {
                    "Comment": "Комментарий",
                    "DelegateID": null,
                    "DelegateName": null
                }
            },
            "TaskCommonInfo":
            {
                "Fields":
                {
                    "KindCaption": null,
                    "KindID": null
                }
            }
        },
        "TypeCaption": "$CardTypes_TypesNames_KrApprove",
        "TypeID": "e4d7f6bf-fea9-4a3b-8a5a-e1a0a40de74c",
        "TypeName": "KrApprove",
        "Version": 0
    },
    "Digest": "{$KrMessages_Stage}: Согласование",
    "GroupRowID": null,
    "HistoryItemParentRowID": null,
    "Info": {},
    "InProgress": "2021-06-22T15:02:18.49Z",
    "OptionID": "8cf5cf41-8347-05b4-b3b2-519e8e621225",
    "ParentRowID": null,
    "Planned": "2021-06-24T06:00:00Z",
    "PlannedQuants": 33,
    "PlannedType": 0,
    "PostponeComment": null,
    "Postponed": null,
    "PostponedTo": null,
    "ProcessID": null,
    "ProcessKind": null,
    "ProcessName": null,
    "Result": null,
    "RoleID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "RoleName": "Admin",
    "RoleTypeID": "929ad23c-8a22-09aa-9000-398bf13979b2",
    "RowID": "7b2fe4eb-7942-4bef-85ec-602d6bd6b54b",
    "SectionRows": null,
    "Settings": {},
    "TimeZoneID": 0,
    "TimeZoneUtcOffsetMinutes": 180,
    "TypeCaption": "$CardTypes_TypesNames_KrApprove",
    "TypeID": "e4d7f6bf-fea9-4a3b-8a5a-e1a0a40de74c",
    "TypeName": "KrApprove",
    "UserID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "UserName": "Admin"
}

SQL исполнители. Для этапов, в которых есть список исполнителей (например, этап “Задача”), в этом поле можно написать sql-запрос, который будет выполнен для формирования списка исполнителей. Запрос выполнится непосредственно перед выполнением этапа. Также есть возможность смешивать вручную заданных исполнителей, подставив в нужное место исполнителей, рассчитанных через запрос.

Warning

Для вычисления SQL исполнителей используется скрипт, указанный в шаблоне этапа на момент выполнения скрипта.

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

#card_id — идентификатор карточки, для которой производится расчет.
#card_type_id — идентификатор типа карточки, для которой производится расчет.
#user_id — идентификатор текущего пользователя.
#user_name — имя текущего пользователя.
#stage_template_id — идентификатор текущего шаблона этапов.
#stage_template_name — название текущего шаблона этапов.
#stage_rowid — идентификатор строки этапа в таблице шаблона этапов, для которого вычисляются роли.

Например, добавим этап, в котором укажем одного согласующего, а также SQL запрос для вычисления исполнителей — запрос, вычисляющий всех пользователей и активных заместителей в подразделении “Финансовый департамент”:

Вот какой результат возвращает запрос.

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

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

На место роли “Вычисляемые согласующие” будут подставлены исполнители, вычисленные в результате выполнения SQL запроса. Исполнители подставляются в том же порядке, в котором они возвращаются запросом.

Согласование¶

Этап согласования предназначен для отправки одного или нескольких заданий согласования.

Название этапа – название текущего этапа согласования.

Срок (рабочие дни) — срок для заданий согласования в рабочих днях. Срок можно задать и дробный, например “0,5” — половина рабочего дня (4 часа).

Дата выполнения — астрономическая дата выполнения задания. Можно указать либо это поле, либо “Срок (рабочие дни)”.

Согласующие – согласующие текущего этапа. Можно указать как конкретных сотрудников, так и роли.

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

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

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

Note

Обратите внимание, что согласующий, для которого указаны дополнительные согласующие, отмечается в списке специальными символами (+) перед названием роли.

От имени (сотрудник или контекстная роль) — позволяет отправить задание от имени любого сотрудника. В отличие от отправки задачи по тайлу “Создать задачу”, здесь можно выбрать абсолютно любого сотрудника, т.к. маршруты настраиваются администратором.

Вид — вид задания.

Комментарий — комментарий к текущему этапу согласования.

Вкладка “Основные настройки”

Параллельный этап – флаг выставляется в случае, если текущий этап согласования должен проходить параллельно (актуально, если в поле “Согласующие” указано более одного согласующего).

Не возвращать на доработку — данный флаг отключает возврат на начало текущей группы этапов, выполняемый этапом “Согласование”. Для того, чтобы был выполнен возврат на доработку, при наличии несогласованных заданий согласования, в стандартную группу этапов “Согласование” включен шаблон этапов “Возврат на доработку”. В конце данного раздела есть примеры маршрутов согласования с использованием этого флага, где объясняется как и в каких случаях ведёт себя процесс.

Данной настройкой также можно управлять на уровне маршрута, в процессе выполнения, используя значение типа Nullable<bool> доступное по ключу Tessa.Extensions.Default.Shared.Workflow.KrProcess.KrConstants.Keys.NotReturnEdit в ProcessInfo. При расчёте итогового значения, значение из ProcessInfo объединяется по “И” со значением указанным в настройках этапа. Если значение в ProcessInfo отсутствует или имеет значение null, то оно не учитывается.

Вернуть при несогласовании – вернуть документ на доработку Инициатору при не согласовании хотя бы одним из согласующих. Флаг проверяет только результат текущего этапа.

Рекомендательное согласование — вариант завершения “не согласовать” не возвращает процесс на доработку. При установке флажка проставляется специальный вид задания, однако можно указывать собственный.

Вкладка “Дополнительно”

Вернуть после согласования – вернуть договор на доработку Инициатору при согласовании всеми текущими согласующими. Флаг проверяет только результат текущего этапа.

Отключить автоматическое согласование — отключить для данного этапа автоматическое завершение задания согласования (см. Автоматическое согласование).

Следующие две настройки управляют логикой работы этапа в подсистеме маршрутов.

Изменять состояние при старте — если флажок установлен (по умолчанию), то при запуске этапа состояние карточки устанавливается в “На согласовании”. Снимите флажок, если вам не нужно такое поведение.

Изменять состояние при завершении — если флажок установлен, то при успешном выходе из этапа (все согласующие согласовали) состояние карточки устанавливается в “Согласовано”. При несогласовании в последовательном режиме — этап устанавливает состояние карточки “Не согласовано” сразу же а в параллельном режиме выполнение — когда все согласующие завершили свои задания. Снимите флажок, если вам не нужно такое состояние.

Настройки прав доступа для согласующих этапа

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

Группа настроек Переопределение группы истории заданий.

Позволяют указать параметры, определяющие группу в истории заданий. Функциональность аналогична, как в этапе “Управление историей”, кроме того, что данные настройки не распространяются на другие этапы.

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

Родительская группа — группа истории заданий, являющейся родительской по отношению к группе, задаваемой в поле “Группа истории заданий”. Если указана, то будет выбрана родительская группа заданного типа с наибольшей итерацией.

Новая итерация — если флаг установлен, то будет создана новая итерация для группы истории заданий, заданной в поле “Группа истории заданий”.

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

Если это последнее задание этапа

И (были несогласовавшие в текущем этапе

ИЛИ результат задания = “Не согласовано”), то:
1. Если флаг “Вернуть при несогласовании” не стоит
  
  И есть еще этапы согласования после текущего в пределах группы, то завершаем этап и идем дальше по маршруту.
2. Если флаг “Не возращать на доработку” стоит, то завершаем этап и идем дальше по маршруту.
3. Если вышеописанные условия не выполнились, то возвращаемся в начало текущей группы.
Если это не последнее задание этапа

И этап последовательный

И результат задания = “Не согласовано”, то:
1. Выполняются те же проверки что и в пунктах 1.a..1.c
Если результат задания = “Согласовано”, то:
1. Если флаг “Не возвращать на доработку” стоит, то завершаем этап и идем дальше по маршруту.
2. Если флаг “Не возвращать на доработку” не стоит
  
  И были несогласовавшие на этом же этапе или ранее в пределах группы
  
  И нет следующих этапов согласования в пределах группы, то возвращаемся в начало текущей группы.
3. Если это последнее задание этапа И флаг “Возвращать при согласовании” стоит, то ищем первый этап доработки в текущей группе:
  1. Если нашли — переходим на него. После завершения задания доработки выполнение маршрута возобновляется с этапа следующего за этапом инициировавшим доработку. Номер цикла не изменяется.
  2. Если не нашли — завершаем этап и идем дальше по маршруту.

При обработке завершения задания, если результат = “Не согласовано” и этап не рекомендательный — в StageInfo пишется признак "Disapproved": true.

Проверка, были ли несогласовашие в прошедших этапах, проверяет наличие флага "Disapproved": true в текущем и предыдущих этапах.

Имя флага Disapproved содержится в константе Tessa.Extensions.Default.Shared.Workflow.KrProcess.KrConstants.Keys.Disapproved.

Предполагается, что этап “Доработка” распологается в начале текущей группе этапов, который отправит задание инициатору на доработку документа.

Этап согласования завершается, когда завершится последнее задание этапа.

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

Примеры маршрутов в типовой группе Согласование с наличием всех типовых шаблонов этапов.

Пример 1. Комбинация флагов “Вернуть при несогласовании” и “Вернуть после согласования”

Example

Шаблон этапов с маршрутом:

№	Исполнители	Параллельный	Вернуть при несогласовании	Не возвращать на доработку	Рекомендательное согласование	Вернуть после согласования
1	Иванов, Петров	Нет	Да	Нет	Нет	Да
2	Волков	Нет	Да	Нет	Нет	Нет

Варианты прохождения маршрута:

Иванов — согласовал, Петров — согласовал, документ отправился на доработку, далее Волкову. Волков согласовал. Документ согласован.

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

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

В данном случае был возврат в начало группы, т.к. документ не согласовали. Причем этот возврат не зависел от наличия флага “Вернуть при несогласовании” на втором этапе, т.к. внутри этапа согласования встроена проверка, срабатывающая на последнем этапе группы: если в маршруте на каком-либо этапе были отрицательные визы — вернуть маршрут в начало группы.

Пример 2. Комбинация флагов “Вернуть при несогласовании” и “Вернуть после согласования”

Example

Шаблон этапов с маршрутом:

№	Исполнители	Параллельный	Вернуть при несогласовании	Не возвращать на доработку	Рекомендательное согласование	Вернуть после согласования
1	Иванов, Петров	Нет	Нет	Нет	Нет	Нет
2	Волков	Нет	Нет	Нет	Нет	Да

Варианты прохождения маршрута:

Иванов — не согласовал, Петров — не согласовал, Волков — не согласовал, документ отправился на доработку с увеличением цикла.

В данном случае не смотря на то, что на обоих этапах снят флаг “Вернуть при несогласовании”, в конце маршрута был выполнен возврат в начало группы, т.к. были отрицательные визы. Однако на первом этапе после отрицательного решения первого согласующего и по завершении всего этапа возврат в начало группы не был выполнен благодаря снятому флагу “Вернуть при несогласовании”.
Иванов — согласовал, Петров — согласовал, Волков — согласовал, документ отправился на доработку, далее переход в состояние “Согласован”.

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

Пример 3. Флаг “Не возвращать на доработку”

Example

Шаблон этапов с маршрутом:

№	Исполнители	Параллельный	Вернуть при несогласовании	Не возвращать на доработку	Рекомендательное согласование	Вернуть после согласования
1	Иванов, Петров	Нет	Нет	Да	Нет	Нет
2	Волков	Нет	Нет	Да	Нет	Нет

Варианты прохождения маршрута:

Иванов — не согласовал, Петров — согласовал, Волков — не согласовал, документ отправился на доработку с увеличением цикла.

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

В этом примере Флаг “Не возвращать на доработку” на первом этапе отключил встроенную в этап проверку, которая в случае несогласования возвращает маршрут в начало группы, а во втором этапе благодаря флагу не сработала проверка, которая в случае, если в группе ранее (на любых этапах) были отрицательные визы — вернуть маршрут в начало группы. Документ же вернулся на доработку в начало группы благодаря шаблону этапов “Возврат на доработку”, входящему в типовую поставку и находящемуся в конце группы Согласование.

В предыдущих примерах маршрутов возврат в начало группы выполнялся как раз благодаря проверке, встроенной внутри этапа Согласования. Шаблон этапов “Возврат на доработку” даже не выполнялся, он выполнится только в случае выставления флага “Не возвращать на доработку” на последнем этапе группы.

Другие варианты прохождения маршрута мы не рассматриваем, т.к. они аналогичны, т.е. не зависимо от решения на первом этапе, будет выполнен переход на второй, а при завершении второго этапа в зависимости от решения на обоих этапах документ или перейдет в состояние “Согласован”, или отправится на доработку.

По сути, флаг “Не возвращать на доработку” отрабатывает так же, как снятый флаг “Вернуть при несогласовании”, небольшое отличие есть только на последнем этапе группы (при условии, что в группе есть типовой шаблон этапов “Возврат на доработку”). Возврат будет выполнен с помощью разных инструментов: с флагом “Не возвращать на доработку” — путём обозначенного шаблона этапов, без флага — путем встроенной проверки в этапе согласования. Инструменты разные, но итог один — возврат выполняется.

Однако флаг “Не возвращать на доработку” может быть полезен и в других целях, например, если в шаблоне этапов снят флаг “Этапы нередактируемые” — тогда пользователи при редактировании этапов, где выставлен флаг “Не возвращать на доработку”, не смогут управлять флагами “Вернуть при несогласовании” и “Вернуть после согласования”, т.к. они будут скрыты.

Пример 4. Флаг “Рекомендательное согласование”

Example

Шаблон этапов с маршрутом:

№	Исполнители	Параллельный	Вернуть при несогласовании	Не возвращать на доработку	Рекомендательное согласование	Вернуть после согласования
1	Иванов, Петров	Нет	Нет	Нет	Да	Да
2	Волков	Нет	Нет	Нет	Нет	Нет

Варианты прохождения маршрута:

Иванов — согласовал, Петров — согласовал, документ отправлен на доработку, далее Волкову. Волков — согласовал. Документ согласован.
Иванов — не согласовал, Петров — не согласовал, документ отправлен на доработку, далее Волкову. Волков — согласовал. Документ согласован.

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

Во-вторых даже при наличии отрицательных виз не было возврата в начало группы (ни путём выполнения проверки, встроенной в этап согласование, ни путём выполнения шаблона этапов “Возврат на доработку”) по той же причине — при включенном флаге “Рекомендательное согласование” любое решение для системы является положительным, не смотря на то, что в истории заданий и листе согласования фиксируется отрицательная виза.

Примеры маршрутов при отсутствии в группе типового шаблона этапов “Возврат на доработку”.

Пример 5. Флаг “Вернуть при несогласовании”

Example

Шаблон этапов с маршрутом:

№	Исполнители	Параллельный	Вернуть при несогласовании	Не возвращать на доработку	Рекомендательное согласование	Вернуть после согласования
1	Иванов, Петров	Нет	Да	Нет	Нет	Нет
2	Волков	Нет	Нет	Нет	Нет	Нет

Варианты прохождения маршрута:

Иванов — согласовал, Петров — не согласовал, документ отправлен на доработку с увеличением цикла.

В этом примере вполне ожидаемое поведение маршрута с учетом приведенных выше примеров

Иванов — согласовал, Петров — согласовал, Волков — не согласовал, документ отправлен на доработку с увеличением цикла.

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

Пример 6. Флаг “Не возвращать на доработку”

Example

Шаблон этапов с маршрутом:

№	Исполнители	Параллельный	Вернуть при несогласовании	Не возвращать на доработку	Рекомендательное согласование	Вернуть после согласования
1	Иванов, Петров	Нет	Нет	Да	Нет	Нет
2	Волков	Нет	Нет	Да	Нет	Нет

Варианты прохождения маршрута:

Иванов — не согласовал, Петров — согласовал, Волков — согласовал, документ переходит в состояние “Не согласован”.
Иванов — согласован, Петров — согласовал, Волков — не согласовал, документ переходит в состояние “Не согласован”.

Это единственный пример, где в конце выполнения группы при наличии отрицательных виз не выполнен возврат на доработку, даже при отсутствии флага “Рекомендательное согласование”. Документ переходит в состояние “Не согласован” и маршрут согласования завершается. При этом наличие флага “Не возвращать на доработку” в первом этапе отрабатывает аналогично снятому флагу “Вернуть при несогласовании”, этот сценарий подробно описан в примере 3.

Комбинация условий: наличие флага “Не возвращать на доработку” на последнем этапе группы и отсутствие в группе шаблона этапов “Возврат на доработку” может быть полезна, например, при настройке сложного маршрута согласования с использованием ветвления (чтобы в случае отрицательных виз ветка могла завершиться, без доработки внутри ветки) или при обработке отрицательных виз по своей логике, отличающейся от типовой.

Подписание¶

Этап подписания полностью аналогичен согласованию, за исключением:

В заданиях кнопки называются “Подписать” и “Отказать” вместо “Согласовать” и “Не согласовать”;
Состояние карточки при входе в этап устанавливается “На подписании”;
Для включения возможности выполнения запроса дополнительного согласования из задания “Подписания” в параметрах этапа необходимо установить флаг “Разрешить дополнительное согласование”. Для подписантов отсутствует возможность задания дополнительных согласующих в параметрах этапа.

Доработка¶

Этап, обеспечивающий доработку документа после несогласования. Отправляет задание на доработку указанному исполнителю. По завершению задания передает управление следующему этапу в маршруте.

Срок (рабочие дни) — срок задания в рабочих днях, допускаются дробные значения.

Исполнитель — исполнитель задания. Обычно это роль “Инициатор согласования”, но можно указывать любую роль в системе.

От имени (сотрудник или контекстная роль) — позволяет отправить задание от имени любого сотрудника.

Вид — вид задания.

Комментарий — комментарий к этапу.

Изменять состояние — если флажок установлен (по умолчанию), то при входе в этап состояние карточки меняется на “На доработке”. Снимите флажок, если вам не нужно такое поведение.

Увеличить цикл — если флажок установлен (по умолчанию), то при входе в этап текущий цикл согласования увеличится на 1. Текущий цикл доступен в контексте из любого сценария: Cycle. Снимите флажок, если вам это не нужно.

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

Управлять видимостью этапа — если флажок установлен (по умолчанию), то этап становится видимым при выполнении, иначе остаётся скрытым.

Группа настроек Переопределение группы истории заданий.

Задача¶

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

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

Исполнители — любые роли в системе, можно указывать несколько. Если не установлен флажок “Отдельная задача каждому исполнителю”, то система объединит всех исполнителей в одну роль, на которую отправит задание. Исполнять его будет тот, кто первым возьмет задание в работу.

Отдельная задача каждому исполнителю — если флажок установлен, то каждый исполнитель получает отдельную задачу.

Первый исполнитель — ответственный — если флажок установлен, то первый исполнитель получит обычную задачу, а остальные — дочерние задачи.

Длительность (рабочие дни) — срок задания в рабочих днях. Допускаются дробные значения.

Дата выполнения — астрономическая дата выполнения задания. Можно указать либо это поле, либо “Длительность (рабочие дни)”.

Вернуть после завершения — если флажок установлен, то после завершения исполнителем задача будет отправлена автору. Он сможет проверить результаты выполнения и при необходимости вернуть ее исполнителю или отправить другому сотруднику или сотрудникам. Если флажок установлен, то станет доступно поле “Вернуть на роль”, позволяющее вернуть задачу не автору, а любой другой роли.

Комментарий — текст задания.

Вид — вид задания.

Группа настроек Переопределение группы истории заданий.

Настраиваемое задание¶

Этап “Настраиваемое задание” позволяет отправить одному или нескольким исполнителям задание с заданными в настройках этапа вариантами завершения и обработать результат. Этап асинхронный и для завершения ждет завершения всех заданий исполнителей. После завершения задания этап завершается и передает управление далее по маршруту.

Вот так выглядит взятое в работу настраиваемое задание.

Срок (рабочие дни) — срок задания в рабочих днях. Допускаются дробные значения.

Исполнители — исполнители задания. Можно указывать любые роли.

От имени (сотрудник или контекстная роль) — сотрудник, который будет автором отправленных заданий. Можно указать конкретного сотрудника или контекстную роль. В случае с контекстной ролью система ее вычислит и автором будет первый сотрудник из входящих в контекстную роль.

Вид — вид задания.

Текст задания — текст задания.

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

При добавлении варианта завершения система автоматически генерирует ему уникальный идентификатор. Пользователь может задать:

Вариант завершения — название варианта завершения (кнопки в задании). Можно использовать локализацию.

Сообщение — сообщение, которое будет отображаться пользователю при нажатии на данный вариант завершения, при этом для завершения задания необходимо будет повторно нажать на кнопку:

Показывать поле Комментарий — с вариантом завершения связано текстовое поле “Комментарий”, которое может заполнить пользователь. Обязательность данного поля система не проверяет, ее можно гарантировать в сценарии пост-обработки.

// если комментарий пустой, ругаемся
if ( String.IsNullOrWhiteSpace ( (string)StageInfo.Tasks[0].Comment ) ) {
  AddError("Пожалуйста, укажите комментарий!");
}

Дополнительный вариант завершения — если флажок установлен, то вариант завершения в задании будет доступен в выпадающем списке “Еще”.

Группа настроек Переопределение группы истории заданий.

При завершении задания этап записывает в состояние этапа информацию о завершаемом задании. Помимо основной информации о задании записывается также дополнительная информация:

Comment – комментарий при завершении;
OptionID – идентификатор варианта завершения, выбранного пользователем;
OptionName – название варианта завершения, выбранного пользователем;
CompletedByID – идентификатор сотрудника, завершившего задание;
CompletedByName – отображаемое имя сотрудника, завершившего задание;
Completed – дата и время завершения задания.

Пример сохраняемых данных

При Stage.WriteTaskFullInformation = false:

{
    ".flags": 44052,
    ".state": 0,
    ".storedState": 1,
    "Action": 3,
    "AuthorID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "AuthorName": "Admin",
    "AuthorPosition": null,
    "Comment": "Комментарий",
    "Completed": "2021-06-22T15:24:13.4663366Z",
    "CompletedByID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "CompletedByName": "Admin",
    "Digest": "",
    "GroupRowID": null,
    "HistoryItemParentRowID": null,
    "InProgress": "2021-06-22T15:23:43.677Z",
    "OptionID": "99398df4-c529-4401-93b8-e4ce14c66d27",
    "OptionName": "Вариант завершения",
    "ParentRowID": null,
    "Planned": "2021-06-24T06:00:00Z",
    "PlannedQuants": 33,
    "PlannedType": 0,
    "PostponeComment": null,
    "Postponed": null,
    "PostponedTo": null,
    "ProcessID": null,
    "ProcessKind": null,
    "ProcessName": null,
    "Result": "Комментарий",
    "RoleID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "RoleName": "Admin",
    "RoleTypeID": "929ad23c-8a22-09aa-9000-398bf13979b2",
    "RowID": "3f3631e0-037e-47be-ae9e-ad78075959e5",
    "Settings": {},
    "TimeZoneID": 0,
    "TimeZoneUtcOffsetMinutes": 180,
    "TypeCaption": "$CardTypes_TypesNames_KrUniversalTask",
    "TypeID": "9c6d9824-41d7-41e6-99f1-e19ea9e576c5",
    "TypeName": "KrUniversalTask",
    "UserID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "UserName": "Admin"
}

При Stage.WriteTaskFullInformation = true:

{
    ".flags": 44052,
    ".state": 0,
    ".storedState": 1,
    "Action": 3,
    "AuthorID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "AuthorName": "Admin",
    "AuthorPosition": null,
    "Card":
    {
        "Created": "2021-06-22T15:25:28.103Z",
        "CreatedByID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
        "CreatedByName": "Admin",
        "Files": null,
        "Flags": 0,
        "ID": "27da5497-cd7d-4032-8f79-f6c90483b047",
        "Info": null,
        "Modified": "2021-06-22T15:25:29.12Z",
        "ModifiedByID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
        "ModifiedByName": "Admin",
        "Permissions":
        {
            "CardPermissions": 87381,
            "FilePermissions": null,
            "Sections": null
        },
        "Sections":
        {
            "KrTask":
            {
                "Fields":
                {
                    "Comment": "Комментарий"
                }
            },
            "KrUniversalTaskOptions":
            {
                ".table": 1,
                "Rows": [
                    {
                        "Additional": false,
                        "Caption": "Вариант завершения",
                        "Message": "Сообщение",
                        "OptionID": "99398df4-c529-4401-93b8-e4ce14c66d27",
                        "Order": 0,
                        "RowID": "94901333-01b7-4e6a-92d1-06f233a4ddd7",
                        "ShowComment": true
                    }
                ]
            },
            "TaskCommonInfo":
            {
                "Fields":
                {
                    "KindCaption": null,
                    "KindID": null
                }
            }
        },
        "TypeCaption": "$CardTypes_TypesNames_KrUniversalTask",
        "TypeID": "9c6d9824-41d7-41e6-99f1-e19ea9e576c5",
        "TypeName": "KrUniversalTask",
        "Version": 0
    },
    "Comment": "Комментарий",
    "Completed": "2021-06-22T15:25:38.5757756Z",
    "CompletedByID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "CompletedByName": "Admin",
    "Digest": "",
    "GroupRowID": null,
    "HistoryItemParentRowID": null,
    "Info":
    {
        ".universalOptionID": "99398df4-c529-4401-93b8-e4ce14c66d27"
    },
    "InProgress": "2021-06-22T15:25:29.12Z",
    "OptionID": "99398df4-c529-4401-93b8-e4ce14c66d27",
    "OptionName": "Вариант завершения",
    "ParentRowID": null,
    "Planned": "2021-06-24T06:00:00Z",
    "PlannedQuants": 33,
    "PlannedType": 0,
    "PostponeComment": null,
    "Postponed": null,
    "PostponedTo": null,
    "ProcessID": null,
    "ProcessKind": null,
    "ProcessName": null,
    "Result": "Комментарий",
    "RoleID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "RoleName": "Admin",
    "RoleTypeID": "929ad23c-8a22-09aa-9000-398bf13979b2",
    "RowID": "27da5497-cd7d-4032-8f79-f6c90483b047",
    "SectionRows": null,
    "Settings": {},
    "TimeZoneID": 0,
    "TimeZoneUtcOffsetMinutes": 180,
    "TypeCaption": "$CardTypes_TypesNames_KrUniversalTask",
    "TypeID": "9c6d9824-41d7-41e6-99f1-e19ea9e576c5",
    "TypeName": "KrUniversalTask",
    "UserID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
    "UserName": "Admin"
}

Регистрация¶

Этап “Регистрация” позволяет отправить задание на регистрацию карточки. При регистрации карточке выделяется постоянный номер и изменяется состояние на “Зарегистрирована”, согласно настройкам типового решения.

Регистрация выполняется после завершения задания.

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

Срок (рабочие дни) — срок задания в рабочих днях. Можно использовать дробные значения.

Регистратор — исполнитель задания. Любая роль в системе.

От имени (сотрудник или контекстная роль) — позволяет отправить задание от имени любого сотрудника.

Вид — вид задания.

Комментарий — комментарий к этапу.

Без отправки задания — если флажок установлен, то задание регистрации не отправляется. В данном режиме этап выполняется в синхронном режиме.

Редактировать карточку – дать права доступа на редактирование карточки регистраторам;
Редактировать любые файлы – дать права доступа на редактирование приложенных файлов для регистраторов.

Отмена регистрации¶

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

Этап синхронный, при получении управления выполняет дерегистрацию и сразу передает управление дальше.

Ознакомление¶

Этап “Ознакомление” позволяет отправить карточку на ознакомление указанным сотрудникам. Они получат почтовое уведомление и доступ на чтение карточки. Также отправленные на ознакомление документы доступны пользователю в рабочем месте “Пользователь” в представлении “Мне на ознакомление”. При открытии ими карточки система зафиксирует факт ознакомления в журнале ознакомления. Функциональность ознакомления полностью аналогична ознакомлению типового решения.

Получатели — список ролей на которые будет отправлено ознакомление. Система объединит состав ролей, сформировав общий список сотрудников и затем каждому из них отравит на ознакомление документ.

Отправитель (сотрудник или контекстная роль) — сотрудник, от имени которого будет отправлено ознакомление. Можно указать сотрудника или контекстную роль. Если указана контекстная роль, система ее вычислит и возьмет первого сотрудника, входящего в эту роль.

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

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

Уведомление — выбор карточки уведомления, которая будет использована для отправки письма с уведомлением пользователя. Система сформирует письмо согласно шаблону в карточке уведомления и разошлет пользователям.

В тексте выбранной карточки уведомления можно использовать некоторые дополнительные псевдо-плейсхолдеры:

{{sender}} — заменяется на имя отправителя;
{{comment}} — заменяется на сформированный комментарий;
<comment_block>…</comment_block> — блок с комментарием. Удаляется в случае, когда {{comment}} пустой. Например, можно написать как показано в примере, и в случае пустого комментария весь текст “Инициатор отправил…” будет удален из почтового уведомления.
```
Пожалуйста, внимательно прочтите документ.
<comment_block>Инициатор отправил следующий комментарий: {{comment}}</comment_block>
```

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

Этап выполняется синхронно, после запуска сразу отправляет уведомления и передает управление следующему этапу в маршруте.

Уведомление¶

Этап “Уведомление” позволяет сформировать и отправить уведомление сотрудникам по электронной почте (email). При формировании уведомления используется карточка уведомления, на которую ссылается этап. Подробнее про уведомления в разделе руководства администратора.

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

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

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

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

Этап выполняется синхронно, после запуска сразу формирует исходящие письма и передает управление следующему этапу в маршруте.

Создание карточки¶

Этап “Создание карточки” позволяет создать новую карточку из маршрута. Создать можно либо по выбранному шабону карточки, либо просто выбрав определенный тип карточки. По созданной карточке можно сразу же запустить маршрут и/или открыть ее в рабочем месте пользователя.

Тип карточки — ссылка на тип карточки, который будет использоваться для создания новой карточки. Обратите внимание, что в большинстве режимов создания (см. поле “Режим”) пользователю не требуются права на создание карточек.

Шаблон — ссылка на шаблон, по которому будет создана карточка. Обратите внимание, что в большинстве режимов создания (см. поле “Режим”) пользователю не требуется доступ на этот шаблон.

Режим — режим создания карточки:

Открыть новую карточку — карточка будет создана и открыта (но не сохранена!) непосредственно в клиентском рабочем месте пользователя, как если бы он ее сам создал по шаблону (или просто создал, если это создание по типу карточки). В этом режиме пользователю требуется доступ на указанный шаблон/права на создание карточки. Открытая карточка будет новой, не сохраненной — пользователю нужно будет самостоятельно сохранить карточку. До момента сохранения информации об этой карточке в базе данных нет.
Сохранить карточку — карточка будет создана и сохранена на сервере. Пользователю в этом режиме не нужны права на создание карточки, а также доступ на шаблон, по которому создается карточка.
Сохранить и открыть карточку — карточка будет создана и сохранена на сервере, а затем уже открыта в рабочем месте пользователя. Пользователю в этом режиме не нужны права на создание карточки, а также доступ на шаблон, по которому создается карточка. Но при этом ему нужен доступ на чтение созданной карточки. Если такого доступа нет, то карточка создастся, но не откроется у пользователя на клиенте. При этом карточка останется существовать в системе.
Запустить процесс — карточка будет создана и сохранена на сервере, а потом по ней будет сформирован маршрут и запущен процесс по маршруту. Процесс при этом сразу же выполнится до первого асинхронного этапа, например, отправки задания. Пользователю в этом режиме не нужны права на создание карточки, а также доступ на шаблон, по которому создается карточка.
Запустить процесс и открыть карточку — аналогичен “Запустить процесс”, но карточка будет открыта в рабочем месте пользователя после запуска процесса. Пользователю в этом режиме не нужны права на создание карточки, а также доступ на шаблон, по которому создается карточка. Но при этом ему нужен доступ на чтение созданной карточки. Если такого доступа нет, то карточка создастся, но не откроется у пользователя на клиенте. При этом карточка останется существовать в системе.

После создания и сохранения карточки этап записывает идентификатор созданной карточки по ключу cardID (константа Tessa.Extensions.Default.Shared.Workflow.KrProcess.KrConstants.Keys.NewCardID) в состояние этапа.

{
  "cardID": "e4d4db89-4320-4fcb-aa1f-9d36e33ca614"
}

Сценарий пост-обработки может получить этот идентификатор ( (Guid)StageInfo.cardID ) и что-нибудь сделать с этим знанием, например:

Изменить созданную карточку, выполнив запрос к БД. К моменту выполнения сценария данные карточки уже записаны в базу данных, но транзакция еще открыта.
Изменить созданную карточку, выполнив следующий этап маршрута в ее контексте. Для этого нужно добавить в маршрут сразу после этапа создания карточки этап сценария. Затем в сценарии постобработки этапа создания карточки выполнить RunNextStageInContextAsync( (Guid)StageInfo.cardID ); (см. пример с созданием уже зарегистрированной карточки). Следующие этапы маршрута выполнятся в контексте вновь созданной карточки и в тексте сценария можно будет просто написать, например, (await GetCardAsync()).DocumentCommonInfo.Amount = 10 для изменения суммы договора.

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

var card = await GetNewCardAsync();
card.Sections["DocumentCommonInfo"].Fields["Subject"] = "Новая тема документа";
// Или
(await NewCardAsync()).DocumentCommonInfo.Subject = "Новая тема документа";

Note

Обратите внимание:

В режиме Открыть новую карточку card содержит пустой пакет карточки, предназначенный только для записи новых значений;
В остальных режимах — card содержит полный пакет карточки.

Смена состояния¶

Этап “Смена состояния” позволяет изменить состояние текущей карточки. Этап синхронный и передает управление дальше сразу после изменения состояния.

Состояние — выбор из справочника состояний. Вы можете добавить свое собственное состояние в таблицу KrDocState при помощи библиотек схемы.

Пересчет маршрута¶

Этап “Пересчет маршрута” — выполняет пересчет состава текущей группы маршрута и обновляет ту его часть, которая будет выполняться после этапа “Пересчет маршрута”. При этом, если были изменения состава этапов ДО того места, где находится этап “Пересчет маршрута”, то система трактует это как ошибки и никаких изменений в итоговом маршруте карточки производиться не будет. Пересчет группы выполняется по обычным правилам пересчета маршрута с выполнением сценариев дизайн-тайма, за исключением того, что система пересчитывает только текущую группу.

Этап не имеет настроек.

Сценарий¶

Этап “Сценарий” позволяет выполнить какие-то действия в сценариях инициализации или постобработки и только лишь.

Этап не имеет настроек.

Управление процессом¶

Этап “Управление процессом” позволяет управлять маршрутом, выполняя различные переходы, отзыв, запуск процесса и так далее.

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

Режимы работы:

Отправить сигнал — это специальный режим, позволяющий отправить некоторые заранее заданные специальные команды процессу. Этот режим может использоваться только с установленным флажком “Выполнять в основном процессе”. Такими командами могут быть:

KrStartProcessSignal — формирует маршрут и запускает процесс по документу. Если процесс уже запущен, выдает ошибку.
KrStartProcessUnlessStartedGlobalSignal — формирует маршрут и запускает процесс по документу. Если процесс уже запущен, просто ничего не делает.

Отменить процесс — может выполняться в основном и вторичном процессе. Отзывает текущий активный этап маршрута в основном процессе. Все этапы маршрута, включая отозванный, переходят в состояние “Не запущен”. Процесс маршрута завершается и должен быть запущен заново.

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

Пропустить процесс — может выполняться в основном и вторичном процессе. Отзывает текущий активный этап маршрута в основном процессе. Отозванный этап и все этапы после него переходят в состояние “Пропущен”. Процесс маршрута завершается и должен быть запущен заново.

Переход на этап — выполняет переход на конкретный этап маршрута.

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

Если переход выполняется вперед, то все пропущенные этапы переходят в состояние “Пропущен”. Если переход выполняется назад, то все пропущенные этапы переходят в состояние “Не запущен”. Если указанного этапа нет, то этап управления процессом не выполняет никаких действий.

При переходе в другую группу маршрута — выполняется пересчет этой группы по общим правилам с выполнением сценариев группы “При расчете маршрута”.

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

В поле Группа этапов нужно выбрать группу, на которую выполняется переход.

При переходе выполняется пересчет этой группы по общим правилам с выполнением сценариев группы “При расчете маршрута”. Далее начинается выполнение этапов этой группы.

Если переход выполняется вперед, то все пропущенные этапы переходят в состояние “Пропущен”. Если переход выполняется назад, то все пропущенные этапы переходят в состояние “Не запущен”. Если указанной группы нет, то этап управления процессом не выполняет никаких действий.

Переход на следующую группу — выполняет переход на следующую группу в маршруте.

При переходе выполняется пересчет этой группы по общим правилам с выполнением сценариев группы “При расчете маршрута”. Далее начинается выполнение этапов этой группы. Если группы нет (маршрут заканчивается), то завершается процесс маршрута.

Переход на предыдущую группу — выполняет переход на предыдущую группу в маршруте.

При переходе выполняется пересчет этой группы по общим правилам с выполнением сценариев группы “При расчете маршрута”. Далее начинается выполнение этапов этой группы. Если предыдущей группы нет (текущая группа первая в маршруте), то этап не выполняет никаких действий.

Переход в начало текущей группы — выполняет переход на начало текущей группы.

Ветвление¶

Этап ветвления предназначен для параллельного запуска нескольких вторичных процессов. Запускаемые таким образом вторичные процессы называются вложенными (имя типа процесса содержится в константе KrConstants.KrNestedProcessName), имеют свой контекст и состояние (ProcessInfo). Тем не менее все вторичные процессы, запущенные через ветвление (далее вложенные), сохраняются в сателлите родительского процесса (далее основной, не путать с первичным процессом).

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

Обратите внимание, что внутри этапа “Ветвление” также может запускаться вложенное “Ветвление”.

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

Пример получения параметров запускаемых вложенных процессов.

IDictionary<string, object> nestInfo = this.GetProcessInfoForBranch(<Идентификатор (RowID) строки в коллекции вторичных процессов>);

nestInfo["key"] = "value";

// Далее в скриптах запускаемого вложенного процесса в ProcessInfo.key будет располагаться значение "value".

Будьте внимательны, “<Идентификатор (RowID) строки в коллекции вторичных процессов>” — это идентификатор строки в секции KrForkSecondaryProcessesSettingsVirtual_Synthetic, а не идентификатор карточки вторичного процесса.

Пример создания ветки процесса

var branches = (IList<object>) Stage.SettingsStorage[KrConstants.KrForkSecondaryProcessesSettingsVirtual.Synthetic];

var branche = new Dictionary<string, object>();
branche[KrConstants.RowID] = Guid.NewGuid();
branche[KrConstants.ID] = this.CardID;
branche[KrConstants.StageRowID] = this.Stage.RowID;
branche[KrConstants.KrForkSecondaryProcessesSettingsVirtual.SecondaryProcessID] = <Идентификатор вторичного процесса>; // Тип значения: Guid.
branche[KrConstants.KrForkSecondaryProcessesSettingsVirtual.SecondaryProcessName] = <Имя вторичного процесса>; // Тип значения: string.

branches.Add(branche);

Tip

В типовом решении, этап “Ветвление”, с настройкой запускаемых вложенных процессов в сценарии инициализации, используется во вторичном процессе “Разослать задачи по решениям”.

После завершения каждой из веток вызывается сценарий “После завершения ветки”. В сценарии доступен параметр NestedProcessInfo метода контекста типа ForkStageTypeHandler.ScriptContext:

SkipForkAndContinueRoute (тип значения bool) – значение, показывающее, необходимо ли завершить выполнение ветвления и перейти к следующему этапу или нет.
KeepBranchesAlive (тип значения bool) – значение, показывающее, необходимо ли отозвать оставшиеся ветки (false) или оставить – true. Используется только с флагом SkipForkAndContinueRoute.
ProcessInfo (тип значения IDictionary<string, object>) – дополнительная информация завершённого вложенного процесса.
SecondaryProcess (тип значения IKrSecondaryProcess) – информация о вторичном процессе.
BranchInfos (тип значения ListStorage<BranchInfo>) – коллекция содержащая информацию о ветках этапа.

Все вложенные процессы могут иметь доступ к родительскому состоянию процесса с помощью IKrScript.MainProcessInfo. Таким образом можно реализовать взаимодействие между вложенными процессами и этапами ветвления.

В постобработке этапа можно получить информацию обо всех ветках следующим образом:

// В nestInfo обновленные ProcessInfo после завершения процесса.
// После выполнения постобработки коллекция будет очищена.
IDictionary<string, object> nestInfos = Stage.InfoStorage
    .TryGet<Dictionary<string, object>>(KrConstants.Keys.ForkNestedProcessInfo)
    .TryGet<Dictionary<string, object>>(<Идентификатор (RowID) строки в коллекции вторичных процессов преобразованный к строковому формату ForkStageTypeHandlerBase.ForkSecondaryProcessesRowIDFormat>);

IDictionary<string, object> nestInfo = this.GetProcessInfoForBranch(<Идентификатор (RowID) строки в коллекции вторичных процессов>);

// ...

// Техническая информация об ветках доступна в ForkStageTypeHandler.BranchInfo.
var branchInfos = new ListStorage<ForkStageTypeHandler.BranchInfo>((List<object>) this.Stage.InfoStorage[ForkStageTypeHandler.PendingProcesses], ForkStageTypeHandler.BranchInfoFactory);

Обратите внимание, при прерывании ветки ее ProcessInfo не попадает в этап “Ветвление”.

Управление ветвлением¶

Этап управления ветвлением необходим для динамического воздействия на активный этап ветвления. Активный этап ветвления — этап с типом “Ветвление” и в состоянии “Активен”. С помощью управления ветвлением можно воздействовать только на “Ветвление”, которое запустило текущий процесс (в котором находится этап управления ветвлением) или на этап “Ветвление” в первичном процессе.

Этап поддерживает два режима:

Добавить ветку — добавить одну или несколько веток к уже активному этапу ветвления. При необходимости, можно указать ProcessInfo также, как и в этапе “Ветвление”.

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

Выполнять в основном процессе — флажок, который необходимо использовать в том случае, если целевой этап “Ветвление” находится в первичном процессе. Если флажок снят, этап влияет на родительское ветвление. Если флажок установлен, тогда этап управления процессом должен находится в вторичном процессе, который запускается вне первичного. Это может быть нажатие кнопки процесса, событие или запуск в коде расширений с помощью IKrProcessLauncher (кроме запуска из сценариев). Если же флаг не выставлен, тогда этап управления должен находится в вложенном процессе.

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

// Получение строк этапов для первичного процесса
var rows = (await GetContextualSatelliteAsync()).Sections[KrConstants.KrStages.Name].Rows;
// Нахождение строки этапа вложенного процесса
var nestedProcessRow = rows.First(
  p => p["NestedProcessID"] != null 
  && (Guid)p["StageTypeID"] == StageTypeDescriptors.ApprovalDescriptor.ID);
// Идентификатор вложенного процесса
var nestedProcessID = (Guid)nestedProcessRow["NestedProcessID"];

// Настройки текущего этапа управления процессом
var section = Stage
  .SettingsStorage
  .TryGet<List<object>>(KrConstants.KrForkNestedProcessesSettingsVirtual.Synthetic);

// Дополняем настройки идентификатором вложенного процесса
// Данные настройки являются скрытыми, из интерфейса недоступны
var dict = new Dictionary<string, object>();
dict["RowID"] = Guid.NewGuid();
dict["ID"] = CardID;
dict["Order"] = 0;
dict["NestedProcessID"] = nestedProcessID;
section.Add(dict);

При необходимости явно выставлять “Не запущен” вместо “Пропущен” для отменяемой ветки, можно воспользоваться следующим сценарием в инициализации этапа:

Stage.Settings.KrForkManagementSettingsVirtual__DirectionAfterInterrupt = (int)DirectionAfterInterrupt.Backward;

Типизированное задание¶

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

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

Ниже описаны настройки этапа типизированного задания

Исполнители — любые роли в системе, можно указывать несколько. Задания рассылаются параллельно всем исполнителям.

Вид — вид задания.

Для обеспечения функционирования возможности задания вида задания необходимо, чтобы тип задания содержал комплексную колонку TaskCommonInfo.Kind.

Тип задания (обязательный) — определяет тип отправляемых заданий.

Дайджест — текст задания.

Группа настроек Переопределение группы истории заданий.

После завершения каждого задания в этапе вызывается сценарий “После завершения задания”. В нем доступен стандартный контекст сценария этапа, а также дополнительные свойства и методы:

TypedTaskContext.Task — пакет завершаемого задания. Вариант завершения находится в Task.OptionID;
TypedTaskContext.CompleteStage — флаг, используемый для указания обработчику этапа на необходимость завершения этапа. Если выставить в true, то этап будет завершен, активные задания отозваны и управление перейдет к следующему этапу;
TypedTaskContext.SendTaskAsync(Performer исполнитель, Guid? тип задания, DateTime? дата завершения, int? срок в рабочих днях, string дайжест задания, CancellationToken cancellationToken = default) — асинхронно отправляет задания в рамках этапа. Обязательным параметром является — “исполнитель”, остальные значения берутся из настроек этапа, если не указано иное;
TypedTaskContext.RevokeTaskAsync(Guid taskID или IEnumerable<Guid> taskIDs, CancellationToken cancellationToken = default) — асинхронного отзывает задание в текущем процессе по указанным идентификаторам.

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

// Получаем завершаемое задание
var task = TypedTaskContext.Task;
var optionID = task.OptionID;
// Если это запрос комментария
if (optionID == DefaultCompletionOptions.RequestComments) {
    // Получаем из задания информацию для запроса комментария
    var commentator = task.Card.Sections["KrCommentators"].Rows[0];
    var comment = task.Card.Sections["KrTask"].Fields["Comment"] as string;
    var performer = new Performer((Guid)commentator["CommentatorID"], (string)commentator["CommentatorName"]);

    // Отправляем новое задание на комментирование
    var newTask = await TypedTaskContext.SendTaskAsync(performer, DefaultTaskTypes.KrRequestCommentTypeID);
    newTask.Card.Sections[KrConstants.KrRequestComment.Name].Fields[KrConstants.KrRequestComment.AuthorRoleID] = task.UserID;
    newTask.Card.Sections[KrConstants.KrRequestComment.Name].Fields[KrConstants.KrRequestComment.AuthorRoleName] = task.UserName;
    newTask.ParentRowID = task.RowID;
    // Запоминаем идентификатор этого задания
    Stage.Info.CommentID = newTask.RowID;
} else if (optionID == DefaultCompletionOptions.Approve || optionID == DefaultCompletionOptions.Disapprove) {
    // При завершении согласования отзываем комментирование
    var commentID = (Guid)Stage.Info.CommentID;
    await TypedTaskContext.RevokeTaskAsync(commentID);
}
if (optionID == DefaultCompletionOptions.Disapprove) {
    // Завершаем весь этап
    TypedTaskContext.CompleteStage = true;
}

Создать файл по шаблону¶

Этап предназначен для создания файла по шаблону.

В ссылочном поле указывается шаблон файла, в поле “Имя” можно переопределить имя файла (в т.ч. с использованием плейсхолдеров).

Более подробная информация о шаблонах файлов находится в разделе Шаблоны файлов и плейсхолдеры

Диалог¶

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

Вид — вид задания (только для асинхронных)
Дайждест — дайджест (описание) задания (только для асинхронных)
Текст кнопки в задании — название варианта завершения (только для асинхронных)
Тип карточки — тип карточки диалога (Если тип карточки содержит секцию “Satellites” (константа Tessa.Cards.Extensions.Templates.CardSatelliteHelper.SatellitesSectionName), то карточка считается сателлитом)
Шаблон — шаблон, по которому будет создана карточка.
Имя диалога — имя диалога для UI расширений (ICardEditorModel.DialogName). Позволяет фильтровать расширения только для текущего диалога
Алиас диалога — ключ уникальности, позволяющий отображать один и тот же экземпляр карточки в нескольких этапах диалога (если ключ уникальный и карточка уже была создана, то открывается существующая, а не создается новая). Используется только для времени жизни “Карточка”
Время жизни диалога — указание того, с каким объектом ассоциируется карточка диалога
Запрос — карточка диалога передается в запросе и нигде не сохраняется. Получить ее можно только в текущем сохранении. Следует использовать тогда, когда промежуточные данные о заполнении хранить не нужно.
Задание — карточка сохраняется в поле Task.Settings задания в виде JSON объекта. Карточка существует, пока существует задание. Следует использовать, когда нужна возможность промежуточного сохранения результатов диалога.
Карточка — диалог сохраняется как полноценная карточка по таблицам секций. Карточка может быть независима от основной, либо быть сателлитом (содержать секцию “Satellites” (константа Tessa.Cards.Extensions.Templates.CardSatelliteHelper.SatellitesSectionName)). Если карточка является сателлитом, то вместе с удалением/импортом/экспортом основной карточки будут производиться соответствующие операции карточки сателлита. Для независимой карточки этого не происходит. Пример карточки-сателлита в типовом решении — KrExampleDialogSatellite.
Режим открытия диалога — определяет поведение при открытии карточки диалога:
- Всегда
- Не отображать автоматически
Отображаемое имя диалога — значение используется для формирования текста заголовка окна диалога при отсутствии дайджеста карточки.
Сохранять файлы после завершения диалога — определяет время жизни файлов приложенных к карточке диалога с временем жизни “Задание”. Если флаг выставлен, то файлы не удаляются после завершения задания.

Пример использования настройки доступен в примерах маршрутов во вторичном процессе “Диалоги. Пример использования настройки ‘Сохранять файлы после завершения диалога’“.
Не предупреждать при закрытии диалога без изменений — отключает предупреждение при закрытии диалога без изменений по кнопке закрытия окна. Флаг влияет только на диалоги, для которых указано значение параметра Время жизни диалога как Запрос.

Настройки кнопок позволяют задать кнопки верхнего и нижнего тулбаров, а также кнопки диалогов.

Алиас кнопки — название кнопки, используемое в скриптах
Текст — отображаемый текст кнопки
Тип — тип кнопки (Тулбар, диалоговая)
Иконка — алиас иконки для кнопок тулбара (Thin, Int)
Отмена — признак того, что окно диалога следует закрыть без отправки запроса.

В этапе есть два вида скриптов:

Скрипт валидации¶

В контексте доступна полная карточка, включая содержимое файлов.

Контекст содержит:

Dialog.Cancel — признак того, что необходимо прервать обработку диалога без закрытия окна. По умолчанию false, может быть выставлено в true.
Dialog.CompleteDialog — признак того, что этап диалога необходимо завершить. По умолчанию true, может быть выставлено в false, тогда диалоговое окно будет закрыто без завершения этапа.
Dialog.ButtonName — алиас нажатой кнопки.
Dialog.StoreMode — способ сохранения карточки диалога (время жизни диалога).
Dialog.GetDialogCardAsync(CancellationToken cancellationToken = default) — возвращает карточку диалога.
Dialog.GetFileContentAsync(CardFile file) — возвращает контент файла из карточки диалога с временем жизни “Запрос” или “Задание”. Параметр метода file должен быть получен из карточки диалога. Например: (await Dialog.GetDialogCardAsync(this.CancellationToken)).Files[0].
Dialog.SetFileContent(CardFile file, byte[] content) — сохраняет контент файла в карточку диалога с временем жизни “Запрос”.
Dialog.GetFileContainerAsync(IValidationResultBuilder validationResult = default, CancellationToken cancellationToken = default) — возвращает файловый контейнер карточки диалога с временем жизни “Задание” или “Карточка”. Добавление и изменение файлов не поддерживается для диалога с временем жизни “Карточка”.

Пример скрипта валидации

if (Dialog.ButtonName == "aaa" ) {
  Dialog.Cancel = true;
} else if (Dialog.ButtonName == "bbb") {
  Dialog.CompleteDialog = false;
}

Скрипт сохранения¶

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

Контекст содержит:

Dialog.ButtonName — алиас нажатой кнопки.
Dialog.StoreMode — способ сохранения карточки диалога (время жизни диалога).
Dialog.GetDialogCardAsync(CancellationToken cancellationToken = default) — возвращает карточку диалога.
Dialog.GetFileContentAsync(CardFile file) — возвращает контент файла из карточки диалога с временем жизни “Запрос” или “Задание”. Параметр метода file должен быть получен из карточки диалога. Например: (await Dialog.GetDialogCardAsync(this.CancellationToken)).Files[0].
Dialog.SetFileContent(CardFile file, byte[] content) — сохраняет контент файла в карточку диалога с временем жизни “Запрос”.
Dialog.GetFileContainerAsync(IValidationResultBuilder validationResult = default, CancellationToken cancellationToken = default) — возвращает файловый контейнер карточки диалога с временем жизни “Задание” или “Карточка”.

Порядок выполнения скриптов этапа

Время жизни	Действие	Порядок выполнения сценариев
Запрос	Завершение задания	1. Сценарий валидации
Задание Карточка	Закрытие карточки с сохранением Завершение задания	1. Сценарий сохранения 2. Сценарий валидации

Tip

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

Вспомогательные методы для работы с карточкой диалога расположены в классе Tessa.Cards.CardTaskDialogHelper.

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

Управление историей¶

Этап управление историей предназначен для управления группами в истории заданий.

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

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

Создать новую группу, которая будет использоваться для формирования истории заданий можно из рабочего места Администратор:

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

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

Созданную группу можно указывать как в этапе Управление историей, так и в этапах с отправкой задания (Согласование, Задача и т.д.).

Источник

Главная
Страница: 2265
Управление контентом в организации.dor
Каждый документ имеет маршрут движения в соответствии с бизнес-процессом, который он инициирует или в котором он участвует. Например, в системе DIRECTUM можно выбрать согласование документа по регламенту или отправить документ на свободное согласование. Сотрудник подготовил служебную записку на получение средств для закупки необходимых материалов. Предложите, какой вариант маршрута выбрать сотруднику в этом случае и поясните, почему.

Купить за 10 руб.

Купить

весь предмет

help

Источник

Формализация документооборота — способ повысить эффективность внедрения СЭД

Подходы к формализации документооборота

Применение технологий бизнес-моделирования

Система бизнес-моделирования Business Studio

Рекомендуемые материалы по тематике

Процедура БП

От процессного управления к цифровой трансформации и роботизации. Версия 4.0

Достичь вершины легко, если ваши работники умеют и хотят работать — интервью с Игорем Лозовицким в проекте «Управление из первых рук»

Техническая поддержка — ПИТ-стоп в вашем бизнесе

13.1. Основные понятия

13.2. Общая часть

13.3. Маршрутизация

13.4. Система адресации

13.5. Старт бизнес-процесса

13.6. Выполнение задач

13.7. Разделение и слияние

13.8. Ручное управление

13.8.1. Признак завершенности бизнес-процесса

13.8.2. Признак выполнения задачи

13.8.3. Удаление задач

13.8.4. Добавление задач

13.9. Условный переход

13.10.Выбор варианта

13.11.Формирование задач

13.12.Проверка выполнения

13.13.Выполнение вложенных процессов

13.14.Завершение бизнес-процесса

13.15.Стандартные реквизиты бизнес-процессов и задач

13.16.Бизнес-процессы с несколькими точками старта

13.17.Обратная связь

13.18.Карта маршрута

13.19.Редактирование бизнес-процесса

13.20.Редактирование задачи

Управленческий аспект согласования

Три «золотых» правила согласования

Роли подразделений

Зоны ответственности подразделений

Условия успешной реализации процедуры согласования

Алгоритм и способы согласования

Сроки согласования

Схемы и маршруты согласования

Оформление результатов согласования

Контроль согласования

Маршруты документов¶

Введение в маршруты¶

Основные компоненты подсистемы маршрутов¶

Компоненты, настраиваемые администратором¶

Виды процессов маршрутов, расчет маршрута и его выполнение¶

Особенности работы маршрутов при удалении или изменении шаблонов этапов¶

Примеры маршрутов¶

Инициация нового договора (пример)¶

Подготовка, согласование и исполнение служебной записки/заявки (пример)¶

Последовательное согласование договора купли-продажи по списку участников, заданных непосредственно в карточке (пример)¶

Создание уже зарегистрированного документа (пример)¶

Пример передачи данных между процессами¶

Передача данных из основного процесса во вторичный процесс¶

Передача данных между вторичными процессами¶

Установка примеров¶

Настройка маршрутов пользователем¶

Справочник настроек этапов маршрута¶

Настройка маршрутов администратором¶

Карточка “Группа этапов”¶

Карточка “Шаблон этапов”¶

Карточка “Вторичный процесс”¶

Режим “Простой процесс”¶

Режим “Кнопка”¶

Режим “Действие”¶

Карточка “Метод расширения”¶

Карточки маршрутов, входящие в типовую конфигурацию¶

Состояние процесса, состояние этапа и настройки этапа¶

Особенности работы сценариев и рекомендации по их использованию¶

Написание сценариев для объектов маршрута¶

Методы, доступные в контексте¶

Подробнее об объектах для маршрута¶

Типы этапов¶

Общие настройки этапов¶

Согласование¶

Подписание¶

Доработка¶

Задача¶