Centralized Management Method of Approval Process in Tax Administration

Abstract

The present invention relates to a method for centralized management of approval processes in tax administration. The method comprises the following steps: Step 1: defining a workflow data structure and storage rule template for the approval process, configuring the workflow data structure and storage rule template to generate an approval process management table group; Step 2: creating a process engine core class, and generating the required external service interface based on the created process engine core class, so as to utilize the generated external service interface to call the generated approval process management table group; Step 3: utilizing the external service interface to perform the required approval process management based on approval process management requirements, wherein the approval process management includes process creation and deployment, process activation, process query, and / or process deletion. The present invention can effectively implement centralized management of approval processes, reduce the cost of process approval, and is safe and reliable.

Description

Technical Field

[0001] The present invention relates to a management method, in particular to a centralized management method for approval processes in tax management. Background Art

[0002] Existing tax authorities utilize numerous internal and external network application systems and terminals, all of which involve various work approval processes. Furthermore, each application system and terminal is built by a different vendor, resulting in a lack of a comprehensive solution for managing the work approval process. This results in an inability to quickly adapt to changing approval process scenarios as business approval processes evolve. Unifying the standards for approval processes across numerous tax business systems is a pressing challenge in tax management. Summary of the Invention

[0003] The purpose of the present invention is to overcome the deficiencies in the prior art and provide a method for centralized management of approval processes in tax management, which can effectively realize centralized management of approval processes, reduce the cost of process approval, and be safe and reliable.

[0004] According to the technical solution provided by the present invention, a method for centralized management of approval processes in tax management includes the following steps:

[0005] Step 1: Define the workflow data structure and storage rule template of the approval process, configure the workflow data structure and storage rule template to generate the approval process management table group;

[0006] Step 2: Create a process engine core class, and generate the required external service interface based on the created process engine core class, so as to use the generated external service interface to call the above-generated approval process management table group;

[0007] Step 3: Based on the approval process management requirements, the above-mentioned external service interface is used to perform the required approval process management, including process creation and deployment, process activation, process query and / or process deletion.

[0008] In step 1, the approval process management table group generated includes a general data information table group, a process running instance table group, a process history table group, a user group table group, a process definition table group, and a basic data table group;

[0009] The general data information table group includes process definition and process resource tables and system-related attribute tables; the process running instance table group includes runtime event table, runtime process execution instance table, runtime user relationship information table, runtime job table, runtime task table, and runtime variable table;

[0010] The process history record table group includes the historical process instance table, the historical process attachment table, the historical descriptive information table, the historical process running detailed information table, the historical process personnel table, the historical process instance table, the historical task instance table and the historical process running variable information table;

[0011] The user group tables include the identity information-group information table, the identity information-group information table, the intermediate table of identity information-user and group relationship, and the identity information-user information table; the process definition table group includes the deployment unit information table, the model information table, and the process parsing table; the basic data table group includes the business system table, the business system and module relationship table, and the module and process association table.

[0012] In step 2, create the process engine core class CentralizeProcessEngine, which is responsible for generating various instances and data when the approval process is running, monitoring and managing the running of the process;

[0013] When generating the external service interface, first call the getDefaultProceeEngine function of the core class to create the service class RepositoryService for the design, deployment, and deletion of the approval process, the service class RuntimeService for process execution, the service class TaskService for task acquisition, the service class HistoryService for historical query, the service class BusinessService for business system docking, and the service class ModelService for module and process instance docking, and then generate the external service interface that is adapted to the created service class. The external service interface includes the process definition external service interface, the process startup external service interface, and the process deletion external service interface.

[0014] In step 3, when the approval process management is creating and deploying the process, a flowchart design bpmn file is constructed, and the process definition external service interface is called. Through the process definition external service interface, the process creation deployment information in the constructed flowchart design bpmn file is passed through the service class RepositoryService to configure the corresponding approval process management table in the approval process management table group.

[0015] After generating the external service call interface, configure the call permissions for any external service call interface.

[0016] In step 1, the configured workflow data structure and storage rule template are read through the Hibernate method to create an approval process management table group in the database.

[0017] The advantages of the present invention are: it can effectively realize centralized management of the approval process, reduce the cost of process approval, and is safe and reliable. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 Flowchart of the present invention. DETAILED DESCRIPTION

[0019] The present invention will be further described below with reference to specific drawings and embodiments.

[0020] like Figure 1 As shown: In order to effectively realize the centralized management of the approval process and reduce the cost of process approval, the centralized management method of the approval process of the present invention includes the following steps:

[0021] Step 1: Define the workflow data structure and storage rule template of the approval process, configure the workflow data structure and storage rule template to generate the approval process management table group;

[0022] Specifically, based on the characteristics of the approval process in tax management, the workflow data structure and storage rule template of the approval process are defined. The main purpose of the workflow data structure and storage rule template of the approval process is to implement the table design in the approval process. The specific method of defining the workflow data structure and storage rule template is related to the approval process to be managed, which is well known to those in this technical field and will not be repeated here. Configuring the workflow data structure and storage rule template mainly involves configuring the data structure. The table structure can also be expanded or deleted according to actual needs so that the approval process management table group can be finally generated. The specific method is consistent with the existing one and is well known to those in this technical field and will not be repeated here.

[0023] The configured digital workflow data structure and storage rule template are read through the Hibernate method to create an approval process management table group in the database. The specific method and process of reading the configured digital workflow data structure and storage rule template by the Hibernate method are consistent with the existing ones and are well known to people in this technical field, so they will not be repeated here.

[0024] In the embodiment of the present invention, the generated approval process management table group includes a general data information table group, a process running instance table group, a process history record table group, a user group table group, a process definition table group and a basic data table group;

[0025] The general data information table group includes process definition and process resource tables, as well as system-related property tables. Specifically, the process definition and process resource table (CENT_GENER_BYTEARRAY) is used to store large text data of deployment files, storing process definition images and XML in binary format. It includes fields such as primary key ID, version number, deployment file name, and large text type. The system-related property table (CENT_GENER_PROPERTY) is used to store process engine-level data, including fields such as property name, property value, and version number.

[0026] The process run instance table group includes the runtime event table, the runtime process execution instance table, the runtime user relationship information table, the runtime job table, the runtime task table, and the runtime variable table. Specifically, the runtime event table (CENT_RU_EVENT_SUBSCR) stores descriptive data for a specific event node in the process. This descriptive data determines the triggering of a process event and includes fields such as event name, execution instance ID, process instance ID, and activity instance ID. The runtime process execution instance table (CENT_RUN_EXECUTION) stores pending task information, including fields such as process instance ID, business ID, version number, process definition ID, and instance ID. The runtime user relationship information table (CENT_RUN_IDENTITYLINK) primarily stores information about the participants at the current node. The task participant data table includes fields such as user group ID, version number, user group type task ID, process instance ID, and process definition ID. The runtime task table (CENT_RUN_TASK) stores executing real-time tasks and serves as a lookup table for pending tasks. It includes fields such as process instance ID, process definition ID, and task name. The runtime variable table (CENT_RUN_VARIABLE) is used to record the parameter values ​​set for each process, including fields such as encoding type, variable name, process instance ID, execution instance ID, task ID, byte group ID, etc.

[0027] The process history record table group includes the historical process instance table, the historical process attachment table, the historical descriptive information table, the detailed information table during the historical process operation, the historical process personnel table, the historical process instance table, the historical task instance table, and the variable information table during the historical process operation. Specifically, the historical process instance table (CENT_HIS_CENTINST) is used to record the historical activity information of all nodes in the process flow, including fields such as the process definition ID, process instance ID, process execution ID, start time, and end time. The historical descriptive information table (CENT_HIS_COMMENT) is used to record historical approval comments, including fields such as user ID, task ID, process instance ID, handling opinions, and notes. The detailed information table during the historical process operation (CENT_HIS_DETAIL) is used to record the details of variables generated in the process, including variables that control the flow of the process and variables required by the process filled in the business form. It includes fields such as process instance ID, execution instance ID, task ID, activity instance ID, and name.

[0028] The historical process personnel table (CENT_HIS_IDENTITYLINK) is used to store information about historical node participants, including fields such as user ID, task ID, user group type, and process instance ID. The historical process instance table (CENT_HIS_PROCINST) is a core table that includes fields such as process instance ID, process definition ID, business key, start time, and end time. The historical task instance table (CENT_HIS_TASKINST) is used to record instance information of historical task processes, including fields such as process definition ID, process instance ID, execution ID, and the actual signatory and task owner. The variable information table (CENT_HIS_VARINST) in the historical process operation is used to record variable information of historical processes, including fields such as process instance ID, execution ID, task ID, name, variable type, and byte array ID. The user group tables include the identity information-group information table, the identity information-group information table, the identity information-intermediate table for user and group relationships, and the identity information-user information table. Specifically, the identity information-group information table (CENT_US_GROUP) is used to store user group information, including fields such as user group ID, user group description, and user group type. The identity information-user information table (CENT_US_USER) is used to record user information, including fields such as user name, password, and email address. The identity information-intermediate table for user and group relationships (CENT_US_MEMBERSHIP) is used to store user group information. In actual business scenarios, this table, including user ID and user group ID, is not used because it relies on the user system of the business system itself.

[0029] The process definition table group includes a deployment unit information table, a model information table, and a process parsing table. Specifically, the deployment unit information table (CENT_RE_DEPLOYMENT) is used to store information that needs to be persisted during deployment, including fields such as the deployment package name, type, and deployment time. The model information table (CENT_RE_MODEL) is used to save the design model for creating the process, including the model name, type, creation time, last modification time, and deployment ID. The process parsing table (CENT_RE_PROCDEF) is used to store successfully parsed process data, including fields such as the process name, process number, process version number, deployment number, and resource file name.

[0030] The basic data table group includes the business system table, the business system and module relationship table, and the module and process association table; specifically, the business system table (CENT_BUSINESS_SYS) is used to store the basic information of the third-party business system, including fields such as the business system name, business system number, creation time, and creator. The business system and module relationship table (CENT_BUSINESS_MODEL) is used to store the information of each third-party business system module (each business system corresponds to multiple modules), including fields such as the primary key ID, business system code, module name, and module code. The module and process association table (CENT_MODEL_PROCESS) is used to record the relationship between each module of the third-party business system and the approval process, including fields such as the module code, process key (unique identifier of the flowchart), process instance ID, creation time, and start and stop flags.

[0031] When implementing, the specific situation of generating the approval process management table group can refer to the above description, or be selected as needed, which is well known to those skilled in the art and will not be described here. After generating the approval process management table group, the generated approval process management table group can be used to express one or more approval processes.

[0032] Step 2: Create a process engine core class, and generate the required external service interface based on the created process engine core class, so as to use the generated external service interface to call the above-generated approval process management table group;

[0033] Specifically, create the process engine core class CentralizeProcessEngine that is responsible for generating various instances and data during the approval process runtime, monitoring and managing the operation of the process;

[0034] When generating the external service interface, first call the getDefaultProceeEngine function of the core class to create the service class RepositoryService for the design, deployment, and deletion of the approval process, the service class RuntimeService for process execution, the service class TaskService for task acquisition, the service class HistoryService for historical query, the service class BusinessService for business system docking, and the service class ModelService for module and process instance docking, and then generate the external service interface that is adapted to the created service class. The external service interface includes the process definition external service interface, the process startup external service interface, and the process deletion external service interface.

[0035] Specifically, the process engine core class CentralizeProcessEngine and the getDefaultProceeEngine function of the core class are consistent with the existing ones and are well known to those in this technical field, so they will not be repeated here. The generated external service interfaces include the process definition external service interface, the process start external service interface, and the process deletion external service interface. The external service interfaces are associated with the service class RepositoryService for the design, deployment, and deletion of the created approval process, the service class RuntimeService for process execution, the service class TaskService for task acquisition, the service class HistoryService for historical query, the service class BusinesService for business system docking, and the service class ModelService for module and process instance docking using the commonly used technical means in this technical field. The specific association method and process are consistent with the existing ones and will not be repeated here.

[0036] After generating the external service call interface, the calling permissions of any external service call interface are configured using the technical means commonly used in this technical field, so that different personnel can conveniently call different external service call interfaces. The configuration of permissions can be selected according to actual needs and will not be repeated here.

[0037] Step 3: Based on the approval process management requirements, the above-mentioned external service interface is used to perform the required approval process management, including process creation and deployment, process activation, process query and / or process deletion.

[0038] Specifically, when creating and deploying a process, approval process management constructs a flowchart design bpmn file. This file models and annotates the business process, using a commonly used construction method. The process definition external service interface is called to pass the process creation and deployment information in the constructed flowchart design bpmn file through the service class RepositoryService to configure the corresponding approval process management table within the approval process management table group.

[0039] When querying the process status, you only need to call the queryProcessState interface and pass in the system code, module code and user information to obtain the process status information; when the business system approval process flows, you only need to pass in the system code and module code by calling other related interfaces, and query the process key (the unique identifier of the flowchart) and process instance ID from the business system table (CENT_BUSINESS_SYS), the business system and module relationship table (CENT_BUSINESS_MODEL), and the module and process association table (CENT_MODEL_PROCESS), and then call the corresponding function to operate the process-related group table, so that you can realize the flow of approval process, review tasks and historical information query and other operations in one stop, and the service interfaces called by each business system are isolated from each other, so as to realize the unified management of the approval workflow of each business system.

[0040] In the embodiment of the present invention, the system code specifically refers to the identity code of the tax third-party business system (similar to an ID card number), which is set by the tax third-party business system itself and ensures uniqueness during setting. When obtaining process data in the centralized approval process management system, it is used to confirm the identity of the tax third-party business system so as to further locate the modules and other information under the system.

[0041] Module coding specifically refers to the module identity code of the tax third-party business system (similar to an ID card number), which is set by the tax third-party business system itself and is guaranteed to be unique within the business system itself. Module coding between different systems can be repeated. When obtaining process data in the centralized approval process management system, it is used to confirm the module identity in order to further locate the process information of the module.

[0042] In specific implementations, the ID is the primary key of each data and is unique, ensuring that unique data can be queried through the primary key. This is well known to those skilled in the art and will not be further described here. The third-party tax business system specifically refers to a commonly used tax management system (such as a comprehensive tax management platform for large enterprises), which is well known to those skilled in the art and will not be further described here.

[0043] During specific implementation, government agencies, especially taxation agencies, are very strict about the distribution and submission of important information. Therefore, various management systems of taxation agencies will involve various approval processes. For example, the off-site collaboration approval process in the off-site taxation collaboration platform. When each taxation agency needs to collaborate with other taxation agencies, it initiates an off-site collaboration application through the off-site collaboration platform and the application is approved by leaders at all levels. After approval, it is sent to the other party for processing. The off-site taxation collaboration platform needs to design an off-site collaboration approval process. For example, the Large Enterprise Bureau needs to use the Large Enterprise Taxation Comprehensive Management Platform to issue the taxpayer compliance management recommendation to the taxpayer only after approval. It needs to design an approval process and the application can be approved by leaders at all levels before it can be issued.

[0044] Similarly, many tax management system approval processes, such as the enterprise compliance report approval process of the large enterprise tax comprehensive management platform, the enterprise tax risk reminder approval process of the large enterprise tax comprehensive management platform, the audit report generation approval process of the audit operation platform, the data collection approval process of the tax data collection and analysis system, the tax-police cooperation platform tax-police document interaction approval process, the tax party building cloud platform announcement release approval process, and the tax audit information management platform indicator collection approval process, can all be managed in the centralized approval process management system.

[0045] The following uses the approval process for issuing enterprise tax risk reminders in the large enterprise tax integrated management platform as an example to introduce the management process of the approval process of various business systems of the tax authorities by the centralized approval process management system.

[0046] The Large Enterprise Management Bureau will conduct risk scans based on the declaration data, account data and other data of each taxpayer, and classify the taxpayer's risks as high, medium and low based on the scan results. For taxpayers with lower risks, tax officials will prepare taxpayer risk reminder letters through the Large Enterprise Tax Comprehensive Management Platform, which will be issued to taxpayers after approval by deputy section chiefs, section chiefs, and deputy directors in charge. Taxpayers will handle the matter themselves according to the content of the risk reminder letter and report the results of the handling.

[0047] In the risk reminder letter process design module of the large enterprise tax comprehensive management platform, the risk reminder letter approval process is designed by calling the external process design interface of the approval process centralized management system. When saving the data after the design is completed, it is necessary to determine whether the large enterprise tax comprehensive management platform is connected for the first time. If it is the first time to connect, a business system basic information data (including business system name, business system number, creation time, creator, etc., such as large enterprise tax comprehensive management platform, taxManagementPlatform, 2021-10-1, Zhang San) will be generated in the business system table (CENT_BUSINESS_SYS).

[0048] Then, a piece of data is generated in the business system and module relationship table (CENT_BUSINESS_MODEL) to store the information of the current module (including module name, module code, business system code, etc., such as risk reminder, RiskReminder, taxManagementPlatform, etc.), and then a piece of data is generated in the process deployment table (CENT_RE_DEPLOYMENT) to store the deployment number, deployment name and deployment time of the process definition (such as RiskReminderDeplyId1, Risk Reminder Approval Process, 2021-10-110:00:00), and a record will be added for each process deployed; and the specific information of the deployed flow (including process definition ID, process name, process key, deployment number, resource file name, image resource file name, etc., such as RiskReminder_1, Risk Reminder Approval Process, RiskReminderKey, RiskRemind) will be stored in the process definition table (CENT_RE_PROCDEF). erDeplyId1, RiskReminder.bmpn20.xml, RiskReminder.png, etc.), then save the BPMN process definition file as a record in binary mode to the resource file table (CENT_GENER_BYTEARRAY) (including the deployment number, deployment file name, and binary deployment file, such as the binary data of RiskReminderDeplyId1, RiskReminder.bmpn20.xml, RiskReminder.bmpn20.xml, or RiskReminder.png). Finally, in the module and process association table (CENT_MODEL_PROCESS), bind the process deployment code and module (including module code, process key, creation time, start and stop flags <enable is Y, disable is N>, etc., such as RiskReminder, RiskReminderKey, 2021-10-110:00:00, Y) to implement the deployment of the risk reminder approval process.

[0049] During the approval process of the risk reminder letter of the large enterprise tax integrated management platform, the process startup service interface exposed by the approval process centralized management system will be called. First, the corresponding module will be found in the business system table (CENT_BUSINESS_SYS) and the business system and module relationship table (CENT_BUSINESS_MODEL) based on the incoming large enterprise tax integrated management platform system code (taxManagementPlatform) and risk reminder module code (RiskReminder). Then, the module and process association table (CENT_MODEL_PROCESS) will be used to locate the operated process.

[0050] Use the process key (RiskReminderKey) to start the process. After starting, starting from the start node, a data will be inserted into the runtime process execution instance table (CENT_RUN_EXECUTION) (including execution instance ID, process instance ID, process definition ID, executor, etc., such as execute001<auto-generated>, 1001<auto-generated>, RiskReminder_define_1<auto-generated>, Zhang San), and a to-do task record will be generated in the runtime task table (CENT_RUN_TASK) (including execution instance ID, process instance ID, task name, parent task ID, agent, etc., such as execute001, 1001, RiskReminder_define_1<auto-generated>, Zhang San). Risk reminder, null, Zhang San), and then update the module and process association table (CENT_MODEL_PROCESS) process instance ID according to the generated instance ID (1001); the business system can query the current to-do tasks of employee Zhang San by calling the task query interface. For process designs with branches, branch variables will be set in the flowchart in advance. The process will determine which branch to take based on different variable values. For example, the risk reminder letter approval process defines that if the number of risks is greater than or equal to 50, it will be approved by the director in charge, and if it is less than 50, it will be approved by the deputy director in charge. These parameters will be stored in the runtime variable table (CENT_RUN_VARIABLE), and a new record will be added to the historical process variable information table (CENT_HIS_VARINST).

[0051] The current operator completes the current task by calling the task completion service interface provided by the approval through the large enterprise tax integrated management platform. The current task in the runtime process execution instance table (CENT_RUN_EXECUTION) will be automatically deleted and the task data of the next node will be generated. The runtime task table (CENT_RUN_TASK) will be updated synchronously. At the same time, the flow data will be inserted into the historical process instance (CENT_HIS_PROCINST), historical node (CENT_HIS_CENTINST), and historical task table (CENT_HIS_TASKINST) to provide a data basis for subsequent historical task queries.

[0052] The other task nodes of the approval process are transferred in the same way as above. When the process-related data in the process execution instance table (CENT_RUN_EXECUTION) is cleared during runtime, the process is marked as finished.

[0053] When querying the historical approval process of the risk reminder letter, the large enterprise tax integrated management platform calls the historical process query interface exposed to the outside world by the approval process centralized management system, and passes in the large enterprise tax integrated management platform system number taxManagementPlatform, module code RiskReminder and process instance ID (1001). First, the large enterprise tax integrated management platform system code (taxManagementPlatform) and risk reminder module code (RiskReminder) are used to find the corresponding module in the business system table (CENT_BUSINESS_SYS) and the business system and module relationship table (CENT_BUSINESS_MODEL). Then, according to the process instance ID (1001), the historical task instance table (CENT_HIS_TASKINST) is queried for the historical task. The historical task refers to the query of how many tasks a certain process has gone through in total, and is returned to the large enterprise tax integrated management system risk reminder letter historical process display module for use.

[0054] When the Large Enterprise Taxation Integrated Management Platform needs to disable or enable the Risk Reminder Letter approval process, it calls the process enable / disable interface exposed by the Approval Process Centralized Management System and passes in the Large Enterprise Taxation Integrated Management Platform system number (taxManagementPlatform), module code (RiskReminder), process key (RiskReminderKey), and enable / disable flag (Y / N). The Approval Process Centralized Management System will set the enable / disable field in the module and process association table (CENT_MODEL_PROCESS) to Y or N, thereby enabling or disabling the Risk Reminder Letter approval process. When the Large Enterprise Taxation Integrated Management Platform needs to execute the Risk Reminder Letter approval process, it will first check the status of the Risk Reminder Letter approval process. If the process is disabled, the Approval Process Centralized Management System will return the result to the Large Enterprise Taxation Integrated Management Platform, thereby implementing permission control for the Risk Reminder Letter module approval process on the Large Enterprise Taxation Integrated Management Platform.

[0055] The above only provides a specific management description of the approval process for issuing corporate tax risk reminders. For other approval processes in tax management, please refer to the above description and will not be repeated here.

Claims

1. A method for centralized management of approval processes in tax administration, characterized by: The centralized management method for approval process includes the following steps: Step 1: Define the workflow data structure and storage rule template of the approval process, configure the workflow data structure and storage rule template to generate the approval process management table group; Step 2: Create a process engine core class, and generate the required external service interface based on the created process engine core class, so as to use the generated external service interface to call the above-generated approval process management table group; Step 3: Based on the approval process management requirements, use the external service interface to perform the required approval process management, including process creation and deployment, process activation, process query and / or process deletion; In step 1, the approval process management table group generated includes general data information table group, process running instance table group, process history table group, user group table, process definition table group and basic data table group; The general data information table group includes process definition and process resource tables as well as system-related attribute tables; The process running instance table group includes a runtime event table, a runtime process execution instance table, a runtime user relationship information table, a runtime job table, a runtime task table, and a runtime variable table; The process history record table group includes the historical process instance table, the historical process attachment table, the historical descriptive information table, the historical process running detailed information table, the historical process personnel table, the historical process instance table, the historical task instance table and the historical process running variable information table; The user group table includes an identity information-group information table, an intermediate table of identity information-user and group relationships, and an identity information-user information table; The process definition table group includes the deployment unit information table, the model information table, and the process parsing table; The basic data table group includes the business system table, the business system and module relationship table, and the module and process association table; In step 2, create the process engine core class CentralizeProcessEngine, which is responsible for generating various instances and data when the approval process is running, monitoring and managing the running of the process; When generating external service interfaces, first call the getDefaultProceeEngine function of the core class to create the service class RepositoryService for designing, deploying, and deleting the approval process, the service class RuntimeService for process execution, the service class TaskService for task acquisition, the service class HistoryService for historical query, the service class BusinessService for business system docking, and the service class ModelService for module and process instance docking. Then generate external service interfaces that are compatible with the created service classes. The external service interfaces include the process definition external service interface, the process startup external service interface, and the process deletion external service interface. In step 3, when the approval process management is creating and deploying a process, a flowchart design bpmn file is constructed, and the process definition external service interface is called. Through the process definition external service interface, the process creation and deployment information in the constructed flowchart design bpmn file is configured in the corresponding approval process management table in the approval process management table group through the service class RepositoryService; In step 1, the configured workflow data structure and storage rule template are read through the Hibernate method to create an approval process management table group in the database; When querying the process status, call the queryProcessState interface and pass in the system code, module code, and user information to obtain the process status information; When the business system approval process flows, the system code and module code are passed in by calling other related interfaces, and the process key and process instance ID are queried from the business system table, the business system and module relationship table, and the module and process association table, and then the corresponding function is called to operate the process-related group table.

2. The method for centralized management of approval processes in tax administration according to claim 1 is characterized by: After generating the external service call interface, configure the call permissions for any external service call interface.

Images