WO2018205942A1 - 工作流审批节点按部门级别设置审批角色的方法 - Google Patents

工作流审批节点按部门级别设置审批角色的方法 Download PDF

Info

Publication number
WO2018205942A1
WO2018205942A1 PCT/CN2018/086079 CN2018086079W WO2018205942A1 WO 2018205942 A1 WO2018205942 A1 WO 2018205942A1 CN 2018086079 W CN2018086079 W CN 2018086079W WO 2018205942 A1 WO2018205942 A1 WO 2018205942A1
Authority
WO
WIPO (PCT)
Prior art keywords
role
approval
department
workflow
node
Prior art date
Application number
PCT/CN2018/086079
Other languages
English (en)
French (fr)
Inventor
陈达志
Original Assignee
成都牵牛草信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 成都牵牛草信息技术有限公司 filed Critical 成都牵牛草信息技术有限公司
Publication of WO2018205942A1 publication Critical patent/WO2018205942A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis

Definitions

  • the invention relates to a method for setting and managing an approval node approval role in a workflow of a management software system such as an ERP, in particular to a method for setting an approval role by a workflow approval node according to a department level.
  • Role-based access control is one of the most researched and matured database rights management mechanisms in recent years. It is considered to be an ideal candidate to replace traditional mandatory access control (MAC) and autonomous access control (DAC). Traditional autonomous access control has high flexibility but low security. Forced access control is highly secure but too restrictive. Role-based access control combines both ease of management and reduces the complexity, cost, and probability of errors. Therefore, it has been greatly developed in recent years.
  • the basic idea of role-based access control (RBAC) is to divide different roles according to different functional positions in the enterprise organization view, encapsulate the access rights of database resources in roles, and indirectly access database resources by being assigned different roles.
  • the role-based permission control mechanism can manage the access rights of the system simply and efficiently, which greatly reduces the burden and cost of the system rights management, and makes the system rights management more in line with the business management specifications of the application system.
  • the traditional role-based user rights management and workflow control methods adopt the "role-to-user one-to-many" association mechanism, and the "role” is group/class nature, that is, one role can simultaneously correspond to/associate multiple users.
  • the role is similar to the concept of position/position/work type.
  • the authorization of user rights under this association mechanism is basically divided into the following three forms:
  • the role (class/group/post/work type nature) is authorized (a role can be associated with multiple users), the user obtains the permission through the role, and the approval operation subject is a group/class nature role;
  • the above two processing methods not only require a long time for the role authorization in the case of a large number of role permissions, but also are easy to make mistakes, the user is cumbersome and troublesome to operate, and is also prone to errors resulting in loss to the system user.
  • the workflow approval node directly selects the employee/user as the approval subject, or the new role is added to meet the requirements of the approval process.
  • employee changes such as transfer, resignation, etc.
  • all the processes involved in the employee must be adjusted accordingly, especially for company management personnel, which involves more approval processes and process adjustments. Large amount, complicated, easy to make mistakes or omissions, affecting the normal operation of the company, and even causing unpredictable losses.
  • the new role involves the creation, association, and authorization of the role. Especially in the case of a large number of roles and a large number of users associated with the role, it is difficult to remember which users are associated with the role.
  • the workflow approval mechanism of the traditional system has the following defects:
  • the process initiator cannot be selected as the approval personnel in the approval node. Before the approval process is completed, the initiator of the approval process cannot review the approval result of the application submitted. For example, the sponsor initiated a reimbursement of 10,000 yuan. The request, due to the wrong content submitted by the sponsor or other reasons, after multiple levels of approval, the approved reimbursement amount was revised to 500 yuan, the final approval result is only allowed to reimburse 500 yuan, the approval process is over. If the sponsor has objection after receiving the approval result, the result of the previous approval process must be invalidated, and then an application for approval is resubmitted, which increases the internal consumption of the system and reduces the efficiency of examination and approval.
  • the object of the present invention is to overcome the deficiencies of the prior art, and to provide a method for setting an approval role by a workflow approval node according to a department level.
  • the submission role of the approval process can be used as an approval role in the approval node to implement a verification verification function of the approval process.
  • Improve the reliability of the approval process by setting the approval role by department level, the system workflow setting personnel only need to input the corresponding department level when setting the approval role.
  • Multiple approval processes can be effectively integrated into one approval process, which can be effective. Reduce flow conditions and flow lines, reduce the workload of system workflow set personnel, and improve system reliability.
  • a method for a workflow approval node to set an approval role by department level including a step of setting a system organization structure and a step of setting an approval role by department level:
  • the step of setting the system organization structure includes the following sub-steps:
  • SS1 Create departments and roles contained in the system organization structure
  • SS2 Set the hierarchical relationship between departments and set the department supervisor role of each department;
  • the steps of setting the approval role by department level include:
  • n is a positive integer ⁇ 0:
  • the approval authority of the corresponding approval role in the level is authorized, and the approval authority of the corresponding approval role in this level is the same.
  • the workflow control method includes the following steps:
  • S1 A three-tier structure model for building user-role-permissions, where:
  • Role layer The operation subject of process approval in workflow is role. Each role is an independent individual, not a group/class. One role can only associate with a unique user in the same period, and one user is associated with one or more roles.
  • Privilege layer consists of the privilege required to be used in the execution of the workflow, and the privilege is directly delegated to the role;
  • User layer The user determines the approval task in the workflow through the associated role, and performs the approval operation with the permission of the associated role;
  • S2 The workflow is controlled by a three-layer structure model, and an approval process includes a start node, at least one approval node, and an end node:
  • Start node Initiate/apply/submit workflow, further, submit role initiation/application/submission workflow, and the role with workflow initiation permission can be initiated/submitted/submitted as a submit role; the system submits according to the submit role
  • the form determines the approval process, and one or more approval processes are designed for the form that needs to have a workflow, but a role can only select one of the approval processes under the form;
  • Approval node set the level of the approved department, and authorize the approval authority for the corresponding approval role in the level;
  • End node After the process flow goes to this node, it indicates that the approval process approval is over;
  • S3 The user determines the approval task to be processed according to the associated role, and performs an approval operation according to the rights of the associated role.
  • One or more approval roles in the approval node can exist in different approval nodes in the same approval process.
  • the approval role can be different for viewing and modifying the form fields in different approval nodes.
  • Select one or more approval roles at the approval node set permissions for the approval role on the approval node, and enable independent permission settings for each approval role for each approval node.
  • the step S1 described includes the following steps:
  • the role belongs to the department, and the role is unique under the department, and the role is authorized according to the work content of the role.
  • the workflow control method further includes a user cross-department management process, which specifically includes:
  • the user determines the authority through its association with the role, and one employee corresponds to one user account.
  • the workflow approval node sets the approval role by department level, including a step to set up the system organization structure and a step to set the approval role by department level:
  • the step of setting the system organization structure includes the following sub-steps:
  • SS1 Create departments and roles contained in the system organization structure
  • SS2 Set the hierarchical relationship between departments and set the department supervisor role of each department;
  • the steps of setting the approval role by department level include:
  • n is a positive integer ⁇ 0:
  • n ⁇ 1 it is necessary to set the approval role of the approval node when the workflow approval process submits the role as the department supervisor role of the department in which it is located, and the department has no upper-level department.
  • the approval node can select one. Or multiple approval roles.
  • the system role is composed of: a post name + a post number.
  • the department level n can be set to 0, that is, the submission role itself is selected as the approval role in the approval node.
  • the submission role itself can be approved and confirmed. Can return to re-approval, choose to agree to enter the next link, and more to submit the role review process, to avoid the problem of incorrect approval results or the approval results are not in line with the expectations of the submitted role and need to create a new approval process, reducing system internal consumption, improve Approval process efficiency and reliability.
  • the submitting role submitted a 10,000 yuan reimbursement approval request.
  • the content submitted by the submitting role is incorrect or other reasons.
  • the approved reimbursement amount is revised to 500 yuan.
  • the submitting role is submitted.
  • the system provides the approval mechanism for the highest level department heads to avoid the problem that the top level department heads cannot complete the approval process through level approval.
  • the approval node sets the roles at the department level to approve the approval request submitted by the chairman.
  • the main body of the approval operation in the workflow is the role, and the role is an independent individual rather than a traditional group/class role, even if employee/user changes occur (such as transfer, resignation, etc.), or employee approval authority If there is a change, simply re-associate the employee to the new role, or adjust the role approval authority accordingly. There is no need to reset/adjust the process. It is easy to set up, no mistakes or omissions, and will not affect the normal operation of the enterprise. Greatly improved the reliability of the workflow.
  • the role of the nature of the post number is the approval authority of the approval link node. The user determines which approval tasks are available through the role. The user can approve the operation by associating the role permissions; the understanding is clear and simple, and the nature of each post number/station number
  • the role is the smallest unit of the work subject, and this application can be well satisfied for each role's different requirements for approval.
  • the role of the application is a one-to-one relationship to the user.
  • a role can only be associated with a unique user at the same time. The advantage of this is that each time a user is created, the operation of assigning rights is no longer required, as long as The user is associated with the role, and the role's permission changes are much less than the user permissions in the traditional mechanism.
  • the number of roles of the nature of the independent body (the nature of the post number/station number) is small. Although the employee turnover is large, the change of the post number/station number is small (even if there is no change in a certain period of time, that is, the role does not change), This will greatly simplify the user's rights management and reduce the overhead of the system.
  • the operation of dynamic management, on-the-job adjustment, etc. is simple and convenient, high in efficiency and high in reliability: the application of the entry/departure/adjustment in the approval process is simple, and the operation subject of the approval of the workflow is the role, when the employee/user There is no need to reset the approval process when the change occurs (the user only needs to cancel or associate the role: the user who is no longer in the role of the job number/station number cancels the role association and takes over the role of the job number/station number. If the user is associated with the role of the job number, the user associated with the role automatically obtains the related tasks and permissions of the role in the approval workflow, without resetting the approval workflow or reauthorizing the roles in the workflow. , greatly improving the efficiency, security and reliability of process settings.
  • Zhang San is no longer working as a “buyer 3”, Zhang San cancels the association with the role; Li Si took over as “Purchaser 3”
  • Li Si is associated with the role, and Li Si automatically obtains the approval task and approval authority for the role of “Purchase 3” in the approval process.
  • the traditional rights management mechanism defines the role as a group, a job type, a class, etc.
  • the role is a one-to-many relationship with the user. In the actual system use process, it is often necessary to perform the user's authority during the operation process. Adjustments, for example, when the employee permissions are changed, the permissions of an employee associated with the role change. We cannot change the permissions of the entire role because of the change of the individual employee permissions, because the role is also associated with other permissions. Staff. So in response to this situation, either create a new role to satisfy the employee whose permissions have changed, or directly authorize (disengage the role) from the employee based on the permission requirements.
  • the above two processing methods not only require a long time for the role authorization in the case of a large number of role permissions, but also are easy to make mistakes, the user is cumbersome and troublesome to operate, and is also prone to errors resulting in loss to the system user.
  • the role since the role is an independent individual, the role permission can be changed to achieve the goal.
  • the method of the present application seems to increase the workload when the system is initialized, it can be made by copying and the like to make the role or authorization more efficient than the traditional group-based role, because the role of the group is not considered.
  • the application scheme will make the permission setting clear and clear; especially after the system is used for a period of time (the user/role authority changes dynamically), the application scheme can greatly improve the system usage for the system user.
  • the efficiency of the rights management makes the dynamic authorization simpler, more convenient, clearer and clearer, and improves the efficiency and reliability of the permission setting.
  • the traditional group-based role authorization method is error-prone, and the method of the present application greatly reduces the probability of authorization errors, because the method of the present application only needs to consider the role as an independent individual, without considering the traditional method to associate the role of the group. What are the commonalities of multiple users? Even if the authorization error occurs, it only affects the user associated with the role, while the traditional group-based role affects all users associated with the role. Even if a permission authorization error occurs, the correction method of the present application is simple and short, and the traditional group-type role needs to consider the commonality of all users associated with the role when correcting the error, and not only the modification when there are many function points. Troublesome, complicated, very error-prone, and in many cases only new roles can be created.
  • the method of the present application is as follows: the transferred user associates several roles.
  • the user When adjusting the post, the user is first unlinked from the role in the original department (the canceled roles can be re-associated to other users), and then Associate users with roles in the new department. The operation is simple and will not go wrong.
  • a role can exist in different approval nodes in the same approval process.
  • the approval role of each approval node can be set independently.
  • the approval role of the approval role can be different for the view fields in different approval nodes.
  • a role is Chengdu sales manager 3, in the contract approval workflow, it exists in the Chengdu sales contract approval and Shanghai sales contract approval two approval nodes; for the Chengdu sales contract approval node, the role can be viewed at the time of approval
  • the customer name, contact person, contact information, product quantity, product unit price, contract amount and other fields of the contract, and the unit price and contract amount of the product can be modified; but the approval node of the sales contract in Shanghai cannot view the customer name and contact person. , sensitive information such as contact information, and can not be modified. In this way, you can customize the permissions of the role in the approval process.
  • FIG. 1 is a schematic diagram of a manner in which a system directly authorizes a user in the background art
  • FIG. 2 is a schematic diagram of a manner in which a system authorizes a group/class role in the background art
  • FIG. 3 is a schematic diagram of a manner in which a system directly authorizes a user and authorizes a group/class role role in the background art
  • Figure 4 is a tree diagram of the organization structure of the embodiment
  • FIG. 5 is a flowchart of a workflow control method according to the present invention.
  • FIG. 6 is a schematic diagram of a manner in which a system authorizes a user through an independent individual role
  • FIG. 7 is a schematic diagram of a workflow approval process according to the present invention.
  • FIG. 8 is a flowchart of a user-role authorization method according to the present invention.
  • a workflow approval node sets an approval role by department level, including a step of setting a system organization structure and a step of setting an approval role by department level:
  • the step of setting the system organization structure includes the following sub-steps:
  • SS1 Create departments and roles contained in the system organization structure
  • SS2 Set the hierarchical relationship between departments (as shown in Figure 4, department A is one level higher than department B, department A is two levels higher than department C%), and the department head roles of each department are set;
  • the steps of setting the approval role by department level include:
  • n is a positive integer ⁇ 0 (the value of N can also be replaced by other symbols, such as a, b, c, d, b is greater than a level, c is greater than a two, d ratio a Big third, and so on): If the role is submitted as role d2, then:
  • the department level n can be set to 0, that is, the submission role d2 itself is selected as the approval role in the approval node. Before the approval process ends, the submission role d2 itself can be approved and confirmed. Return to re-approval, choose to agree to the next step, and submit the review function review procedure to avoid the problem that the approval result is incorrect or the approval result does not match the expected behavior of the submitted role, and the new (resubmission) approval process is required, which reduces the system internal consumption. Improve the efficiency and reliability of the approval process.
  • submit role d2 submitted a 10,000 yuan reimbursement approval request, because the submitted content d2 submitted incorrect content or other reasons, after multiple levels of approval, the approved reimbursement amount was revised to 500 yuan, before the end of the approval process, by Submit the role d2 as an approval role to review and confirm the problem. If you choose to disagree, you can return to re-approval, choose to agree to enter the next link, and do not need to create (resubmit) an approval process.
  • the department head role of the highest level department acts as the approval role of the approval node.
  • the department level should be up to 4, and when the department level is set to 6, the department head role a1 of the highest level department A serves as the approval role for the approval node.
  • the workflow approval node sets the approval role by department level, including a step of setting the system organization structure and a step of setting the approval role by department level:
  • the step of setting the system organization structure includes the following sub-steps:
  • SS1 Create departments and roles contained in the system organization structure
  • SS2 Set the hierarchical relationship between departments (as shown in Figure 4, department A is one level higher than department B, department A is two levels higher than department C%), and the department head roles of each department are set;
  • the step of setting an approval role by department level includes:
  • n is a positive integer ⁇ 0 (the value of N can also be replaced by other symbols, such as a, b, c, d, b is greater than a level, c is greater than a two levels, d is greater than a, and so on): If the role is submitted as role d2, then:
  • the role d2 is submitted by the workflow approval process as the approval role of the approval node; the approval node can set the approval level to the department level n, which is 0, that is, the submission role d2 itself is selected as the approval node.
  • the approval role before the end of the approval process, can be confirmed by the submitting role d2 itself.
  • the approval result does not match the expectations of the submitted role and the new approval process is required, which reduces the internal consumption of the system and improves the efficiency and reliability of the approval process.
  • submit role d2 submitted a 10,000 yuan reimbursement approval request, because the submitted content d2 submitted incorrect content or other reasons, after multiple levels of approval, the approved reimbursement amount was revised to 500 yuan, before the end of the approval process, by Submit the role d2 as an approval role to review and confirm the problem. If you choose to disagree, you can return to re-approval, choose to agree to enter the next link, and do not need to create a new approval process.
  • the department head role of the highest level department acts as the approval role of the approval node.
  • the department level should be up to 4, and when the department level is set to 6, the department head role a1 of the highest level department A serves as the approval role for the approval node.
  • n ⁇ 1 it is necessary to set the approval role of the approval node when the workflow approval process submits the role as the department supervisor role of the department in which it is located, and the department has no upper-level department.
  • the approval node can select one. Or multiple approval roles.
  • the system provides the approval mechanism for the highest level department heads to avoid the problem that the top level department heads cannot complete the approval process through level approval.
  • the chairman a1 when the highest-level department supervisor role a1 submits an approval request, in the level approval, the chairman a1 does not have a superior department, but when the approval node sets the department level, what roles are set to approve the highest-level department supervisor role? A1 submitted an approval request.
  • the approval authority of the corresponding approval role in the level is authorized, and the approval authority of the corresponding approval role in this level is the same.
  • the workflow control method includes the following steps:
  • S1 A three-tier structure model for building user-role-permissions, where:
  • Role layer The operation subject of process approval in workflow is role. Each role is an independent individual, not a group/class. One role can only associate with a unique user in the same period, and one user is associated with one or more roles.
  • Privilege layer consists of the privilege required to be used in the execution of the workflow, and the privilege is directly delegated to the role;
  • User layer The user determines the approval task in the workflow through the associated role, and performs the approval operation with the permission of the associated role;
  • an approval process includes a start node, at least one approval node, and an end node:
  • Start node Initiate/apply/submit workflow, further, submit role initiation/application/submission workflow, and the role with workflow initiation permission can be initiated/submitted/submitted as a submit role; the system submits according to the submit role
  • the form determines the approval process and designs one or more approval processes for forms that require a workflow, but a role can only select one of the approval processes under the form (the same role can only exist in one of the processes in the same form) );
  • Approval node set the level of the approved department, and authorize the approval authority for the corresponding approval role in the level;
  • End node After the process flow goes to this node, it indicates that the approval process approval is over;
  • S3 The user determines the approval task to be processed according to the associated role, and performs an approval operation according to the rights of the associated role.
  • a role is Chengdu sales manager 3, in the contract approval workflow, it exists in the Chengdu sales contract approval and Shanghai sales contract approval two approval nodes; for the Chengdu sales contract approval node, the role can be viewed at the time of approval
  • the customer name, contact person, contact information, product quantity, product unit price, contract amount and other fields of the contract, and the unit price and contract amount of the product can be modified; but the approval node of the sales contract in Shanghai cannot view the customer name and contact person.
  • the sensitive field content, such as contact information can not be modified (but can also be set to have viewing rights, no modification rights).
  • step S1 described includes the following sequence of substeps:
  • S103 Associate a user to a role, wherein one role can only associate a unique user in the same period, and one user associates one or more roles.
  • the user determines the privilege through its association with the role. If the privilege of the user is to be modified, the privilege possessed by the role is adjusted to achieve the purpose of changing the privilege of the user associated with the role. Once a user associates a role, that user has all the operational privileges for that role.
  • the role of the role to the user is one-to-one (when the role is associated with a user, other users can no longer associate the role; if the role is not associated with the user, it can be associated with other users).
  • a user's relationship to a role is one-to-many (one user can associate multiple roles at the same time).
  • Role definition The role does not have the nature of group/class/category/post/job/work, but a non-collection nature, the role is unique, the role is an independent independent entity; in the enterprise application is equivalent Job number (The job number here is not a post, one post may have multiple employees at the same time, and one job number can only correspond to one employee at the same time).
  • a company system can create the following roles: general manager, deputy general manager 1, deputy general manager 2, Beijing sales manager, Beijing sales manager, Beijing sales manager, Shanghai sales engineer 1, Shanghai sales Engineer 2, Shanghai Sales Engineer 3, Shanghai Sales Engineer 4, Shanghai Sales Engineer 5...
  • general manager deputy general manager 1, deputy general manager 2, Beijing sales manager, Beijing sales manager, Shanghai sales engineer 1, Shanghai sales Engineer 2, Shanghai Sales Engineer 3, Shanghai Sales Engineer 4, Shanghai Sales Engineer 5...
  • Zhang San serves as the company's deputy general manager 2, and also serves as a sales manager in Beijing, then Zhang The three roles to be associated are Deputy General Manager 2 and Beijing Sales Manager. Zhang San has the rights to these two roles.
  • the system's authorization for a role includes, but is not limited to, authorization of a form, authorization of a menu, or authorization of a function.
  • Authorization for the operation of the form includes but is not limited to additions and deletions.
  • roles are group/class/post/position/work type, and one role can correspond to multiple users.
  • the concept of "role" in this application is equivalent to the post number/station number, and is similar to the role in the film and television drama: a character can only be played by one actor at the same time (childhood, juvenile, middle-aged). And an actor may be decorated with multiple angles.
  • Authorization for a role includes, but is not limited to, authorization of a form, authorization of a menu, or authorization of a function.
  • the role belongs to the department, and the role is unique under the department, and the role is authorized according to the work content of the role.
  • the specific operation process includes: (1) canceling the association between the user and the role in the original department; and (2) associating the user with the role in the new department.
  • the role After the role is created, you can associate the role in the process of creating the user, or you can associate it at any time after the user is created. After the user associates the role, the relationship with the role can be released at any time, and the relationship with other roles can be established at any time.
  • the step S1 described includes the following sequence of sub-steps: S101: establishing a role, each role being an independent individual, not a group/class; S102: associating a user to a role, wherein a role only during the same time period A unique user can be associated, and one user associates one or more roles; S103: Authorize the roles established by S101 separately.
  • the role belongs to the department, and the role is unique under the department, and the role is authorized according to the work content of the role.
  • the workflow control method further includes a user cross-department management step, which includes: (1) canceling the association between the user and the role in the original department; and (2) associating the user with the role in the new department.
  • a workflow approval node sets a system for an approval role by department level, including a model construction unit, a workflow control unit, and an approval operation unit: a model construction unit is used to construct a three-layer structure model of user-role-permission, wherein : Role layer: The main body of the process approval in the workflow is the role, each role is an independent individual, not a group/class.
  • one role can only associate with a unique user, and one user is associated with one or more roles;
  • Privilege layer consists of the privilege required for workflow execution, and the privilege is directly delegated to the role;
  • user tier the user determines the approval task in the workflow through the associated role, and approves the operation with the privilege of the associated role;
  • workflow control The unit controls the workflow using a three-tier structure model.
  • An approval process includes a start node, at least one approval node, and an end node: start node: initiate/apply/submit workflow, and further, submit role initiation/application/ Submit a workflow, a role with workflow initiation permissions can be submitted as a submit role Start/apply/submit workflow; the system determines the approval process based on the form submitted by the submitting role, and designs one or more approval processes for the form that needs to have a workflow, but a role can only select one of the approval processes under the form; Approval node: set the level of the approved department and authorize the approval authority for the corresponding approval role in the level; End node: After the process flow goes to this node, it indicates that the approval process approval is over; the user in the approval operation unit is based on its associated role. Determine the approval tasks that need to be processed and approve the actions based on the permissions of the associated role.
  • the model construction unit includes a role establishment sub-module, a role authorization sub-module, and a user-role association sub-module;
  • the role establishment sub-module is configured to perform role layout according to the post, and establish a system role, and each role is an independent individual.
  • the role authorization sub-module is used to assign a role to the role according to the work content of the role;
  • the user-role association sub-module is used to associate the user to the role, ensuring that one role can only be associated in the same time period.
  • a unique user a user associated with one or more roles.
  • the system role is composed of: a post name + a post number.
  • workshop production workers 1, workshop production workers 2, workshop production workers 3... roles are independent individuals, equivalent to the concept of job number and station number, different from the role in the traditional authority management system, the concept of role in the traditional system It is the group/class nature of the position/position/work type.
  • Zhang also arranged for Zhang San to be responsible for the sales of regional TV products in Beijing (the corresponding role is to sell the role of “Sales Engineer 8” under the Ministry of Sales) and concurrently as the head of the after-sales department (corresponding to the after-sales department)
  • the three users added the roles of “sales engineer 8” under the sales department and “sales department supervisor 1” under the after-sales department.
  • Zhang San employees associated three roles, respectively.
  • Zhang San users have the authority of these three roles.
  • Zhang San serves as the post-sales manager (corresponding to the role of “after-sales manager” in the after-sales department) and no longer take up other jobs. Then Zhang San user is associated with the role of “after-sales manager” in the after-sales department, and cancels the three roles previously associated (Sales Engineer 5 under Sales, Sales Engineer 8 and “After Sales Manager 1” under the after-sales department) At this time, Zhang San users only have the authority of the role of “after-sales manager” under the after-sales department.
  • This application authorizes the role of the nature of the post number/station number, and the user associates the role to determine the authority, then the control of the user right is achieved through a simple user-role relationship, allowing the authority Control is simple, easy to operate, clear and clear, and greatly enhances the efficiency of authorization and the reliability of authorization.
  • the role (class/group/post/work type) is authorized (a role can be associated with multiple users), the user obtains the permission through the role, and the approval operation subject is the group/class nature role; As shown in Figure 3, the above two methods are combined.
  • both 2 and 3 need to authorize the role of the class/group nature, and the way of authorization and workflow control through the role of class/group/post/work type has the following disadvantages: 1.
  • Difficulties in operation In the actual system use process, it is often necessary to adjust the user's authority during the operation process. For example, when dealing with employee permission changes, the employee rights associated with the role change, we cannot because of this Changes in employee permissions change the permissions of the entire role, because the role is also associated with other employees whose permissions have not changed. So in response to this situation, either create a new role to satisfy the employee whose permissions have changed, or directly authorize (disengage the role) from the employee based on the permission requirements.
  • the above two processing methods not only require a long time for the role authorization in the case of a large number of role permissions, but also are easy to make mistakes, the user is cumbersome and troublesome to operate, and is also prone to errors resulting in loss to the system user.
  • the workflow approval node directly selects the employee/user as the approval subject, or the new role is added to meet the requirements of the approval process.
  • employee changes such as transfer, resignation, etc.
  • all the processes involved in the employee must be adjusted accordingly, especially for company management personnel, which involves more approval processes and process adjustments. Large amount, complicated, easy to make mistakes or omissions, affecting the normal operation of the company, and even causing unpredictable losses.
  • the new role involves the creation, association, and authorization of the role. Especially in the case of a large number of roles and a large number of users associated with the role, it is difficult to remember which users are associated with the role.

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Data Mining & Analysis (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明公开了一种工作流审批节点按部门级别设置审批角色的方法，创建系统组织结构中的部门及角色；设置各部门之间的层级关系，并设置各部门的部门主管角色；部门级别n=0时，由提交角色担任审批角色；n=1时，由提交角色所在部门的部门主管角色担任审批角色；n=2时，由提交角色所在部门的上一级部门的部门主管角色担任审批角色；以此类推；当部门级别的设置超过最高级别部门时，由最高级别部门的部门主管角色担任审批角色。本发明通过按部门级别设置审批角色的方式，工作流设置人员在设置审批角色时只需输入部门级别即可，多个审批流程能够有效整合在一起，能够有效减少流转条件和流转线路，降低了系统工作流设置人员的工作量，提高了系统可靠性。

Description

工作流审批节点按部门级别设置审批角色的方法 技术领域
本发明涉及一种ERP等管理软件系统的工作流中审批节点审批角色的设置和管理方法，特别是涉及一种工作流审批节点按部门级别设置审批角色的方法。
 背景技术
基于角色的访问控制（RBAC）是近年来研究最多、思想最成熟的一种数据库权限管理机制，它被认为是替代传统的强制访问控制（MAC）和自主访问控制（DAC）的理想候选。传统的自主访问控制的灵活性高但是安全性低，强制访问控制安全性高但是限制太强；基于角色的访问控制两者兼具，不仅易于管理而且降低了复杂性、成本和发生错误的概率，因而近年来得到了极大的发展。基于角色的访问控制（RBAC）的基本思想是根据企业组织视图中不同的职能岗位划分不同的角色，将数据库资源的访问权限封装在角色中，用户通过被赋予不同的角色来间接访问数据库资源。
在大型应用系统中往往都建有大量的表和视图，这使得对数据库资源的管理和授权变得十分复杂。由用户直接管理数据库资源的存取和权限的收授是十分困难的，它需要用户对数据库结构的了解非常透彻，并且熟悉SQL语言的使用，而且一旦应用系统结构或安全需求有所变动，都要进行大量复杂而繁琐的授权变动，非常容易出现一些意想不到的授权失误而引起的安全漏洞。因此，为大型应用系统设计一种简单、高效的权限管理方法已成为系统和系统用户的普遍需求。
基于角色的权限控制机制能够对系统的访问权限进行简单、高效的管理，极大地降低了系统权限管理的负担和代价，而且使得系统权限管理更加符合应用系统的业务管理规范。
然而，传统基于角色的用户权限管理和工作流控制方法均采用“角色对用户一对多”的关联机制，其“角色”为组/类性质，即一个角色可以同时对应/关联多个用户，角色类似于岗位/职位/工种等概念，这种关联机制下对用户权限的授权基本分为以下三种形式：
1、如图1所示，直接对用户授权，缺点是工作量大、操作频繁且麻烦；审批流程中审批节点的审批操作主体是用户，工作流审批节点直接选择员工/用户作为审批主体，当发生员工变动（如调岗、离职等），该员工涉及到的所有流程必须要作相应调整，特别是对于公司管理人员，其涉及到的审批流程多，流程调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。
即使只是员工审批权限发生变化，也需要对该员工涉及到的流程作出相应调整，也存在以上类似问题。
2、如图2所示，对角色（类/组/岗位/工种性质）进行授权（一个角色可以关联多个用户），用户通过角色获得权限，审批操作主体是组/类性质角色；
3、如图3所示，以上两种方式结合。
以上的表述中，2、3均需要对类/组性质的角色进行授权，而通过类/组/岗位/工种性质的角色进行授权和工作流控制的方式有以下缺点：
1、用户权限变化时的操作难：在实际的系统使用过程中，经常因为在运营过程中需要对用户的权限进行调整，比如：在处理员工权限变化时，角色关联的某个员工权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。
员工/用户的审批权限发生变化时，要么员工/用户脱离角色，工作流审批节点直接选择员工/用户作为审批主体，要么新增角色来满足审批流程的要求。第一种方式，当发生员工变动（如调岗、离职等），该员工涉及到的所有流程必须要作相应调整，特别是对于公司管理人员，其涉及到的审批流程多，流程调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。即使只是员工审批权限发生变化，也需要对该员工涉及到的流程作出相应调整，也存在以上类似问题。第二种方式，新增角色便涉及到角色的新建、关联、授权工作，特别在角色多、角色关联的用户也多的情况下，角色具体关联了哪些用户是很难记住的。
2、要长期记住角色包含的具体权限难：若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，相近角色的权限也很容易混淆；若要关联新的用户，无法准确判断应当如何选择关联。
3、因为用户权限变化，则会造成角色创建越来越多（若不创建新角色，则会大幅增加直接对用户的授权），更难分清各角色权限的具体差别。
4、调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。
传统系统的工作流审批机制存在以下缺陷：
（1）审批节点中无法选择流程发起人自身作为审批人员，在审批流程结束之前，审批流程的发起人无法复核确认其提交的申请的审批结果，例如：发起人发起了一个10000元的报销审批请求，因发起人提交的内容有误或其他原因，经过多级审批后核准报销金额被修改为500元，最终的审批结果只允许报销500元，审批流程结束。发起人收到审批结果后有异议的话，必须将之前的审批流程结果作废，再重新提交一个审批申请，增加了系统内耗，降低了审批效率。
（2）对于组织结构比较复杂的跨省、跨国集团公司等，涉及到的审批流程数量非常多，审批流程流转条件和流转线路也很复杂，对于系统流程设置人员来说，工作量非常大，而且很容易在设置审批流程时出错，系统使用很不方便、系统可靠性不高。
（3）在按级别设置审批时，系统无法实现对最高级部门主管所提交的审批请求的审批，一般需要单独为最高级部门主管分配专门的审批角色，增加了系统工作流设置人员的工作量。
 技术问题
本发明的目的在于克服现有技术的不足，提供一种工作流审批节点按部门级别设置审批角色的方法，审批流程的提交角色可以作为审批节点中的审批角色，实现审批流程的复核确认功能，提高审批流程可靠性；通过按部门级别设置审批角色的方式，系统工作流设置人员在设置审批角色时只需输入相应部门级别即可，多个审批流程能够有效整合在一个审批流程内，能够有效减少流转条件和流转线路，降低系统工作流设置人员的工作量，提高系统可靠性。
 技术解决方案
本发明的目的是通过以下技术方案来实现的：工作流审批节点按部门级别设置审批角色的方法，包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：
所述设置系统组织结构的步骤包括以下子步骤：
SS1：创建系统组织结构中所包含的部门及角色；
SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色；
所述按部门级别设置审批角色的步骤包括：
设置部门级别为n，n为≥0的正整数：
（1）当n=0时，由工作流审批流程提交角色担任该审批节点的审批角色；
（2）当n=1时，由工作流审批流程提交角色所在部门的部门主管角色担任该审批节点的审批角色；若提交角色为其所在部门的部门主管角色，则由提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；
（3）当n=2时，由工作流审批流程提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；
（4）当n=3时，由工作流审批流程提交角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；
（5）当n=4时，由工作流审批流程提交角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；
（6）以此类推；
（7）当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色。
当审批节点选择的是级别审批时，对级别中对应的审批角色进行审批权限授权，则此级别中对应的审批角色的审批权限都相同。
所述工作流的控制方法包括以下步骤：
S1：构建用户-角色-权限的三层结构模型，其中：
角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；
权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；
用户层：用户通过关联的角色确定工作流中的审批任务，并以关联角色的权限进行审批操作；
S2：利用三层结构模型对工作流进行控制，一个审批流程中包括一个开始节点、至少一个审批节点、一个结束节点：
开始节点：发起/申请/提交工作流，进一步的，提交角色发起/申请/提交工作流，有工作流发起权限的角色才能作为提交角色发起/申请/提交工作流；系统根据提交角色所提交的表单确定审批流程，针对需要有工作流的表单设计一个或多个审批流程，但一个角色只能选择该表单下的某一个审批流程；
审批节点：设置审批的部门的级别，并对级别中对应的审批角色进行审批权限授权；
结束节点：流程流转到此节点后，表示该审批流程审批结束；
S3：用户根据其关联的角色确定所需处理的审批任务，并根据关联的角色的权限进行审批操作。
在审批节点选择一个或多个审批角色，一个角色在同一个审批流程中能够存在于不同审批节点，不同审批节点中该审批角色对表单字段的查看、修改权限可不同。
在审批节点选择一个或多个审批角色，在审批节点设置审批角色的权限，针对每个审批节点的每个审批角色能够进行独立的权限设置。
所述的步骤S1包括以下步骤：
（1）创建角色，每个角色是独立的个体，而非组/类；
（2）对步骤（1）所创建的角色分别进行授权；
（3）将用户关联到角色，其中，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。
所述的角色归属于部门，且该角色在该部门下唯一，根据角色的工作内容对角色进行授权。
所述工作流的控制方法还包括一个用户跨部门调岗管理步骤，具体包括：
（1）取消用户与原部门内的角色的关联；
（2）将用户与新部门内的角色进行关联。
所述的用户通过其与角色的关联确定权限，一个员工对应一个用户账号。
工作流审批节点按部门级别设置审批角色的方法，包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：
所述设置系统组织结构的步骤包括以下子步骤：
SS1：创建系统组织结构中所包含的部门及角色；
SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色；
所述按部门级别设置审批角色的步骤包括：
设置部门级别为n，n为≥0的正整数：
（1）当n=0时，由工作流审批流程提交角色担任该审批节点的审批角色；
（2）当n=1时，由工作流审批流程提交角色所在部门的部门主管角色担任该审批节点的审批角色；若提交角色为其所在部门的部门主管角色，则由提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；
（3）当n=2时，由工作流审批流程提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；
（4）当n=3时，由工作流审批流程提交角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；
（5）当n=4时，由工作流审批流程提交角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；
（6）以此类推；
（7）当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；
（8）当n≥1时，需要设置“工作流审批流程提交角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点的审批角色，该审批节点能够选择一个或多个审批角色。
所述系统角色的构成为：岗位名+岗内编号。
 有益效果
本发明的有益效果是：
（1）审批节点在设置审批角色时部门级别n可以设置为0，即选择提交角色本身作为审批节点中的审批角色，在审批流程结束前，可以由提交角色本身进行审批确认，选择不同意后可返回重新审批，选择同意进入下一环节，多出了提交角色复核程序，避免出现审批结果不正确或审批结果与提交角色的预期不符而需要新建审批流程的问题，减少了系统内耗，提高了审批流程效率和可靠性。
举例：提交角色提交了一个10000元的报销审批请求，因提交角色所提交的内容有误或其他原因，经过多级审批后核准报销金额被修改为500元，在审批流程结束之前，由提交角色作为审批角色进行复核确认即可发现问题，选择不同意后可返回重新审批，选择同意进入下一环节，无需新建一个审批流程。
（2）系统提供了最高级别部门主管的审批机制，避免出现最高级别部门主管无法通过级别审批方式完成审批流程的问题。
举例：企业的最高级领导董事长提交审批请求时，在级别审批中，董事长虽没有上级部门，但该审批节点在设置部门级别时，还设置了哪些角色来审批董事长提交的审批请求。
（3）通过按部门级别设置审批角色的方式，系统工作流设置人员在设置审批角色时只需输入相应部门级别即可，多个审批流程能够有效整合在一个审批流程内，能够有效减少流转条件和流转线路，降低了系统工作流设置人员的工作量，提高了系统可靠性。比如：在费用报销审批流程中，在一个审批节点设置级别审批，并设置部门级别为1，则所有的费用报销在该审批节点自动由提交角色所在的部门的部门主管角色进行审批。
（4）工作流中审批操作的主体是角色，而且这个角色是独立的个体而不是传统组/类性质的角色，即使发生员工/用户变动（如调岗、离职等），或者是员工审批权限发生变化，只需将员工重新关联到新角色，或是针对性调整该角色审批权限即可，无需重新设置/调整流程，设置方便，不会出错或遗漏，不会影响企业的正常运营，极大提高了工作流的可靠性。以岗位号性质的角色为审批环节节点的审批授权主体，用户通过角色确定其有哪些审批任务，用户通过关联角色的权限进行审批操作即可；理解清晰简单，每个岗位号/工位号性质的角色是工作主体的最小单位，针对每个角色对审批的不同需求，本申请均能够很好满足。
（5）本申请角色对用户是一对一的关系，同一时段一个角色只能关联唯一的用户，这样做的好处是，在每次创建用户时都不再需要进行分配权限的操作，只要将用户关联到角色即可，而且角色的权限变更比传统机制中的用户权限变更要少得多。独立体性质（岗位号/工位号性质）的角色数量变化小，虽然员工流动大，但岗位号/工位号的变化小（甚至在一定时段内是没有变化的，即角色没有变化），这样将极大简化用户的权限管理，减少系统的开销。
（6）动态管理、入职调岗等的操作简单方便，效率高，可靠性高：入职/离职/调岗在审批流程中的应用简单，工作流程的审批的操作主体是角色，当员工/用户发生变化时不用重新设置审批流程（用户只需取消或关联角色即可：不再任职该岗位号/工位号的角色的用户就取消该角色关联，接手任职该岗位号/工位号的角色的用户关联该岗位号的角色，则关联该角色的用户自动就获得了该角色在审批工作流中的相关任务和权限，无需对审批工作流进行重新设置或对工作流中的角色进行重新授权，极大地提高了流程设置的效率、安全性和可靠性。
举例：因张三用户离职或调岗等原因，张三不再做“采购员3”这个角色的工作，则张三取消了与该角色的关联；另外李四接手做“采购员3”这个角色的工作，则将李四关联该角色，则李四自动获得了审批流程中“采购员3”这个角色的审批任务和审批权限。
（7）传统的权限管理机制将角色定义为组、工种、类等性质，角色对用户是一对多的关系，在实际的系统使用过程中，经常因为在运营过程中需要对用户的权限进行调整，比如：在处理员工权限变化的时候，角色关联的某个员工的权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。
但在本申请的方法下，因为角色是一个独立的个体，则可以选择改变角色权限即可达到目的。本申请的方法，虽然看起来在系统初始化时会增加工作量，但可以通过复制等方法，使其创建角色或授权的效率高于传统以组为性质的角色，因为不用考虑性质为组的角色在满足关联用户时的共通性，本申请方案会让权限设置清晰，明了；尤其是在系统使用一段时间后（用户/角色权限动态变化），该申请方案能为系统使用方大幅度提高系统使用中的权限管理效率，使动态授权更简单，更方便，更清晰、明了，提高权限设置的效率和可靠性。
（8）传统以组为性质的角色授权方法容易出错，本申请方法大幅降低了授权出错的几率，因为本申请方法只需考虑作为独立个体的角色，而不用考虑传统方法下关联该组性质角色的多个用户有哪些共通性。即使授权出错也只影响关联到该角色的那一个用户，而传统以组性质的角色则会影响关联到该角色的所有用户。即使出现权限授权错误，本申请的修正方法简单、时间短，而传统以组性质的角色在修正错误时需要考虑关联到该角色的所有用户的权限共通性，在功能点多的情况下不仅修改麻烦、复杂，非常容易出错，且很多情况下只能新创建角色才能解决。
（9）在传统以组为性质的角色授权方法下，若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，若要关联新的用户，无法准确判断应当如何选择关联。本申请方法的角色本身就具有岗位号/工位号的性质，选择一目了然。
（10）调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。
本申请方法则为：被调岗用户关联了几个角色，在调岗时，首先取消用户与原部门内的角色的关联（被取消的这几个角色可以被重新关联给其他用户），然后将用户与新部门内的角色进行关联即可。操作简单，不会出错。
（11）角色归属于部门，则该角色的部门不能被更换，角色为什么不能更换部门：理由1：因为本申请的角色性质等同于一个工位号/岗位号，不同的工位号/岗位号的工作内容/权限是不一样的，如销售部门下的销售员1角色和技术部门的开发人员1角色是完全不同的两个工位号/岗位号，其权限是不同的；理由2：若将销售员1角色的所属部门（销售部）更换为技术部，其销售人员1这个角色的权限不变，则在技术部存在拥有销售部权限的一个角色，这样会导致管理混乱及安全漏洞。
（12）一个角色在同一个审批流程中能够存在于不同审批节点，针对每个审批节点的审批角色能够进行独立的权限设置，不同审批节点中该审批角色对表单字段的查看、修改权限可不同。优势举例：某角色为成都销售经理3，在合同审批工作流中，其存在于成都销售合同审批和上海销售合同审批两个审批节点；对于成都销售合同的审批节点，在审批时该角色可查看该合同的客户名称、联系人、联系方式、产品数量、产品单价、合同金额等全部字段内容，且可修改产品单价、合同金额；但在上海销售合同的审批节点却无法查看客户名称、联系人、联系方式等敏感字段内容，更不能作任何修改。这样一来，能够自定义地设置角色在审批流程中的权限。
 附图说明
图1为背景技术中系统直接对用户进行授权的方式示意图；
图2为背景技术中系统对组/类性质角色进行授权的方式示意图；
图3为背景技术中系统对用户直接授权和对组/类性质角色授权相结合的方式示意图；
图4为实施例中系统组织结构树状图；
图5为本发明工作流控制方法流程图；
图6为本发明系统通过独立个体性质角色对用户进行授权的方式示意图；
图7为本发明工作流审批流程示意图；
图8为本发明用户-角色授权方法流程图。
 本发明的实施方式
下面结合附图进一步详细描述本发明的技术方案，但本发明的保护范围不局限于以下所述。
【实施例1】工作流审批节点按部门级别设置审批角色的方法，包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：
所述设置系统组织结构的步骤包括以下子步骤：
SS1：创建系统组织结构中所包含的部门及角色；
SS2：设置各部门之间的层级关系（如图4所示，部门A比部门B高一级，部门A比部门C高两级……），并设置各部门的部门主管角色；
所述按部门级别设置审批角色的步骤包括：
设置部门级别为n，n为≥0的正整数（N的值也可采用其他符号代替，比如a、b、c、d，b比a大一级，c比a大两级，d比a大三级，以此类推）：若提交角色为角色d2，则：
（1）当n=0时，由工作流审批流程提交角色d2担任该审批节点的审批角色；
审批节点在设置审批角色时部门级别n可以设置为0，即选择提交角色d2本身作为审批节点中的审批角色，在审批流程结束前，可以由提交角色d2本身进行审批确认，选择不同意后可返回重新审批，选择同意进入下一环节，多出了提交角色复核程序，避免出现审批结果不正确或审批结果与提交角色的预期不符而需要新建（重新提交）审批流程的问题，减少了系统内耗，提高了审批流程效率和可靠性。
举例：提交角色d2提交了一个10000元的报销审批请求，因提交角色d2所提交的内容有误或其他原因，经过多级审批后核准报销金额被修改为500元，在审批流程结束之前，由提交角色d2作为审批角色进行复核确认即可发现问题，选择不同意后可返回重新审批，选择同意进入下一环节，无需新建（重新提交）一个审批流程。
（2）当n=1时，由工作流审批流程提交角色d2所在部门D的部门主管角色d1担任该审批节点的审批角色；（若提交角色是d1，他是其所在部门D的部门主管角色，则由提交角色所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色）
（3）当n=2时，由工作流审批流程提交角色d2所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色；
（4）当n=3时，由工作流审批流程提交角色d2所在部门D的上上一级部门B的部门主管角色b1担任该审批节点的审批角色；
（5）当n=4时，由工作流审批流程提交角色d2所在部门D的上上上一级部门A的部门主管角色a1担任该审批节点的审批角色；
（6）以此类推；
（7）当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色。例如：对于角色d2而言，部门级别最高应为4，当部门级别设置为6时，由最高级别部门A的部门主管角色a1担任该审批节点的审批角色。
【实施例2】工作流审批节点按部门级别设置审批角色的方法，包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：
所述设置系统组织结构的步骤包括以下子步骤：
SS1：创建系统组织结构中所包含的部门及角色；
SS2：设置各部门之间的层级关系（如图4所示，部门A比部门B高一级，部门A比部门C高两级……），并设置各部门的部门主管角色；
[0117] 所述按部门级别设置审批角色的步骤包括：
[0118] 设置部门级别为n，n为≥0的正整数（N的值也可采用其他符号代替，比如a、b、c、d，b比a大一级，c比a大两级，d比a大三级，以此类推）：若提交角色为角色d2，则：
（1）当n=0时，由工作流审批流程提交角色d2担任该审批节点的审批角色；审批节点在设置审批角色时部门级别n可以设置为0，即选择提交角色d2本身作为审批节点中的审批角色，在审批流程结束前，可以由提交角色d2本身进行审批确认，选择不同意后可返回重新审批，选择同意进入下一环节，多出了提交角色复核程序，避免出现审批结果不正确或审批结果与提交角色的预期不符而需要新建审批流程的问题，减少了系统内耗，提高了审批流程效率和可靠性。
举例：提交角色d2提交了一个10000元的报销审批请求，因提交角色d2所提交的内容有误或其他原因，经过多级审批后核准报销金额被修改为500元，在审批流程结束之前，由提交角色d2作为审批角色进行复核确认即可发现问题，选择不同意后可返回重新审批，选择同意进入下一环节，无需新建一个审批流程。
（2）当n=1时，由工作流审批流程提交角色d2所在部门D的部门主管角色d1担任该审批节点的审批角色；（若提交角色是d1，他是其所在部门D的部门主管角色，则由提交角色所在部门的上一级部门C的部门主管角色c1担任该审批节点的审批角色）
（3）当n=2时，由工作流审批流程提交角色d2所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色；
（4）当n=3时，由工作流审批流程提交角色d2所在部门D的上上一级部门B的部门主管角色b1担任该审批节点的审批角色；
（5）当n=4时，由工作流审批流程提交角色d2所在部门D的上上上一级部门A的部门主管角色a1担任该审批节点的审批角色；
（6）以此类推；
（7）当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色。例如：对于角色d2而言，部门级别最高应为4，当部门级别设置为6时，由最高级别部门A的部门主管角色a1担任该审批节点的审批角色。
（8）当n≥1时，需要设置“工作流审批流程提交角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点的审批角色，该审批节点能够选择一个或多个审批角色。系统提供了最高级别部门主管的审批机制，避免出现最高级别部门主管无法通过级别审批方式完成审批流程的问题。
举例：企业的最高级别部门主管角色a1提交审批请求时，在级别审批中，董事长a1虽没有上级部门，但该审批节点在设置部门级别时，还设置了哪些角色来审批最高级别部门主管角色a1提交的审批请求。
当审批节点选择的是级别审批时，对级别中对应的审批角色进行审批权限授权，则此级别中对应的审批角色的审批权限都相同。
举例：n=1时，a3、b3、c3、d3分别提交审批流程时，则对应的审批主管分别为a1、b1、c1、d1，且a1、b1、c1、d1的审批权限都一样。
【实施例3】如图5所示，工作流的控制方法包括以下步骤：
 S1：构建用户-角色-权限的三层结构模型，其中：
角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；
权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；
用户层：用户通过关联的角色确定工作流中的审批任务，并以关联角色的权限进行审批操作；
S2：如图7所示，利用三层结构模型对工作流进行控制，一个审批流程中包括一个开始节点、至少一个审批节点、一个结束节点：
开始节点：发起/申请/提交工作流，进一步的，提交角色发起/申请/提交工作流，有工作流发起权限的角色才能作为提交角色发起/申请/提交工作流；系统根据提交角色所提交的表单确定审批流程，针对需要有工作流的表单设计一个或多个审批流程，但一个角色只能选择该表单下的某一个审批流程（同一个角色只能存在于同一个表单的其中一个流程中）；
举例: 采购合同表单有两种流程，分别为P1流程和P2流程，如果在P1流程的开始节点中选择了角色A，那么在P2流程的开始节点就不能再选择角色A，此时角色A新增一个采购合同的审批，提交审批时自动进入P1流程。
审批节点：设置审批的部门的级别，并对级别中对应的审批角色进行审批权限授权；
结束节点：流程流转到此节点后，表示该审批流程审批结束；
S3：用户根据其关联的角色确定所需处理的审批任务，并根据关联的角色的权限进行审批操作。
在审批节点选择一个或多个审批角色，一个角色在同一个审批流程中能够存在于不同审批节点，不同审批节点中该审批角色对表单字段的查看、修改权限可不同。优势举例：某角色为成都销售经理3，在合同审批工作流中，其存在于成都销售合同审批和上海销售合同审批两个审批节点；对于成都销售合同的审批节点，在审批时该角色可查看该合同的客户名称、联系人、联系方式、产品数量、产品单价、合同金额等全部字段内容，且可修改产品单价、合同金额；但在上海销售合同的审批节点却无法查看客户名称、联系人、联系方式等敏感字段内容，更不能作任何修改（但也可以设为具有查看权限，没有修改权限）。
在审批节点选择一个或多个审批角色，在审批节点设置审批角色的权限，针对每个审批节点的每个审批角色能够进行独立的权限设置。例如：在一个合同表单的审批流程中，有某个审批节点设置了2个审批角色，分别为角色A、角色B，可设置角色A能够看到该合同表单中的合同金额字段及该字段的值，也可以看到该合同表单中的客户地址字段及该字段的值；设置角色B不能看到合同表单中的合同金额字段，或能看到合同金额字段但看不到该字段的值，看不到值时可用其他符号显示，比如*号，角色B能够看到该合同表单中的客户地址字段及该字段的值。
【实施例4】如图6和图8所示，所述的步骤S1包括以下顺序子步骤：
S101：创建角色，每个角色是独立的个体，而非组/类；
S102：对S101所创建的角色分别进行授权；
S103：将用户关联到角色，其中，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。用户通过其与角色的关联确定权限，如果要修改用户的权限，通过调整角色所拥有的权限以达到改变关联了该角色的用户的权限的目的。一旦用户关联角色后，该用户就拥有了该角色的所有操作权限。
角色对用户的关系为一对一（该角色与一个用户关联时，其他用户则不能再关联该角色；若该角色未被用户关联，则可以被其他用户选择关联）。用户对角色的关系为一对多（一个用户可以同时关联多个角色）。
角色的定义：角色不具有组/类/类别/岗位/职位/工种等性质，而是一个非集合的性质，角色具有唯一性，角色是独立存在的独立个体；在企事业单位应用中相当于岗位号（此处的岗位号非岗位，一个岗位同时可能有多个员工，而同一时段一个岗位号只能对应一个员工）。
举例：某个公司系统中可创建如下角色：总经理、副总经理1、副总经理2、北京销售一部经理、北京销售二部经理、北京销售三部经理、上海销售工程师1、上海销售工程师2、上海销售工程师3、上海销售工程师4、上海销售工程师5……用户与角色的关联关系：若该公司员工张三任职该公司副总经理2，同时任职北京销售一部经理，则张三需要关联的角色为副总经理2和北京销售一部经理，张三拥有了这两个角色的权限。
对角色的授权：系统对角色的授权包括但不限于对表单的授权、对菜单的授权或对功能的授权。对表单的操作授权包括但不限于增删查改。
传统角色的概念是组/类/岗位/职位/工种性质，一个角色能够对应多个用户。而本申请“角色”的概念相当于岗位号/工位号，也类同于影视剧中的角色：一个角色在同一时段（童年、少年、中年……）只能由一个演员来饰演，而一个演员可能会分饰多角。
对角色的授权包括但不限于对表单的授权、对菜单的授权或对功能的授权。
所述的角色归属于部门，且该角色在该部门下唯一，根据角色的工作内容对角色进行授权。
如果用户要变换部门则涉及到跨部门调岗，其具体操作过程包括：（1）取消用户与原部门内的角色的关联；（2）将用户与新部门内的角色进行关联。
在创建角色之后，可以在创建用户的过程中关联角色，也可以在用户创建完成后随时进行关联。用户关联角色后可以随时解除与角色的关联关系，也可以随时建立与其他角色的关联关系。
【实施例5】所述的步骤S1包括以下顺序子步骤：S101：建立角色，每个角色是独立的个体，而非组/类；S102：将用户关联到角色，其中，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；S103：对S101所建立的角色分别进行授权。
所述的角色归属于部门，且该角色在该部门下唯一，根据角色的工作内容对角色进行授权。
工作流控制方法，还包括一个用户跨部门调岗管理步骤，具体包括：（1）取消用户与原部门内的角色的关联；（2）将用户与新部门内的角色进行关联。
【实施例6】工作流审批节点按部门级别设置审批角色的系统，包括模型构建单元、工作流控制单元和审批操作单元：模型构建单元用于构建用户-角色-权限的三层结构模型，其中：角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；用户层：用户通过关联的角色确定工作流中的审批任务，并以关联角色的权限进行审批操作；工作流控制单元利用三层结构模型对工作流进行控制，一个审批流程中包括一个开始节点、至少一个审批节点、一个结束节点：开始节点：发起/申请/提交工作流，进一步的，提交角色发起/申请/提交工作流，有工作流发起权限的角色才能作为提交角色发起/申请/提交工作流；系统根据提交角色所提交的表单确定审批流程，针对需要有工作流的表单设计一个或多个审批流程，但一个角色只能选择该表单下的某一个审批流程；审批节点：设置审批的部门的级别，并对级别中对应的审批角色进行审批权限授权；结束节点：流程流转到此节点后，表示该审批流程审批结束；审批操作单元中用户根据其关联的角色确定所需处理的审批任务，并根据关联的角色的权限进行审批操作。
所述的模型构建单元包括角色建立子模块、角色授权子模块和用户-角色关联子模块；所述的角色建立子模块用于根据岗位进行角色布局，建立系统角色，每个角色是独立个体，而非组/类；所述的角色授权子模块用于根据角色的工作内容对角色赋予权限；所述的用户-角色关联子模块用于将用户关联到角色，确保同一时段一个角色只能关联唯一的用户，一个用户关联一个或多个角色。
所述系统角色的构成为：岗位名+岗内编号。例如：车间生产工人1、车间生产工人2、车间生产工人3……角色是独立个体，相当于岗位号、工位号的概念，不同于传统权限管理体系中的角色，传统体系中角色的概念是岗位/职位/工种等的组/类性质。
【实施例7】以下举例员工张三进入某公司后，员工、用户与角色之间的关系为：1、新入职：员工新入职，直接为该用户（员工）选择相应的岗位号/工位号的角色进行关联即可，例：张三入职公司（公司为张三分配了一个张三用户），工作内容是在销售一部，负责北京区域冰箱产品的销售（对应的角色是销售一部下的“销售工程师5”这个角色），则张三用户直接选择“销售工程师5”这个角色关联即可。
2、增加职位：张三工作一段时间后，公司还安排张三负责北京区域电视产品的销售（对应的角色是销售一部下的“销售工程师8”这个角色）并兼任售后部主管（对应售后部主管1这个角色），则张三用户再增加关联销售一部下的“销售工程师8”和售后部下的“售后部主管1”这两个角色，此时，张三员工关联了三个角色，分别为销售一部下的“销售工程师5”、“销售工程师8”和售后部下的“售后部主管1”，张三用户则拥有了这三个角色的权限。
3、减少职位：又过了一段时间，公司决定让张三任职售后部经理（对应售后部下“售后部经理”这个角色），且不再兼任其他工作。则张三用户关联售后部下“售后部经理”这个角色，同时取消此前关联的三个角色（销售一部下的“销售工程师5”、“销售工程师8”和售后部下的“售后部主管1”），此时，张三用户只拥有售后部下“售后部经理”这个角色的权限。
4、角色权限的调整（针对角色本身所拥有的权限的调整）：如公司决定增加售后部经理的权限，则只需增加对售后部经理这个角色的授权即可，则张三用户因为售后部经理这个角色的权限增加了，张三用户的权限也增加了。
5、离职：一年后，张三离职了，则取消张三用户与售后部下“售后部经理”这个角色的关联即可。
举例：公司在动态的经营中，职员的入职、离职是经常持续发生的，但岗位号/工位号的变化非常少(甚至在一定时期内是没有变化的)。
传统授权方法：在系统功能点多的情况下，以传统的组/类性质的角色进行授权，不仅授权工作量大，繁杂，而且很容易出错，甚至出错了在短时间内都不容易发现，容易对系统使用方造成损失。
本申请授权方法：本申请是对岗位号/工位号性质的角色进行授权，用户关联角色而确定权限，则对用户权限的控制，只是通过简单的用户-角色的关联关系来实现，让权限控制变得简单、易操作，清晰明了，大幅度提高了授权效率和授权可靠性。
传统基于角色的用户权限管理和工作流控制方法均采用“角色对用户一对多”的关联机制，其“角色”为组/类性质，即一个角色可以同时对应/关联多个用户，角色类似于岗位/职位/工种等概念，这种关联机制下对用户权限的授权基本分为以下三种形式：1、如图1所示，直接对用户授权，缺点是工作量大、操作频繁且麻烦；审批流程中审批节点的审批操作主体是用户，工作流审批节点直接选择员工/用户作为审批主体，当发生员工变动（如调岗、离职等），该员工涉及到的所有流程必须要作相应调整，特别是对于公司管理人员，其涉及到的审批流程多，流程调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。
即使只是员工审批权限发生变化，也需要对该员工涉及到的流程作出相应调整，也存在以上类似问题。
2、如图2所示，对角色（类/组/岗位/工种性质）进行授权（一个角色可以关联多个用户），用户通过角色获得权限，审批操作主体是组/类性质角色；3、如图3所示，以上两种方式结合。
以上的表述中，2、3均需要对类/组性质的角色进行授权，而通过类/组/岗位/工种性质的角色进行授权和工作流控制的方式有以下缺点：1、用户权限变化时的操作难：在实际的系统使用过程中，经常因为在运营过程中需要对用户的权限进行调整，比如：在处理员工权限变化时，角色关联的某个员工权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。
员工/用户的审批权限发生变化时，要么员工/用户脱离角色，工作流审批节点直接选择员工/用户作为审批主体，要么新增角色来满足审批流程的要求。第一种方式，当发生员工变动（如调岗、离职等），该员工涉及到的所有流程必须要作相应调整，特别是对于公司管理人员，其涉及到的审批流程多，流程调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。即使只是员工审批权限发生变化，也需要对该员工涉及到的流程作出相应调整，也存在以上类似问题。第二种方式，新增角色便涉及到角色的新建、关联、授权工作，特别在角色多、角色关联的用户也多的情况下，角色具体关联了哪些用户是很难记住的。
2、要长期记住角色包含的具体权限难：若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，相近角色的权限也很容易混淆；若要关联新的用户，无法准确判断应当如何选择关联。
3、因为用户权限变化，则会造成角色创建越来越多（若不创建新角色，则会大幅增加直接对用户的授权），更难分清各角色权限的具体差别。
4、调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。
以上所述仅是本发明的优选实施方式，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。

Claims (11)

  1. [根据细则91更正 21.06.2018]
    工作流审批节点按部门级别设置审批角色的方法，其特征在于，包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：
    所述设置系统组织结构的步骤包括以下子步骤：
    SS1：创建系统组织结构中所包含的部门及角色；
    SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色；
    所述按部门级别设置审批角色的步骤包括：
    设置部门级别为n，n为≥0的正整数：
    （1）当n=0时，由工作流审批流程提交角色担任该审批节点的审批角色；
    （2）当n=1时，由工作流审批流程提交角色所在部门的部门主管角色担任该审批节点的审批角色；若提交角色为其所在部门的部门主管角色，则由提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；
    （3）当n=2时，由工作流审批流程提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；
    （4）当n=3时，由工作流审批流程提交角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；
    （5）当n=4时，由工作流审批流程提交角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；
    （6）以此类推；
    （7）当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色。
  2. [根据细则91更正 21.06.2018]　
    2.根据权利要求1所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：当审批节点选择的是级别审批时，对级别中对应的审批角色进行审批权限授权，则此级别中对应的审批角色的审批权限都相同。
  3. [根据细则91更正 21.06.2018]
    3.根据权利要求1所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：
    所述工作流的控制方法包括以下步骤：
    S1：构建用户-角色-权限的三层结构模型，其中：
    角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；
    权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；
    用户层：用户通过关联的角色确定工作流中的审批任务，并以关联角色的权限进行审批操作；
    S2：利用三层结构模型对工作流进行控制，一个审批流程中包括一个开始节点、至少一个审批节点、一个结束节点：
    开始节点：发起/申请/提交工作流；
    审批节点：设置审批的部门的级别，并对级别中对应的审批角色进行审批权限授权；
    结束节点：流程流转到此节点后，表示该审批流程审批结束；
    S3：用户根据其关联的角色确定所需处理的审批任务，并根据关联的角色的权限进行审批操作。
  4. [根据细则91更正 21.06.2018]　
    4.根据权利要求3所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：在审批节点选择一个或多个审批角色，一个角色在同一个审批流程中能够存在于不同审批节点，不同审批节点中该审批角色对表单字段的查看、修改权限可不同。
  5. [根据细则91更正 21.06.2018]　
    5.根据权利要求3所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：在审批节点选择一个或多个审批角色，在审批节点设置审批角色的权限，针对每个审批节点的每个审批角色能够进行独立的权限设置。
  6. [根据细则91更正 21.06.2018]
    6.根据权利要求3所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：所述的步骤S1包括以下步骤：
    （1）创建角色，每个角色是独立的个体，而非组/类；
    （2）对步骤（1）所创建的角色分别进行授权；
    （3）将用户关联到角色，其中，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；
    步骤（1）在先，但步骤（2）与步骤（3）无先后顺序关系。
  7. [根据细则91更正 21.06.2018]　
    7.根据权利要求1或3所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：所述的角色归属于部门，且该角色在该部门下唯一，根据角色的工作内容对角色进行授权。
  8. [根据细则91更正 21.06.2018]
    8.根据权利要求7所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：所述工作流的控制方法还包括一个用户跨部门调岗管理步骤，具体包括：
    （1）取消用户与原部门内的角色的关联；
    （2）将用户与新部门内的角色进行关联。
  9. [根据细则91更正 21.06.2018]　
    9.根据权利要求1所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：所述的用户通过其与角色的关联确定权限，一个员工对应一个用户账号。
  10. [根据细则91更正 21.06.2018]　
    10.根据权利要求1所述的工作流审批节点按部门级别设置审批角色的方法，其特征在于：所述角色的构成为：岗位名+岗内编号。
  11. [根据细则91更正 21.06.2018]
    11.工作流审批节点按部门级别设置审批角色的方法，其特征在于，包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：
    所述设置系统组织结构的步骤包括以下子步骤：
    SS1：创建系统组织结构中所包含的部门及角色；
    SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色；
    所述按部门级别设置审批角色的步骤包括：
    设置部门级别为n，n为≥0的正整数：
    （1）当n=0时，由工作流审批流程提交角色担任该审批节点的审批角色；
    （2）当n=1时，由工作流审批流程提交角色所在部门的部门主管角色担任该审批节点的审批角色；若提交角色为其所在部门的部门主管角色，则由提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；
    （3）当n=2时，由工作流审批流程提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；
    （4）当n=3时，由工作流审批流程提交角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；
    （5）当n=4时，由工作流审批流程提交角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；
    （6）以此类推；
    （7）当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；
    （8）当n≥1时，需要设置“工作流审批流程提交角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点的审批角色，该审批节点能够选择一个或多个审批角色。
PCT/CN2018/086079 2017-05-09 2018-05-08 工作流审批节点按部门级别设置审批角色的方法 WO2018205942A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710322980.0 2017-05-09
CN201710322980.0A CN107153921A (zh) 2017-05-09 2017-05-09 工作流审批节点按部门级别设置审批角色的方法

Publications (1)

Publication Number Publication Date
WO2018205942A1 true WO2018205942A1 (zh) 2018-11-15

Family

ID=59792753

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/086079 WO2018205942A1 (zh) 2017-05-09 2018-05-08 工作流审批节点按部门级别设置审批角色的方法

Country Status (2)

Country Link
CN (2) CN107153921A (zh)
WO (1) WO2018205942A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107153921A (zh) * 2017-05-09 2017-09-12 成都牵牛草信息技术有限公司 工作流审批节点按部门级别设置审批角色的方法
CN107169365A (zh) * 2017-05-16 2017-09-15 成都牵牛草信息技术有限公司 工作流及其审批节点的表单字段操作权限的设定方法
CN109615333A (zh) * 2018-12-13 2019-04-12 普元信息技术股份有限公司 云平台中基于抽屉模型实现流程逐级审批的系统及方法
CN110490484A (zh) * 2019-08-27 2019-11-22 山东浪潮通软信息科技有限公司 一种基于管理团队实现设定流程审批人的方法
CN110941624A (zh) * 2019-11-15 2020-03-31 上海易点时空网络有限公司 用于人事变动的数据处理方法及装置
CN111090478A (zh) * 2019-12-20 2020-05-01 金蝶软件（中国）有限公司 Erp系统业务审批流配置方法以及相关装置
CN111311188A (zh) * 2020-02-21 2020-06-19 北京字节跳动网络技术有限公司 一种任务处理方法、装置、介质和电子设备
CN112163840A (zh) * 2020-10-29 2021-01-01 银川安翰互联网医院有限公司 工作流的定义方法、实例的跨地域管理方法和设备
CN114118959A (zh) * 2021-11-24 2022-03-01 京东方科技集团股份有限公司 审批目标对象的方法及装置、计算机存储介质、电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130311348A1 (en) * 2012-03-09 2013-11-21 Gideon Samid Fitting digital currency into modern transactional ecosystems
CN105046446A (zh) * 2015-08-14 2015-11-11 北京京东尚科信息技术有限公司 一种基于工作流框架的自定义权限流程方法及系统
CN106557854A (zh) * 2015-09-25 2017-04-05 北京奇虎科技有限公司 一种业务流程的展示方法和装置
CN107153921A (zh) * 2017-05-09 2017-09-12 成都牵牛草信息技术有限公司 工作流审批节点按部门级别设置审批角色的方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103516679A (zh) * 2012-06-25 2014-01-15 上海博腾信息科技有限公司 一种基于角色的办公系统访问控制系统及其实现方法
CN102945519A (zh) * 2012-10-23 2013-02-27 中国建设银行股份有限公司 一种银行内部工作审批流程管理系统
US20150310687A1 (en) * 2012-12-06 2015-10-29 CrowdzSpeak Inc. Synchronous and Asynchronous Electronic Voting Terminal System and Network
CN103593734A (zh) * 2013-11-12 2014-02-19 金蝶软件（中国）有限公司 电子会签方法和装置
CN103679384A (zh) * 2013-12-25 2014-03-26 武汉武船信息集成有限公司 一种工作流协同办公的方法
CN106228059A (zh) * 2016-07-22 2016-12-14 南京航空航天大学 基于三员管理和拓展的角色访问控制方法
CN106503969A (zh) * 2016-11-03 2017-03-15 东软集团股份有限公司 业务流程审批方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130311348A1 (en) * 2012-03-09 2013-11-21 Gideon Samid Fitting digital currency into modern transactional ecosystems
CN105046446A (zh) * 2015-08-14 2015-11-11 北京京东尚科信息技术有限公司 一种基于工作流框架的自定义权限流程方法及系统
CN106557854A (zh) * 2015-09-25 2017-04-05 北京奇虎科技有限公司 一种业务流程的展示方法和装置
CN107153921A (zh) * 2017-05-09 2017-09-12 成都牵牛草信息技术有限公司 工作流审批节点按部门级别设置审批角色的方法

Also Published As

Publication number Publication date
CN107153921A (zh) 2017-09-12
CN108550029A (zh) 2018-09-18
CN108550029B (zh) 2021-04-27

Similar Documents

Publication Publication Date Title
WO2018210248A1 (zh) 基于表单字段的工作流审批节点设置审批角色的方法
WO2018196876A1 (zh) 基于角色对用户一对一的工作流控制方法和系统
WO2018224024A1 (zh) 工作流审批节点高效审批方法
WO2018205942A1 (zh) 工作流审批节点按部门级别设置审批角色的方法
WO2018214889A1 (zh) 基于会签的审批节点在审批流程中的设置方法
CN108764833B (zh) 工作流审批节点按部门设置审批角色的方法
WO2018214890A1 (zh) 工作流审批节点按角色设置审批角色的方法
US20200151670A1 (en) Method for setting form field operation authority of workflow, and method for setting form field operation authority of approval node
WO2019011220A1 (zh) 基于依据字段设置审批流程的方法
WO2019029650A1 (zh) 表单数据操作的审核方法
WO2019007260A1 (zh) 表单字段值操作权限授权方法
WO2019007292A1 (zh) 基于角色的表单操作权限授权方法
WO2018214828A1 (zh) 基于投票的审批节点在审批流程中的设置方法
WO2018192557A1 (zh) 基于角色对用户的一对一的权限授权方法和系统
WO2018219230A1 (zh) 审批工作流的委托及其再委托方法
WO2019015539A1 (zh) 一种表单数据操作权限授权方法
WO2019034023A1 (zh) 审批者针对审批任务征询参考意见的方法
WO2019011162A1 (zh) 快捷功能设置方法
WO2018224023A1 (zh) 系统中员工登录其账户后的权限显示方法
WO2019029500A1 (zh) 基于列值对统计列表操作权限进行分别授权的方法
WO2019024832A1 (zh) 管理系统中事务处理的管理方法
OA19306A (en) Workflow control method and system based on one-to-one correspondence between roles and users.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18798179

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18798179

Country of ref document: EP

Kind code of ref document: A1