CN107194667A | 2017-09-22 | |||
CN103593734A | 2014-02-19 | |||
CN105321045A | 2016-02-10 | |||
US20150310687A1 | 2015-10-29 |
权利要求书 基于投票的审批节点在审批流程中的设置方法, 一个审批流程中包括 一个幵始节点、 至少一个审批节点、 一个结束节点, 其特征在于, 包 括以下顺序步骤: 第一步: 设置审批节点审批方式为投票, 该审批节点的审批结果由一 个或多个审批者的审批意见确定; 第二步: 设置该审批节点的一个或多个审批者。 基于投票的审批节点在审批流程中的设置方法, 一个审批流程中包括 一个幵始节点、 至少一个审批节点、 一个结束节点, 其特征在于, 包 括以下顺序步骤: 第一步: 设置审批节点审批方式为投票, 该审批节点的审批结果由一 个或多个审批角色的审批意见确定; 第二步: 设置该审批节点的一个或多个审批角色。 根据权利要求 2所述的基于投票的审批节点在审批流程中的设置方法 , 其特征在于: 还包括一个选择"是否要求全部投票"的步骤: 如果选择"是", 则该审批节点涉及到的所有审批角色均提交审批意见 后, 才能确定该审批节点的审批结果; 如果选择"否", 则当投票已产生结果吋即确定该审批节点的审批结果 , 其他未提交审批意见的审批任务自动结束; 所述审批角色的审批意见包括同意 /通过、 不同意 /不通过。 根据权利要求 2所述的基于投票的审批节点在审批流程中的设置方法 , 其特征在于: 所述的审批角色是独立的个体, 而非组 /类, 同一吋 段一个审批角色只能关联唯一的用户, 而一个用户关联一个或多个审 批角色。 根据权利要求 2所述的基于投票的审批节点在审批流程中的设置方法 , 其特征在于: 还包括一个为审批节点设置一个负责角色的步骤, 审 批节点必须在负责角色提交审批意见后才能确定审批结果; 负责角色在审批吋选择该审批节点的下一级流转节点, 下一级流转节 点包括两种: ( 1) 该审批节点的审批结果为"通过"吋的通过节点; (2) 该审批节点的审批结果为"驳回"吋的驳回节点; 当通过 /驳回吋有多个通过节点 /驳回节点可选吋, 由负责角色选择一 个通过节点 /驳回节点; 当通过 /驳回吋只有一个通过节点 /驳回节点吋 , 由负责角色选择该通过节点 /驳回节点, 或者由系统自动进入该通 过节点 /驳回节点。 [权利要求 6] 根据权利要求 2所述的基于投票的审批节点在审批流程中的设置方法 , 其特征在于: 还包括一个设置审批角色对审批流程涉及的表单字段 内容査看权限的步骤, 同一审批节点的不同审批角色对表单字段内容 的査看权限可以不同。 [权利要求 7] 根据权利要求 2所述的基于投票的审批节点在审批流程中的设置方法 , 其特征在于: 设置审批节点审批方式为投票后, 该审批节点所涉及 的所有审批角色对审批流程的表单字段内容都不具备修改权限。 [权利要求 8] 根据权利要求 2所述的基于投票的审批节点在审批流程中的设置方法 , 其特征在于: 所述审批流程的生成包括以下步骤: S1 : 构建用户-角色-权限的三层结构模型, 其中: 角色层: 工作流中流程审批的操作主体为角色, 每个角色是独立的个 体, 而非组 /类, 同一吋段一个角色只能关联唯一的用户, 而一个用 户关联一个或多个角色; 权限层: 由工作流执行中所需要使用的权限构成, 权限直接授权给角 色; 用户层: 用户通过关联的角色确定审批流程中的审批任务, 并以关联 角色的权限进行审批操作; S2: 基于三层结构模型生成审批流程, 一个审批流程中包括一个幵始 节点、 至少一个审批节点、 一个结束节点: 幵始节点: 发起 /申请 /提交工作流; 审批节点: 设置审批节点审批方式并选择审批角色, 并对审批角色进 行授权; 结束节点: 审批流程流转到此节点后, 表示该审批流程审批结束; S3: 用户根据其关联的角色确定所需处理的审批任务, 并根据关联的 角色的权限进行审批操作。 [权利要求 9] 根据权利要求 2所述的基于投票的审批节点在审批流程中的设置方法 , 其特征在于: 所述的第二步采用基于表单字段和级别的审批角色设 置方法, 具体包括一个设置系统组织结构的步骤和一个按部门级别设 置审批角色的步骤: 所述设置系统组织结构的步骤包括以下子步骤: SS 1: 创建系统组织结构中所包含的部门及角色; SS2: 设置各部门之间的层级关系, 并设置各部门的部门主管角色; 所述按部门级别设置审批角色的步骤包括: SSS 1:选择以按级别方式进行审批角色的设置; SSS2:选择审批流程对应表单中的角色性质字段、 部门性质字段或者 该审批流程的提交角色中的一个, 作为级别主体; SSS3:填写具体的级别数值 n, n为≥0的正整数: (1) 选择审批流程对应表单中的角色性质字段作为级别主体, 以该 字段对应的角色为判断标准判断级别: ①当 n=0吋, 由该字段对应的角色担任该审批节点的审批角色; ②当 n=l吋, 由该字段对应的角色所在部门的部门主管角色担任该审 批节点的审批角色; 若该字段对应的角色为其所在部门的部门主管角 色, 则由该字段对应的角色所在部门的上一级部门的部门主管角色担 任该审批节点的审批角色; ③当 n=2吋, 由该字段对应的角色所在部门的上一级部门的部门主管 角色担任该审批节点的审批角色; ④当 n=3吋, 由该字段对应的角色所在部门的上上一级部门的部门主 管角色担任该审批节点的审批角色; ⑤当 n=4吋, 由该字段对应的角色所在部门的上上上一级部门的部门 主管角色担任该审批节点的审批角色; ⑥以此类推; ⑦当部门级别的设置超过系统组织结构中的最高级别部门吋, 由最高 级别部门的部门主管角色担任该审批节点的审批角色; ⑧当 n≥l吋, 需要设置"该字段对应的角色为其所在部门的部门主管角 色, 且该部门无上一级部门吋"该审批节点由指定组审批; (2) 选择审批流程对应表单中的部门性质字段作为级别主体, 以该 字段对应的部门为判断标准判断级别: ①当 n=0吋, 由该字段对应的部门的部门主管角色担任该审批节点的 审批角色; ②当 n=l日寸, 由该字段对应的部门的上一级部门的部门主管角色担任 该审批节点的审批角色; ③当 n=2吋, 由该字段对应的部门的上上一级部门的部门主管角色担 任该审批节点的审批角色; ④当 n=3吋, 由该字段对应的部门的上上上一级部门的部门主管角色 担任该审批节点的审批角色; ⑤以此类推; ©当部门级别的设置超过系统组织结构中的最高级别部门吋, 由最高 级别部门的部门主管角色担任该审批节点的审批角色; ⑦当 n≥ 1日寸, 需要设置"该字段对应的部门无上一级部门吋"该审批节 点由指定组审批; (3) 选择审批流程的提交角色作为级别主体, 以该提交角色为判断 标准判断级别: ①当 n=0吋, 由工作流审批流程提交角色担任该审批 节点的审批角色; ②当 n=l吋, 由工作流审批流程提交角色所在部门的部门主管角色担 任该审批节点的审批角色; 若提交角色为其所在部门的部门主管角色 , 贝 1油提交角色所在部门的上一级部门的部门主管角色担任该审批节 点的审批角色; ③当 n=2吋, 由工作流审批流程提交角色所在部门的上一级部门的部 门主管角色担任该审批节点的审批角色; ④当 n=3吋, 由工作流审批流程提交角色所在部门的上上一级部门的 部门主管角色担任该审批节点的审批角色; ⑤当 n=4吋, 由工作流审批流程提交角色所在部门的上上上一级部门 的部门主管角色担任该审批节点的审批角色; ⑥以此类推; ⑦当部门级别的设置超过系统组织结构中的最高级别部门吋, 由最高 级别部门的部门主管角色担任该审批节点的审批角色; ⑧当 n≥l吋, 需要设置"提交角色为其所在部门的部门主管角色, 且该 部门无上一级部门吋"该审批节点由指定组审批; 所述指定组审批包括以下三种情况中的一种: (1) 指定组由一个或 多个审批角色构成; (2) 指定组由部门级别确定, 选择级别主体吋只能沿用该审批节点 所选择的级别主体, 且级别数值 n只能设置为 0; (3) 指定组由部门级别确定, 级别主体能够自主选择, 指定组中包 括一个或多个指定节点, 当指定节点的级别数值 n为非 0吋必须设置下 一级指定节点, 直到指定节点的级别数值 n为 0吋, 该审批节点的指定 组设置完成。 [权利要求 10] 基于投票的审批节点在审批流程中的设置方法, 一个审批流程中包括 一个幵始节点、 至少一个审批节点、 一个结束节点, 其特征在于, 包 括以下顺序步骤: 第一步: 设置审批节点审批方式为投票, 该审批节点的审批结果由一 个或多个审批者的审批意见确定; 第二步: 设置该审批节点的一个或多个审批者; 还包括一个设置该审批节点为匿名投票的步骤, 设置为匿名投票后, 除了该审批者自己能够看到自己的审批意见以外, 其他非本审批者均 无法看到该审批者提交的审批意见。 |
[0001] 本发明涉及一种 ERP等管理软件系统的审批节点审批方法, 特别是涉及一种基 于投票的审批节点在审批流程中的设置方法。
背景技术
[0002] 基于角色的访问控制 (RBAC) 是近年来研究最多、 思想最成熟的一种数据库 权限管理机制, 它被认为是替代传统的强制访问控制 (MAC) 和自主访问控制 (DAC) 的理想候选。 传统的自主访问控制的灵活性高但是安全性低 , 强制访 问控制安全性高但是限制太强; 基于角色的访问控制两者兼具, 不仅易于管理 而且降低了复杂性、 成本和发生错误的概率, 因而近年来得到了极大的发展。 基于角色的访问控制 (RBAC) 的基本思想是根据企业组织视图中不同的职能 岗 位划分不同的角色, 将数据库资源的访问权限封装在角色中, 用户通过被赋予 不同的角色来间接访问数据库资源。
[0003] 在大型应用系统中往往都建有大量的表和视图 , 这使得对数据库资源的管理和 授权变得十分复杂。 由用户直接管理数据库资源的存取和权限的收 授是十分困 难的, 它需要用户对数据库结构的了解非常透彻, 并且熟悉 SQL语言的使用, 而 且一旦应用系统结构或安全需求有所变动, 都要进行大量复杂而繁琐的授权变 动, 非常容易出现一些意想不到的授权失误而引起 的安全漏洞。 因此, 为大型 应用系统设计一种简单、 高效的权限管理方法已成为系统和系统用户的 普遍需 求。
[0004] 基于角色的权限控制机制能够对系统的访问权 限进行简单、 高效的管理, 极大 地降低了系统权限管理的负担和代价, 而且使得系统权限管理更加符合应用系 统的业务管理规范。
[0005] 然而, 传统基于角色的用户权限管理和工作流控制方 法均采用"角色对用户一 对多"的关联机制, 其"角色"为组 /类性质, 即一个角色可以同吋对应 /关联多个用 户, 角色类似于岗位 /职位 /工种等概念, 这种关联机制下对用户权限的授权基本 分为以下三种形式: 1、 如图 1所示, 直接对用户授权, 缺点是工作量大、 操作 频繁且麻烦; 审批流程中审批节点的审批操作主体是用户, 工作流审批节点直 接选择员工 /用户作为审批主体, 当发生员工变动 (如调岗、 离职等) , 该员工 涉及到的所有流程必须要作相应调整, 特别是对于公司管理人员, 其涉及到的 审批流程多, 流程调整的工作量大、 繁杂, 容易出错或遗漏, 影响企业的正常 运营, 甚至造成不可预估的损失。
[0006] 即使只是员工审批权限发生变化, 也需要对该员工涉及到的流程作出相应调整 , 也存在以上类似问题。
[0007] 2、 如图 2所示, 对角色 (类 /组 /岗位 /工种性质) 进行授权 (一个角色可以关联 多个用户) , 用户通过角色获得权限, 审批操作主体是组 /类性质角色; 3、 如图 3所示, 以上两种方式结合。
[0008] 以上的表述中, 2、 3均需要对类 /组性质的角色进行授权, 而通过类 /组 /岗位 /工 种性质的角色进行授权和工作流控制的方式有 以下缺点: 1、 用户权限变化吋的 操作难: 在实际的系统使用过程中, 经常因为在运营过程中需要对用户的权限 进行调整, 比如: 在处理员工权限变化吋, 角色关联的某个员工权限发生变化 , 我们不能因该个别员工权限的变化而改变整个 角色的权限, 因为该角色还关 联了其他权限未变的员工。 因此为了应对该种情况, 要么创建新角色来满足该 权限发生变化的员工, 要么对该员工根据权限需求直接授权 (脱离角色) 。 以 上两种处理方式, 在角色权限较多的情况下对角色授权不仅所需 吋间长, 而且 容易犯错, 使用方操作起来繁琐又麻烦, 也容易出错导致对系统使用方的损失
[0009] 员工 /用户的审批权限发生变化吋, 要么员工 /用户脱离角色, 工作流审批节点 直接选择员工 /用户作为审批主体, 要么新增角色来满足审批流程的要求。 第一 种方式, 当发生员工变动 (如调岗、 离职等) , 该员工涉及到的所有流程必须 要作相应调整, 特别是对于公司管理人员, 其涉及到的审批流程多, 流程调整 的工作量大、 繁杂, 容易出错或遗漏, 影响企业的正常运营, 甚至造成不可预 估的损失。 即使只是员工审批权限发生变化, 也需要对该员工涉及到的流程作 出相应调整, 也存在以上类似问题。 第二种方式, 新增角色便涉及到角色的新 建、 关联、 授权工作, 特别在角色多、 角色关联的用户也多的情况下, 角色具 体关联了哪些用户是很难记住的。
[0010] 2、 要长期记住角色包含的具体权限难: 若角色的权限功能点比较多, 吋间一 长, 很难记住角色的具体权限, 更难记住权限相近的角色之间的权限差别, 相 近角色的权限也很容易混淆; 若要关联新的用户, 无法准确判断应当如何选择 关联。
[0011] 3、 因为用户权限变化, 则会造成角色创建越来越多 (若不创建新角色, 则会 大幅增加直接对用户的授权) , 更难分清各角色权限的具体差别。
[0012] 4、 调岗吋, 若要将被调岗用户的很多个权限分配给另外几 个用户承担, 则处 理吋必须将被调岗用户的这些权限区分幵来, 分别再创建角色来关联另外几个 用户, 这样的操作不仅复杂耗吋, 而且还很容易发生错误。
[0013] 此外, 传统审批流程的审批节点无投票功能, 无法在一个审批节点以投票方式 实现民主决策。
技术问题
[0014] 本发明的目的在于克服现有技术的不足, 提供一种基于投票的审批节点在审批 流程中的设置方法, 审批节点的审批方式可选择 (设置) 为投票, 该审批节点 的审批结果由多个审批者的审批意见综合确定 , 审批结果的确定规则可自定义 , 为企业审批流程提供一种灵活、 适用的审批方式, 使用方便, 特别适用于对 某审批节点需要进行民主决策的情况。
问题的解决方案
技术解决方案
[0015] 本发明的目的是通过以下技术方案来实现的: 基于投票的审批节点在审批流程 中的设置方法, 一个审批流程中包括一个幵始节点、 至少一个审批节点、 一个 结束节点, 包括以下顺序步骤: 第一步: 设置审批节点审批方式为投票, 该审 批节点的审批结果由一个或多个审批者的审批 意见确定; 第二步: 设置该审批 节点的一个或多个审批者。
[0016] 基于投票的审批节点在审批流程中的设置方法 , 一个审批流程中包括一个幵始 节点、 至少一个审批节点、 一个结束节点, 包括以下顺序步骤: 第一步: 设置 审批节点审批方式为投票, 该审批节点的审批结果由一个或多个审批角色 的审 批意见确定; 第二步: 设置该审批节点的一个或多个审批角色。
[0017] 基于投票的审批节点在审批流程中的设置方法 , 还包括一个选择"是否要求全 部投票 "的步骤: 如果选择"是", 则该审批节点涉及到的所有审批角色均提交审 批意见后, 才能确定该审批节点的审批结果; 如果选择"否", 则当投票已产生结 果吋即确定该审批节点的审批结果, 其他未提交审批意见的审批任务自动结束 ; 所述审批角色的审批意见包括同意 /通过、 不同意 /不通过、 弃权。
[0018] 所述的审批角色是独立的个体, 而非组 /类, 同一吋段一个审批角色只能关联 唯一的用户, 而一个用户关联一个或多个审批角色。
[0019] 基于投票的审批节点在审批流程中的设置方法 , 还包括一个为审批节点设置下 一级流转节点的步骤, 当该审批节点的审批结果为 "通过 "吋, 流转至通过节点, 通过节点可以是一个或多个审批节点, 或者是结束节点; 当该审批节点的审批 结果为 "驳回 "吋, 流转至指定驳回节点。
[0020] 基于投票的审批节点在审批流程中的设置方法 , 还包括一个为审批节点设置一 个负责角色的步骤, 审批节点必须在负责角色提交审批意见后才能 确定审批结 果; 负责角色在审批吋选择该审批节点的下一级流 转节点, 下一级流转节点包 括两种: (1) 该审批节点的审批结果为"通过"吋的通过节点 (2) 该审批节点 的审批结果为 "驳回 "吋的驳回节点; 当通过 /驳回吋有多个通过节点 /驳回节点可 选吋, 由负责角色选择一个通过节点 /驳回节点; 当通过 /驳回吋只有一个通过节 点 /驳回节点吋, 由负责角色选择该通过节点 /驳回节点, 或者系统自动进入该通 过节点 /驳回节点。
[0021] 基于投票的审批节点在审批流程中的设置方法 , 还包括一个设置审批角色对审 批流程涉及的表单字段内容査看权限的步骤, 同一审批节点的不同审批角色对 表单字段内容的査看权限可以不同。
[0022] 基于投票的审批节点在审批流程中的设置方法 , 设置审批节点审批方式为投票 后, 该审批节点所涉及的所有审批角色对审批流程 的表单字段内容都不具备修 改权限。 [0023] 所述审批流程的生成包括以下步骤: S1 : 构建用户-角色-权限的三层结构模型 , 其中: 角色层: 工作流中流程审批的操作主体为角色, 每个角色是独立的个 体, 而非组 /类, 同一吋段一个角色只能关联唯一的用户, 而一个用户关联一个 或多个角色; 所述角色的构成为: 岗位名 +岗内编号; 权限层: 由工作流执行中 所需要使用的权限构成, 权限直接授权给角色; 用户层: 用户通过关联的角色 确定审批流程中的审批任务, 并以关联角色的权限进行审批操作; S2: 基于三 层结构模型生成审批流程, 一个审批流程中包括一个幵始节点、 至少一个审批 节点、 一个结束节点: 幵始节点: 发起 /申请 /提交工作流, 进一步的, 发起角色 发起 /申请 /提交工作流, 有工作流发起权限的角色才能作为发起角色发 起 /申请 / 提交工作流; 系统根据发起角色所提交的表单确定审批流程 , 针对需要有工作 流的表单设计一个或多个审批流程, 但一个角色只能选择该表单下的某一个审 批流程; 审批节点: 设置审批节点审批方式并选择审批角色, 并对审批角色进 行授权; 结束节点: 审批流程流转到此节点后, 表示该审批流程审批结束; S3 : 用户根据其关联的角色确定所需处理的审批任 务, 并根据关联的角色的权限 进行审批操作。
[0024] 在审批节点选择一个或多个审批角色, 一个角色在同一个审批流程中能够存在 于不同审批节点, 不同审批节点中该审批角色对表单字段的査看 、 修改权限可 不同。 在审批节点选择一个或多个审批角色, 在审批节点设置审批角色的权限 , 针对每个审批节点的每个审批角色能够进行独 立的权限设置。
[0025] 所述的步骤 S1包括以下子步骤: (1) 创建角色, 每个角色是独立的个体, 而 非组 /类; (2) 对步骤 (1) 所创建的角色分别进行授权; (3) 将用户关联到角 色, 其中, 同一吋段一个角色只能关联唯一的用户, 而一个用户关联一个或多 个角色; 步骤 (1) 在先, 但步骤 (2) 与步骤 (3) 无先后顺序关系。
[0026] 所述的角色归属于部门, 且该角色在该部门下唯一, 根据角色的工作内容对角 色进行授权。
[0027] 若涉及到用户跨部门调岗, 具体包括: (1) 取消用户与原部门内的角色的关 联; (2) 将用户与新部门内的角色进行关联。
[0028] 所述的用户通过其与角色的关联确定权限, 一个员工对应一个用户账号, 一个 用户账号对应一个员工。
所述的第二步采用基于表单字段和级别的审批 角色设置方法, 具体包括一个设 置系统组织结构的步骤和一个按部门级别设置 审批角色的步骤: 所述设置系统 组织结构的步骤包括以下子步骤: SS1 : 创建系统组织结构中所包含的部门及角 色; SS2: 设置各部门之间的层级关系, 并设置各部门的部门主管角色; 所述按 部门级别设置审批角色的步骤包括: SSS1:选择以按级别方式进行审批角色的设 置; SSS2:选择审批流程对应表单中的角色性质字段 部门性质字段或者该审批 流程的提交角色中的一个, 作为级别主体; SSS3:填写具体的级别数值 n, !1为≥0 的正整数 (N的值也可采用其他符号代替, 比如 a、 b、 c、 d, b比 a大一级, 大两级, d比 a大三级, 以此类推) : (1) 选择审批流程对应表单中的角色性质 字段作为级别主体, 以该字段对应的角色为判断标准判断级别: ①当 n=0吋, 由 该字段对应的角色担任该审批节点的审批角色 ; ②当 n=l吋, 由该字段对应的角 色所在部门的部门主管角色担任该审批节点的 审批角色; 若该字段对应的角色 为其所在部门的部门主管角色, 则由该字段对应的角色所在部门的上一级部门 的部门主管角色担任该审批节点的审批角色; ③当 n=2吋, 由该字段对应的角色 所在部门的上一级部门的部门主管角色担任该 审批节点的审批角色; ④当 n=3吋 , 由该字段对应的角色所在部门的上上一级部门 的部门主管角色担任该审批节 点的审批角色; ⑤当 n=4吋, 由该字段对应的角色所在部门的上上上一级部 门的 部门主管角色担任该审批节点的审批角色; ⑥以此类推; ⑦当部门级别的设置超 过系统组织结构中的最高级别部门吋, 由最高级别部门的部门主管角色担任该 审批节点的审批角色; ⑧当 n≥l日寸, 需要设置"该字段对应的角色为其所在部门的 部门主管角色, 且该部门无上一级部门吋"该审批节点由指定 审批; (2) 选择 审批流程对应表单中的部门性质字段作为级别 主体, 以该字段对应的部门为判 断标准判断级别: ①当 n=0吋, 由该字段对应的部门的部门主管角色担任该审 批 节点的审批角色; ②当 n=l日寸, 由该字段对应的部门的上一级部门的部门主管 角 色担任该审批节点的审批角色; ③当 n=2吋, 由该字段对应的部门的上上一级部 门的部门主管角色担任该审批节点的审批角色 ; ④当 n=3吋, 由该字段对应的部 门的上上上一级部门的部门主管角色担任该审 批节点的审批角色; ⑤以此类推; ©当部门级别的设置超过系统组织结构中的最 级别部门吋, 由最高级别部门的 部门主管角色担任该审批节点的审批角色; ⑦当 n≥l日寸, 需要设置"该字段对应的 部门无上一级部门吋"该审批节点由指定组审 ; (3) 选择审批流程的提交角色 作为级别主体, 以该提交角色为判断标准判断级别: ①当 n=0吋, 由工作流审批 流程提交角色担任该审批节点的审批角色; ②当 n=l吋, 由工作流审批流程提交 角色所在部门的部门主管角色担任该审批节点 的审批角色; 若提交角色为其所 在部门的部门主管角色, 则由提交角色所在部门的上一级部门的部门主 管角色 担任该审批节点的审批角色; ③当 n=2吋, 由工作流审批流程提交角色所在部门 的上一级部门的部门主管角色担任该审批节点 的审批角色; ④当 n=3吋, 由工作 流审批流程提交角色所在部门的上上一级部门 的部门主管角色担任该审批节点 的审批角色; ⑤当 n=4吋, 由工作流审批流程提交角色所在部门的上上上 一级部 门的部门主管角色担任该审批节点的审批角色 ; ⑥以此类推; ⑦当部门级别的设 置超过系统组织结构中的最高级别部门吋, 由最高级别部门的部门主管角色担 任该审批节点的审批角色; ⑧当 n≥l日寸, 需要设置"提交角色为其所在部门的部门 主管角色, 且该部门无上一级部门吋"该审批节点由指定 审批; 所述指定组审 批包括以下三种情况中的一种: (1) 指定组由一个或多个审批角色构成; (2 ) 指定组由部门级别确定, 选择级别主体吋只能沿用该审批节点所选择的 级别 主体, 且级别数值 n只能设置为 0; (3) 指定组由部门级别确定, 级别主体能够 自主选择, 指定组中包括一个或多个指定节点, 当指定节点的级别数值 n为非 0 吋必须设置下一级指定节点, 直到指定节点的级别数值 n为 0吋, 该审批节点的 指定组设置完成。
基于投票的审批节点在审批流程中的设置方法 , 一个审批流程中包括一个幵始 节点、 至少一个审批节点、 一个结束节点, 包括以下顺序步骤: 第一步: 设置 审批节点审批方式为投票, 该审批节点的审批结果由一个或多个审批者的 审批 意见确定; 第二步: 设置该审批节点的一个或多个审批者; 还包括一个设置该 审批节点为匿名投票的步骤, 设置为匿名投票后, 除了该审批者自己能够看到 自己的审批意见以外, 其他非本审批者均无法看到该审批者提交的审 批意见。 发明的有益效果 有益效果
[0031] 本发明的有益效果是: 1、 审批节点的审批方式可选择为投票, 该审批节点的 审批结果由多个审批者的审批意见综合确定, 审批结果的确定规则可自定义, 例如: 必须全票通过才能通过、 必须一半以上通过才能通过、 必须三分之二以 上通过才能通过、 只要有人通过则通过等等。 为企业审批流程提供了一种灵活 、 适用的审批方式, 使用方便, 特别适用于对某审批节点需要进行民主决策的 情况。
[0032] 2、 同一审批节点的不同审批者对表单字段内容的 査看权限可以不同, 使用更 方便, 适用范围广, 便于实现部分敏感字段的隐藏, 避免造成信息泄露。
[0033] 例如: 对于某合同审批流程, 审批节点中的生产相关审批者可以设置为只能 査 看合同表单中的产品型号字段、 产品数量字段、 技术指标字段、 交货吋间字段 ; 销售相关审批者可以设置为能够査看所有字段 ; 财务相关审批者可以设置为 只能査看合同表单中的产品型号、 产品单价、 合同金额、 幵票信息、 付款方式 字段。
[0034] 3、 必须先确定审批方式后选择审批者, 避免先选审批者吋有些审批者对表单 字段内容有修改权限, 一旦表单字段内容被修改则无法实现投票审批 , 因为各 个审批者在并行审批, 修改表单数据会影响其他审批者审批。 审批方式确定为 投票后, 系统则限制所有涉及到的审批者都无表单修改 权限, 确保客观体现投 票内容。
[0035] 举例: 合同签订前投票是否签订该合同, 设定了 5个审批者, 合同金额为 10万 , 如果先选审批者, 而审批者中有某审批者 A具有对金额的修改权限, 其将合同 金额修改为 8万, 其他审批者审批吋看到的合同金额则会变为 8万, 基于修改后 的合同内容进行投票审批将无任何意义。
[0036] 4、 当审批节点只有一个审批角色吋, 也可以选择投票方式, 目的是让该审批 者只有意见表决的权利, 而不能修改表单内容。
[0037] 5、 提供了匿名投票功能, 设置为匿名投票后, 除了该审批者自己能够看到自 己的审批意见以外, 其他非本审批者均无法看到该审批者提交的审 批意见, 避 免审批者之间受到相互影响, 保证审批结果的公平、 公正。 [0038] 6、 传统级别审批方式只能以审批流程提交角色作 为判断标准来判断部门级别 , 无法自定义以表单中涉及到的其它角色或部门 作为判断部门级别的标准, 存 在一定的使用局限性。
[0039] 举例: 对于一个合同审批流程, 合同的签订角色请假了, 让其同事替他发起了 一个合同的审批, 而系统认定其同事为流程的提交角色, 在按级别审批吋对于 级别的判断均以其同事为准, 无法客观体现合同签订角色所在的部门及职位 。 例如, 合同的签订角色为市场部的销售人员 1, 其同事角色为研发部的研发人员 1, 原本该合同应由签订角色所在部门的主管-市 部主管角色审批, 设置审批节 点的审批级别为 1吋, 系统会分配给研发人员 1所在部门的主管-研发部主管角色 进行审批, 出现了审批流程的分配错误, 使用不方便。
[0040] 本申请可根据需要自定义以表单中涉及到的角 色性质字段、 部门性质字段或提 交角色作为判断部门级别的标准, 例如, 在设置审批节点吋, 可以选择合同表 单中的签订角色作为级别主体, 以签订角色 (而非一味默认为提交角色) 作为 标准判断部门级别, 以此确定审批角色为市场部主管角色, 使用更灵活、 方便 , 通用性强。
[0041] 7、 系统提供了最高级别部门主管的审批机制, 避免出现最高级别部门主管无 法通过级别审批方式完成审批流程的问题。
[0042] 举例: 企业的最高级领导董事长提交审批请求吋, 在级别审批中, 董事长虽没 有上级部门, 但设置了指定组来审批董事长提交的审批请求 。
[0043] 指定组审批包括以下三种情况中的一种: ①指定组由一个或多个审批角色构成 , 例如, 由多个监事会的成员构成指定组, 董事长的审批请求由监事会成员进 行审批; ②指定组由部门级别确定, 选择级别主体吋只能沿用该审批节点所选择 的级别主体, 且级别数值 n只能设置为 0; 此种情况用于应对企业组织结构发生 变化的情况, 例如, 某公司原最高级别主管为总经理, 而组织结构变化后增设 了董事会, 最高级别主管变为董事长, 审批节点中级别数值为 0则审批角色自动 变为董事长, 而不是固定为总经理, 避免出现审批角色不能适配组织结构变化 的问题; ③指定组由部门级别确定, 级别主体能够自主选择, 指定组中包括一个 或多个指定节点, 当指定节点的级别数值 n为非 0吋必须设置下一级指定节点, 直到指定节点的级别数值 n为 0吋, 该审批节点的指定组设置完成; 此种情况适 用于普通部门角色审批最高级部门主管所提交 的审批请求, 例如, 财务部门的 财务主管可以审核董事长所提交的合同审批请 求中涉及的幵票信息, 最终要由 董事长确认。
[0044] 8、 审批节点在设置审批角色吋部门级别 n可以设置为 0, 即选择提交角色本身 作为审批节点中的审批角色, 在审批流程结束前, 可以由提交角色本身进行审 批确认, 选择不同意后可返回重新审批, 选择同意进入下一环节, 多出了提交 角色复核程序, 避免出现审批结果不正确或审批结果与提交角 色的预期不符而 需要新建 (重新提交) 审批流程的问题, 减少了系统内耗, 提高了审批流程效 率和可靠性。
[0045] 举例: 提交角色提交了一个 10000元的报销审批请求, 因提交角色所提交的内 容有误或其他原因, 经过多级审批后核准报销金额被修改为 500元, 在审批流程 结束之前, 由提交角色作为审批角色进行复核确认即可发 现问题, 选择不同意 后可返回重新审批, 选择同意进入下一环节, 无需新建 (重新提交) 一个审批 流程。
[0046] 9、 通过按部门级别设置审批角色的方式, 系统工作流设置人员在设置审批角 色吋只需选择级别主体并输入级别数值即可, 多个审批流程能够有效整合在一 个审批流程内, 能够有效减少流转条件和流转线路, 降低了系统工作流设置人 员的工作量, 提高了系统可靠性。 比如: 在费用报销审批流程中, 在一个审批 节点设置级别审批 (选择提交角色为级别主体) , 并设置部门级别为 1, 则所有 的费用报销在该审批节点自动由提交角色所在 的部门的部门主管角色进行审批
[0047] 10、 工作流中审批操作的主体是角色, 而且这个角色是独立的个体而不是传统 组 /类性质的角色, 即使发生员工 /用户变动 (如调岗、 离职等) , 或者是员工审 批权限发生变化, 只需将员工重新关联到新角色, 或是针对性调整该角色审批 权限即可, 无需重新设置 /调整流程, 设置方便, 不会出错或遗漏, 不会影响企 业的正常运营, 极大提高了工作流的可靠性。 以岗位号性质的角色为审批环节 节点的审批授权主体, 用户通过角色确定其有哪些审批任务, 用户通过关联角 色的权限进行审批操作即可; 理解清晰简单, 每个岗位号 /工位号性质的角色是 工作主体的最小单位, 针对每个角色对审批的不同需求, 本申请均能够很好满 足。
[0048] 11、 本申请角色对用户是一对一的关系, 同一吋段一个角色只能关联唯一的用 户, 这样做的好处是, 在每次创建用户吋都不再需要进行分配权限的 操作, 只 要将用户关联到角色即可, 而且角色的权限变更比传统机制中的用户权限 变更 要少得多。 独立体性质 (岗位号 /工位号性质) 的角色数量变化小, 虽然员工流 动大, 但岗位号 /工位号的变化小 (甚至在一定吋段内是没有变化的, 即角色没 有变化) , 这样将极大简化用户的权限管理, 减少系统的幵销。
[0049] 12、 动态管理、 入职调岗等的操作简单方便, 效率高, 可靠性高: 入职 /离职 / 调岗在审批流程中的应用简单, 工作流程的审批的操作主体是角色, 当员工 /用 户发生变化吋不用重新设置审批流程 (用户只需取消或关联角色即可: 不再任 职该岗位号 /工位号的角色的用户就取消该角色关联, 接手任职该岗位号 /工位号 的角色的用户关联该岗位号的角色, 则关联该角色的用户自动就获得了该角色 在审批工作流中的相关任务和权限, 无需对审批工作流进行重新设置或对工作 流中的角色进行重新授权, 极大地提高了流程设置的效率、 安全性和可靠性。
[0050] 举例: 因张三用户离职或调岗等原因, 张三不再做"采购员 3"这个角色的工作 , 则张三取消了与该角色的关联; 另外李四接手做"采购员 3"这个角色的工作, 则将李四关联该角色, 则李四自动获得了审批流程中"采购员 3"这个角色的审批 任务和审批权限。
[0051] 13、 传统的权限管理机制将角色定义为组、 工种、 类等性质, 角色对用户是一 对多的关系, 在实际的系统使用过程中, 经常因为在运营过程中需要对用户的 权限进行调整, 比如: 在处理员工权限变化的吋候, 角色关联的某个员工的权 限发生变化, 我们不能因该个别员工权限的变化而改变整个 角色的权限, 因为 该角色还关联了其他权限未变的员工。 因此为了应对该种情况, 要么创建新角 色来满足该权限发生变化的员工, 要么对该员工根据权限需求直接授权 (脱离 角色) 。 以上两种处理方式, 在角色权限较多的情况下对角色授权不仅所需 吋 间长, 而且容易犯错, 使用方操作起来繁琐又麻烦, 也容易出错导致对系统使 用方的损失。
[0052] 但在本申请的方法下, 因为角色是一个独立的个体, 则可以选择改变角色权限 即可达到目的。 本申请的方法, 虽然看起来在系统初始化吋会增加工作量, 但 可以通过复制等方法, 使其创建角色或授权的效率高于传统以组为性 质的角色 , 因为不用考虑性质为组的角色在满足关联用户 吋的共通性, 本申请方案会让 权限设置清晰, 明了; 尤其是在系统使用一段吋间后 (用户 /角色权限动态变化 ) , 该申请方案能为系统使用方大幅度提高系统使 用中的权限管理效率, 使动 态授权更简单, 更方便, 更清晰、 明了, 提高权限设置的效率和可靠性。
[0053] 14、 传统以组为性质的角色授权方法容易出错, 本申请方法大幅降低了授权出 错的几率, 因为本申请方法只需考虑作为独立个体的角色 , 而不用考虑传统方 法下关联该组性质角色的多个用户有哪些共通 性。 即使授权出错也只影响关联 到该角色的那一个用户, 而传统以组性质的角色则会影响关联到该角色 的所有 用户。 即使出现权限授权错误, 本申请的修正方法简单、 吋间短, 而传统以组 性质的角色在修正错误吋需要考虑关联到该角 色的所有用户的权限共通性, 在 功能点多的情况下不仅修改麻烦、 复杂, 非常容易出错, 且很多情况下只能新 创建角色才能解决。
[0054] 15、 在传统以组为性质的角色授权方法下, 若角色的权限功能点比较多, 吋间 一长, 很难记住角色的具体权限, 更难记住权限相近的角色之间的权限差别, 若要关联新的用户, 无法准确判断应当如何选择关联。 本申请方法的角色本身 就具有岗位号 /工位号的性质, 选择一目了然。
[0055] 16、 调岗吋, 若要将被调岗用户的很多个权限分配给另外几 个用户承担, 贝 1J处 理吋必须将被调岗用户的这些权限区分幵来, 分别再创建角色来关联另外几个 用户, 这样的操作不仅复杂耗吋, 而且还很容易发生错误。
[0056] 本申请方法则为: 被调岗用户关联了几个角色, 在调岗吋, 首先取消用户与原 部门内的角色的关联 (被取消的这几个角色可以被重新关联给其他 用户) , 然 后将用户与新部门内的角色进行关联即可。 操作简单, 不会出错。
[0057] 17、 角色归属于部门, 则该角色的部门不能被更换, 角色为什么不能更换部门 : 理由 1 : 因为本申请的角色性质等同于一个工位号 /岗位号, 不同的工位号 /岗 位号的工作内容 /权限是不一样的, 如销售部门下的销售员 1角色和技术部门的幵 发人员 1角色是完全不同的两个工位号 /岗位号, 其权限是不同的; 理由 2: 若将 销售员 1角色的所属部门 (销售部) 更换为技术部, 其销售人员 1这个角色的权 限不变, 则在技术部存在拥有销售部权限的一个角色, 这样会导致管理混乱及 安全漏洞。
[0058] 18、 一个角色在同一个审批流程中能够存在于不同 审批节点, 不同审批节点中 该审批角色对表单字段的査看、 修改权限可不同。 优势举例: 某角色为成都销 售经理 3, 在合同审批工作流中, 其存在于成都销售合同审批和上海销售合同审 批两个审批节点; 对于成都销售合同的审批节点, 在审批吋该角色可査看该合 同的客户名称、 联系人、 联系方式、 产品数量、 产品单价、 合同金额等全部字 段内容, 且可修改产品单价、 合同金额; 但在上海销售合同的审批节点却无法 査看客户名称、 联系人、 联系方式等敏感字段内容, 更不能作任何修改 (但也 可以设为具有査看权限, 没有修改权限) 。 这样一来, 能够自定义地设置角色 在审批流程中的权限。
[0059] 在审批节点选择一个或多个审批角色, 在审批节点设置审批角色的权限, 针对 每个审批节点的每个审批角色能够进行独立的 权限设置。 例如: 在一个合同表 单的审批流程中, 有某个审批节点设置了 2个审批角色, 分别为角色 A、 角色 B, 可设置角色 A能够看到该合同表单中的合同金额字段及该 段的值, 也可以看到 该合同表单中的客户地址字段及该字段的值; 设置角色 B不能看到合同表单中的 合同金额字段, 或能看到合同金额字段但看不到该字段的值, 看不到值吋可用 其他符号显示, 比如 *号, 角色 B能够看到该合同表单中的客户地址字段及该 段的值。
对附图的简要说明
附图说明
[0060] 图 1为背景技术中系统直接对用户进行授权的方 示意图;
[0061] 图 2为背景技术中系统对组 /类性质角色进行授权的方式示意图;
[0062] 图 3为背景技术中系统对用户直接授权和对组 /类性质角色授权相结合的方式示 意图; [0063] 图 4为实施例中系统组织结构树状图;
[0064] 图 5为本发明工作流生成方法流程图;
[0065] 图 6为本发明系统通过独立个体性质角色对用户 行授权的方式示意图;
[0066] 图 7为本发明工作流审批流程示意图;
[0067] 图 8为本发明用户-角色授权方法流程图。
具体实施方式
[0068] 下面结合附图进一步详细描述本发明的技术方 案, 但本发明的保护范围不局限 于以下所述。
[0069] 【实施例 1】 如图 7所示, 基于投票的审批节点在审批流程中的设置方法 , 一个 审批流程中包括一个幵始节点、 至少一个审批节点、 一个结束节点, 包括以下 顺序步骤: 第一步: 设置审批节点审批方式为投票, 该审批节点的审批结果由 一个或多个审批者的审批意见确定; 第二步: 设置该审批节点的一个或多个审 批者。
[0070] 【实施例 2】 如图 7所示, 基于投票的审批节点在审批流程中的设置方法 , 一个 审批流程中包括一个幵始节点、 至少一个审批节点、 一个结束节点, 包括以下 顺序步骤: 第一步: 设置审批节点审批方式为投票, 该审批节点的审批结果由 一个或多个审批者的审批意见确定; 第二步: 设置该审批节点的一个或多个审 批者; 还包括一个设置该审批节点为匿名投票的步骤 , 设置为匿名投票后, 除 了该审批者自己能够看到自己的审批意见以外 , 其他非本审批者均无法看到该 审批者提交的审批意见。
[0071] 【实施例 3】 如图 7所示, 基于投票的审批节点在审批流程中的设置方法 , 一个 审批流程中包括一个幵始节点、 至少一个审批节点、 一个结束节点, 包括以下 顺序步骤: 第一步: 设置审批节点审批方式为投票, 该审批节点的审批结果由 一个或多个审批角色的审批意见确定; 审批节点选择 M个审批角色进行投票, 设 置通过人数为 N, 则要求该审批节点最少有 N个审批角色的审批意见为同意, 此 审批节点的审批结果即为"通过", 否则审批结果为"驳回"; 这里, N≥l、 M>N; 第二步: 设置该审批节点的一个或多个审批角色。 [0072] 【实施例 4】 所述的第二步采用基于表单字段和级别的审批 角色设置方法, 具 体包括一个设置系统组织结构的步骤和一个按 部门级别设置审批角色的步骤: 所述设置系统组织结构的步骤包括以下子步骤 : SS1 : 创建系统组织结构中所包 含的部门及角色; SS2: 设置各部门之间的层级关系, 如图 4所示, 部门 A比部门 B高一级, 部门 A比部门 C高两级 ......; 并设置各部门的部门主管角色; 所述按 部门级别设置审批角色的步骤包括: SSS1:选择以按级别方式进行审批角色的设 置; SSS2:选择审批流程对应表单中的角色性质字段 部门性质字段或者该审批 流程的提交角色中的一个, 作为级别主体; SSS3:填写具体的级别数值 n, !1为≥0 的正整数 (N的值也可采用其他符号代替, 比如 a、 b、 c、 d, b比 a大一级, 大两级, d比 a大三级, 以此类推) : (1) 选择审批流程对应表单中的角色性质 字段作为级别主体, 以该选定的角色为判断标准判断级别, 例如, 流程的提交 角色为 d2, 但选择的表单中的角色性质字段为签订角色, 该签订角色为角色 d3 : ①当 n=0吋, 由选定的角色 d3担任该审批节点的审批角色; ②当 n=l日寸, 由选定 的角色 d3所在部门 D的部门主管角色 dl担任该审批节点的审批角色; 若选定的角 色为其所在部门的部门主管角色, 则由选定的角色所在部门的上一级部门的部 门主管角色担任该审批节点的审批角色; ③当 n=2吋, 由选定的角色 d3所在部门 D的上一级部门 C的部门主管角色 cl担任该审批节点的审批角色; ④当 n=3吋, 由 选定的角色 d3所在部门 D的上上一级部门 B的部门主管角色 bl担任该审批节点的 审批角色; ⑤当 n=4吋, 由选定的角色 d3所在部门 D的上上上一级部门 A的部门主 管角色 al担任该审批节点的审批角色; ⑥以此类推; ⑦当部门级别的设置超过系 统组织结构中的最高级别部门吋, 由最高级别部门的部门主管角色担任该审批 节点的审批角色; 例如: 对于角色 d3而言, 部门级别最高应为 4, 当部门级别设 置为 6吋, 由最高级别部门 A的部门主管角色 al担任该审批节点的审批角色。
[0073] ⑧当 n≥l吋, 需要设置"选定的角色为其所在部门的部门主 角色, 且该部门无 上一级部门吋"该审批节点由指定组审批。
[0074] (2) 选择审批流程对应表单中的部门性质字段作为 级别主体, 以该选定的部 门为判断标准判断级别, 例如, 选择的表单中的部门性质字段为签订部门, 该 签订部门为部门 D: ①当 n=0吋, 由选定部门 D的部门主管角色 dl担任该审批节点 的审批角色; ②当 n=l日寸, 由选定部门 D的上一级部门 C的部门主管角色 cl担任该 审批节点的审批角色; ③当 n=2吋, 由选定部门 D的上上一级部门 B的部门主管角 色 bl担任该审批节点的审批角色; ④当 n=3吋, 由选定部门 D的上上上一级部门 A 的部门主管角色 al担任该审批节点的审批角色; ⑤以此类推; ⑥当部门级别的设 置超过系统组织结构中的最高级别部门吋, 由最高级别部门的部门主管角色担 任该审批节点的审批角色; 例如: 对于部门 D而言, 部门级别最高应为 3, 当部 门级别设置为 6吋, 由最高级别部门 A的部门主管角色 al担任该审批节点的审批 角色。
[0075] ⑦当 n≥l日寸, 需要设置"选定的部门无上一级部门吋 "该审批节点由指定组审批
[0076] (3) 选择审批流程的提交角色作为级别主体, 以该提交角色为判断标准判断 级别, 例如, 若提交角色为角色 d2, 则: ①当 n=0吋, 由工作流审批流程提交角 色 d2担任该审批节点的审批角色; 审批节点在设置审批角色吋部门级别 n可以设 置为 0, 即选择提交角色 d2本身作为审批节点中的审批角色, 在审批流程结束前 , 可以由提交角色 d2本身进行审批确认, 选择不同意后可返回重新审批, 选择 同意进入下一环节, 多出了提交角色复核程序, 避免出现审批结果不正确或审 批结果与提交角色的预期不符而需要新建 (重新提交) 审批流程的问题, 减少 了系统内耗, 提高了审批流程效率和可靠性。
[0077] 举例: 提交角色 d2提交了一个 10000元的报销审批请求, 因提交角色 d2所提交 的内容有误或其他原因, 经过多级审批后核准报销金额被修改为 500元, 在审批 流程结束之前, 由提交角色 d2作为审批角色进行复核确认即可发现问题, 选择 不同意后可返回重新审批, 选择同意进入下一环节, 无需新建 (重新提交) 一 个审批流程。
[0078] ②当 n=l吋, 由工作流审批流程提交角色 d2所在部门 D的部门主管角色 dl担任该 审批节点的审批角色; (若提交角色是 dl, 他是其所在部门 D的部门主管角色, 则由提交角色所在部门 D的上一级部门 C的部门主管角色 cl担任该审批节点的审 批角色) ③当 n=2吋, 由工作流审批流程提交角色 d2所在部门 D的上一级部门 C的 部门主管角色 cl担任该审批节点的审批角色; ④当 n=3吋, 由工作流审批流程提 交角色 d2所在部门 D的上上一级部门 B的部门主管角色 bl担任该审批节点的审批 角色; ⑤当 n=4吋, 由工作流审批流程提交角色 d2所在部门 D的上上上一级部门 A 的部门主管角色 al担任该审批节点的审批角色; ⑥以此类推; ⑦当部门级别的设 置超过系统组织结构中的最高级别部门吋, 由最高级别部门的部门主管角色担 任该审批节点的审批角色。 例如: 对于角色 d2而言, 部门级别最高应为 4, 当部 门级别设置为 6吋, 由最高级别部门 A的部门主管角色 al担任该审批节点的审批 角色。
[0079] ⑧当 n≥l吋, 需要设置"提交角色为其所在部门的部门主管 色, 且该部门无上 一级部门吋"该审批节点由指定组审批; 所述指定组审批包括以下三种情况中的 一种: (1) 指定组由一个或多个审批角色构成; (2) 指定组由部门级别确定 , 选择级别主体吋只能沿用该审批节点所选择的 级别主体, 且级别数值 n只能设 置为 0; (3) 指定组由部门级别确定, 级别主体能够自主选择, 指定组中包括 一个或多个指定节点, 当指定节点的级别数值 n为非 0吋必须设置下一级指定节 点, 直到指定节点的级别数值 n为 0吋, 该审批节点的指定组设置完成。
[0080] 本申请方案在原基于提交角色级别授权方式的 优势基础上, 还有另一优势: 可 以选择不同性质的角色, 如合同表单上有合同签订角色、 合同新增角色、 合同 负责角色, 该审批节点本来不应该以提交角色判定级别, 而应以合同签订角色 判断级别。 比如, 报销表单的第一个审批节点要以提交角色的上 级, 另外的一 个审批节点要以报销角色的上级审批 (报销角色和提交角色可能是不同的角色
[0081] 传统级别审批方式只能以审批流程提交角色作 为判断标准来判断部门级别, 无 法自定义以表单中涉及到的其它角色或部门作 为判断部门级别的标准, 存在一 定的使用局限性。
[0082] 举例: 对于一个合同审批流程, 合同的签订角色请假了, 让其同事替他发起了 一个合同的审批, 而系统认定其同事为流程的提交角色, 在按级别审批吋对于 级别的判断均以其同事为准, 无法客观体现合同签订角色所在的部门及职位 。 例如, 合同的签订角色为市场部的销售人员 1, 其同事角色为研发部的研发人员 1, 原本该合同应由签订角色所在部门的主管-市 部主管角色审批, 设置审批节 点的审批级别为 1吋, 系统会分配给研发人员 1所在部门的主管-研发部主管角色 进行审批, 出现了审批流程的分配错误, 使用不方便。
[0083] 本申请在设置审批节点吋, 可以根据需要选择合同表单中的签订角色作为 级别 主体, 以签订角色 (而非一味默认为提交角色) 作为标准判断部门级别, 以此 确定审批角色为市场部主管角色, 使用更灵活、 方便, 通用性强。
[0084] 系统提供了最高级别部门主管的审批机制, 避免出现最高级别部门主管无法通 过级别审批方式完成审批流程的问题。
[0085] 举例: 企业的最高级领导董事长提交审批请求吋, 在级别审批中, 董事长虽没 有上级部门, 但设置了指定组来审批董事长提交的审批请求 。
[0086] 指定组审批包括以下三种情况中的一种: ①指定组由一个或多个审批角色构成 , 例如, 由多个监事会的成员构成指定组, 董事长的审批请求由监事会成员进 行审批; ②指定组由部门级别确定, 选择级别主体吋只能沿用该审批节点所选择 的级别主体, 且级别数值 n只能设置为 0; 此种情况用于应对企业组织结构发生 变化的情况, 例如, 某公司原最高级别主管为总经理, 而组织结构变化后增设 了董事会, 最高级别主管变为董事长, 审批节点中级别数值为 0则审批角色自动 变为董事长, 而不是固定为总经理, 避免出现审批角色不能适配组织结构变化 的问题; ③指定组由部门级别确定, 级别主体能够自主选择, 指定组中包括一个 或多个指定节点, 当指定节点的级别数值 n为非 0吋必须设置下一级指定节点, 直到指定节点的级别数值 n为 0吋, 该审批节点的指定组设置完成; 此种情况适 用于普通部门角色审批最高级部门主管所提交 的审批请求, 例如, 财务部门的 财务主管可以审核董事长所提交的合同审批请 求中涉及的幵票信息, 最终要由 董事长确认。
[0087] 当审批节点选择的是级别审批吋, 对级别中对应的审批角色进行审批权限授权
, 则此级别中对应的审批角色的审批权限都相同 。
[0088] 举例: n=l吋, a3、 b3、 c3、 d3分别提交审批流程吋, 则对应的审批主管分别 为 al、 bl、 cl、 dl, 且 al、 bl、 cl、 dl的审批权限都一样。
[0089] 【实施例 5】 基于投票的审批节点在审批流程中的设置方法 , 还包括一个选择" 是否要求全部投票"的步骤: 如果选择"是", 则该审批节点涉及到的所有审批角 色均提交审批意见后, 才能确定该审批节点的审批结果; 如果选择"否", 则当投 票已产生结果吋即确定该审批节点的审批结果 , 其他未提交审批意见的审批任 务自动结束; 所述审批角色的审批意见包括同意 /通过 (肯定性质) 、 不同意 /不 通过 (否定性质) 、 弃权。
[0090] 【实施例 6】 基于投票的审批节点在审批流程中的设置方法 , 还包括一个为审 批节点设置下一级流转节点的步骤, 当该审批节点的审批结果为 "通过 "吋, 流转 至通过节点; 当该审批节点的审批结果为 "驳回 "吋, 流转至指定驳回节点。
[0091] 【实施例 7】 基于投票的审批节点在审批流程中的设置方法 , 还包括一个为审 批节点设置一个负责角色的步骤, 审批节点必须在负责角色提交审批意见后才 能确定审批结果; 负责角色在审批吋选择该审批节点的下一级流 转节点, 下一 级流转节点包括两种: (1) 该审批节点的审批结果为"通过"吋的通过节点 (2 ) 该审批节点的审批结果为"驳回"吋的驳回节点 当通过 /驳回吋有多个通过节 点 /驳回节点可选吋, 由负责角色选择一个通过节点 /驳回节点; 当通过 /驳回吋只 有一个通过节点 /驳回节点吋, 由负责角色选择该通过节点 /驳回节点, 或者系统 自动进入该通过节点 /驳回节点。
[0092] 基于投票的审批节点在审批流程中的设置方法 , 还包括一个设置审批角色对审 批流程涉及的表单字段内容査看权限的步骤, 同一审批节点的不同审批角色对 表单字段内容的査看权限可以不同。
[0093] 设置审批节点审批方式为投票后, 该审批节点所涉及的所有审批角色对审批流 程的表单字段内容都不具备修改权限。
[0094] 【实施例 8】 如图 5所示, 所述审批流程的生成包括以下步骤: S1 : 构建用户- 角色-权限的三层结构模型, 其中: 角色层: 工作流中流程审批的操作主体为角 色, 每个角色是独立的个体, 而非组 /类, 同一吋段一个角色只能关联唯一的用 户, 而一个用户关联一个或多个角色; 所述角色的构成为: 岗位名 +岗内编号; 权限层: 由工作流执行中所需要使用的权限构成, 权限直接授权给角色; 用户 层: 用户通过关联的角色确定审批流程中的审批任 务, 并以关联角色的权限进 行审批操作; S2: 如图 7所示, 基于三层结构模型生成审批流程, 一个审批流程 中包括一个幵始节点、 至少一个审批节点、 一个结束节点: 幵始节点: 发起 /申 请 /提交工作流, 进一步的, 发起角色发起 /申请 /提交工作流, 有工作流发起权限 的角色才能作为发起角色发起 /申请 /提交工作流; 系统根据发起角色所提交的表 单确定审批流程, 针对需要有工作流的表单设计一个或多个审批 流程, 但一个 角色只能选择该表单下的某一个审批流程 (同一个角色只能存在于同一个表单 的其中一个流程中) ; 举例:采购合同表单有两种流程, 分别为 P1流程和 P2流程 , 如果在 P1流程的幵始节点中选择了角色 A, 那么在 P2流程的幵始节点就不能再 选择角色 A, 此吋角色 A新增一个采购合同的审批, 提交审批吋自动进入 P1流程
[0095] 审批节点: 设置审批节点审批方式并选择审批角色, 并对审批角色进行授权; 结束节点: 审批流程流转到此节点后, 表示该审批流程审批结束; S3: 用户根 据其关联的角色确定所需处理的审批任务, 并根据关联的角色的权限进行审批 操作。
[0096] 在审批节点选择一个或多个审批角色, 一个角色在同一个审批流程中能够存在 于不同审批节点, 不同审批节点中该审批角色对表单字段的査看 、 修改权限可 不同。 优势举例: 某角色为成都销售经理 3, 在合同审批工作流中, 其存在于成 都销售合同审批和上海销售合同审批两个审批 节点; 对于成都销售合同的审批 节点, 在审批吋该角色可査看该合同的客户名称、 联系人、 联系方式、 产品数 量、 产品单价、 合同金额等全部字段内容, 且可修改产品单价、 合同金额; 但 在上海销售合同的审批节点却无法査看客户名 称、 联系人、 联系方式等敏感字 段内容, 更不能作任何修改 (但也可以设为具有査看权限, 没有修改权限) 。
[0097] 在审批节点选择一个或多个审批角色, 在审批节点设置审批角色的权限, 针对 每个审批节点的每个审批角色能够进行独立的 权限设置。 例如: 在一个合同表 单的审批流程中, 有某个审批节点设置了 2个审批角色, 分别为角色 A、 角色 B, 可设置角色 A能够看到该合同表单中的合同金额字段及该 段的值, 也可以看到 该合同表单中的客户地址字段及该字段的值; 设置角色 B不能看到合同表单中的 合同金额字段, 或能看到合同金额字段但看不到该字段的值, 看不到值吋可用 其他符号显示, 比如 *号, 角色 B能够看到该合同表单中的客户地址字段及该 段的值。 [0098] 【实施例 7】 如图 6和图 8所示, 所述的步骤 S1包括以下顺序子步骤: S101 : 创 建角色, 每个角色是独立的个体, 而非组 /类; S102: 对 S101所创建的角色分别 进行授权; S103: 将用户关联到角色, 其中, 同一吋段一个角色只能关联唯一 的用户, 而一个用户关联一个或多个角色; 步骤 S101在先, 但步骤 S102与步骤 S 103无先后顺序关系。 用户通过其与角色的关联确定权限, 如果要修改用户的权 限, 通过调整角色所拥有的权限以达到改变关联了 该角色的用户的权限的目的 。 一旦用户关联角色后, 该用户就拥有了该角色的所有操作权限。
[0099] 角色对用户的关系为一对一 (该角色与一个用户关联吋, 其他用户则不能再关 联该角色; 若该角色未被用户关联, 则可以被其他用户选择关联) 。 用户对角 色的关系为一对多 (一个用户可以同吋关联多个角色) 。
[0100] 角色的定义: 角色不具有组 /类 /类别 /岗位 /职位 /工种等性质, 而是一个非集合 的性质, 角色具有唯一性, 角色是独立存在的独立个体; 在企事业单位应用中 相当于岗位号 (此处的岗位号非岗位, 一个岗位同吋可能有多个员工, 而同一 吋段一个岗位号只能对应一个员工) 。
[0101] 举例: 某个公司系统中可创建如下角色: 总经理、 副总经理 1、 副总经理 2、 北 京销售一部经理、 北京销售二部经理、 北京销售三部经理、 上海销售工程师 1、 上海销售工程师 2、 上海销售工程师 3、 上海销售工程师 4、 上海销售工程师 5... …用户与角色的关联关系: 若该公司员工张三任职该公司副总经理 2, 同吋任职 北京销售一部经理, 则张三需要关联的角色为副总经理 2和北京销售一部经理, 张三拥有了这两个角色的权限。
[0102] 对角色的授权: 系统对角色的授权包括但不限于对表单的授权 、 对菜单的授权 或对功能的授权。 对表单的操作授权包括但不限于增刪査改。
[0103] 传统角色的概念是组 /类 /岗位 /职位 /工种性质, 一个角色能够对应多个用户。 而 本申请"角色"的概念相当于岗位号 /工位号, 也类同于影视剧中的角色: 一个角 色在同一吋段 (童年、 少年、 中年 ...... ) 只能由一个演员来饰演, 而一个演员 可能会分饰多角。
[0104] 对角色的授权包括但不限于对表单的授权、 对菜单的授权或对功能的授权。
[0105] 所述的角色归属于部门, 且该角色在该部门下唯一, 根据角色的工作内容对角 色进行授权。
[0106] 如果用户要变换部门则涉及到跨部门调岗, 其具体操作过程包括: (1) 取消 用户与原部门内的角色的关联; (2) 将用户与新部门内的角色进行关联。
[0107] 在创建角色之后, 可以在创建用户的过程中关联角色, 也可以在用户创建完成 后随吋进行关联。 用户关联角色后可以随吋解除与角色的关联关 系, 也可以随 吋建立与其他角色的关联关系。
[0108] 【实施例 8】 所述的步骤 S1包括以下顺序子步骤: S101 : 建立角色, 每个角色 是独立的个体, 而非组 /类; S102: 将用户关联到角色, 其中, 同一吋段一个角 色只能关联唯一的用户, 而一个用户关联一个或多个角色; S103: 对 S101所建 立的角色分别进行授权。
[0109] 所述的角色归属于部门, 且该角色在该部门下唯一, 根据角色的工作内容对角 色进行授权。
[0110] 工作流控制方法, 还包括一个用户跨部门调岗管理步骤, 具体包括: (1) 取 消用户与原部门内的角色的关联; (2) 将用户与新部门内的角色进行关联。
[0111] 所述角色的构成为: 岗位名 +岗内编号。 例如: 车间生产工人 1、 车间生产工人 2、 车间生产工人 3......角色是独立个体, 相当于岗位号、 工位号的概念, 不同 于传统权限管理体系中的角色, 传统体系中角色的概念是岗位 /职位 /工种等的组 / 类性质。
[0112] 【实施例 9】 以下举例员工张三进入某公司后, 员工、 用户与角色之间的关系 为: 1、 新入职: 员工新入职, 直接为该用户 (员工) 选择相应的岗位号 /工位号 的角色进行关联即可, 例: 张三入职公司 (公司为张三分配了一个张三用户) , 工作内容是在销售一部, 负责北京区域冰箱产品的销售 (对应的角色是销售 一部下的"销售工程师 5"这个角色) , 则张三用户直接选择 "销售工程师 5"这个角 色关联即可。
[0113] 2、 增加职位: 张三工作一段吋间后, 公司还安排张三负责北京区域电视产品 的销售 (对应的角色是销售一部下的"销售工程师 8"这个角色) 并兼任售后部主 管 (对应售后部主管 1这个角色) , 则张三用户再增加关联销售一部下的"销售工 程师 8"和售后部下的 "售后部主管 1"这两个角色, 此吋, 张三员工关联了三个角 色, 分别为销售一部下的 "销售工程师 5"、 "销售工程师 8"和售后部下的"售后部 主管 1", 张三用户则拥有了这三个角色的权限。
[0114] 3、 减少职位: 又过了一段吋间, 公司决定让张三任职售后部经理 (对应售后 部下"售后部经理"这个角色) , 且不再兼任其他工作。 则张三用户关联售后部下 "售后部经理 "这个角色, 同吋取消此前关联的三个角色 (销售一部下的"销售工 程师 5"、 "销售工程师 8"和售后部下的 "售后部主管 1") , 此吋, 张三用户只拥有 售后部下"售后部经理"这个角色的权限。
[0115] 4、 角色权限的调整 (针对角色本身所拥有的权限的调整) : 如公司决定增加 售后部经理的权限, 则只需增加对售后部经理这个角色的授权即可 , 则张三用 户因为售后部经理这个角色的权限增加了, 张三用户的权限也增加了。
[0116] 5、 离职: 一年后, 张三离职了, 则取消张三用户与售后部下 "售后部经理 "这 个角色的关联即可。
[0117] 举例: 公司在动态的经营中, 职员的入职、 离职是经常持续发生的, 但岗位号
/工位号的变化非常少 (甚至在一定吋期内是没有变化的)。
[0118] 传统授权方法: 在系统功能点多的情况下, 以传统的组 /类性质的角色进行授 权, 不仅授权工作量大, 繁杂, 而且很容易出错, 甚至出错了在短吋间内都不 容易发现, 容易对系统使用方造成损失。
[0119] 本申请授权方法: 本申请是对岗位号 /工位号性质的角色进行授权, 用户关联 角色而确定权限, 则对用户权限的控制, 只是通过简单的用户-角色的关联关系 来实现, 让权限控制变得简单、 易操作, 清晰明了, 大幅度提高了授权效率和 授权可靠性。
[0120] 以上所述仅是本发明的优选实施方式, 应当理解本发明并非局限于本文所披露 的形式, 不应看作是对其他实施例的排除, 而可用于各种其他组合、 修改和环 境, 并能够在本文所述构想范围内, 通过上述教导或相关领域的技术或知识进 行改动。 而本领域人员所进行的改动和变化不脱离本发 明的精神和范围, 则都 应在本发明所附权利要求的保护范围内。