11工作流—条件判断工作流节点处理人应用方案.doc

条件判断工作流节点处理人应用方案 目录 业务场景 步骤一：将“组织单元全名称”变量引入条件判断中 步骤二：设置节点处理人条件判断公式 步骤三：根据请假天数设置流程流向 常见报错问题检查 业务场景 HR实施顾问小王，在使用K3HR给客户XXX公司实施工作流时，遇到了难题。XXX公司在全国有30余家分支机构，在上了K3HR之后，希望将全国各分支机构的人事工作流程纳入HR系统统一管理。小王和客户沟通后，确定先从业务最频繁的请假工作流着手分步实施。 根据客户的请假制度，凡是三天以下的假期，由直接上级审批即可；超过三天的，需由间接上级审批。审批后，所有请假申请均需传到对应的人力资源部审核备案。比如，北京分公司的员工，请假审批后需要传到北京分公司人力资源部审核备案。上海分公司的员工，请假审批后需要传到上海分公司审核备案。 经过仔细研究，小王发现系统不能自动判断出员工所属分公司，在同一流程中系统无法将员工的申请自动提交到对应的分公司人力资源部。因此，只能对每个分公司对应设置一条请假流程才能解决客户的需求。于是，小王与客户方的系统管理员一起，花了整整一周的时间，分别按照32家分公司建立了32条请假流程。流程是建好了，可如果再上其他业务流程，又得每个业务再建32条，客户认为，这样做系统管理员的工作量太大，且流程维护相当的繁杂，且这32条流程的设置原理基本相同，最好是能归结到一条流程中实现。 根据客户需求，在K3HR10.3版本中，实现了自动判断流程节点处理人的功能来满足该客户的业务需要。即在32家分公司中，员工的请假申请可以通过条件判断，自动流向对应分公司的人力资源部处理人。条件判断的主要参照变量，就是员工的所属组织单元全名称。 新功能面世了，小王非常高兴，根据产品说明，结合XXX公司的业务场景，小王迫不及待的在测试账套中使用起来。 首先，小王根据XXX公司的请假审批权限划分，创建了一条由“本人、直接上级、间接上级和人力资源部”四节点组成的请假审批流程。然后，就根据产品说明一步步开始进行条件判断设置。 步骤一：将“组织单元全名称”变量引入条件判断中 对不能通过职员上下级关系来进行判断，且有众多的分支条件的情况下，可以使用职员的所属组织单元全名称变量来设置判断条件，由系统自动判断下一节点的处理人。 比如非人力资源部的员工，和分公司人力资源部不存在直接上下级关系，就不能通过职员上下级关系来进行流程判断。且客户有32家分公司，就意味着有32个分支条件。根据新功能，可以使用员工所在的组织单元全名称来作为条件的判断变量。 如何将“所属组织单元全名称”变量引入到条件判断中呢？ 操作方法： 第一步：进入请假工作流流程图。如下图： 第二步：在流程图中增加“自动应用”节点。“所属组织单元全名称”变量必须通过“自动应用”节点来引入。“自动应用”节点可增在“开始”和“直接上级”节点间。如下图： 第三步：自定义“组织单元全名称”变量并更新至流程变量。双击“自动应用”节点，弹出“活动属性对话框”，在“变量”页签，须自定义两个变量，例如：一个叫“职员ID”，类型为“职员”；一个就是“组织单元全称”，类型为“字符型”。定义完成后，点击“更新至流程变量”。系统会提示更新成功。如图： 注意 上图中的职员ID类型错了，应该是职员类型，不是整型。 这里为什么要定义“职员ID”变量呢？由于小王设置的流程是以请假职员本人，即流程对象作为参照对象的，因此必须要定义一个“职员ID”变量。 第四步：建立自定义变量的引出对应关系。进入“自动应用”节点活动属性框中的“任务”页签，点击“任务列表”的选择按钮，进入“任务列表对话框”，双击选择“人事公用信息”下的“获取组织单元全名称”任务，点击“确定”按钮，返回“任务”页签界面。在“入口参数”中，建立参数和变量的对应关系：职员（empid）参数对应职员ID变量，组织单元全名称（orgFullname）参数对应组织单元全称变量。如下图： 可能会问，“入口参数”中建立参数和变量对应关系的作用是什么？这里的作用是，将职员ID输入系统后，系统会根据职员ID，找到对应的组织单元全名称，并输出组织单元全名称的值。那么自定义的职员ID是怎样才能和系统中的职员ID对应呢？马上就介绍。 第五步：建立职员ID变量对应关系。进入“开始”节点的活动属性，在“任务”页签的“活动输出”中，将“职员ID”变量的对象属性设为“员工ID”，点击“确定”，这样就完成了第四步遗留的疑问了。变量关系全部建立完成了，可别忘了添加连接弧。 第六步：组织单元全名称变量进入条件判断表达式编辑器。经过前面的辛苦 劳动，组织单元全称变量已经被引入到公式编辑器中了。在“人力资源部”节点，进行节点处理人的判断条件设置时，就可以在公式编辑器中使用到“组织单元全名称”变量了。具体的使用方法，请接步骤二