Маршрут движения документа предполагает последовательность его согласования в компании

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 1

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

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

Пример 2

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

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

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

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

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

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

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

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

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

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

Пример 3

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

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

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

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

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

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

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

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

Пример 4

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

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

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

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

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

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

1 этап.

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

2 этап.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 6

Источник

Направление документа по маршруту

В программе предусмотрено направление документа по следующим элементам маршрута:

Подготовка
Визирование: рассмотрение, утверждение, согласование, подписание
Ознакомление
Исполнение
Регистрация (доступен при автоматическом движении документа по маршруту)
Сканирование (доступен при автоматическом движении документа по маршруту)
Отправка контрагенту (доступен при автоматическом движении документа по маршруту)
Получение от контрагента (доступен при автоматическом движении документа по маршруту)
Формирование дела (доступен при автоматическом движении документа по маршруту)
Передача в архив (доступен при автоматическом движении документа по маршруту)

Для направления документа по маршруту используются модули Документы и Задачи

Способы направления документа по маршруту

В программе предусмотрено несколько способов направления документа по маршруту:

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

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

Обратите внимание

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

Направление документа по автоматическому маршруту

В строке меню карточки документа нажмите на кнопку Отправить и выберите пункт По маршруту.

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

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

Документ будет направлен по выбранному маршруту и выведено соответствующее уведомление.

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

Маршрут документа и варианты создания задач по маршруту (персональная или общая) настраивается в поле Задача справочника Маршруты документов. При этом уведомление о задаче будет направлено всем участникам этой общей задачи.
Задачи, созданные при движении документа по маршруту, могут быть открыты из следующих форм:
- Журнал задач
- Карточка документа / Задачи / Подготовка и визирование документа (задача появляется в течение 1-2 минут с момента перехода документа на соответствующую точку маршрута)
  
  Рабочая группа в карточке документа
Участнику движения документа необходимо:
- Открыть карточку задачи, созданной при движении документа
- Ознакомиться с документом и вынести свое решение (например, согласовать или отклонить документ)

Ознакомление с текущий точкой маршрута документа

При движении документа по маршруту в карточке документа вместо пункта меню Отправить будет приведен пункт Маршрут.

Пункт меню Маршрут в карточке документа

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

Место нахождения документа при движении по маршруту

Направление документа по маршруту в ручном режиме

Обратите внимание

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

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

Согласование договоров и документов в IT Audit

Если документ направлен по автоматическому маршруту, то до его завершения или остановки, направление документа по маршруту в ручном режиме невозможно

В строке меню карточка документа нажмите на кнопку Отправить и выберите один из пунктов:
- На подготовку
- На рассмотрение
- На утверждение
- На согласование
- На подписание
- На исполнение
- На ознакомление
Пункты меню для направления документа по маршруту
В зависимости от выбранного пункта меню будет открыта форма с соответствующим наименованием. Например, при выборе пункта «На согласование» будет открыта форма Направление документа на согласование.
В открывшейся форме необходимо выбрать сотрудника, которому будет направлен документ. Доступно несколько способов выбора сотрудника. Нажмите на кнопку Добавить и выберите один из вариантов:
- сотрудник. Будет открыта форма Выбор сотрудников для выбора одного или нескольких сотрудников, которым необходимо направить документ по маршруту.
  
  Обратите внимание
  
  Если по документу уже была сотруднику создана задача определенного типа (например, согласование документа), то повторно направить такому сотруднику документ по данному типу будет запрещено (данный сотрудник будет отсутствовать в списке для выбора).
  
  При необходимости повторно направить документ данному сотруднику необходимо удалить связь задачи, связанной с движением документа, и документом. В форме Подготовка и визирование документа выделите необходимую задачу и нажмите на кнопку Отменить
- должность. Будет открыта форма Выбор должностей для выбора должностей сотрудников, которым необходимо направить документ. Например, при выборе должности «бухгалтер» программа отберет всех действующих сотрудников с выбранной должность. Должность сотрудника приводится в карточке сотрудника. Данный вариант рекомендуется использовать, если необходимо направить документ по маршруту сотрудникам определенной должности.
- роль. Будет открыта форма Выбор ролей для выбора ролей сотрудников, которым необходимо направить документ. Например, при выборе роли «Руководитель отдела» программа отберет всех действующих сотрудников с выбранной ролью. Найденные сотрудники будет приведены на вкладке Исполнители. документ будет направлен всем сотрудникам с данной ролью. Роли сотрудников настраиваются в формы Управление пользователями. Данный вариант рекомендуется использовать, если необходимо направить документ по маршруту сотрудникам определенной роли.
При необходимости в поле Крайний срок формы Направление документа на согласование … внести крайнюю дату окончания задачи (дедлайн).
При необходимости на вкладке Комментарий внести комментарий. Внесенный комментарий будет приведен на вкладке Обсуждение созданной карточки задачи.
В форме Направление документа на согласование … нажмите на кнопку ОК. Выбранным сотрудникам будут созданы задачи, связанные с движением документа по маршруту. Каждому сотруднику будет создана отдельная задача и направлено уведомление. В качестве инициатора задачи выступает пользователь, который направил документ по маршруту.

В теме созданного уведомления приводится вариант визирования (например, согласование)

Уведомление о задаче по согласованию документа

Открытие задачи, созданной при движении документа по маршруту

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

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

Журнал задач
Рабочая группа в карточке документа

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

Файлы. Внесенные файлы по задаче будут доступны и в карточке документа
Обсуждение. Комментарии, внесенные исполнителем задачи (например, при согласовании документа), будут приведены и в карточке документа

Выполнение задачи, созданной при движении документа по маршруту

В карточке задачи, созданной при движении документа по маршруту, наименования кнопок в панели инструментов зависит от маршрута документа:

Маршрут документа, тип визирования	Кнопки в карточке задачи
Подготовка документа	Подготовлено
Рассмотрение документа	Рассмотрено
Утверждение документа	Утвердить, отклонить
Согласование документа	Согласовать, Отклонить
Подписание документа	Подписать, Отклонить
Исполнение документа	Исполнено
Ознакомление с документом	Ознакомлен
Регистрация документа	Выполнено
Сканирование документа	Выполнено
Отправка документа контрагенту	Выполнено
Получение документа от контрагента	Выполнено
Формирование дела	Выполнено
Передача документа в архив	Выполнено

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

Карточка задачи при согласовании договора

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

Комментарий согласующего лица

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

Рабочая группа в карточке документа

Отмена задачи, созданной при движении документа по маршруту

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

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

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

Формирование отчетов по результатам визирования документа

По результатам визирования и ознакомления с документом формируются следующие отчеты:

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

Чтобы сформировать отчет по документу, в панели инструментов карточки документа нажмите на кнопку Отчет.В открывшейся форме Доступные отчеты выберите необходимый отчет и нажмите на кнопку Сформировать.

См. также

Карточка документа

Справочник «Маршруты документов»

Источник

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

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

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

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

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

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

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

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

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

Прочие команды для управления этапами:

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

Важно

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

На вкладке Основное определяются общие характеристики:
1. Использование маршрута:

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

2. Завершение маршрута:

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

На закладке Дополнительно настраиваются следующие характеристики:
1. Режим возврата на пересмотр – порядок направления документа при его возврате:

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

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

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

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

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

(547)

Комментировать материалы сайта могут зарегистрированные пользователи.

Вход с помощью STSL

Источник

Содержание:

1. Настройка маршрута согласования документов в 1С

2. Создание маршрута согласования

3. Основные этапы маршрута согласования в 1С

3.1 Согласование в 1С

3.2 Объект утвержден и Объект отклонен

3.3 Переход по условию

1. Настройка маршрута согласования документов в 1С

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

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

Далее выбираем требуемый документ:

В нем заходим в меню «Согласование» и нажимает на кнопку «Открыть матрицу полномочий»:

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

После выбора определенного маршрута он становится прикрепленным к документу:

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

2. Создание маршрута согласования

Маршруты согласований находятся в разделе «Процессы и согласования».

Нажимаем кнопку «Создать», пишем наименование и выбираем режим процесса «Маршрут согласования»:

После этого заполняем два появившихся реквизита:

В данном случае был выбран документ «Версия коммерческого договора.

Записываем и закрываем.

Теперь наш маршрут появился в списке. Открываем его. С этого и начинается процесс создания маршрута в 1С:

Нажимаем кнопку «Шаблоны этапов». У нас появляется меню с этапами процесса согласования. Чтобы применить шаблон, его надо перетащить мышкой в левое окно.

3. Основные этапы маршрута согласования в 1С

В этой статье рассмотрим самые распространённые этапы маршрута согласования в 1С.

3.1. Согласование в 1С

Согласование – основной этап маршрута. На этих этапах и происходит согласование либо отклонение согласования. Имеет такой вид (открывается сразу после перетаскивания мышкой):

Основные реквизиты – Наименование и Список согласующих.

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

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

В данном примере настроена доступность корректировки вида договора:

Выбираем нужный реквизит и ставим признак «Есть».

Также в настройках этапа «Согласование» есть опция автоматическое утверждение.

Для включение этой опции надо выставить соответствующую «птичку» и количество часов:

В данном случае этап будет автоматически утвержден по истечении 2 часов от начала согласования этапа.

Для того чтобы этапы согласования в 1С имели взаимосвязь, в каждом из них необходимо прописывать «этапы-последователи»:

Открывается следующее диалоговое окно:

После выбора в качестве последователя «Этап 2» диаграмма приобретет такой вид:

Третий этап согласования (Согласующий Сидоров) пока никак не используется и поэтому он не связан стрелками с другими этапами.

3.2.Объект утвержден и Объект отклонен

Имеют такой вид:

Этап «Объект утвержден» ставят в конце маршрута согласования.

Например, в этапе 2 мы прописали этап последователя «Автоматическое утверждение»:

Маршрут приобрел такой вид:

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

Этап «Объект отклонен» обычно применяется при этапах «Переход по условию», когда документ не соответствует определенным требованиям и не согласовывается.

3.3.Переход по условию

Этот этап служит для перехода по веткам голосования на основании логических условий:

Переходим в сами настройки перехода.

Начинаем с добавления логического условия.

После выбора имеем такой вид:

Следующий шаг – выбор реквизита для условия «если». Раскрываем «Согласуемый объект» и выбираем реквизит. Перетаскиваем его мышкой в поле «параметр», после чего выбираем логическое значение. В данном примере логическое выражение звучит так «Если договор является «Договором с поставщиком»:

Следующий шаг – выбрать действие для этого условия и выбор действия, если это условие не выполняется:

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

Если договор является договором с покупателем, то идем в этап 1 (согласовывает Иванов), если же иначе (договор допустим «С покупателем»), то переходим к этапу 3 (согласовывает Сидоров»).

Маршрут согласования приобрел такой вид:

Желтый цвет стрелок говорит о том, что этап был недавно изменен.

По данному маршруту договоры с поставщиками согласовывают последовательно Иванов и Петров. Остальные договоры согласовывает Сидоров.

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

На шаге «Иначе» добавим еще одно условие.

Сначала удалим предыдущее действие:

Затем добавим условие:

Добавили условие по валюте.

Теперь этап «Переход по условию» выглядит так: если договор с поставщиком, то переходим на этап 1, иначе — если остальные договоры с валютой евро – то переходим на этап 3, иначе переходи на этап «автоматическое отклонение».

Маршрут согласования приобрел такой вид:

Новый маршрут можно читать так: если договор «с поставщиком», то его согласуют последовательно Иванов (этап 1) и Петров (этап 2); а если договор не с «поставщиком» и его валюта взаиморасчетов равно евро – то его согласовывает Сидоров (этап 3). Во всех остальных случаях договор не согласовывается.

Специалист компании ООО «Кодерлайн»

Валерий Есипов.

Источник

Отправим материал Вам на почту

Согласование документов в ЭДО – быстро и прозрачно

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

Согласно опросу, проведенному в июне 2021 года оператором фискальных данных OFD.RU, около 4% российских компаний в своем документообороте отказались от бумаги и завершили переход на ЭДО. При этом больше четверти российских компаний используют только бумажный документооборот. Данные этого исследования объясняют, почему одним из наиболее востребованных и быстро растущих в цене товаров в конце февраля-марте 2022 года оказалась канцелярская бумага.

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

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

Скидка 50% на годовое подключение к внутреннему ЭДО! Если ваше предприятие МСП, подключите пакет «Внутренний ЭДО Плюс» за пол цены.

Подключиться со скидкой

Уровень проникновения ЭДО в России:

3,8% компаний завершили процесс перехода на ЭДО.
39% компаний используют примерно равное количество бумажных и электронных документов.
27% компаний используют только бумажные документы.

Источник: опрос OFD.RU, данные на июнь 2021 года.

Эксперты фиксируют повышение динамики спроса на ЭДО в последние время. Пандемия, санкции и цифровая эволюция подтолкнули рост. Уходить от бумаги документооборот заставляет и государство. Чуть более года назад, в конце 2020-го, была утверждена Концепция развития электронного документооборота. Согласно этому программному документу,

к концу 2024 года в электронный вид должны быть переведены 95 % счетов-фактур и 70% транспортных и товарных накладных. Концепция предполагает ежегодный 20-ти процентный рост числа электронных документов.

Отрасли-флагманы ЭДО в 2021-2022 гг:

финансы,
строительство,
торговля,
машиностроение.

Источник: экспертные оценки.

Проверьте, готовы ли вы к переходу на электронный документооборот?

Этапы работы с документом в ЭДО

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

Особенности электронного согласования

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

Плюсы электронного согласования документа:

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

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

История одного внедрения с оценкой эффективности ЭДО

Компания ««Газпром нефть» публично озвучила детали цифровизации своего документооборота. Речь идет о 82 обществах предприятия и более чем 75 000 контрагентов. Как сообщается в онлайн-журнале предприятия «Сибирская нефть», инвестиции в проект электронного документооборота, по данным на 2020 год, составили около 200 млн. рублей. ЭДО затронул не только внешний документооборот, но и внутренние бизнес-процессы: были автоматизированы все контрольные этапы учета документов, которые раньше делались вручную. «В результате время подписания документа сократилось в десятки раз. Например, согласование акта выполненных работ со сторонним подрядчиком теперь вместо нескольких суток занимает пару часов», — рассказали в компании.

Результаты ЭДО в компании:

7 секунд — доставка документа,

2 дня — обработка документа.

Результаты бумажного документооборота в компании:

20 дней – доставка документа,

6 дней – обработка документа.

Виды электронного согласования документов

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

3 разновидности согласования:

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

СБИС позволяет создавать, эффективно согласовывать и подписывать документы, визируя их электронной подписью. Сделать это легко с электронной подписью для документооборота. Помните, для ЭЦП необходим сертифицированный носитель ЭЦП – токен, например, Рутокен ЭЦП.

Скидка на годовое подключение к ЭДО в размере 50% для предприятий из реестра МСП. Оставьте заявку, и мы расскажем, как получить ЭДО за пол цены.

Получить скидку 50%

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

Оставьте заявку и получите бесплатную консультацию уже сегодня!

Видео по теме

150 000

Клиентов на постоянной поддержке

Офисов по всей России и продолжаем расширяться

15 лет

Мы успешно работаем в сфере электронных решений

24/7

Всегда на связи с клиентами группа Техподдержки

Источник

Преподаватель который помогает студентам и школьникам в учёбе.

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

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

Маршрут документа можно создавать несколькими способами:

Табличный;
Графический.

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

Таблица 1

Маршрут движения договора. Табличная модель.

№	Операция	Документ	Исполнитель	Действия
1.	Составление	Договор	Менеджер	Составляет договор и передает его на согласование юристу.
2.	Проверка	Договор	Юрист	Если все верно, согласовывает договор, в случае возникновения замечаний отправляет менеджеру на доработку.
3.	Доработка	Договор	Менеджер	Исправляет замечания согласующих и отправляет на согласование
4.	Правка	Договор	Руководитель отдела 1, Руководитель отдела 2,	Если все верно, согласовывают договор, в случае возникновения замечаний отправляют менеджеру на доработку.
5.	Согласование	Договор	Бухгалтер	Согласовывает договор и передает его на утверждение.
6.	Утверждение	Договор	Генеральный директор	Утверждает договор, в случае несогласия отправляет его на доработку.

Рис. 1. Маршрут движения договора. Графическая схема

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

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

Многопроцессорные системы
Инструменты поиска информации в Интернет
SEO технологии
Ich habe ein Zimmer für mich
Unser Haus ist hoch und neu
Основные направления развития систем стандартизации, метрологии и сертификации
Профессиональный и жизненный путь Л.С. Выготского «Мысли и язык»
Гуманная педагогика и анти педагогика (принципы гуманистической педагогики)
Чем, по моему мнению, воспитание отличается от обучения (процесс получения знаний)
Моя стратегия формирования новых знаний (развития способностей)
Какая теория/ концепция мне нравится больше и почему
Понятие человеческого капитала организации и его влияние на рыночные позиции, и финансовые результаты

Источник

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

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

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

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

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

Маршрут — это последовательность этапов различных типов, которые выполняются в указанной последовательности. Маршрут строится на основании различных настроек, заданных администратором, а также может быть изменен пользователем в пределах, разрешенных его правами доступа и настройками маршрутов. Возможность для пользователя изменять маршрут, а для администратора — управлять и контролировать этот процесс — уникальная особенность подсистемы маршрутов платформы 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 вернёт открываемую карточку.

Управление историей¶

Этап управление историей предназначен для управления группами в истории заданий.

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

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

Создать новую группу, которая будет использоваться для формирования истории заданий можно из рабочего места Администратор:

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

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

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

Источник