审批流的生成方法及装置、电子设备、存储介质与流程

1.本技术涉及互联网技术领域，特别涉及一种审批流生成方法及装置、电子设备、计算机可读存储介质。


背景技术：

2.工作流“workflow”，指业务过程的部分或整体在计算机应用环境下的自动化，是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。审批流是工作流的一种应用。
3.被定义了审批流程的单据将按照定义的审批流程被传递和审批。这一完整的过程就称为审批流。审批流的实现可以全面提升企业的办公效率，实现企业在整个审批过程中的高效、透明、及时性。
4.现有审批功能通常嵌入在单个模块或功能的实现逻辑当中，单个系统由多个不同模块，而每个模块又可能由不同的功能组成，嵌入式的审批功能不仅会带来大量重复的编码工作，同时也会增加系统逻辑的复杂度,使系统维护困难。并且审批规则散布在系统的不同位置，很难直观的对审批逻辑进行展示。同时由于逻辑都内嵌在代码内部，非编程人员难以对逻辑进行编辑修改，审批规则的变动需要制定者先与开发人员进行需求沟通后才能进行修改。同时也由于审批逻辑的分散性,难以对审批数据进行集中统计。


技术实现要素：

5.本技术实施例提供了一种审批流的生成方法，用于降低审批流生成的难度。
6.本技术实施例提供了一种审批流的生成方法，包括：
7.响应于审批规则新建请求，生成审批规则标识；
8.接收对应所述审批规则标识的每一阶段的审批人员信息以及触发条件；
9.根据每个阶段的审批人员信息以及触发条件，生成所述审批规则标识对应的审批流。
10.在一实施例中，所述响应于审批规则新建请求，生成审批规则标识，包括：
11.响应于审批规则新建请求，根据所述审批规则新建请求中携带的规则名称，生成所述审批规则标识。
12.在一实施例中，所述接收对应所述审批规则标识的每一阶段的审批人员信息以及触发条件，包括：
13.将所述审批规则标识返回所述审批规则新建请求的请求方，触发所述请求方显示信息输入界面；
14.接收所述请求方发送的用户在所述信息输入界面录入的每个阶段的审批人员信息以及触发条件。
15.在一实施例中，所述接收所述请求方发送的用户在所述信息输入界面录入的每个阶段的审批人员信息以及触发条件，包括：
16.接收所述请求方发送的用户在所述信息输入界面输入的审批人员名单、多种判断
参数以及多种判断类型；
17.接收所述请求方发送的用户从所述审批人员名单中选取的每个阶段的审批人员信息，以及从所述多种判断参数中选取的指定判断参数、所述多种判断类型中选取的指定判断类型；
18.根据每个阶段的指定判断参数、指定判断类型以及所述请求方发送的所述阶段的触发值，获得每个阶段的触发条件。
19.在一实施例中，上述方法还包括：接收所述请求方配置的每个阶段完成时的状态值；
20.所述根据每个阶段的审批人员信息以及触发条件，生成所述审批规则标识对应的审批流，包括：
21.根据每个阶段的审批人员信息、触发条件以及完成所述阶段时的状态值，生成所述审批流。
22.在一实施例中，所述审批人员信息包括一个或多个审批人员对应的人员信息。
23.在一实施例中，生成所述审批规则标识对应的审批流之后，所述方法还包括：
24.接收所述审批规则标识对应的审批流的调用请求；
25.根据所述审批流指示的每个阶段的审批人员信息，将申请表发送到相应的审批人员；
26.在接收到当前阶段的审批完成通知时，向当前阶段的审批人员返回状态值，并修改所述申请表的当前审批状态。
27.另一方面，本技术实施例还提供了一种审批流的生成装置，包括：
28.标识生成模块，用于响应于审批规则新建请求，生成审批规则标识；
29.信息获取模块，用于接收对应所述审批规则标识的每一阶段的审批人员信息以及触发条件；
30.审批流生成模块，用于根据每个阶段的审批人员信息以及触发条件，生成所述审批规则标识对应的审批流。
31.另一方面，本技术实施例还提供了一种电子设备，所述电子设备包括：
32.处理器；
33.用于存储处理器可执行指令的存储器；
34.其中，所述处理器被配置为执行上述审批流的生成方法。
35.另一方面，本技术实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序可由处理器执行以完成上述审批流的生成方法。
36.本技术上述实施例提供的方案，服务端响应于审批规则新建请求，生成审批规则标识，服务端可以直接从客户端获取到用户在图形用户界面输入的每个阶段的审批人员信息和触发条件，生成审批流，审批流规则生成后只需向用户端提供规则标识，用户端调用相关接口便可实现审批流相关逻辑,大大提高审批流逻辑的清晰度，减少代码的重复率，提升开发效率。
附图说明
37.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使
用的附图作简单地介绍。
38.图1为本技术一实施例提供的审批流的生成方法的应用场景示意图；
39.图2是本技术实施例提供的电子设备的结构示意图；
40.图3是本技术实施例提供的一种审批流的生成方法的流程示意图；
41.图4是图3对应实施例的基础上审批人员信息以及触发条件接收流程示意图；
42.图5是图3对应实施例的基础上审批流构建之后的流程示意图；
43.图6是本技术另一实施例提供的一种审批流的生成方法的流程示意图；
44.图7是本技术另一实施例提供的一种审批流的生成装置的框图。
具体实施方式
45.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。
46.相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本技术的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
47.图1为本技术实施例提供的审批流的生成方法的应用场景示意图。该方法包括：服务端以及客户端，服务端与客户端之间通过无线网络通信。客户端可以是智能手机、平板电脑、台式电脑。服务端可以是服务器或服务器集群。服务端可以执行本技术实施例提供的审批流的生成方法。
48.图2是本技术实施例提供的电子设备的结构示意图。该电子设备可以作为上述服务端，该电子设备200可以用于执行本技术实施例提供的审批流的生成方法。如图2所示，该电子设备200包括：一个或多个处理器202、一个或多个存储处理器可执行指令的存储器204。其中，所述处理器202被配置为执行本技术下述实施例提供的审批流的生成方法。
49.所述处理器202可以是包含中央处理单元(cpu)、图像处理单元(gpu)或者具有数据处理能力和/或指令执行能力的其它形式的处理单元的设备，可以对所述电子设备200中的其它组件的数据进行处理，还可以控制所述电子设备200中的其它组件以执行期望的功能。
50.所述存储器204可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(ram)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(rom)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器202可以运行所述程序指令，以实现下文所述的审批流的生成方法。在所述计算机可读存储介质中还可以存储各种应用程序和各种数据，例如所述应用程序使用和/或产生的各种数据等。
51.在一实施例中，图2所示电子设备200还可以包括输入装置206、输出装置208以及数据采集装置210，这些组件通过总线系统212和/或其它形式的连接机构(未示出)互连。应当注意，图2所示的电子设备200的组件和结构只是示例性的，而非限制性的，根据需要，所述电子设备200也可以具有其他组件和结构。
52.所述输入装置206可以是用户用来输入指令的装置，并且可以包括键盘、鼠标、麦克风和触摸屏等中的一个或多个。所述输出装置208可以向外部(例如，用户)输出各种信息
(例如，图像或声音)，并且可以包括显示器、扬声器等中的一个或多个。所述数据采集装置210可以采集对象的图像，并且将所采集的图像存储在所述存储器204中以供其它组件使用。示例性地，该数据采集装置210可以为摄像头。
53.在一实施例中，用于实现本技术实施例的审批流的生成方法的示例电子设备100中的各器件可以集成设置，也可以分散设置，诸如将处理器202、存储器204、输入装置206和输出装置208集成设置于一体，而将数据采集装置210分离设置。
54.在一实施例中，用于实现本技术实施例的审批流的生成方法的示例电子设备200可以被实现为诸如计算机、服务器等智能设备。
55.图3是本技术实施例提供的一种审批流的生成方法的流程示意图。该方法可以由上述服务端执行，如图3所示，该方法可以包括以下步骤s310
‑
步骤s330。
56.步骤s310：响应于审批规则新建请求，生成审批规则标识。
57.审批规则新建请求可以由客户端发送到服务端。审批规则标识是指审批规则的唯一标识符，用于区分不同的审批规则。举例来说，可以是名称、编号等。服务端接收到审批规则新建请求，生成审批规则标识。
58.在一实施例中，响应于审批规则新建请求，根据审批规则新建请求中携带的规则名称，生成所述审批规则标识。
59.非编程人员可以在客户端的交互界面输入规则名称，例如租房合同审批、用章审批等。客户端将携带规则名称的审批规则新建请求发送到服务端，服务端基于规则名称生成审批规则标识。
60.步骤s320：接收对应所述审批规则标识的每一阶段的审批人员信息以及触发条件。
61.审批人员信息以及触发条件可以由非编程人员在客户端的交互界面输入。由客户端发送到服务端，从而服务端获得审批人员信息以及触发条件。
62.一个审批流可以包括多个阶段，例如，一个请假申请的审批流，可以包括人事审批阶段、部门经理审批阶段、总经理审批阶段等。
63.一个阶段的审批人员可以是一个或多个，在多个审批人员均审批通过时，才进入下一个阶段。故审批人员信息可以是一个或多个审批人员对应的人员信息，人员信息可以包括姓名、职位名称、邮箱地址、用户id等。
64.触发条件是指触发该阶段的审批人员进行审批的判断条件。例如合同金额大于1000，例如hr已完成审批。
65.在一实施例中，服务端生成审批规则标识之后，可以将审批规则标识返回所述审批规则新建请求的请求方，触发请求方显示信息输入界面；之后接收请求方发送的用户在所述信息输入界面录入的每个阶段的审批人员信息以及触发条件。
66.请求方可以是上文发送审批规则新建请求的客户端。客户端可以显示信息输入界面，用户可以在信息输入界面按序指定每个阶段的审批人员和触发条件。之后由客户端将审批人员信息和触发条件发送到客户端。请求方提供图形化操作界面，非开发人员经学习后也可自由制定修改审批规则，摆脱需要与开发频繁沟通对接需求的过程。审批逻辑可图形化展示,不必审阅代码规则一目了然。
67.在一实施例，如图4所示，所述接收所述请求方发送的用户在所述信息输入界面录
入的每个阶段的审批人员信息以及触发条件，包括以下步骤s401
‑
步骤s403。
68.步骤s401：接收所述请求方发送的用户在所述信息输入界面输入的审批人员名单、多种判断参数以及多种判断类型。
69.其中，审批人员名单是指多个审批人员对应的人员信息。判断参数是指要进行判断的参数种类，举例来说，判断参数可以有“合同金额”、“合同类型”、“申请人职位”、“入职时间”等等。判断类型可以有布尔值判断、大小判断、类型判断、枚举值判断等等。
70.步骤s402：接收所述请求方发送的用户从所述审批人员名单中选取的每个阶段的审批人员信息，以及从所述多种判断参数中选取的指定判断参数、所述多种判断类型中选取的指定判断类型。
71.每个阶段的审批人员信息可以从审批人员名单中选取。判断参数可以从多种判断参数中选取，判断类型可以从多种判断类型中选取，简化审批流创建的难度，提高开发效率。
72.步骤s403：根据每个阶段的指定判断参数、指定判断类型以及所述请求方发送的所述阶段的触发值，获得每个阶段的触发条件。
73.触发值可以由非编程人员通过客户端录入，并发送到服务端。服务端根据选取的指定判断参数、判断类型以及触发值，得到触发条件。每个阶段的触发条件可以按序进行设定，得到审批流每个阶段的触发条件。
74.举例来说，合同审批时设定判断参数为“合同金额”，设定判断类型为“大小判断”,触发值为大于10000,则当合同金额大于此值时触发该审批人员审批。
75.举例来说，设定判断参数为“合同类型”,设定判断类型为枚举,触发值为“采购合同”,则当合同类型为采购合同时触发该审批人员审批。
76.步骤s330：根据每个阶段的审批人员信息以及触发条件，生成所述审批规则标识对应的审批流。
77.一个审批规则标识唯一对应一个审批流。根据审批规则标识，通过相应的调用接口可以调用对应的审批流。审批流包括按序的每个阶段的审批人员信息和触发该阶段的审批人员进行审批的触发条件。同一个阶段可以多个审批人同时进行审批操作。在实际应用时，当所有并联审批人完成审批时,如果存在拒绝状态的审批则向审批所属应用返回申请单被拒绝的状态,如果所有人都同意,则向审批所属应用返回进入下一阶段的状态。
78.在一实施例中，服务端可以接收所述请求方配置的每个阶段完成时的状态值。状态值是指在该阶段完成时，向审批所属应用(客户端)返回的此次申请的当前状态。客户端可以基于返回的状态值，可以修改主申请表(此次审批所对应的应用申请表)的申请状态。例如，比如一次用章申请,状态值可以是用章申请的状态，假设将一次用章申请划分为业务审批人审批
‑
>用章人员确认
‑
>合同返原三个阶段.那么对应的当业务审批人审批完成后,向审批所属应用(客户端)返回此合同应当进入待用章人员确认的阶段,以此类推,不断更新此用章申请的状态,直到完成所有流程。
79.服务端接收到客户端配置的每个阶段完成时的状态值之后，可以根据每个阶段的审批人员信息、触发条件以及完成所述阶段时的状态值，生成所述审批流。
80.在上述实施例的基础上，生成审批规则标识对应的审批流之后，可以调用审批流实现审批逻辑。如图5所示，具体方法还包括以下步骤s501
‑
步骤s503。
81.步骤s501：接收所述审批规则标识对应的审批流的调用请求。
82.接收客户端发送的调用请求，调用请求中可以包含审批规则标识、申请表。
83.步骤s502：根据所述审批流指示的每个阶段的审批人员信息，将申请表发送到相应的审批人员。
84.申请表可以是用章申请、请假申请、晋级申请等。基于每个阶段的触发条件，在满足一个阶段的触发条件时，将申请表发送给该阶段的审批人员，在满足下个阶段的触发条件时，将审批表发送给下个阶段的审批人员，以此类推。
85.步骤s503：在接收到当前阶段的审批完成通知时，向当前阶段的审批人员返回状态值，并修改所述申请表的当前审批状态。
86.审批人员所在终端在完成当前阶段的审批后可以向服务端发送审批完成通知。服务端接收到该审批完成通知，可以向审批人员所在终端返回该阶段完成时对应配置的状态值。并修改本地记录的申请表的当前审批状态。
87.在一实施例中，服务端可以支持相关人员对已创建审批流进行审批人员新增,支持多人同时并联审批提升多人审批时的审批效。
88.在一实施例中，服务端还可以对各个维度的数据进行统计，为公司审批流程的优化提供数据支持。例如可以统计每个申请从发起到结束的审批总用时，每个审批阶段、审批人员审批的用时，每个申请类别、每个审批角色的平均审批用时，每个审批人员以日,周,月,年等为单位的审批数量统计。
89.图6是本技术实施例提供的审批流的生成方法的详细流程示意图。如图6所示，包括以下步骤：
90.(1)用户在系统中新建审批规则，服务端生成唯一规则id；
91.(2)在角色管理模块的人员识别参数中录入人员识别字段名,如邮箱,用户id等，在角色设置表中为录入的人员设定自定义的角色名称(也就是审批人员信息)；
92.(3)在参数设置模块中设置对应的判断参数,并选择判断类型，生成判断条件(也就是触发条件)；
93.(4)在审批流规则管理模块中可按序指定每一阶段的审批人员及触发该角色审批的触发条件,如大小判断中设置amount(数值)>1000。同时按照客户端的配置请求，可以支持为审批流设置不同阶段，每完成一个阶段向审批所述应用返回对应的状态值，并且支持在同一阶段内多个审批人可同时进行审批操作,汇总多个审批人的审批结果后再决定是否进入下一阶段。
94.(5)开发人员侧可以根据唯一规则id,调用相关接口实现审批逻辑。在生成审批规则之后，一种实现方式是，服务端可以提供纯审批流json信息，由调用系统根据数据自行构建审批逻辑。即服务端可以提供基本的审批人数据生成,具体如何实现审批由调用方自己来实现。另一实现方式是，服务端提供完整的审批功能，开发者可通过调用接口获取返回值，只需根据返回值对主申请表进行状态修改。即服务端提供完整的审批逻辑，调用方通过调用接口,获取申请状态返回值来更新对应申请数据的状态,不需要自己来实现审批逻辑,所有的审批数据都留存在服务端中。从而既可提供全审批流程支持也可选择只获取默认审批人信息自行构建审批逻辑。本技术上述实施例提供的方案，同一审批规则可复用度高，能够减少大量同质开发。
95.整个审批系统可以拆分为角色管理，参数管理，审批模板管理，审批数据统计，审批后台实现几个子模块。角色管理,参数管理,审批模板管理三个模块提供图形化的操作界面，规则制定人员不需要与开发人员进行沟通,在经过简单的使用培训后便可在界面自行设定生成默认的审批模板，完成后只需向开发人员提供规则id，开发人员调用相关接口便可实现审批流相关逻辑，大大提高审批流逻辑的清晰度，减少代码的重复率，提升开发效率。同时在审批数据统计中提供基于模板，审批人的数据聚合统计，可随时查询审批数量，耗时，业务完成率等数据，为审批节点优化提供数据支撑。
96.下述为本技术装置实施例，可以用于执行本技术上述审批流的生成方法实施例。对于本技术装置实施例中未披露的细节，请参照本技术审批流的生成方法实施例实施例。
97.图7为本技术一实施例示出的一种审批流的生成装置的框图。如图7所示，该装置包括：标识生成模块710、信息获取模块720以及审批流生成模块730。
98.标识生成模块710，用于响应于审批规则新建请求，生成审批规则标识；
99.信息获取模块720，用于接收对应所述审批规则标识的每一阶段的审批人员信息以及触发条件；
100.审批流生成模块730，用于根据每个阶段的审批人员信息以及触发条件，生成所述审批规则标识对应的审批流。
101.上述装置中各个模块的功能和作用的实现过程具体详见上述审批流的生成方法中对应步骤的实现过程，在此不再赘述。
102.在本技术所提供的几个实施例中，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本技术的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
103.另外，在本技术各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
104.功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。