WO2019011220A1 - 基于依据字段设置审批流程的方法 - Google Patents

基于依据字段设置审批流程的方法 Download PDF

Info

Publication number
WO2019011220A1
WO2019011220A1 PCT/CN2018/095052 CN2018095052W WO2019011220A1 WO 2019011220 A1 WO2019011220 A1 WO 2019011220A1 CN 2018095052 W CN2018095052 W CN 2018095052W WO 2019011220 A1 WO2019011220 A1 WO 2019011220A1
Authority
WO
WIPO (PCT)
Prior art keywords
approval
field
role
user
approval process
Prior art date
Application number
PCT/CN2018/095052
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
Priority to US16/629,298 priority Critical patent/US20200134527A1/en
Priority to EP18832293.7A priority patent/EP3654133A4/en
Priority to JP2020500634A priority patent/JP7276780B2/ja
Priority to AU2018299512A priority patent/AU2018299512A1/en
Priority to MX2020000257A priority patent/MX2020000257A/es
Priority to PE2020000017A priority patent/PE20200290A1/es
Priority to CA3068930A priority patent/CA3068930A1/en
Priority to KR1020207001596A priority patent/KR20200018665A/ko
Application filed by 成都牵牛草信息技术有限公司 filed Critical 成都牵牛草信息技术有限公司
Priority to EA202090238A priority patent/EA202090238A1/ru
Priority to BR112020000567-3A priority patent/BR112020000567A2/pt
Publication of WO2019011220A1 publication Critical patent/WO2019011220A1/zh
Priority to PH12020500009A priority patent/PH12020500009A1/en
Priority to CONC2020/0000173A priority patent/CO2020000173A2/es
Priority to ZA2020/00151A priority patent/ZA202000151B/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/93—Document management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • 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/06313—Resource planning in a project environment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2145—Inheriting rights or properties, e.g., propagation of permissions or restrictions within a hierarchy

Definitions

  • the invention relates to a method for setting an approval process by a system flow setting person of a management software such as ERP, in particular to a method for setting an approval process based on a field according to a field.
  • 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: 1. As shown in Figure 1, the user is authorized directly. The disadvantage is that the workload is large and the operation is frequent. And trouble; the approval operation subject of the approval node in the approval process is the user, and the workflow approval node directly selects the employee/user as the approval subject.
  • 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.
  • the traditional approval process setting method can only create one approval process for a form (only one approval process can be used in the same time period), all submissions of the form go through the process, although the flow conditions of the process can be set in the process to guide Different approval lines of process approval, but in the face of complex approval requirements, the flow conditions in the process will be very complicated, and the flow of approval lines will be very large. There must be a certain process to fully meet the management requirements. Difficulties, and the setting operation is complicated and error-prone. It is very troublesome to modify, and the modification may affect the normal use of the relevant personnel of the process.
  • the object of the present invention is to overcome the deficiencies of the prior art and provide a method for setting an approval process based on a field.
  • a form form data
  • the field automatically associates the approval process, according to the content of the field in the approval form (form data) to determine which process to go for approval, simple and clear, easy to understand, easy to operate, the form field of the form can be replaced, can meet the actual management Approval requirements.
  • a method for setting an approval process based on a field including a step of determining a basis field for an approval form, a step of creating an approval process, and an automatic association approval according to an approval form submitted by the user.
  • Steps of the process Steps to determine the basis field for the approval form: Determine a basis field for each form that requires workflow approval, or determine a basis field for each form that needs to perform workflow approval based on the field.
  • An approval form is The same period can only determine one basis field; the step of creating an approval process includes the following steps: S1: selecting (or setting) a form corresponding to the approval process, one form corresponding to one or more approval processes; S2: The approval process selects a basis field, and a basis field can be selected by one or more approval processes.
  • the field is: submit the role, or the role nature field in the corresponding form, or the department property field in the corresponding form; S3: set the approval Step S2 of the process Depending on the field's set of field values, each field value (which is based on each field value of the field) can only exist in the field value set of an approval process under the base field; "Steps for determining the field based on the approval form” and The two steps of "Steps to Create an Approval Process" are not in the order of precedence.
  • the step of automatically associating the approval process according to the approval form submitted by the user includes the following steps: SS1: The system finds the basis field determined by the approval form (the approval form corresponding to the form data) according to the approval form (form data) submitted by the user; SS2: According to the basis field determined in step SS1, if the corresponding approval process cannot be found according to the basis field of the approval form, "no corresponding approval process" is displayed (prompt "no corresponding approval process", if it can be found , find out all the approval processes corresponding to the field, and jump to step SS3, or if it can be found, jump directly to step SS3; SS3: according to the field of the basis field in the approval form (form data) The value, which determines the field value set of the corresponding field corresponding to the approval process, the approval form (form data) uses this approval process for approval, and completes the association of the approval form (form data) with the approval process.
  • the field value in the field value set is the role; if the selected field is the department property field in the corresponding form, the field in the field value set The values are all departments.
  • the field value set includes a field value that is a null value, and when the approval process is set, an approval process corresponding to a form whose field value of the selected field is null is set, and the approval form submitted by the user (form data) When the content of the field is empty, use this approval process for approval.
  • the field value set of the selected field according to the approval process has a field value option of "all" optional and “all” is selected, and the user submits the approval form (
  • the approval form of the form data is determined by the same field as the selection field selected by the approval process, and the submitted approval form (form) regardless of the field value of the field according to the approval form (form data) submitted by the user.
  • the data is used for approval by the approval process, and the field value of the newly added field is also approved by the approval process (ie, the added process of the field value of the field is the approval process) .
  • the role nature field in the form and the department property field in the form are all optional. (Example: For example, the content of the "Contracting Department" field in the contract form must be single-selected and required/required for this field to be the basis field).
  • the roles are independent individuals, not groups/classes. One role can only associate unique users at the same time, and one user associates one or more roles.
  • the role belongs to the department, and the role is unique under the department.
  • the role is authorized according to the work content of the role, and the user obtains the permission by associating the role.
  • the user When a user moves across departments, the user is first associated with the role in the original department, and then the user is associated with the role in the new department.
  • the approval process is based on a three-layer structure model of user-role-permission, wherein: role layer: the operation subject of the process approval in the workflow is a role, and each role is an independent individual, not a group/class, one at the same time. A role can only be associated with a unique user, and a user is associated with one or more roles.
  • the privilege layer consists of the privilege required for workflow execution, and the privilege is directly delegated to the role.
  • the user tier the user determines the approval process through the associated role. The approval task in the middle, and the approval operation is performed with the permission of the associated role.
  • the approval process includes a start node, at least one approval node, and an end node: a start node: an approval process starts; an approval node: selects an approval role, and authorizes the approval role; and ends the node: the approval process ends.
  • the beneficial effects of the present invention are as follows: 1.
  • the approval process may be automatically associated according to the field according to the approval form (form corresponding to the form data), according to the basis of the approval form (form data)
  • the content of the field to determine which process to go for approval, simple and clear, easy to understand, easy to operate, the form field of the form can be replaced, can meet the different approval requirements in the actual management.
  • a submit role - role 5 submits a contract form (a contract / form data), the contract form (this contract) contains the following fields: contract signing role: role 1 (contract sign role is the field, role 1 is the content of the field / Value), contract responsible role: role 2, contract signing department: department 1, contract department: department 2, the user submits the contract form (this contract), the system will automatically find the current contract form (the contract form corresponding to this contract)
  • the corresponding (set) basis field is the "contract signing role", thereby finding out the multiple approval processes corresponding to the "contract signing role", and finally according to the "contract signing role” in the contract form (this contract)
  • the field value of the field, "Role 1” determines the only one approval process for the "Contraction Role” field that contains “Role 1" in the field value set of the field.
  • One form of the application can create one or more approval processes.
  • the field value of the field can be set to “all”, and the approval field (form data) submitted by the user determines the basis field and the approval.
  • the selected fields of the process are the same, regardless of the value of the field value of the field, the submitted approval form is approved by the approval process, and the field value of the newly added field is also used by the approval process.
  • Approval is simple and convenient; in complex application scenarios, for example, there are three business units in the system, each of which sells different products. In the traditional way, the sales contract form can only create one approval process, which must be complicated when created. Process conditions and approval route trends are not only complicated, error-prone, but also difficult to set up an approval process that fully meets management requirements.
  • This application can create three approval processes for the sales contract form to meet the approval requirements of the sales contracts of the three business divisions, and the system user can also determine whether to use the “contract signing department” or the “submit role” field. Execute (select/determine) the approval of the contract (approval process) to more accurately meet the needs of the user.
  • the process user understands clearly and simply, and the modification is also clear and simple, and does not affect the use of other processes during the modification process.
  • the submitted form data is executed and approved according to the approval process corresponding to the current field of the form. For example, if the current contract field is replaced by the contract signing department, the contract signing department is now. Is the current basis, for example, after submitting a certain combination For approval, the approval process corresponding to the current contract field of the contract form is approved, and the approval process corresponding to the “contract signing role” cannot be approved. That is, the submitted form data is based on its corresponding form. Currently, the relevant approval is performed according to the approval process corresponding to the field.
  • 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.), simply re-enter the new employee. Link to the role in the approval process; or change the employee approval authority, adjust the role approval authority in a targeted manner, no need to reset / adjust the process, easy to set up, no mistakes or omissions, will not affect the normal business Operation greatly improves 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 (acquires) the approval tasks through the role. The user can approve the operation by associating the role. The understanding is clear and simple, and each post number/work The role of the nature of the tag is the smallest unit of the work subject, and this application is 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 as long as the user is associated with the role, the permission can be obtained (ie, the user obtains the associated role). Permissions), 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.
  • 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 roles as groups, types of work, classes, etc.
  • the role is a one-to-many relationship with the user. In the actual system use process, it is often necessary to adjust the user's rights during the operation process. For example, when dealing with employee permission changes, 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 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 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.
  • 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 of associating the group of roles. 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.
  • 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
  • FIG. 4 is a schematic diagram of a manner in which a system authorizes a user through an independent individual role
  • FIG. 5 is a schematic diagram of a workflow approval process according to the present invention.
  • a method for setting an approval process based on a field including a step of determining a basis field for an approval form, a step of creating an approval process, and a step of automatically associating an approval process according to an approval form submitted by a user: determining for an approval form Steps based on fields: Determine a basis field for each form that requires workflow approval, or determine a basis field for each form that needs to perform workflow approval based on the field.
  • An approval form can only identify one at the same time.
  • the step of creating an approval process includes the following steps: S1: selecting (or setting) a form corresponding to the approval process, one form corresponding to one or more approval processes; S2: selecting a basis field for the approval process, one The basis field can be selected by one or more approval processes, according to the field: submit the role, or one of the character nature fields in the corresponding form, or one of the department property fields in the corresponding form; S3: Step S2 of setting the approval process Set of field values for the selected by field Each field value (which is based on each field value of the field) can only exist in the set of field values for an approval process under the base field; "Steps for determining the basis for the approval form” and “Steps for creating the approval process” These two steps are not in order.
  • the field value in the field value set is the role; if the selected field is the department property field in the corresponding form, the field in the field value set
  • the values are all departments; the steps of automatically associating the approval process according to the approval form submitted by the user include the following steps: SS1: The system finds the approval form (the approval form corresponding to the form data) according to the approval form (form data) submitted by the user.
  • the determined basis field; SS2 according to the basis field determined in step SS1, if the corresponding approval process cannot be found according to the basis field of the approval form (there is no approval process with the basis field of the form as its basis field), then " There is no corresponding approval process" (prompt "no corresponding approval process"), if found, find all approval processes corresponding to the field, and jump to step SS3, or if you can find it, jump directly Go to step SS3; SS3: according to the field value of the field according to the approval form (form data), determine which belongs to Field by field value set corresponding to the article approval process, the approval form (form data) which use an approval process for approval, approval form complete the link (form data) and the approval process.
  • the approval process can be determined according to the field content of the field in the form, and multiple approval processes are assigned to an approval form, and the process is determined according to the field content of the field (currently according to the field) in the approval form, which is simple and clear and easy to understand.
  • the contract form determines the “contract signing department” on the form as the basis field (currently based on the field), there are three approval processes to select the contract form, and the three approval processes also select the “contract signing department” of the contract form as the basis field.
  • the three approval processes are A, B, and C processes respectively;
  • the field value set of the contract signing department of the A approval process includes “sales one, sales two, sales three, etc.”, and the contracting department of the B approval process
  • the field value set includes “sales four, sales five, sales six, etc.”
  • the field value set of the contract signing department of the C approval process includes “sales seven, sales eight, sales nine, etc.”.
  • the basis field of the form can be replaced. If the contract form is replaced with a field according to the field, for example, the field is replaced by the “contract signing department” to the “contract signing role” (ie, the current field is replaced by the “contract signing department”. For the “contract signing role”, the “contract signing role” is the current basis field. Now the user submits a contract form (contract) for approval, and the approval process under the “contract signing role” (current basis field) is based on the relevant rules. To approve the submitted contract form/contract data (not related to the approval process under Contracting Department).
  • the sales contract form can only create one approval process (only one approval process can be used in the same time period). It is necessary to set complicated process conditions and approve the route direction. It is not only complicated and error-prone, but also difficult to set up an approval process that fully satisfies the management requirements.
  • This application can create three approval processes for the sales contract form to meet the approval requirements of the sales contracts of the three business divisions, and the system user can also determine whether to use the “contract signing department” or the “submit role” field. Execution of contract approval can more accurately meet the needs of users. In the process of use, the process user understands clearly and simply, and the modification is also clear and simple, and does not affect the use of other processes during the modification process.
  • the approval process corresponding to the current contract field “contract signing department” of the contract form is approved, but not the “contract signing role”.
  • the approval process is approved, ie the submitted form It is its form corresponds to the current implementation of the relevant approval by field corresponding approval process).
  • the field value set includes a field value that is a null value, and when the approval process is set, an approval process corresponding to a form in which the field value of the selected field is null is set, when the user submits When the content of the field in the approval form (form data) is empty, use this approval process for approval.
  • the field value set of the selected field according to the approval process has a field value option of "all" optional and "all" is selected, the user
  • the submitted approval form determines the same field as the basis selected by the approval process, and the submission is based on the field value of the field according to the approval form (form data) submitted by the user.
  • the approval form (form data) is approved by the approval process, and the field value of the newly added field is also approved by the approval process (ie, the added process of the field value of the field is Is the approval process).
  • the contract form determines the "contract signing department" on the form as the basis field (currently based on the field), and only one approval process selects the "contract signing department” as the basis field, and the field value set of the contract signing department of the approval process Including "all” ("all” is just a way of expressing, can also be expressed as “all”, etc.), regardless of the field value of the contract signing department of the contract form (form data) submitted for approval (including field values) Empty, and new field values in the future) are approved by the approval process.
  • the role property field in the form and the department property field in the form are all mandatory. In this case, there is no case where the field value in Embodiment 2 is null. (Example: For example, the content of the “Contracting Department” field in the contract form must be single-selected and required/required for this field to be used as the basis field)
  • the roles are independent individuals, not groups/classes, and one role can only associate with a unique user in the same period, and one user associates one or more. Character.
  • the approval process is based on a three-layer structure model of user-role-permission, wherein: role layer: the operation subject of the process approval in the workflow is a role, and each role is an independent individual, not a group/class, one at the same time.
  • a role can only be associated with a unique user, and a user is associated with one or more roles; the role consists of: the post name + the post number; the privilege layer: consists of the permissions required to be used in the workflow execution, and the rights are directly authorized.
  • user layer The user determines the approval task in the approval process through the associated role, and performs the approval operation with the permission of the associated role.
  • the construction of the user-role-permission three-tier structure model includes the following steps: establishing roles, each role being an independent individual, not a group/class; authorizing the established roles separately; associating the user with the role , in which a role can only be associated with a unique user, and a user is associated with one or more roles. You can authorize the roles you create separately, or you can associate users to roles first.
  • the approval process includes a start node, at least one approval node (such as 5 approval nodes in FIG. 5), and an end node: a start node: a launch/application/submission workflow, and further, Initiate the role initiation/application/submission workflow as the start node, or the first approval node as the start node; the approval node: select the approval role and authorize the approval role; the system determines the approval process according to the form submitted by the initiation role.
  • a start node such as 5 approval nodes in FIG. 5
  • an end node a start node: a launch/application/submission workflow, and further, Initiate the role initiation/application/submission workflow as the start node, or the first approval node as the start node
  • the approval node select the approval role and authorize the approval role
  • the system determines the approval process according to the form submitted by the initiation role.
  • End node When the approval process flow goes to this node, the approval process ends, the end node does not perform the approval operation; or the last approval node is used as the end node, and the end node needs to perform the approval operation.
  • the following is an analysis of the advantages of the method of authorizing a user through an independent individual role: the user determines (acquires) the right through the association with the role, and if the user's permission is to be modified, the relationship is changed to adjust the association.
  • the purpose of the permissions of the user of 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.
  • 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.
  • 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 composition of the character is: post name + 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.
  • the following example shows the relationship between employees, users and roles after the employee Zhang San enters a company: 1. New entry: The employee is newly hired, and directly associates the role of the corresponding job number/station number for the user (employee). Yes, for example: Zhang San joined the company (the company assigned a three-user for Zhang San), the job content is in the sales department, responsible for the sales of refrigerator products in Beijing area (the corresponding role is to sell the sales engineer under the 5 "This role", Zhang San users directly select the "sales engineer 5" role association.
  • 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 determines the (acquired) authority by associating the role, and the control of the user authority is realized by a simple user-role relationship. It makes the permission control simple, easy to operate, clear and clear, and greatly improves the authorization efficiency and authorization reliability.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Data Mining & Analysis (AREA)
  • Bioethics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computational Linguistics (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Automation & Control Theory (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Stored Programmes (AREA)

Abstract

本发明公开了一种基于依据字段设置审批流程的方法，创建审批流程的步骤：S1：选择该审批流程对应的一个表单；S2：为该审批流程选择一个依据字段，一个依据字段能够被一条或多条审批流程选择；S3：设置该审批流程所选依据字段的字段值集合，每个字段值只能存在于该依据字段下的一条审批流程的字段值集合中。关联审批流程时，根据审批表单中依据字段的字段值，判断其属于哪一条审批流程对应的依据字段的字段值集合。本发明在提交表单进行审批流程审批时，可根据表单中的依据字段的字段值自动关联审批流程，根据表单中依据字段的内容来确定流程，简单清晰、操作方便，表单的依据字段可以更换，可以满足实际管理中不同的审批需求。

Description

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

Claims (10)

  1. 基于依据字段设置审批流程的方法，其特征在于，包括一个为审批表单确定依据字段的步骤、一个创建审批流程的步骤和一个根据用户提交的审批表单自动关联审批流程的步骤：
    为审批表单确定依据字段的步骤：为每一个需要工作流审批的表单确定一个依据字段，或为每一个需要根据依据字段执行工作流审批的表单确定一个依据字段，一个审批表单在同一时段能且只能确定一个依据字段；
    创建审批流程的步骤，包括以下步骤：
    S1：选择该审批流程对应的一个表单，一个表单对应一个或多个审批流程；
    S2：为该审批流程选择一个依据字段，一个依据字段能够被一条或多条审批流程选择，依据字段为：提交角色，或者对应表单中的角色性质字段，或者对应表单中的部门性质字段；
    S3：设置该审批流程的步骤S2所选依据字段的字段值集合，每个字段值只能存在于该依据字段下的一条审批流程的字段值集合中；
    根据用户提交的审批表单自动关联审批流程的步骤，包括以下步骤：
    SS1：系统根据用户所提交的审批表单找到该审批表单所确定的依据字段；
    SS2：根据步骤SS1所确定的依据字段，若按照该审批表单的依据字段找不到对应的审批流程，则显示“无对应的审批流程”，若能找到，则找出该依据字段所对应的所有审批流程，并跳转至步骤SS3，或若能找到，则直接跳转至步骤SS3；
    SS3：根据该审批表单中该依据字段的字段值，判断其属于哪一条审批流程对应的依据字段的字段值集合，则该审批表单使用这一条审批流程进行审批，完成审批表单与审批流程的关联。
  2. 根据权利要求1所述的基于依据字段设置审批流程的方法，其特征在于：若所选依据字段为提交角色或对应表单中的角色性质字段，则字段值集合中的字段值均为角色；若所选依据字段为对应表单中的部门性质字段，则字段值集合中的字段值均为部门。
  3. 根据权利要求1所述的基于依据字段设置审批流程的方法，其特征在于：所述的字段值集合中包含一个为空值的字段值，设置审批流程时设置一个所选依据字段的字段值为空值的表单所对应的审批流程，当用户所提交的审批表单中该依据字段内容为空时，使用这一条审批流程进行审批。
  4. 根据权利要求1或3所述的基于依据字段设置审批流程的方法，其特征在于：当所选依据字段仅对应唯一一条审批流程时，该审批流程的所选依据字段的字段值集合中有一个为“所有”的字段值选项可选且选中“所有”，用户提交的审批表单确定的依据字段与该审批流程所选的依据字段相同，则无论用户提交的审批表单中该依据字段的字段值为何值，该提交的审批表单都使用该审批流程进行审批，且之后新增的该依据字段的字段值也都使用该审批流程进行审批。
  5. 根据权利要求1所述的基于依据字段设置审批流程的方法，其特征在于：表单中的角色性质字段、表单中的部门性质字段均为单选必填。
  6. 根据权利要求1所述的基于依据字段设置审批流程的方法，其特征在于：所述的角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。
  7. 根据权利要求6所述的基于依据字段设置审批流程的方法，其特征在于：所述角色归属于部门，该角色在该部门下唯一，根据角色的工作内容对角色进行授权，用户通过关联角色获得权限。
  8. 根据权利要求7所述的基于依据字段设置审批流程的方法，其特征在于：用户跨部门调岗时，先取消用户与原部门内的角色的关联，再将用户与新部门内的角色进行关联。
  9. 根据权利要求6所述的基于依据字段设置审批流程的方法，其特征在于：所述的审批流程基于用户-角色-权限的三层结构模型，其中：
    角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；
    权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；
    用户层：用户通过关联的角色确定审批流程中的审批任务，并以关联角色的权限进行审批操作。
  10. 根据权利要求1所述的基于依据字段设置审批流程的方法，其特征在于：所述的审批流程包括一个开始节点、至少一个审批节点、一个结束节点：
    开始节点：审批流程开始；
    审批节点：选择审批角色，并对审批角色进行授权；
    结束节点：审批流程结束。
PCT/CN2018/095052 2017-07-10 2018-07-09 基于依据字段设置审批流程的方法 WO2019011220A1 (zh)

Priority Applications (13)

Application Number Priority Date Filing Date Title
CA3068930A CA3068930A1 (en) 2017-07-10 2018-07-09 Method for setting approval procedure based on base fields
JP2020500634A JP7276780B2 (ja) 2017-07-10 2018-07-09 基準フィールドにより承認プロセスを設置する方法
AU2018299512A AU2018299512A1 (en) 2017-07-10 2018-07-09 Method for setting approval procedure based on base fields
MX2020000257A MX2020000257A (es) 2017-07-10 2018-07-09 Procedimiento para establecer un proceso de aprobacion basado en campos base.
PE2020000017A PE20200290A1 (es) 2017-07-10 2018-07-09 Procedimiento para establecer un proceso de aprobacion basado en campos base
US16/629,298 US20200134527A1 (en) 2017-07-10 2018-07-09 Method for setting approval procedure based on base fields
KR1020207001596A KR20200018665A (ko) 2017-07-10 2018-07-09 기준 필드에 의거하여 승인 절차를 설정하는 방법
EP18832293.7A EP3654133A4 (en) 2017-07-10 2018-07-09 PROCESS FOR ESTABLISHING AN APPROVAL PROCEDURE BASED ON BASIC FIELDS
EA202090238A EA202090238A1 (ru) 2017-07-10 2018-07-09 Способ установки процессов утверждения на основе базовых полей
BR112020000567-3A BR112020000567A2 (pt) 2017-07-10 2018-07-09 método para definir o processo de aprovação baseado em campos de base
PH12020500009A PH12020500009A1 (en) 2017-07-10 2020-01-02 Method for setting approval procedure based on base fields
CONC2020/0000173A CO2020000173A2 (es) 2017-07-10 2020-01-09 Procedimiento para establecer un proceso de aprobación basado en campos base
ZA2020/00151A ZA202000151B (en) 2017-07-10 2020-01-09 Method for setting approval procedure based on base fields

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710554117.8A CN107357882A (zh) 2017-07-10 2017-07-10 基于依据字段设置审批流程的方法
CN201710554117.8 2017-07-10

Publications (1)

Publication Number Publication Date
WO2019011220A1 true WO2019011220A1 (zh) 2019-01-17

Family

ID=60292341

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/095052 WO2019011220A1 (zh) 2017-07-10 2018-07-09 基于依据字段设置审批流程的方法

Country Status (15)

Country Link
US (1) US20200134527A1 (zh)
EP (1) EP3654133A4 (zh)
JP (1) JP7276780B2 (zh)
KR (1) KR20200018665A (zh)
CN (2) CN107357882A (zh)
AU (1) AU2018299512A1 (zh)
BR (1) BR112020000567A2 (zh)
CA (1) CA3068930A1 (zh)
CO (1) CO2020000173A2 (zh)
EA (1) EA202090238A1 (zh)
MX (1) MX2020000257A (zh)
PE (1) PE20200290A1 (zh)
PH (1) PH12020500009A1 (zh)
WO (1) WO2019011220A1 (zh)
ZA (1) ZA202000151B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111210204A (zh) * 2020-01-13 2020-05-29 普元信息技术股份有限公司 云平台流程应用业务审批环节中实现通用核查项配置与展现处理的系统及其方法
CN113282278A (zh) * 2021-05-17 2021-08-20 山东浪潮通软信息科技有限公司 一种基础数据参与者矩阵设计方法、装置及介质
CN114546358A (zh) * 2022-02-28 2022-05-27 重庆允丰科技有限公司 基于低代码平台配置生产过程管理产品的方法及存储介质

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107357882A (zh) * 2017-07-10 2017-11-17 成都牵牛草信息技术有限公司 基于依据字段设置审批流程的方法
CN107330307A (zh) * 2017-07-16 2017-11-07 成都牵牛草信息技术有限公司 一种表单数据操作权限授权方法
CN107392499A (zh) 2017-08-10 2017-11-24 成都牵牛草信息技术有限公司 对使用者进行审批流程及其审批节点授权的方法
CN108038669A (zh) * 2017-12-25 2018-05-15 泰康保险集团股份有限公司 权限管理机制的配置方法、装置、设备和存储介质
CN109102244A (zh) * 2018-07-19 2018-12-28 平安科技（深圳）有限公司 审批报销的方法、装置、计算机设备和存储介质
CN111400274A (zh) * 2019-12-06 2020-07-10 杭州美创科技有限公司 一种web应用的审批流程状态字段设计方法
CN111538748A (zh) * 2020-04-30 2020-08-14 中国银行股份有限公司 业务页面修改方法及装置
CN111680918B (zh) * 2020-06-09 2024-03-19 浙江师范大学 智能制造服务流程确定方法及系统
CN113554412A (zh) * 2021-06-29 2021-10-26 国网山东省电力公司东营供电公司 一种用于制定审批流程的引擎系统
CN115422414B (zh) * 2022-10-11 2023-07-11 广州盛祺信息科技股份有限公司 一种审批流程可视化配置方法
CN117973828B (zh) * 2024-03-28 2024-06-28 北京首信科技股份有限公司 基于Activiti的业务通用的审批流程管理方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104408339A (zh) * 2014-12-18 2015-03-11 山东钢铁股份有限公司 一种信息系统中权限管理方法
CN105046446A (zh) * 2015-08-14 2015-11-11 北京京东尚科信息技术有限公司 一种基于工作流框架的自定义权限流程方法及系统
AU2016100635A4 (en) * 2015-05-18 2016-06-16 Certainedge Pty Ltd Software creation system
CN107357882A (zh) * 2017-07-10 2017-11-17 成都牵牛草信息技术有限公司 基于依据字段设置审批流程的方法

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088679A (en) * 1997-12-01 2000-07-11 The United States Of America As Represented By The Secretary Of Commerce Workflow management employing role-based access control
JP4263786B2 (ja) * 1998-11-06 2009-05-13 大日本印刷株式会社 電子帳票システム及び記録媒体
US7251666B2 (en) * 2000-02-01 2007-07-31 Internet Business Information Group Signature loop authorizing method and apparatus
US7487182B2 (en) * 2001-01-23 2009-02-03 Conformia Software, Inc. Systems and methods for managing the development and manufacturing of a drug
US7546633B2 (en) * 2002-10-25 2009-06-09 Microsoft Corporation Role-based authorization management framework
US7516161B1 (en) * 2003-08-27 2009-04-07 Sparta Systems, Inc. Administrative triggers
JP2006120040A (ja) * 2004-10-25 2006-05-11 Canon Software Inc ワークフローシステムおよびワークフロー連携方法およびプログラムおよび記録媒体
JP4643707B2 (ja) * 2005-05-23 2011-03-02 エスエーピー・ガバナンス・リスク・アンド・コンプライアンス・インコーポレーテッド アクセス・エンフォーサー
US7506001B2 (en) * 2006-11-01 2009-03-17 I3Solutions Enterprise proposal management system
US7752562B2 (en) * 2006-12-15 2010-07-06 Sap Ag Detection of procedural deficiency across multiple business applications
US10140590B2 (en) * 2008-07-14 2018-11-27 Oracle International Corporation Data approval system and method
US8225213B2 (en) * 2008-10-07 2012-07-17 Siegal Bess L M User interface (UI) control for attestation process
WO2012015988A1 (en) * 2010-07-27 2012-02-02 Globalytica, Llc Collaborative structured analysis system and method
US20140025425A1 (en) * 2012-07-17 2014-01-23 Winshuttle, Llc Bulk business workflow systems and methods
US8924935B1 (en) * 2012-09-14 2014-12-30 Emc Corporation Predictive model of automated fix handling
US20140095390A1 (en) * 2012-09-28 2014-04-03 Oracle International Corporation Mobile transaction approvals
CN104216912B (zh) * 2013-06-04 2017-10-27 广州中国科学院软件应用技术研究所 一种无侵入式的业务表单工作流化的实现方法与装置
CN104346663A (zh) * 2013-07-26 2015-02-11 镇江雅迅软件有限责任公司 一种基于工作流的合同审批方法
CN106022734A (zh) * 2016-06-22 2016-10-12 武汉斗鱼网络科技有限公司 一种合同自动化管理方法与系统
CN106503969A (zh) * 2016-11-03 2017-03-15 东软集团股份有限公司 业务流程审批方法及装置
CN106779594A (zh) * 2016-12-01 2017-05-31 江苏鸿信系统集成有限公司 一种基于Activiti的工作流管理方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104408339A (zh) * 2014-12-18 2015-03-11 山东钢铁股份有限公司 一种信息系统中权限管理方法
AU2016100635A4 (en) * 2015-05-18 2016-06-16 Certainedge Pty Ltd Software creation system
CN105046446A (zh) * 2015-08-14 2015-11-11 北京京东尚科信息技术有限公司 一种基于工作流框架的自定义权限流程方法及系统
CN107357882A (zh) * 2017-07-10 2017-11-17 成都牵牛草信息技术有限公司 基于依据字段设置审批流程的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3654133A4 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111210204A (zh) * 2020-01-13 2020-05-29 普元信息技术股份有限公司 云平台流程应用业务审批环节中实现通用核查项配置与展现处理的系统及其方法
CN111210204B (zh) * 2020-01-13 2023-10-27 普元信息技术股份有限公司 云平台流程应用业务审批环节中实现通用核查项配置与展现处理的系统及其方法
CN113282278A (zh) * 2021-05-17 2021-08-20 山东浪潮通软信息科技有限公司 一种基础数据参与者矩阵设计方法、装置及介质
CN113282278B (zh) * 2021-05-17 2024-03-22 浪潮通用软件有限公司 一种基础数据参与者矩阵设计方法、装置及介质
CN114546358A (zh) * 2022-02-28 2022-05-27 重庆允丰科技有限公司 基于低代码平台配置生产过程管理产品的方法及存储介质
CN114546358B (zh) * 2022-02-28 2023-09-19 重庆允丰科技有限公司 基于低代码平台配置生产过程管理产品的方法及存储介质

Also Published As

Publication number Publication date
PE20200290A1 (es) 2020-02-05
CA3068930A1 (en) 2019-01-17
KR20200018665A (ko) 2020-02-19
CN108984715B (zh) 2021-07-23
PH12020500009A1 (en) 2020-12-07
CO2020000173A2 (es) 2020-01-17
JP7276780B2 (ja) 2023-05-18
US20200134527A1 (en) 2020-04-30
ZA202000151B (en) 2021-02-24
EP3654133A1 (en) 2020-05-20
EA202090238A1 (ru) 2020-04-27
EP3654133A4 (en) 2021-07-28
MX2020000257A (es) 2021-03-02
AU2018299512A1 (en) 2020-02-06
JP2020528601A (ja) 2020-09-24
BR112020000567A2 (pt) 2020-07-21
CN107357882A (zh) 2017-11-17
CN108984715A (zh) 2018-12-11

Similar Documents

Publication Publication Date Title
WO2019011220A1 (zh) 基于依据字段设置审批流程的方法
WO2018196876A1 (zh) 基于角色对用户一对一的工作流控制方法和系统
US20230419265A1 (en) Method based on form fields for arranging examination and approval roles at workflow examination and approval nodes
WO2018214890A1 (zh) 工作流审批节点按角色设置审批角色的方法
WO2018214891A1 (zh) 工作流审批节点按部门设置审批角色的方法
WO2018224024A1 (zh) 工作流审批节点高效审批方法
WO2018214889A1 (zh) 基于会签的审批节点在审批流程中的设置方法
WO2018210245A1 (zh) 工作流及其审批节点的表单字段操作权限的设定方法
WO2018205942A1 (zh) 工作流审批节点按部门级别设置审批角色的方法
WO2019029650A1 (zh) 表单数据操作的审核方法
WO2019007260A1 (zh) 表单字段值操作权限授权方法
WO2019007292A1 (zh) 基于角色的表单操作权限授权方法
WO2019011304A1 (zh) 基于角色获取的表单数据的授权方法
WO2018192557A1 (zh) 基于角色对用户的一对一的权限授权方法和系统
WO2019015656A1 (zh) 一种系统派工方法
WO2019029501A1 (zh) 统计列表操作权限授权方法
WO2018214828A1 (zh) 基于投票的审批节点在审批流程中的设置方法
WO2019015539A1 (zh) 一种表单数据操作权限授权方法
WO2018219230A1 (zh) 审批工作流的委托及其再委托方法
WO2019029648A1 (zh) 基于改进型rbac权限控制机制的审批任务转交方法
WO2019007291A1 (zh) 根据表单字段值对表单操作权限进行分别授权的方法
WO2019034023A1 (zh) 审批者针对审批任务征询参考意见的方法
WO2018224023A1 (zh) 系统中员工登录其账户后的权限显示方法
WO2019029649A1 (zh) 对使用者进行审批流程及其审批节点授权的方法
WO2019011162A1 (zh) 快捷功能设置方法

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 3068930

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2020500634

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20207001596

Country of ref document: KR

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112020000567

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2018299512

Country of ref document: AU

Date of ref document: 20180709

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2018832293

Country of ref document: EP

Effective date: 20200210

ENP Entry into the national phase

Ref document number: 112020000567

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20200110