表单数据操作的审核方法与流程

本发明涉及erp、crm等管理软件中表单数据操作的审核方法。

背景技术

基于角色的访问控制（rbac）是近年来研究最多、思想最成熟的一种数据库权限管理机制，它被认为是替代传统的强制访问控制（mac）和自主访问控制（dac）的理想候选。传统的自主访问控制的灵活性高但是安全性低，强制访问控制安全性高但是限制太强；基于角色的访问控制两者兼具，不仅易于管理而且降低了复杂性、成本和发生错误的概率，因而近年来得到了极大的发展。基于角色的访问控制（rbac）的基本思想是根据企业组织视图中不同的职能岗位划分不同的角色，将数据库资源的访问权限封装在角色中，用户通过被赋予不同的角色来间接访问数据库资源。

在大型应用系统中往往都建有大量的表和视图，这使得对数据库资源的管理和授权变得十分复杂。由用户直接管理数据库资源的存取和权限的收授是十分困难的，它需要用户对数据库结构的了解非常透彻，并且熟悉sql语言的使用，而且一旦应用系统结构或安全需求有所变动，都要进行大量复杂而繁琐的授权变动，非常容易出现一些意想不到的授权失误而引起的安全漏洞。因此，为大型应用系统设计一种简单、高效的权限管理方法已成为系统和系统用户的普遍需求。

基于角色的权限控制机制能够对系统的访问权限进行简单、高效的管理，极大地降低了系统权限管理的负担和代价，而且使得系统权限管理更加符合应用系统的业务管理规范。

然而，传统基于角色的用户权限管理均采用“角色对用户一对多”的关联机制，其“角色”为组/类性质，即一个角色可以同时对应/关联多个用户，角色类似于岗位/职位/工种等概念，这种关联机制下对用户权限的授权基本分为以下三种形式：1、如图1所示，直接对用户授权，缺点是工作量大、操作频繁且麻烦；当发生员工变动（如调岗、离职等），该员工涉及到的所有权限必须要作相应调整，特别是对于公司管理人员，其涉及到的权限多，权限调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。

2、如图2所示，对角色（类/组/岗位/工种性质）进行授权（一个角色可以关联多个用户），用户通过角色获得权限，权限授权主体是组/类性质角色；3、如图3所示，以上两种方式结合。

以上的表述中，2、3均需要对类/组性质的角色进行授权，而通过类/组/岗位/工种性质的角色进行授权的方式有以下缺点：1、用户权限变化时的操作难：在实际的系统使用过程中，经常因为在运营过程中需要对用户的权限进行调整，比如：在处理员工权限变化时，角色关联的某个员工权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。

员工/用户的表单操作权限发生变化时，要么员工/用户脱离角色，要么新增角色来满足工作要求。第一种方式的缺陷同上述“直接对用户授权”方式的缺陷。第二种方式，新增角色便涉及到角色的新建、关联、授权工作，特别在角色多、角色关联的用户也多的情况下，角色具体关联了哪些用户是很难记住的。

2、要长期记住角色包含的具体权限难：若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，相近角色的权限也很容易混淆；若要关联新的用户，无法准确判断应当如何选择关联。

3、因为用户权限变化，则会造成角色创建越来越多（若不创建新角色，则会大幅增加直接对用户的授权），更难分清各角色权限的具体差别。

4、调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。

审核与审批的区别:1、审核角色与审批角色的区别：本申请审核方法的审核角色是有权限对该条数据（表单数据）进行审核的角色，通过表单授权或数据/表单数据（表单表达的是一种业务对象，比如订单、合同、客户等等，每一条表单数据对应了一个唯一的业务对象，比如客户表单中的001客户就代表了一个唯一的客户001，客户001为一个表单数据/对象）授权实现，可能有多个角色都对某一条数据（表单数据）有权限，只需要其中一个角色完成审核（或该数据审核有一个结果，不论该结果是肯定还是否定），该审核任务就结束了；而审批角色是审批流程步骤中设置的角色，不特定针对哪条数据（表单数据），而是针对到达该审批节点的审批任务，则该审批节点的审批角色就可以审批，根据审批流程的类型，一个角色审批完成就到下一步骤或结束（单人审批），也可能是多个角色审批后看通过人数（投票），或是所有角色都必须提交审批意见（会签）；2、审核任务与审批任务的区别：（1）任务的取消：本申请的审核方法，表单数据在新增时（已经提交新增审核请求了）是提交角色(或提交者)点击撤销提交按钮，审核任务就撤销，修改和删除时是有权限点击撤销提交（撤销修改）或撤销删除的角色(或提交者)都可以点击撤销审核任务；流程审批的审批取消都是由流程发起者取消。

（2）任务的过程：本申请的审核方法，有且只有一个审核步骤，一旦审核同意或不同意，审核任务即结束；审批，是根据设置的审批流程步骤一步一步的建立任务，一个审批流程步骤执行之后是要同意进行下一步，还是不同意退回到某一步骤，或者根据投票情况判断该执行哪一步，或者步骤中所有角色表达意见后到下一步，最后的某一个步骤同意通过后可以选择结束步骤，然后结束该审批流程，数据（表单数据）的审批任务才算完成；审批过程中，有可能再次执行到之前的某流程步骤（比如驳回）。

（3）审核可以同意或不同意（本申请审核方法：审核结果为同意或不同意该审核任务都结束），而审批流程结束时就一定是同意才能结束。

市面上也有部分软件具有审核功能，然而现有软件的审核功能中没有给出不同意的审核结果的功能，仅仅只有类似签字（或确认性质）同意的功能，没有表达不签字/不同意/不通过的功能，不能及时快速地向审核请求人反馈未通过的审核结果。对于提交人而言，其提交的数据（表单数据）中未通过的部分包括审核结果为不通过的数据（表单数据）和未经审核的数据（表单数据），提交人难以分辨。

市面上现有软件的审核功能表达的是表单数据的一种状态或表单数据的状态切换，不是表达其审核过程，也没有解锁申请/请求、审核申请/请求，不能清晰的表达其过程，不能清晰的了解数据变化的逻辑；而本申请审核方法有解锁申请/请求和/或审核申请/请求，并生成相关明确的审核任务，更适合企业的实际管理需求。

技术实现要素：

本发明的目的在于克服现有技术的不足，提供一种表单数据操作的审核方法，对于不需要繁杂审批流程的表单数据，用审核功能实现表单数据操作的审核确认，无需创建流程，减少审核人员/流程创建人员的工作量，缩短表单数据操作审核周期；审核者采用独立个体性质的角色，能够实现审核权限的无缝交接，保证用户审核权限得到及时更新，不会出现审核权限更新的滞后或遗漏，不会影响企业正常运营，也规避了机密信息泄露的风险。

本发明的目的是通过以下技术方案来实现的：表单数据操作的审核方法，包括以下步骤：

（1）创建系统中的角色，所述的角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；

（2）选择系统中的一个或多个角色作为审核者，为每个审核者授权其具有的表单数据的操作的审核权限；

（3）审核请求人提交某个表单数据的某种操作的审核请求；

（4）由具有该表单数据该操作的审核权限的审核者对该审核请求进行审核，给出审核意见。

步骤（1）~步骤（4）顺序执行，或步骤（3）、步骤（1）、步骤（2）、步骤（4）顺序执行。

所述的审核意见包括同意/通过、不同意/不通过（同意/通过、不同意/不通过只是一种肯定或否定的表达方式，也可以用其他方式表达）。

所述的表单数据的操作包括对表单数据的新增、修改和删除中的任意一种。

若要修改/删除表单数据，还包括一个解锁申请的步骤：s1：解锁申请人申请解锁表单数据，由有该条表单数据该操作的解锁权限的解锁者确认是否解锁；s2：如果解锁通过，由操作者根据其表单数据操作权限进行该表单数据的修改/删除操作；s3：审核请求人提交对该表单数据的该次修改/删除操作的审核请求；s4：审核者对该次修改/删除操作进行审核，给出审核意见。

如果用户需要调岗，还包括一个用户调岗管理步骤，具体包括：（1）取消用户与原角色的关联；（2）将用户与调岗后对应的新角色进行关联，用户自动获得该新角色的审核权限。

表单数据操作的审核方法，还包括一个通过表单字段的字段值授权审核者具有的该表单的表单数据的操作的审核权限的步骤，所述表单字段的字段值为选择确定或自动确定的。

当一个审核请求有多个审核者时，根据预设的审核规则得出审核结果。

所述的审核规则为：以第一个给出审核意见的审核者的审核意见作为审核结果，只要有任意一个审核者给出了审核意见，审核即结束。

所述的审核规则为：多个审核者中，只要有任何一个审核者给出的审核意见是“同意/通过”，则审核结果为“同意/通过”，只要有任意一个审核者给出了“同意/通过”的审核意见，审核即结束。

或，所述的审核规则为：多个审核者中，只要有任何一个审核者给出的审核意见是“不同意/不通过”，则审核结果为“不同意/不通过”，只要有任意一个审核者给出了“不同意/不通过”的审核意见，审核即结束。

表单数据操作的审核方法，包括以下步骤：

（1）为每个审核者授权其具有的表单数据的操作的审核权限；

（2）审核请求人提交某个表单数据的某种操作的审核请求；

（3）由具有该表单数据该操作的审核权限的审核者对该审核请求进行审核，给出审核意见；

步骤（3）最后执行，步骤（1）与步骤（2）之间无先后顺序。

所述的表单数据操作包括对表单数据的修改或删除，若要修改/删除表单数据，还包括一个解锁申请的步骤：

s1：解锁申请人申请解锁表单数据，由有该条表单数据该操作的解锁权限的解锁者确认是否解锁；

s2：如果解锁通过，由操作者根据其表单数据操作权限进行该表单数据的修改/删除操作；

s3：审核请求人提交对该表单数据的该次修改/删除操作的审核请求；

s4：审核者对该次修改/删除操作进行审核，给出审核意见。

优选的，所述解锁申请人包括有权限申请该表单数据（或该表单数据该操作）解锁的员工、用户、角色、组/类中的一种或多种；

优选的，所述解锁者包括有该条表单数据该操作的解锁权限的员工、用户、角色、组/类中的一种或多种；

优选的，所述操作者包括解锁申请人和/或具有该表单数据的该操作权限的员工、用户、角色、组/类中的一种或多种；

优选的，所述审核请求人包括操作者和/或具有该表单数据的该操作和/或该审核请求权限的员工、用户、角色、组/类中的一种或多种；

优选的，所述审核者包括具有该表单数据该操作的审核权限的员工、用户、角色、组/类中的一种或多种；

优选的，所述角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

本发明的有益效果是：1）审核只有一个审核步骤，一旦审核同意/通过或不同意/不通过后，审核任务即结束，对于不需要繁杂审批流程的表单数据，或是需要审查确认但又不想创建繁杂的审批流程的表单数据，用审核功能实现表单数据操作的审核确认，无需创建流程，减少了审核人员/流程创建人员的工作量，缩短了表单数据操作的审核周期。

2）审核者采用独立个体性质的角色，在员工离职、调岗时，通过用户与角色的关联/取消关联顺带就实现了审核权限的切换和更新，能够实现审核权限的无缝交接，保证用户审核权限得到及时更新，不会出现审核权限更新的滞后或遗漏，不会影响企业正常运营，也规避了机密信息泄露的风险。

离职举例：员工张三对应的用户关联角色“生产工人1”，张三离职时，系统管理员（或相应管理员）直接取消张三对应的用户与“生产工人1”这一角色的关联，则张三自动失去“生产工人1”相应的审核权限，避免审核权限交接滞后使得张三离职后仍具某些机密信息的审核和查看权限，导致相关机密信息泄露给张三；新入职员工李四接替张三的工作时，直接让李四对应的用户关联“生产工人1”，则李四自动获得了“生产工人1”这一角色对应的审核权限，无需再为李四重新设置审核权限，操作简单快捷，大大减少了工作量。

调岗举例：员工张三要从生产部调岗到售后部，系统管理员（或相应管理员）取消张三对应的用户与原角色“生产工人1”的关联，再关联到售后部的新角色“售后服务人员3”，张三则自动获得了“售后服务人员3”这一角色对应的审核权限。

3）本发明可给出同意/通过、不同意/不通过的审核结果，能够及时快速地向审核请求人反馈审核结果，包括审核结果为不同意/不通过。

4）本申请提供了解锁申请功能，对需要审核的表单的正式数据，若需要进行修改或删除，需要提交解锁申请/请求，由有该条表单数据该操作解锁权限的解锁者进行解锁，传统的审核中没有解锁申请/请求，由具有解锁权限的解锁者对已经通过审核的需要解锁的表单数据进行解锁。

解锁申请（请求）功能的好处：①减少解锁者的工作量，让解锁者清晰知道有哪些解锁需求；②为解锁需求者和解锁者搭建了一个交互的方式：举例：企业有销售人员1000人，其中只有8人有解锁权限，若没有解锁申请（请求）功能，而有人需要解锁某条表单正式数据，则只能通过电话或即时通讯等方式告知解锁者哪条表单数据需要解锁，解锁者得知信息后查找到该条表单数据再进行解锁，则：a、与解锁需求者沟通及查找需要解锁的表单数据，会很大程度上增加解锁者的工作量和繁琐度；b、通过电话或即时通讯等方式沟通，很容易在信息传递过程中出现理解偏差，导致错误，或解锁者得知信息后可能不能及时处理，甚至遗忘，则会导致解锁滞后；c、解锁过程无法记录解锁需求者、解锁需求提出时间等信息，解锁没有相关依据，出现问题难以追责（审核请求的好处与解锁申请/请求的好处雷同）。

本申请提供的解锁申请（请求）功能能够很好地解决上述问题。

5）本申请审核规则可自定义，例如：只要有人通过则通过、必须全票通过才能通过、必须一半以上通过才能通过、必须三分之二以上通过才能通过等等。为企业表单数据操作审核提供了一种灵活、适用的审核方式，使用方便，特别适用于需要进行民主决策的情况。

本申请审核规则可设置为：只要有任一个审核者提交了审核意见，就确定了审核结果，审核即结束，其他审核者的审核任务自动撤除，实现了高效、快速审核。特别适用于多人对同一个审核任务的审核权限相同，任何一个人都可以决定审核结果的情形。

6）本申请角色对用户是一对一的关系，同一时段一个角色只能关联唯一的用户，一个用户关联一个或多个角色，这样做的好处是，只要将用户关联到角色即可获得权限（即用户获得其关联的角色的权限），而且角色的权限变更比传统机制中的用户权限变更要少得多。独立体性质（岗位号/工位号性质）的角色数量变化小，虽然员工流动大，但岗位号/工位号的变化小（甚至在一定时段内是没有变化的，即角色没有变化），这样将极大简化用户的权限管理，减少系统的开销。

7）动态管理、入职调岗等的操作简单方便，效率高，可靠性高：入职/离职/调岗在权限管理中的应用简单，当员工/用户发生变化时不用重新设置权限，用户只需取消或关联角色即可：不再任职该角色的用户就取消该角色关联，接手任职该角色的用户关联该岗位号的角色，关联该角色的用户自动就获得了该角色的审核权限，无需对角色进行重新授权，极大地提高了系统设置的效率、安全性和可靠性。

举例：因张三用户离职或调岗等原因，张三不再做“采购员3”这个角色的工作，则将张三取消与“采购员3”的关联；另外李四接手做“采购员3”这个角色的工作，只需将李四关联该角色，则李四自动获得了“采购员3”这个角色的审核权限、审核任务。

8）传统的权限管理机制将角色定义为组、工种、类等性质，角色对用户是一对多的关系，在实际的系统使用过程中，因为在运营过程中经常需要对用户的权限进行调整，比如：在处理员工权限变化的时候，角色关联的某个员工的权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。

但在本申请的方法下，因为角色是一个独立的个体，则可以选择改变角色权限即可达到目的。本申请的方法，虽然看起来在系统初始化时会增加工作量，但可以通过复制等方法，使其创建角色或授权的效率高于传统组/类性质的角色，因为不用考虑组/类性质角色在满足关联用户时的共通性，本申请方案会让权限设置清晰，明了；尤其是在系统使用一段时间后（用户/角色权限动态变化），该申请方案能为系统使用方大幅度提高系统使用中的权限管理效率，使动态授权更简单，更方便，更清晰、明了，提高权限设置的效率和可靠性。

9）传统组/类性质的角色授权方法容易出错，本申请方法大幅降低了授权出错的几率，因为本申请方法只需考虑作为独立个体的角色，而不用考虑传统方法下关联该组性质角色的多个用户有哪些共通性。即使授权出错也只影响关联到该角色的那一个用户，而传统以组性质的角色则会影响关联到该角色的所有用户。即使出现权限授权错误，本申请的修正方法简单、时间短，而传统以组性质的角色在修正错误时需要考虑关联到该角色的所有用户的权限共通性，在功能点多的情况下不仅修改麻烦、复杂，非常容易出错，且很多情况下只能新创建角色才能解决。

10）在传统以组为性质的角色授权方法下，若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，若要关联新的用户，无法准确判断应当如何选择关联。本申请方法的角色本身就具有岗位号/工位号的性质，选择一目了然。

11）调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。

本申请方法则为：被调岗用户关联了几个角色，在调岗时，首先取消用户与原部门内的角色的关联（被取消的这几个角色可以被重新关联给其他用户），然后将用户与新部门内的角色进行关联即可。操作简单，不会出错。

附图说明

图1为背景技术中系统直接对用户进行授权的方式示意图；

图2为背景技术中系统对组/类性质角色进行授权的方式示意图；

图3为背景技术中系统对用户直接授权和对组/类性质角色授权相结合的方式示意图；

图4为本发明系统通过独立个体性质角色对用户进行授权的方式示意图；

图5为本发明审核方法流程图；

图6为本发明解锁申请流程图。

具体实施方式

下面结合附图进一步详细描述本发明的技术方案，但本发明的保护范围不局限于以下所述。

【实施例1】如图5所示，表单数据操作的审核方法，包括以下步骤：创建系统中的角色，如图4所示，所述的角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；在角色创建时或角色创建后为该角色选择一个部门，则该角色归属于该部门，根据角色的工作内容对角色进行授权，且该角色的名称在该部门下唯一，该角色的编号在系统中唯一；一个用户对应一个员工，一个员工对应一个用户，员工通过其对应的用户关联的角色确定（获得）权限。

选择系统中的一个或多个角色作为审核者，为每个审核者授权其具有的表单数据的操作的审核权限（即为每个审核者授权其具有哪些表单数据的哪些操作的审核权限）；审核请求人（审核请求人可以是员工、用户、组/类性质角色、独立个体性质角色等）提交某个表单数据的某种操作的审核请求；所述的表单数据的操作包括对表单数据的新增、修改、删除；由具有该表单数据该操作的审核权限的审核者对该审核请求进行审核，给出审核意见。

例如，客户表单设置了删除需要审核，审核者角色1具有软件行业的客户的删除的审核权限，则张三要删除客户“用友软件公司”（软件行业）时提交的审核请求由角色1进行审核。

例如，客户表单设置了删除需要审核，审核者角色1具有客户的删除的审核权限，则凡是删除客户提交的审核请求都由角色1进行审核。

例如，客户表单设置了新增、修改、删除需要审核，审核者角色1具有客户的新增、修改、删除的审核权限，则凡是新增、修改、删除客户提交的审核请求都由角色1进行审核。

例如，销售订单表单设置了修改需要审核，审核者角色a具有“角色b、角色c、角色d”的销售订单数据的修改的审核权限，则现在角色b修改了长虹电器公司的一个销售订单，角色c修改了一个应用软件公司的销售订单，角色d修改了万达建筑公司的一个销售订单，则角色b\c\d在修改了这三个销售订单并提交/保存后，角色a就可以对这三个订单的修改进行审核。

进一步的，审核请求人一次也可以提交多个表单数据的某种操作的审核请求，由有对应表单数据该操作的审核权限的审核者进行审核。

进一步的，表单数据操作的审核方法，还包括一个通过表单字段的字段值授权审核者具有的该表单的表单数据的操作的审核权限的步骤，所述表单字段的字段值为选择确定（如客户表单的字段客户行业的字段值有制造、金融、航空等行业选项由表单操作人选择，如合同表单的字段合同签订人的字段值有张三、李四、王五等公司员工选项由表单操作人选择，这些字段值是非人工填写的，而是通过选择方式获得的字段值，还比如合同表单的字段合同级别、客户所在城市、合同签订部门、合同负责部门、合同执行负责人、合同负责角色等字段的字段值也是选择的）或自动确定（如客户表单的字段创建人的字段值有张三、李四、王五等公司员工选项，但在该客户创建时创建人的值是自动获取当前的操作人作为创建人，录单人、制单角色、制单人等字段的字段值也是如此，这类字段的字段值依据表单的相关规则自动确定/保存）的。

例如，合同表单设置了删除需要审核，张三一次提交了5个合同（合同表单上，负责部门字段的字段值有3个是销售一部，有2个是销售二部）的删除的审核请求，角色1的审核权限是：合同表单的负责部门字段的字段值为销售一部的删除的审核；角色2的审核权限是：合同表单的负责部门字段的字段值为销售二部的删除的审核。则角色1只能审核负责部门字段的字段值为销售一部的3个合同的删除审核请求，角色2只能审核负责部门字段的字段值为销售二部的2个合同的删除审核请求。

审核就是审查核准，当某个表单数据的操作不能立即生效而是需要有审核权限的审核者确认这个操作时用到表单数据操作的审核。

审核权限：通过表单授权方式来控制哪些审核者有哪些表单的哪些数据（表单数据）的审核权限(审核权限授权方式可以设计为：如，有某条数据（表单数据）的审核权限，则有这条数据（表单数据）的新增审核/修改审核/删除审核/解锁审核这几项权限；如，也可以设计为将这条数据（表单数据）的新增审核/修改审核整体授权，将删除审核独立授权；如，也可设计为将这几种权限分别进行独立授权)。

审核同意/通过表示认可该表单数据的操作，操作生效，审核不同意/不通过表示不认可该操作，数据（表单数据）回到该审核前的状态：需要设置哪些表单需要审核，该表单设置为某种操作需要审核时，则在进行该表单的表单数据的该操作时才进行审核，否则不需要审核。

a.新增审核：同意后数据（表单数据）成为正式数据（表单数据），不同意数据（表单数据）变为新增审核前的状态或草稿状态；b.修改审核：同意后数据（表单数据）成为正式数据（表单数据），不同意数据（表单数据）变为解锁状态；c.删除审核：同意后数据（表单数据）被删除，不同意数据（表单数据）变为解锁状态；d.解锁审核：同意后数据（表单数据）变为解锁状态（非正式数据状态），不同意数据（表单数据）变回（或还是）为正式数据（表单数据）状态。

审核的设置：a.如果新增要求审核，那么修改就必须审核；反之，如果修改要求审核，新增可以不审核；b.如果新增或者修改有审核或者审批的要求，那么删除都必须要求审核；c.可以新增、修改都不需要审核也不需要审批，但是可以设置要求删除审核（也可以不设置为审核）。

数据（表单数据）处于审核过程中，可以撤销提交，取消审核任务：a.新增审核，只有新增审核请求人点击撤销提交按钮，审核任务才撤销，撤销提交后，数据（表单数据）状态变为“草稿”（非正式数据状态）；b.修改审核，有权限修改该数据（表单数据）的角色（或员工、用户、组/类等）都可以点击撤销提交，撤销后数据（表单数据）状态为“已解锁”（非正式数据状态）；c.删除审核，有权限删除该数据（表单数据）的角色（或员工、用户、组/类等）都可以点击撤销提交，撤销后数据（表单数据）状态为“已解锁”。

举例：假设订单新增/修改/删除都需要审核，新增一个订单001提交，有权限的角色审核同意后该订单成为正式数据（表单数据）；此时如果需要修改该订单，那么需要先发起解锁申请（请求），解锁申请被通过后，再对数据（表单数据）进行修改后提交，再由有权限的角色审核，审核同意后该修改后的数据（表单数据）成为正式数据（表单数据）；此时如果想删除该订单，那么需要先发起解锁申请，解锁申请被审核通过后再提交删除数据（表单数据），由有权限的角色审核后数据（表单数据）才被删除。

解锁请求、审核请求并不需要填写另外一个请求单，而是对请求对象（表单数据）本身产生一个相应任务给对应的有权限的解锁者/审核者。

审核只有一个审核步骤，一旦审核同意/通过或不同意/不通过后，审核任务即结束，对于不需要繁杂审批流程的表单数据，或是需要审查确认但又不想创建繁杂的审批流程的表单数据，用审核功能实现表单数据操作的审核确认，无需创建流程，减少了审核人员/流程创建人员的工作量，缩短了表单数据操作的审核周期。

所述的审核意见包括同意/通过、不同意/不通过，本发明可给出同意/通过、不同意/不通过的审核结果，能够及时快速地向审核请求人反馈审核结果，包括审核结果为不同意/不通过。

本实施例中，如果用户需要调岗，还包括一个用户调岗管理步骤，具体包括：（1）取消用户与原角色的关联；（2）将用户与调岗后对应的新角色进行关联，用户自动获得该新角色的审核权限。

本实施例中，审核者采用独立个体性质的角色，在员工离职、调岗时，通过用户与角色的关联/取消关联顺带就实现了审核权限的切换和更新，能够实现审核权限的无缝交接，保证用户审核权限得到及时更新，不会出现审核权限更新的滞后或遗漏，不会影响企业正常运营，也规避了机密信息泄露的风险。

离职举例：员工张三对应的用户关联角色“生产工人1”，张三离职时，系统管理员（或相应管理员）直接取消张三对应的用户与“生产工人1”这一角色的关联，则张三自动失去“生产工人1”相应的审核权限，避免审核权限交接滞后使得张三离职后仍具某些机密信息的审核和查看权限，导致相关机密信息泄露给张三（交接滞后还会影响相关审核任务拖延，影响公司的正常或高效运营，甚至造成不可预估的损失）；新入职员工李四接替张三的工作时，直接让李四对应的用户关联“生产工人1”，则李四自动获得了“生产工人1”这一角色对应的审核权限，无需再为李四重新设置审核权限，操作简单快捷，大大减少了工作量。

调岗举例：员工张三要从生产部调岗到售后部，系统管理员（或相应管理员）取消张三对应的用户与原角色“生产工人1”的关联，再关联到售后部的新角色“售后服务人员3”，张三则自动获得了“售后服务人员3”这一角色对应的审核权限。

以下对通过独立个体性质角色对用户进行授权所具备的优势进行分析：用户通过其与角色的关联确定（获得）权限，如果要修改用户的权限，通过调整角色所拥有的权限以达到改变关联了该角色的用户的权限的目的。一旦用户关联角色后，该用户就拥有了该角色的审核权限。

角色对用户的关系为一对一（该角色与一个用户关联时，其他用户则不能再关联该角色；若该角色未被用户关联，则可以被其他用户选择关联；即同一时段，一个角色能且只能被一个用户关联）。用户对角色的关系为一对多（一个用户可以同时关联多个角色）。

角色的定义：角色不具有组/类/类别/岗位/职位/工种等性质，而是一个非集合的性质，角色具有唯一性，角色是独立存在的独立个体；在企事业单位应用中相当于岗位号（此处的岗位号非岗位，一个岗位同时可能有多个员工，而同一时段一个岗位号只能对应一个员工）。

举例：某个公司系统中可创建如下角色：总经理、副总经理1、副总经理2、北京销售一部经理、北京销售二部经理、北京销售三部经理、上海销售工程师1、上海销售工程师2、上海销售工程师3、上海销售工程师4、上海销售工程师5……用户与角色的关联关系：若该公司员工张三任职该公司副总经理2，同时任职北京销售一部经理，则张三需要关联的角色为副总经理2和北京销售一部经理，张三拥有了这两个角色的权限。

传统角色的概念是组/类/岗位/职位/工种性质，一个角色能够对应多个用户。而本申请“角色”的概念相当于岗位号/工位号，也类同于影视剧中的角色：一个角色在同一时段（童年、少年、中年……）只能由一个演员来饰演，而一个演员可能会分饰多角。

在创建角色之后，可以在创建用户的过程中关联角色，也可以在用户创建完成后随时进行关联。用户关联角色后可以随时解除与角色的关联关系，也可以随时建立与其他角色的关联关系。

所述角色的构成为：岗位名+岗内编号。例如：车间生产工人1、车间生产工人2、车间生产工人3……角色是独立个体，相当于岗位号、工位号的概念，不同于传统权限管理体系中的角色，传统体系中角色的概念是岗位/职位/工种等的组/类性质。

以下举例员工张三进入某公司后，员工、用户与角色之间的关系为：1、新入职：员工新入职，直接为该用户（员工）选择相应的岗位号/工位号的角色进行关联即可，例：张三入职公司（公司为张三分配了一个张三用户），工作内容是在销售一部，负责北京区域冰箱产品的销售（对应的角色是销售一部下的“销售工程师5”这个角色），则张三用户直接选择“销售工程师5”这个角色关联即可。

2、增加职位：张三工作一段时间后，公司还安排张三负责北京区域电视产品的销售（对应的角色是销售一部下的“销售工程师8”这个角色）并兼任售后部主管（对应售后部主管1这个角色），则张三用户再增加关联销售一部下的“销售工程师8”和售后部下的“售后部主管1”这两个角色，此时，张三员工关联了三个角色，分别为销售一部下的“销售工程师5”、“销售工程师8”和售后部下的“售后部主管1”，张三用户则拥有了这三个角色的权限。

3、减少职位：又过了一段时间，公司决定让张三任职售后部经理（对应售后部下“售后部经理”这个角色），且不再兼任其他工作。则张三用户关联售后部下“售后部经理”这个角色，同时取消此前关联的三个角色（销售一部下的“销售工程师5”、“销售工程师8”和售后部下的“售后部主管1”），此时，张三用户只拥有售后部下“售后部经理”这个角色的权限。

4、角色权限的调整（针对角色本身所拥有的权限的调整）：如公司决定增加售后部经理的权限，则只需增加对售后部经理这个角色的授权即可，则张三用户因为售后部经理这个角色的权限增加了，张三用户的权限也增加了。

5、离职：一年后，张三离职了，则取消张三用户与售后部下“售后部经理”这个角色的关联即可。

举例：公司在动态的经营中，职员的入职、离职是经常持续发生的，但岗位号/工位号的变化非常少(甚至在一定时期内是没有变化的)。

传统授权方法：在系统功能点多的情况下，以传统的组/类性质的角色进行授权，不仅授权工作量大，繁杂，而且很容易出错，甚至出错了在短时间内都不容易发现，容易对系统使用方造成损失。

本申请授权方法：本申请是对岗位号/工位号性质的角色进行授权，用户关联角色而确定（获得）权限，则对用户权限的控制，通过简单的用户-角色的关联关系来实现，让权限控制变得简单、易操作，清晰明了，大幅度提高了授权效率和授权可靠性。

【实施例2】如图6所示，若要修改/删除表单数据，还包括一个解锁申请的步骤：s1：解锁申请人申请解锁表单数据，由有该条表单数据该操作的解锁权限的解锁者确认是否解锁；s2：如果解锁通过，由操作者根据其表单数据操作权限进行该表单数据的修改/删除操作；如果解锁不通过，则该表单数据仍保持原状态；s3：审核请求人提交对该表单数据的该次修改/删除操作的审核请求；s4：审核者对该次修改/删除操作进行审核，给出审核意见。

发起解锁申请后，就有了解锁任务，解锁者可以同意或不同意解锁申请（请求），同意，数据（表单数据）就为解锁状态，可以对数据（表单数据）进行修改、删除等操作；不同意，数据（表单数据）依然是审核通过的状态，为正式数据（表单数据）。

表单正式数据为：1、不需要审核/审批的表单数据提交后就是正式数据；2、需要审核的表单数据，通过审核后成为正式数据（表单数据）；3、需要审批的表单数据，通过审批后成为正式数据（表单数据）。

对该表单数据具有查看权限的用户，或具有查看权限且具有修改权限的用户都能提交解锁申请，由有解锁权限的解锁者进行解锁。

本实施例提供了解锁申请（请求）功能，对需要审核的表单的正式数据，若需要进行修改或删除，需要提交解锁申请（请求），由有该条表单数据解锁权限的解锁者进行解锁，传统的审核中没有解锁申请（请求），由具有解锁权限的解锁者对已经通过审核的需要解锁的表单数据进行解锁。

解锁申请功能的好处：①减少解锁者的工作量，让解锁者清晰知道有哪些解锁需求；②为解锁需求者和解锁者搭建了一个交互的方式：举例：企业有销售人员1000人，其中只有8人有解锁权限，若没有解锁申请功能，而有人需要解锁某条表单正式数据，则只能通过电话或即时通讯等方式告知解锁者哪条表单数据需要解锁，解锁者得知信息后查找到该条表单数据再进行解锁，则：a、与解锁需求者沟通及查找需要解锁的表单数据，会很大程度上增加解锁者的工作量和繁琐度；b、通过电话或即时通讯等方式沟通，很容易在信息传递过程中出现理解偏差，导致错误，或解锁者得知信息后可能不能及时处理，甚至遗忘，则会导致解锁滞后；c、解锁过程无法记录解锁需求者、解锁需求提出时间等信息，解锁没有相关依据，出现问题难以追责。

本实施例提供的解锁申请（请求）功能能够很好地解决上述问题。

【实施例3】当一个审核请求有多个审核者时，根据预设的审核规则得出审核结果。

具体的，所述的审核规则可以为：以第一个给出审核意见的审核者的审核意见作为审核结果，只要有任意一个审核者给出了审核意见，审核即结束。

只要有任一个审核者提交了审核意见，就确定了审核结果，审核即结束，其他审核者的审核任务自动撤除，实现了高效、快速审核。特别适用于多人（多审批角色）对同一个审核任务的审核权限相同，任何一个人（角色）都可以决定审核结果的情形。

可以为：多个审核者中，只要有任何一个审核者给出的审核意见是“同意/通过”，则审核结果为“同意/通过”，只要有任意一个审核者给出了“同意/通过”的审核意见，审核即结束。

可以为：多个审核者中，只要有任何一个审核者给出的审核意见是“不同意/不通过”，则审核结果为“不同意/不通过”，只要有任意一个审核者给出了“不同意/不通过”的审核意见，审核即结束。

本申请审核规则可自定义，例如：只要有人通过则通过、必须全票通过才能通过、必须一半以上通过才能通过、必须三分之二以上通过才能通过等等。为企业表单数据操作审核提供了一种灵活、适用的审核方式，使用方便，特别适用于需要进行民主决策的情况。

【实施例4】表单数据操作的审核方法，包括以下步骤：为每个审核者授权其具有的表单数据的操作的审核权限；审核请求人提交某个表单数据的某种操作的审核请求；由具有该表单数据该操作的审核权限的审核者对该审核请求进行审核，给出审核意见；所述的表单数据操作包括对表单数据的修改或删除，若要修改/删除表单数据，还包括一个解锁申请的步骤：s1：解锁申请人申请（请求）解锁表单数据，由有该条表单数据该操作的解锁权限的解锁者确认是否解锁；s2：如果解锁通过，由操作者根据其表单数据操作权限进行该表单数据的修改/删除操作；如果解锁不通过，则该表单数据仍保持原状态；s3：审核请求人提交对该表单数据的该次修改/删除操作的审核请求；s4：审核者对该次修改/删除操作进行审核，给出审核意见。

以上所述仅是本发明的优选实施方式，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。