Personnel dynamic configuration and countersigning implementation method and device for approval node

Abstract

The invention provides a personnel dynamic configuration and countersigning implementation method and device for an approval node, and relates to the technical field of digital office, and the method comprises the steps: obtaining the configuration information of the approval node and the business data of an approval document corresponding to the approval node; based on a target dimension in the configuration information, determining a preset personnel field mapping rule corresponding to the target dimension; extracting original personnel data associated with the target dimension from the business data based on a preset personnel field mapping rule; performing aggregation processing on the original personnel data to obtain a countersigning approver list after duplicate removal; and triggering and executing a countersigning approval process based on the countersigning approver list. According to the method, the multi-dimensional personnel data is accurately extracted, the countersigning list is generated through automatic aggregation and de-duplication, the process is triggered, the approval requirements of the apportionment personnel are adapted, the approval configuration universality and the process efficiency are improved, and the consistency of multi-terminal experience is guaranteed.

Description

Technical Field

[0001] This application relates to the field of digital office technology, and more specifically, to a method and apparatus for dynamic personnel configuration and countersigning at approval nodes. Background Technology

[0002] In digital office scenarios such as corporate expense reimbursement and business approval, the rationality and accuracy of the approval process directly impact business efficiency and risk control. Especially in scenarios like research divisions with expense allocation needs, allocation personnel must participate in the approval of reimbursement documents to confirm expense attribution and rationality. This requirement places higher demands on the personnel association and configuration capabilities of the approval system. However, existing approval systems have significant shortcomings: limited approver configuration, unable to obtain personnel fields from document allocation methods, making it difficult to meet the core needs of allocation personnel in the approval process; insufficient functional versatility, lacking a unified extraction and configuration mechanism for personnel fields across different dimensions such as documents, details, and allocation; lack of co-signing adaptation capabilities, unable to automatically aggregate multiple allocation personnel and trigger co-signing processes; and incomplete personnel aggregation logic, easily leading to duplicate or omitted target personnel in multiple details or allocation items, resulting in chaotic approval processes. These problems severely affect approval efficiency and accuracy. Summary of the Invention

[0003] The purpose of this application is to provide a method and apparatus for dynamic personnel configuration and countersigning at approval nodes, which solves the above-mentioned problems existing in the prior art, can accurately adapt to the approval needs of personnel allocation, realize efficient aggregation and deduplication of multi-dimensional personnel data, and improve countersigning efficiency.

[0004] Firstly, a method for dynamically configuring and co-signing personnel at approval nodes is provided, which may include: Obtain the configuration information of the approval node and the business data of the approval document corresponding to the approval node; Based on the target dimension in the configuration information, determine the preset personnel field mapping rule corresponding to the target dimension; Based on the preset personnel field mapping rules, extract the original personnel data associated with the target dimension from the business data; The original personnel data is aggregated to obtain a deduplicated list of co-signers and approvers; Based on the list of co-signers and approvers, the co-signing and approval process is triggered and executed.

[0005] In one possible implementation, the target dimension includes a document dimension, a detail dimension, or an allocation dimension; The preset personnel field mapping rules are the correspondence between different dimensions and different personnel field identifiers, and the correspondence between different field types and different data extraction paths.

[0006] In one possible implementation, based on the preset personnel field mapping rules, original personnel data associated with the target dimension is extracted from the business data, including: If the target dimension is a document dimension, then the original personnel field is extracted from the document-level attributes of the business data; If the target dimension is a detail dimension, then traverse all detail items in the business data and extract the original personnel field from each detail item; If the target dimension is an allocation dimension, then traverse all allocation items in the business data and extract the original personnel field from each allocation item.

[0007] In one possible implementation, the original personnel data is aggregated to obtain a deduplicated list of co-signing approvers, including: Each data item in the original personnel data is identified as a single personnel identifier or a personnel multi-select field; If it is a field for multiple selections of personnel, then iterate through each personnel identifier contained therein; All identified personnel identifiers are added to an ordered set for automatic deduplication; The ordered set is converted into a list to generate the list of co-signers and approvers.

[0008] In one possible implementation, based on the list of countersigning approvers, the countersigning approval process is triggered and executed, including: The approval document is pushed to each approver in the list of countersigners; Record the approval status of each approver; Based on the configured co-signing approval rules and the approval status of each approver, the process result of the co-signing approval process is determined.

[0009] In one possible implementation, after triggering and executing the countersigning approval process, the method further includes: Get the type of access terminal; Based on the type of access terminal, the display data related to the co-signing and approval process is adapted to generate a user interface that is compatible with the terminal type.

[0010] In one possible implementation, after triggering and executing the countersigning approval process, the method further includes: The business data is updated based on the results of the aforementioned countersigning and approval process.

[0011] Secondly, a device for dynamic personnel configuration and countersigning at approval nodes is provided, which may include: The acquisition unit is used to acquire the configuration information of the approval node and the business data of the approval document corresponding to the approval node; The determining unit is used to determine a preset personnel field mapping rule corresponding to the target dimension based on the target dimension in the configuration information; The extraction unit is used to extract original personnel data associated with the target dimension from the business data based on the preset personnel field mapping rules. The processing unit is used to aggregate the original personnel data to obtain a deduplicated list of co-signers and approvers. The triggering unit is used to trigger and execute the co-signing approval process based on the list of co-signers and approvers.

[0012] Thirdly, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps described in the first aspect above.

[0013] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0014] This application provides a method and apparatus for dynamic personnel configuration and co-signing at approval nodes. The method includes: acquiring configuration information of the approval node and business data of the approval documents corresponding to the approval node; determining preset personnel field mapping rules corresponding to the target dimension based on the target dimension in the configuration information; extracting original personnel data associated with the target dimension from the business data based on the preset personnel field mapping rules; aggregating the original personnel data to obtain a deduplicated list of co-signers; and triggering and executing the co-signing approval process based on the list of co-signers. This method accurately extracts multi-dimensional personnel data, automatically aggregates and deduplicates data to generate a co-signing list and triggers the process, adapts to the needs of distributed personnel approval, improves the universality of approval configuration and process efficiency, and ensures a consistent experience across multiple terminals. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1A flowchart illustrating a method for dynamic personnel configuration and countersigning at an approval node, provided in an embodiment of this application; Figure 2 A schematic diagram of a device for dynamically configuring and countersigning personnel at an approval node, provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] In digital office scenarios such as corporate expense reimbursement and business approval, the rationality and accuracy of the approval process directly impact business efficiency and risk control. Especially in scenarios like research divisions with expense allocation needs, allocation personnel must participate in the approval of reimbursement documents to confirm expense attribution and rationality. This requirement places higher demands on the personnel association and configuration capabilities of the approval system. However, existing approval systems have significant shortcomings: limited approver configuration, unable to obtain personnel fields from document allocation methods, making it difficult to meet the core needs of allocation personnel in the approval process; insufficient functional versatility, lacking a unified extraction and configuration mechanism for personnel fields across different dimensions such as documents, details, and allocation; lack of co-signing adaptation capabilities, unable to automatically aggregate multiple allocation personnel and trigger co-signing processes; and incomplete personnel aggregation logic, easily leading to duplicate or omitted target personnel in multiple details or allocation items, resulting in chaotic approval processes. These problems severely affect approval efficiency and accuracy.

[0019] Therefore, this application provides a method for dynamic configuration and countersigning of personnel at approval nodes, which solves the above-mentioned problems in the existing technology, can accurately adapt to the approval needs of personnel allocation, realize efficient aggregation and deduplication of multi-dimensional personnel data, and improve the efficiency of countersigning.

[0020] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0021] Figure 1 This is a flowchart illustrating a method for dynamically configuring and countersigning personnel at an approval node, as provided in an embodiment of this application. Figure 1 As shown, the method may include: Step S110: Obtain the configuration information of the approval node and the business data of the approval document corresponding to the approval node.

[0022] When the approval workflow engine detects that the approval process has moved to a preset co-signing node, it automatically triggers the dynamic configuration of approvers and the co-signing collaboration process. In order to obtain the configuration information of the approval node and the business data of the approval document corresponding to the approval node, the specific implementation process is as follows: The configuration information of the approval node is the basis for subsequent dimension identification and personnel field matching. It is stored in the node configuration library of the approval system and managed using a structured data format. The current co-signing node is accurately located by using the node identifier (NodeID) of the approval flow engine, and the complete configuration data is extracted from the configuration library by calling the configuration information query interface (getApprovalNodeConfig(NodeID)).

[0023] The configuration information includes: ApprovalDimension, which specifies the dimension type to be extracted from the personnel field; Personnel field matching identifier, which associates the preset approval dimension with the field configuration in the personnel field mapping table; Countersigning rule configuration, including countersigning approval conditions (such as unanimous agreement, majority agreement), approval timeout handling mechanism, etc.; Terminal adaptation identifier, which is used for subsequent front-end display to identify adaptation requirements.

[0024] The process of obtaining configuration information has a fault tolerance mechanism. If the query result is empty or the core configuration item is missing, an exception prompt process will be triggered, a configuration exception alarm will be pushed to the administrator, and the current approval process will be suspended to ensure that the execution of subsequent steps is based on compliance and effectiveness.

[0025] The business data of approval documents serves as the data source for personnel information extraction. It is stored in the main document table and associated detail and allocation sub-tables of the business database. Each table is linked through a unique document identifier (DocumentID). After obtaining the approval node configuration information, the business data query interface (getDocumentBusinessData(DocumentID)) is called using the document association identifier contained in this configuration information to extract complete business data from the database in batches.

[0026] Business data includes: main document table data, containing basic attributes such as document number, submitter information, business type (e.g., expense reimbursement, business approval), and submission time; detailed sub-table data (if present), storing specific information for each detailed item in list form, including detailed number, expense amount, and associated allocation information, with each detailed item containing a corresponding personnel field (e.g., allocation personnel); allocation sub-table data (if present), recording the allocation ratio and allocation object for each allocation item, also containing a target personnel field; and auxiliary data such as document-related attachment information and previous approval records.

[0027] During the data acquisition process, data integrity is verified to ensure consistency between the main document table and related sub-tables. If data is missing or the association is abnormal, a data completion mechanism will be automatically triggered or a data correction prompt will be sent to the submitter to ensure that the extracted business data can meet the needs of subsequent personnel for field parsing.

[0028] This step, through precise positioning and compliant queries, ensures that the obtained approval node configuration information and approval document business data are complete, accurate, and effective, laying a solid foundation for subsequent steps such as personnel field parsing based on target dimensions and aggregation of co-signing approvers.

[0029] Step S120: Based on the target dimension in the configuration information, determine the preset personnel field mapping rules corresponding to the target dimension.

[0030] Among them, the target dimensions include document dimensions, detail dimensions, or allocation dimensions; The default personnel field mapping rules are the correspondence between different dimensions and different personnel field identifiers, and the correspondence between different field types and different data extraction paths.

[0031] Specifically, the core configuration item target dimension identifier (ApprovalDimension) is first extracted from the obtained approval node configuration information. This identifier is a preset enumeration type that clearly limits the extraction dimension range of the personnel field, including only three types: document dimension (ApprovalDimension.DOCUMENT), detail dimension (ApprovalDimension.DETAIL), or allocation dimension (ApprovalDimension.ALLOCATION).

[0032] The target dimension identifier is validated using the configuration information parsing interface (parseTargetDimension(NodeConfig)) to confirm whether it is one of the three types of valid enumeration values ​​mentioned above. If the parsing result is an invalid identifier or a missing field, an exception handling mechanism is triggered, pushing an alert message indicating invalid dimension configuration to the administrator and suspending the current approval process to prevent subsequent data extraction failures due to dimension errors.

[0033] A pre-configured mapping table of structured approval dimensions and personnel fields is stored in the rule configuration library of the approval system. Administrators can maintain and update the configuration through the system backend, and all configuration changes will be logged to ensure traceability.

[0034] In this mapping table, each target dimension (document dimension, detail dimension, allocation dimension) corresponds to a unique PersonFieldConfig configuration object. This object contains three types of core configuration information, which constitute the complete preset personnel field mapping rules: Personnel field identifier configuration: Clearly define the target personnel field name and unique ID to be extracted under the corresponding dimension (such as the applicant field ID in the document dimension, and the allocation manager field ID in the allocation dimension) to ensure the uniqueness of field matching; Field type configuration: Define the data type of the target field, including only a single person or multiple people selected from both categories, to provide a type basis for subsequent data parsing; Data extraction path configuration: Clarify the storage path of the field in the business database (e.g., document dimension fields are stored in the applicant_id field of the document master table, and detail dimension fields are stored in the allocation_person field of the detail sub-table) to guide data query operations.

[0035] Based on the target dimension obtained from the parsing, the mapping rule query interface (getPersonFieldConfig(ApprovalDimension)) is called to accurately match the corresponding PersonFieldConfig configuration object from the approval dimension and personnel field mapping table.

[0036] The specific matching logic is as follows: using the target dimension as the query key value of the mapping table, traversing the key-value pairs in the mapping table, when the query key value is completely consistent with the target dimension, the corresponding PersonFieldConfig configuration object is returned, that is, the preset personnel field mapping rule under the current dimension is determined; if no corresponding configuration object is found after the traversal is completed, an exception of no corresponding dimension personnel field configuration will be thrown, and the process interruption mechanism will be triggered to ensure that subsequent data extraction operations have clear rule basis and avoid invalid extraction.

[0037] For example, when the target dimension is parsed as a detail dimension (ApprovalDimension.DETAIL), the corresponding PersonFieldConfig object is obtained from the mapping table. It contains the field identifier for the assigned personnel, the field type for multiple personnel selection, and the data extraction path for the detail sub-table.allocation_person. This configuration serves as the core rule for extracting personnel data from the detail items.

[0038] This step, through a standardized dimensional parsing and rule matching mechanism, ensures that the mapping rules for personnel fields under different target dimensions are accurate and unique, providing reliable rule support for the accurate extraction of multi-dimensional personnel data in the future. At the same time, it ensures the maintainability and scalability of the mapping rules and adapts to the configuration requirements of different business scenarios.

[0039] Step S130: Based on the preset personnel field mapping rules, extract the original personnel data associated with the target dimension from the business data.

[0040] Specifically, A) If the target dimension is a document dimension, the original personnel field is extracted from the document-level attributes of the business data. Furthermore, when the target dimension is parsed as a document dimension, it indicates that the personnel field to be extracted is stored in the main table attributes of the approval document, without needing to associate sub-table data. The specific extraction steps are as follows: Based on the data extraction path in the mapping rules, locate the target personnel field (uniquely identified by FieldID) in the document main table of the business data; call the document main table data extraction interface (extractDocumentField(BusinessData,FieldID)) to directly read the personnel data corresponding to this field; if the field type is a single personnel, the extraction result is a single personnel identifier (such as user ID, username); if it is a multi-selection of personnel, the extraction result is a collection of data containing multiple personnel identifiers; use the extracted personnel data as the unique element of the original personnel data list to complete the personnel data extraction for the document dimension. For example, if the target field corresponding to the document dimension is the applicant (field type is a single personnel), then the applicant's user ID 1001 is directly extracted from the document main table, and the original personnel data list is

[1001] .

[0041] B. If the target dimension is a detail dimension, then traverse all detail items in the business data and extract the original personnel field from each detail item. Furthermore, when the target dimension is parsed as a detail dimension, the personnel field is scattered across the detail items in the business data and needs to be extracted in batches through traversal. The specific steps are: call the detail item retrieval interface (getAllDetails(BusinessData)) to extract all detail items from the business data, forming a detail item list; traverse each detail item in the detail item list, and according to the FieldID in the mapping rule, read the personnel data corresponding to the current detail item through the detail field extraction interface (extractDetailField(DetailItem,FieldID)); for the extraction result of each detail item, if the field type is a single personnel, directly add the personnel identifier to the original personnel data list; if it is a multi-selection of personnel, add the entire set of personnel corresponding to the multi-selection field to the original personnel data list, preserving the set structure; after traversal, the original personnel data list contains personnel data for all detail items (which may contain duplicate data or nested sets). For example, if a business trip expense report contains two expense details, and the target field of the detail dimension is the person to be allocated (the field type is multiple selection of personnel), the person to be allocated in detail 1 is [Zhang San, Li Si], and the person to be allocated in detail 2 is [Li Si, Wang Wu]. Then the extracted original personnel data list will be [[Zhang San, Li Si], [Li Si, Wang Wu]].

[0042] C. If the target dimension is an allocation dimension, then iterate through all allocation items in the business data and extract the original personnel field from each allocation item. Further, when the target dimension is resolved to an allocation dimension, the personnel field is stored in each allocation item of the business data. The extraction logic is similar to that of the detailed dimension. The specific steps are: call the allocation item retrieval interface (getAllAllocations(BusinessData)) to extract all allocation items from the business data, forming an allocation item list; iterate through each allocation item in the allocation item list, and according to the FieldID in the mapping rule, read the personnel data corresponding to the current allocation item through the allocation field extraction interface (extractAllocationField(AllocationItem,FieldID)); process the extraction results according to the field type: single personnel data is directly added to the original personnel data list, and multiple-selection personnel data is added to the list in the form of a set; after the iteration is complete, generate the original personnel data list containing personnel data for all allocation items. For example, a business approval form contains 3 allocation items. The target field of the allocation dimension is the person in charge of allocation (the field type is a single person). The persons in charge of the 3 allocation items are Zhang San, Li Si, and Zhang San, respectively. Then the extracted original personnel data list is [Zhang San, Li Si, Zhang San].

[0043] Then, it is stored in a temporary data cache, with the data format remaining consistent with that at the time of extraction (including single personnel identifiers and multiple selection sets of personnel) to ensure that the data type can be accurately identified during subsequent aggregation processing.

[0044] This step, through differentiated extraction logic targeting different target dimensions and precise positioning based on preset mapping rules, achieves complete extraction of personnel / multiple-selection field data under various dimensions such as documents, details, and allocation, ensuring the accuracy and comprehensiveness of the original personnel data and providing a reliable data foundation for subsequent aggregation of co-signature approvers.

[0045] Step S140: Aggregate the original personnel data to obtain a deduplicated list of co-signers and approvers.

[0046] Specifically, the extracted raw personnel data list is first loaded, and the data format is pre-validated to ensure that the type of each data item in the list conforms to preset rules. The validation includes: whether the data item is a valid personnel identification format (such as a unique user ID or standardized username), and whether the personnel multi-select field is a valid collection type (such as an array or list) and whether the internal elements are personnel identifiers.

[0047] If invalid data items are found during verification (such as non-personnel identifier strings or empty sets), a data filtering mechanism will be triggered to automatically remove invalid data and push aggregation data preprocessing and invalid data removal logs to the administrator. If all data items meet the format requirements, the formal aggregation process will begin. Simultaneously, the necessary tool components for aggregation will be initialized, including an ordered set (LinkedHashSet) instance. This set has the dual characteristics of automatic deduplication and preservation of element addition order, ensuring the uniqueness and consistency of the list of co-signers and approvers.

[0048] Next, each data item in the original personnel data is identified as a single personnel identifier or a personnel multi-select field; If it is a field for multiple selections of personnel, then iterate through each personnel identifier contained therein; Furthermore, by calling the data type identification interface (identifyDataType(PersonDataItem)) through the aggregation processor, each data item in the original personnel data list is traversed to identify its type as a single personnel identifier or a personnel multi-select field. The specific identification and processing logic is as follows: If the data item is a single person identifier (such as user ID1001, username Zhang San): this type of data does not need to be split, and is directly marked as an independent element to be added to the ordered set; If the data item is a multi-select field for personnel (such as the set [1002, 1003], [Li Si, Wang Wu]): This type of data needs to be split. Call the multi-select field splitting interface (splitMultiPersonField(PersonDataItem)), traverse each personnel identifier in the multi-select field, and mark each identifier as an element to be added to ensure that all personnel participating in the allocation are included in the aggregation scope.

[0049] For example, the original list of personnel data is [[Zhang San, Li Si], Li Si, Wang Wu]. After type identification and splitting, the set of elements to be added is obtained: [Zhang San, Li Si, Li Si, Wang Wu].

[0050] Next, all identified personnel identifiers are added to an ordered set for automatic deduplication. Further, all personnel identifiers obtained after type identification and splitting are added to the initialized ordered set in the order they were extracted from the original data. The underlying storage mechanism of the ordered set automatically determines whether the personnel identifier to be added already exists: if the identifier does not exist in the set, it is directly inserted at the end of the set, preserving its relative order in the original data; if the identifier already exists in the set, the addition operation is automatically ignored, and duplicate storage is avoided, achieving seamless deduplication of personnel data.

[0051] This method requires no manual intervention and ensures efficient deduplication through the characteristics of the data structure, while preserving the order in which personnel identifiers are added. It can adapt to the requirements of some business scenarios regarding the order of approvers (such as prioritizing by allocation ratio or sorting by the order of submission of detailed items). Continuing with the example above, after the elements to be added [Zhang San, Li Si, Li Si, Wang Wu] are added to the ordered set in sequence, the elements in the set will be [Zhang San, Li Si, Wang Wu], and the duplicate Li Si identifier has been automatically removed.

[0052] Finally, the sorted set is converted into a list to generate the list of co-signers and approvers. That is, after all personnel identifiers have been added to the sorted set, the set-to-list interface (convertSetToList(uniqueApprovers)) is called to convert the sorted set into a standardized list data structure. This list is the final list of co-signers and approvers. The list of co-signers and approvers will be stored in the context data of the approval process, containing all personnel identifiers (without duplicates), and the personnel order will be consistent with the valid extraction order in the original data. Simultaneously, an aggregation processing log is generated, recording key information such as the original personnel data volume, the valid data volume, the amount of duplicate data removed, and the final number of co-signers and approvers, for subsequent process traceability and problem investigation. For example, the original personnel data list of a research division's expense report is [Zhang San, Li Si, Li Si, Wang Wu]. After aggregation, the generated list of co-signers and approvers is [Zhang San, Li Si, Wang Wu]. If the original data list is [[1001, 1002], [1002, 1003], 1004], then the aggregated list is [1001, 002, 1003, 1004].

[0053] This step, through data preprocessing, type identification and splitting, ordered set deduplication, and list transformation, achieves efficient aggregation of original personnel data. It ensures both the uniqueness of the list of co-signers and approvers (avoiding duplicate approvals) and the comprehensiveness of personnel coverage (avoiding missed approvals), laying a core data foundation for the accurate triggering and efficient execution of subsequent co-signing processes.

[0054] Step S150: Based on the list of co-signers and approvers, trigger and execute the co-signing and approval process.

[0055] Specifically, firstly, the approval documents are pushed to each approver in the list of co-signers. That is, the approval workflow engine extracts relevant parameters for co-signing pushes from the approval node configuration information, including the push method (system message, email, APP notification, etc.), approval timeout threshold, and timeout handling strategy (such as default rejection or automatic reassignment). It then calls the co-signer push interface (pushDocumentToApprovers(ApproverList,DocumentData,PushConfig)) to initiate batch approval document push requests targeting each person's identifier in the co-signer list. During the push process, the approval tasks are accurately pushed to the corresponding account's pending approval queue by associating the personnel identifier with the approver's account information, ensuring that each co-signer receives a unique approval task without omissions or duplicate pushes. After the push is completed, a push log is generated, recording the push time, push method, and reception status (delivered, not delivered) for each approver. Undelivered requests will trigger a secondary push mechanism (every 30 minutes apart), with a maximum of 3 pushes. If delivery is still unsuccessful, an alert is sent to the administrator. The data pushed to each approver includes complete information related to the joint signature process, specifically: basic information of the approval document (document number, business type, submitter, submission time), cost details / allocation information (detailed items related to the co-signers, allocation ratio), a list of co-signers (displaying all participants in the joint signature process and the current approval status), and approval operation entry points (approval, rejection, and rejection buttons, and a comment form), ensuring that approvers can obtain complete approval basis without additional queries.

[0056] Next, the approval status of each approver is recorded; this approval status specifically includes: pending approval (initial status), approved, rejected, and dismissed (including two sub-status: dismissed to submitter and dismissed to previous node). After the co-signers perform the approval operation through the terminal, the front end uploads the operation result (including approval comments and operation time) to the approval flow engine in real time; the engine calls the status update interface (updateApprovalStatus(ApproverID,DocumentID,Status,Opinion)) to update the approver's approval status to the approval process status database and associates and stores the approval comments and operation timestamp.

[0057] Finally, based on the configured approval rules and the approval status of each approver, the outcome of the approval process is determined. The approval rules can include: A) Unanimous Approval: All signatories select "Approved," and no one fails to approve within the time limit; the process is considered approved. B) Veto Rule: If any signatories select "Rejected," the process is immediately rejected without waiting for approval from other signatories. C) Majority Approval Rule: If the percentage of those who approve exceeds a preset threshold (e.g., 50%, 2 / 3), and no one rejects, the process is considered approved (thresholds are configurable).

[0058] Whenever a co-signer completes the approval process (updates status), check whether the status of all co-signers meets the preset rules: If the veto rule is met (there is already a rejection status), the signing process will be terminated immediately, and the result will be rejection. If all personnel have completed the approval process (no pending approval status), the result will be determined as either approval or rejection according to the preset rules. If there are still personnel whose applications are pending approval and the time limit has not expired, the final result will not be determined for the time being, and the application will continue to be awaited.

[0059] Timeout determination: When the approval timeout threshold is reached, the status of unapproved personnel is handled according to the preset strategy (such as default rejection, default approval), and then the final result is determined according to the rules. Once the decision is made, the approval workflow engine automatically executes the subsequent process flow: if the result is approved, it is pushed to the next approval node; if the result is rejected, it is pushed to the document submitter or the previous node, and a process result notification is generated and pushed to relevant personnel (submitter, countersigners, administrator).

[0060] In some embodiments, after triggering and executing the countersigning approval process, the method further includes: The system obtains the type of access terminal. Specifically, after the countersigning process is triggered, when the countersigning personnel or relevant parties access the approval system, the system obtains the type of access terminal through the terminal identification interface (identifyTerminalType(RequestHeader)). The system primarily supports two types of terminals: PC (including desktop clients and browsers on Windows and MacOS systems) and mobile (including apps and mobile browsers on Android and iOS systems). The identification criteria are the device identifier, screen resolution, browser kernel, and other information in the request header.

[0061] Based on the type of access terminal, the display data related to the co-signing and approval process is adapted to generate a user interface suitable for the terminal type. Specifically, the display data related to the co-signing process is uniformly encapsulated into a standardized dataset (including a list of co-signers, approval status of each person, approval document information, process results, and approval opinions). Then, differentiated adaptation processing is performed according to the terminal type: For PC: a fully functional co-signing interface is rendered, displaying the detailed status of all co-signers (including operation time and approval opinions), complete document details and allocation data, and supporting extended functions such as batch viewing of approval opinions, exporting document attachments, and viewing historical approval records; For mobile: a simplified adaptation logic is adopted, prioritizing the display of core information (pending approval indicator, key document information, and summary of opinions from completed approvers), displaying complete details and all approval statuses through a drop-down loading mechanism, and optimizing the touch interaction experience (such as increasing the size of operation buttons and simplifying the input process). After adaptation, a user interface matching the terminal type is generated to ensure that users on multiple terminals can efficiently complete approval operations or information queries, ensuring a consistent user experience.

[0062] In some embodiments, after triggering and executing the countersigning approval process, the method further includes: Based on the results of the joint approval process, the business data is updated. Specifically, the approval workflow engine calls the business data update interface (updateBusinessDat(DocumentID,ProcessResult)) to write the process result (approved / rejected) and details of the joint approval result (status and opinions of each approver) into the business data of the approval document, updating the overall approval status of the document. If the process result is approved, the cost allocation related data is updated synchronously (such as marking the allocation personnel as confirmed and updating the cost attribution ledger). If it is rejected, the reason for rejection and the personnel who rejected it are recorded, so that the submitter can make targeted modifications. After the data update is completed, a data update log is generated to ensure that all changes are traceable, while supporting subsequent business statistics, auditing and other needs, and strengthening the closed-loop management of the process.

[0063] This step, through standardized push notifications, status tracking, and result determination mechanisms, automates and precisely executes the joint approval process. Combined with multi-terminal adaptation and business data synchronization, it not only ensures approval efficiency and user experience but also guarantees the integrity and consistency of business data, effectively reducing management risks.

[0064] This application provides a method for dynamic personnel configuration and co-signing implementation at approval nodes. The method includes: acquiring the configuration information of the approval node and the business data of the approval documents corresponding to the approval node; determining a preset personnel field mapping rule corresponding to the target dimension based on the target dimension in the configuration information; extracting original personnel data associated with the target dimension from the business data based on the preset personnel field mapping rule; aggregating the original personnel data to obtain a deduplicated list of co-signers; and triggering and executing the co-signing approval process based on the list of co-signers. This method accurately extracts multi-dimensional personnel data, automatically aggregates and deduplicates data to generate a co-signing list and trigger the process, adapts to the needs of distributed personnel approval, improves the universality of approval configuration and process efficiency, and ensures a consistent experience across multiple terminals.

[0065] Corresponding to the above method, this application embodiment also provides a device for dynamic personnel configuration and countersigning at approval nodes, such as... Figure 2 As shown, the device includes: The acquisition unit 210 is used to acquire the configuration information of the approval node and the business data of the approval document corresponding to the approval node; The determining unit 220 is used to determine a preset personnel field mapping rule corresponding to the target dimension based on the target dimension in the configuration information; Extraction unit 230 is used to extract original personnel data associated with the target dimension from the business data based on the preset personnel field mapping rules; Processing unit 240 is used to aggregate the original personnel data to obtain a deduplicated list of co-signers and approvers; Triggering unit 250 is used to trigger and execute the co-signing approval process based on the co-signing approver list. The functions of each functional unit of the approval node dynamic personnel configuration and countersigning implementation device provided in the above embodiments of this application can be implemented through the above methods and steps. Therefore, the specific working process and beneficial effects of each unit in the approval node dynamic personnel configuration and countersigning implementation device provided in the embodiments of this application will not be repeated here.

[0066] This application also provides an electronic device, such as... Figure 3 As shown, it includes a processor 310, a communication interface 320, a memory 330, and a communication bus 340, wherein the processor 310, the communication interface 320, and the memory 330 communicate with each other through the communication bus 340.

[0067] Memory 330 is used to store computer programs; When the processor 310 executes the program stored in the memory 330, it performs the following steps: Obtain the configuration information of the approval node and the business data of the approval document corresponding to the approval node; Based on the target dimension in the configuration information, determine the preset personnel field mapping rule corresponding to the target dimension; Based on the preset personnel field mapping rules, extract the original personnel data associated with the target dimension from the business data; The original personnel data is aggregated to obtain a deduplicated list of co-signers and approvers; Based on the list of co-signers and approvers, the co-signing and approval process is triggered and executed.

[0068] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0069] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0070] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0071] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0072] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 1The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0073] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to execute a method for dynamic personnel configuration and countersigning of an approval node as described in any of the above embodiments.

[0074] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute a method for dynamic personnel configuration and countersigning of an approval node as described in any of the above embodiments.

[0075] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0076] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0077] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0078] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0079] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected," "coupled," or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0080] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the embodiments in this application are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments in this application.

[0081] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the embodiments of this application and their equivalents, then these modifications and variations are also intended to be included in the embodiments of this application.

Claims

1. A method for dynamic personnel configuration and countersigning at approval nodes, characterized in that, The method includes: Obtain the configuration information of the approval node and the business data of the approval document corresponding to the approval node; Based on the target dimension in the configuration information, determine the preset personnel field mapping rule corresponding to the target dimension; Based on the preset personnel field mapping rules, extract the original personnel data associated with the target dimension from the business data; The original personnel data is aggregated to obtain a deduplicated list of co-signers and approvers; Based on the list of co-signers and approvers, the co-signing and approval process is triggered and executed.

2. The method as described in claim 1, characterized in that, The target dimensions include document dimensions, detail dimensions, or allocation dimensions; The preset personnel field mapping rules are the correspondence between different dimensions and different personnel field identifiers, and the correspondence between different field types and different data extraction paths.

3. The method as described in claim 1, characterized in that, Based on the preset personnel field mapping rules, the original personnel data associated with the target dimension is extracted from the business data, including: If the target dimension is a document dimension, then the original personnel field is extracted from the document-level attributes of the business data; If the target dimension is a detail dimension, then traverse all detail items in the business data and extract the original personnel field from each detail item; If the target dimension is an allocation dimension, then traverse all allocation items in the business data and extract the original personnel field from each allocation item.

4. The method as described in claim 1, characterized in that, The original personnel data is aggregated to obtain a deduplicated list of co-signers and approvers, including: Each data item in the original personnel data is identified as a single personnel identifier or a personnel multi-select field; If it is a field for multiple selections of personnel, then iterate through each personnel identifier contained therein; All identified personnel identifiers are added to an ordered set for automatic deduplication; The ordered set is converted into a list to generate the list of co-signers and approvers.

5. The method as described in claim 1, characterized in that, Based on the aforementioned list of co-signers and approvers, the co-signing and approval process is triggered and executed, including: The approval document is pushed to each approver in the list of countersigners; Record the approval status of each approver; Based on the configured co-signing approval rules and the approval status of each approver, the process result of the co-signing approval process is determined.

6. The method as described in claim 1, characterized in that, After triggering and executing the countersigning approval process, the method further includes: Get the type of access terminal; Based on the type of access terminal, the display data related to the co-signing and approval process is adapted to generate a user interface that is compatible with the terminal type.

7. The method as described in claim 1, characterized in that, After triggering and executing the countersigning approval process, the method further includes: The business data is updated based on the results of the aforementioned countersigning and approval process.

8. A device for dynamic personnel configuration and countersigning at approval nodes, characterized in that, The device includes: The acquisition unit is used to acquire the configuration information of the approval node and the business data of the approval document corresponding to the approval node; The determining unit is used to determine a preset personnel field mapping rule corresponding to the target dimension based on the target dimension in the configuration information; The extraction unit is used to extract original personnel data associated with the target dimension from the business data based on the preset personnel field mapping rules. The processing unit is used to aggregate the original personnel data to obtain a deduplicated list of co-signers and approvers. The triggering unit is used to trigger and execute the co-signing approval process based on the list of co-signers and approvers.

9. An electronic device, characterized in that, The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-7.

Images