Personnel receipt processing method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of personnel business data processing, in particular to a personnel receipt processing method, device and equipment and a storage medium, and the method comprises the steps: responding to received request information of a heterogeneous data source, and converting the request information of the heterogeneous data source into a standard query instruction; executing batch query based on the standard query instruction to obtain target personnel data, and automatically backfilling the target personnel data to a to-be-processed document; in response to the approval validation instruction of the to-be-processed document, acquiring document validation data; and based on a preset data assembly rule, carrying out data assembly on the receipt effective data, and writing the assembled data into a personnel master data model in a single transaction. Therefore, through the predefined rule based on the business type and the multi-source data adapter, automatic loading and backfilling of personnel information are realized, the database requests which are dispersed for multiple times are optimized into one-time batch query, the database pressure is greatly reduced, and accurate execution of the business rule is ensured.

Description

Technical Field

[0001] This application relates to the field of personnel business data processing technology, and in particular to a method, apparatus, electronic device and storage medium for processing personnel documents. Background Technology

[0002] In the field of document processing in human resources management systems, existing technologies mainly rely on the capabilities of general secondary development platforms, including the following two types of solutions. One solution uses a general form designer, which allows business personnel to configure custom forms with zero coding through a visual drag-and-drop method, adapting to multiple business types and layout requirements. However, it only has front-end form design capabilities, and the back-end lacks a unified loading and assembly mechanism for data models for human resources business. When a document becomes effective, developers need to manually write data extraction and assembly logic. Due to the complexity of the personnel master data model and the large number of related entities, incomplete data loading or assembly errors are prone to occur.

[0003] Another approach is to determine the rules for file changes and the mapping relationship between fields through a wizard-guided step-by-step configuration to adapt to the needs of custom documents. However, this approach breaks down the business logic into a large number of scattered configuration items. The system needs to read, parse, and process the configuration multiple times during runtime, resulting in high latency in business request response and high resource consumption. Furthermore, configuration migration requires manual identification and export of scattered configurations, which can easily lead to functional abnormalities due to configuration omissions or environmental differences, increasing the complexity of maintenance and version management. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for processing personnel documents, which can improve the efficiency, data accuracy, and system robustness of personnel document processing, and reduce development and maintenance costs.

[0005] To achieve the above objectives, this application adopts the following technical solution: Firstly, a method for processing personnel documents is provided, including: In response to the received request information from the heterogeneous data source, the request information from the heterogeneous data source is converted into a standard query instruction; Batch queries are executed based on the standard query instructions to obtain target personnel data, and the target personnel data is automatically populated back into the pending documents; In response to the approval activation instruction of the pending document, obtain the document activation data; Based on preset data assembly rules, the effective data of the document is assembled, and the assembled data is written into the personnel master data model within a single transaction.

[0006] Secondly, a personnel document processing device is provided, comprising: The determination module is used to determine the corresponding target query task based on the natural language text currently entered by the user in response to the received query command. The decomposition module is used to analyze and break down the target query task to obtain multiple atomized subtasks; The matching module is used to match the plurality of atomized subtasks with each intelligent agent, so that each atomized subtask is matched with the corresponding target intelligent agent; An execution module is used to execute the corresponding atomized subtask for each target agent to obtain an execution result; The response module is used to generate natural language response text based on the execution results of each step.

[0007] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the personnel document processing method as described in any one of the first aspects above.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the personnel document processing method as described in any one of the first aspects above.

[0009] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the personnel document processing method described in any of the first aspects above.

[0010] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0011] The embodiments of this application have the following beneficial effects: First, in response to received requests from heterogeneous data sources, the requests are converted into standard query instructions. A batch query is then executed based on these instructions to retrieve target personnel data, which is automatically populated into pending documents. In response to approval instructions for these pending documents, the approved data is retrieved. Based on pre-defined data assembly rules, the approved data is assembled and written into the personnel master data model within a single transaction. This achieves automated loading and population of personnel information. Optimizing multiple, scattered database requests into a single batch query significantly reduces database load. The pre-defined data assembly and writing mechanism transforms error-prone manual coding into an automated standard process, ensuring accurate execution of business rules.

[0012] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0013] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiments below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating a personnel document processing method provided in an embodiment of this application; Figure 2 This is a structural block diagram of the personnel document processing device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0014] The embodiments of the technical solutions of this application will now be described in detail with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of this application, and are therefore merely examples and should not be used to limit the scope of protection of this application. When the following description relates to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. Various changes, modifications, and equivalents of the methods, apparatus, and / or systems described herein will become apparent upon understanding this disclosure. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but can be changed as will become apparent upon understanding this disclosure, except for operations that must be performed in a specific order. Furthermore, for clarity and conciseness, descriptions of features known in the art may be omitted.

[0015] The embodiments described in the following examples of this disclosure are not representative of all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0016] It should be noted that the executing entity of the personnel document processing method in this embodiment can be a personnel document processing device, hereinafter referred to as "device". The device can be configured in any type of electronic device, and this application embodiment does not limit it.

[0017] See Figure 1This is a flowchart illustrating the personnel document processing method provided in the first embodiment of this application. Figure 2 As shown, the personnel document processing method may include the following steps: Step 101: In response to the received request information from the heterogeneous data source, convert the request information from the heterogeneous data source into a standard query command.

[0018] Heterogeneous data sources refer to personnel information input channels with different origins and formats, including three core types: interactive, interface, and file-based. The system achieves unified adaptation through a multi-source adapter. Optionally, interactive data sources (such as front-end forms) are used for real-time user input; interface data sources (such as OpenAPI) are used for cross-system data synchronization; and file-based data sources (such as Excel) are used for large-scale data import.

[0019] Optionally, the heterogeneous data sources supported by the system may include three core types and extended types: Interactive data sources: These refer to user-initiated data through the system's front-end interface, such as data submitted by filling out web forms or APP forms. The characteristics of this type of data source are strong real-time performance and relatively standardized data format. Interface-based data sources: These refer to data from third-party systems accessed through interfaces such as OpenAPI, such as personnel-related data synchronized from attendance systems and recruitment systems. This type of data source supports cross-system data exchange. File-based data sources refer to data obtained through file import, such as batch personnel information files in Excel format, which are suitable for large-scale data processing scenarios.

[0020] Specifically, it first receives request information from heterogeneous data sources (such as front-end forms, API interfaces, and Excel files), and then uses a built-in adaptation mechanism to convert requests of different formats into standard query commands that are unified by the system.

[0021] Furthermore, for front-end form data sources, the adapter parses the JSON data submitted by the form and extracts key request parameters; for API interface data sources, the adapter connects to the interface specifications of third-party systems, performing parameter format conversion and data decryption; for file-based data sources, the adapter supports parsing Excel, CSV, and other file formats, extracting personnel identifiers and request information from the tables. Through the above adaptation logic, request information from various heterogeneous data sources is uniformly converted into standard query commands that the system can recognize.

[0022] Step 102: Execute a batch query based on standard query instructions to obtain target personnel data, and automatically populate the target personnel data back into the pending documents.

[0023] Target personnel data refers to comprehensive personnel information related to the pending documents, retrieved from the personnel master data model based on business type requirements. This includes basic information, related business information, and secondary extended information. Specifically, the personnel data that the system can load covers all dimensions of information required for human resources operations, including at least: Basic personnel information: core identity information such as name, ID number, contact information, and date of birth; Work experience: Current position, length of service, job level, reporting line, and other relevant job information; Employment information: Employment type, employment contract term, start date, salary grade, and other employment-related information; Organizational allocation information: Department, department code, organizational structure level, work location, and other organization-related information; Secondary development can extend personnel-related information such as educational background, professional qualifications, and award and punishment records, which can be customized according to business needs.

[0024] Optionally, after obtaining the target personnel data, the target personnel data can be checked for field integrity, data format, and consistency of association. Then, the target personnel data that passes the checks can be automatically backfilled into the documents to be processed according to the document field mapping relationship.

[0025] Specifically, after obtaining the target personnel data, the data can be verified three times.

[0026] Field integrity validation is used to check whether required fields (such as personnel ID, name, and department) are missing in the set of personnel information fields to be filled back. For example, it checks whether the "date of employment" field is empty.

[0027] Data format validation is used to verify whether the data in each field conforms to the system specifications. For example, ID numbers must be 18 digits long, date fields must conform to the "yyyy-MM-dd" format, and numeric fields must be within the preset range.

[0028] Consistency checks on relationships are used to verify whether the logical relationships between fields are reasonable. For example, "employment contract expiration date" must not be earlier than "employment date", and "department" must have a valid record in the organizational structure table.

[0029] For data that passes verification, the device automatically backfills personnel data into the corresponding fields of the document to be processed based on the document field mapping relationship (which is pre-set in the template processing rules): for single-value fields (such as name), it directly fills into the corresponding input box; for multi-value fields (such as multiple educational experiences, multiple professional qualifications), it dynamically generates the corresponding number of records in the document's entry area and backfills the data one by one; after the backfilling is completed, the system automatically refreshes the document interface to display the backfilling results, and users can directly view or supplement non-core field information. For data that fails verification, the backfilling unit automatically records an exception log (including the exception field, personnel ID, and error type) and returns a friendly prompt to the user (such as "Personnel XXX's 'Labor Contract Term' format is incorrect, please check and try again"), while also supporting user-triggered reloading operations.

[0030] As one possible approach, the specific steps for performing batch queries based on standard query commands to obtain target personnel data may include: The system determines the target personnel document template corresponding to the business type selected by the user. The target personnel document template corresponds to the target business category identifier. The system loads and activates the target processing rule corresponding to the target business type identifier. The system determines the target field loading rule bound to the target business category identifier from the target processing rule. Then, based on the target field loading rule, the system automatically identifies and determines the set of personnel information fields to be loaded. Finally, based on the standard query command and the set of personnel information fields to be loaded, the system retrieves the target personnel data from the personnel master data model.

[0031] Among them, personnel document templates refer to standardized form configuration templates pre-built by the system for specific personnel business scenarios. They include core configurations such as business-specific field layouts, processing rules, and data mapping relationships. Each type of template is bound to a unique business type identifier, which is not specified here. Each type of personnel document template corresponds to a unique business type identifier and predefined processing rules.

[0032] Optionally, the system can pre-configure six types of core HR business templates, including: Onboarding templates: Suitable for new employee onboarding registration and information entry. Transfer templates: Suitable for employee department transfers and job transfers; Resignation templates: Suitable for both voluntary and involuntary employee resignations; Templates for adding new job positions: Adapted for adding part-time or temporary positions for employees; Templates for termination of employment: Suitable for termination of part-time employment or end of temporary assignment. General templates: Adaptable to other common HR processes such as probation and salary adjustments, and support custom extensions.

[0033] The business type identifier uniquely identifies the code of a personnel document template (e.g., "ONBOARD-001" corresponds to the onboarding template), and is associated with the complete set of processing rules and configuration information of the template. It serves as the system's identifier for recognizing business types and triggering corresponding logic. This identifier allows retrieval of field loading rules and matching of business logic rules. Each template type is associated with a unique business type identifier (e.g., "ONBOARD-001" for onboarding templates and "TRANSFER-002" for transfer templates), and each template type has built-in predefined processing rules. Template storage utilizes a structured database design, supporting the addition, modification, deletion, and version management of templates, ensuring the consistency and maintainability of template configurations.

[0034] The processing rules, which can be standardized business logic configurations pre-installed in personnel document templates, are the core basis for the system's automated processing. These rules include field loading rules, file type filtering rules, and submission activation rules. It should be noted that field loading rules define the personnel information fields and their attributes that need to be loaded for this business type; file type filtering rules filter irrelevant file information based on the business scenario (e.g., filtering "transfer application" related files for resignation documents); and submission activation rules define the preconditions for document submission (e.g., required field validation passes, associated data exists) and the logic for triggering activation.

[0035] The target personnel document template is the personnel document template corresponding to the business type selected by the user, and the business category identifier corresponding to the target personnel document template is the target business category identifier. For example, when the user selects the target business type (such as resignation) on the system interface, this unit determines the corresponding resignation template (target personnel document template) through the mapping relationship between business types and templates, extracts the target business category identifier corresponding to the template, and loads and activates the target processing rules bound to the identifier (such as field loading rules and file filtering rules specific to resignation business) through the interface of the template preset module.

[0036] Furthermore, the target field loading rules bound to the target business category identifier can be determined from the target processing rules (e.g., the "reason for leaving", "date of leaving", "employment contract number" and other fields need to be loaded for resignation-related businesses). Based on the target field loading rules, the set of personnel information fields to be loaded can be automatically identified and determined, and the relationship between fields can be parsed (e.g., the relationship between "employment contract number" and "employment information").

[0037] By combining the personnel information field set, batch query plans can be constructed. For example, when processing the resignation documents of 100 employees simultaneously, this unit integrates the query conditions for all 100 employees into a single batch query statement, performing a one-time database interaction instead of querying each employee individually. This significantly reduces database I / O operations and efficiently obtains the complete target personnel dataset from the personnel master data model (which includes related tables such as personnel basic information table, work experience table, and employment information table).

[0038] Step 103: In response to the approval activation instruction of the pending document, obtain the document activation data.

[0039] It should be noted that when the pending document completes the entire approval process (such as department head approval → HR approval → final approval), the document status changes to "approval effective". The device can then receive the approval effective instruction for the pending document, obtain the document's effective data, and then initiate subsequent steps to perform structured assembly of the document's effective data (such as field mapping, relational processing, and default value filling). Finally, within a single database transaction, the assembled structured data is written in batches into the personnel master data model, ensuring the atomicity of the data write.

[0040] Step 104: Based on the preset data assembly rules, perform data assembly on the effective data of the document, and write the assembled data into the personnel master data model within a single transaction.

[0041] The pre-defined data assembly rules refer to the data processing rule system pre-set in the template, including four categories: field mapping rules, business logic rules, transaction control rules, and extended rules, which guide the data assembly and writing process. Field mapping rules define the field correspondence between documents and master data; business logic rules define the data change logic; transaction control rules ensure the atomicity of writes; and extended rules support custom configuration.

[0042] Optionally, based on the change rules corresponding to the target business type identifier and the key identifiers in the document effective data, the change type corresponding to each information group can be determined. Then, based on the preset data assembly rules and the change type corresponding to each information group, the document effective data can be assembled into structured data that meets the requirements of the personnel master data model.

[0043] The types of changes include at least addition, update, and termination, and the key identifiers include personnel ID, original associated data ID, differences in fields before and after the change, and business scenario identifier.

[0044] It should be noted that before data assembly, two input data are required: the key identifier in the document's effective data and the change rule corresponding to the target business type identifier. Specifically, the document's effective data is first split according to information group dimensions (personnel basic information group, employment information group, organization allocation information group, secondary extended entry information group, etc.); then, for each information group, the change type (addition, update, termination) is determined one by one, combining the change rule and the key identifier.

[0045] The specific application scenarios for key identifiers are as follows: Personnel ID: As a core unique identifier, it is used to associate historical data in the personnel master data model, such as querying the employee's historical employment information by personnel ID; Original associated data ID: Used to locate historical records that need to be updated or terminated, such as locating old employment records that need to be terminated by the original employment experience ID; Differences in fields before and after changes: By comparing the field values ​​of the effective data in the document with the historical data, it can be determined whether there have been changes; Business scenario identifier: Used to distinguish special business scenarios. For example, the "whether it is the first time to join" identifier is used to determine the type of change in employment information (first time joining is "new", second time joining is "updated").

[0046] Below is an example of determining the type of change: For onboarding transactions: the key identifiers for the personnel basic information group, employment information group, and organization allocation information group are displayed as "first entry". Based on the change rules, the change type is determined to be "new". For transfer-related business: There are discrepancies in the "Department" field of the organization's allocation information group. The original associated data ID is valid. Based on the change rules, the change type is determined to be "update". For resignation-related transactions: The "Resignation Date" in the Employment Information group has been filled in. Based on the change rules, the change type is determined to be "Termination".

[0047] Furthermore, based on the field mapping rules in the preset data assembly rules, the effective data of the document can be assembled into structured data that meets the requirements of the personnel master data model. The preset data assembly rules also include business logic rules, transaction control rules, and extension rules.

[0048] The specific details of the pre-defined data assembly rules are as follows: Field mapping rules can predefine the correspondence between document fields and personnel master data model fields, supporting one-to-one mapping (e.g., document "Name" corresponds to master data "person_name") and one-to-many mapping (e.g., document "Department Information" corresponds to master data "dept_id", "dept_name", and "dept_level"). Business logic rules are used to encapsulate the business logic of data processing, such as automatically filling default values ​​(e.g., "Data Status" defaults to "Valid"), generating data version numbers, and handling related dependencies. Transaction control rules are used to define the transaction isolation level for data writing, the writing order (e.g., writing basic personnel information first, then writing related employment information), and exception handling strategies (e.g., triggering rollback when writing fails). Extended rules can support custom configuration through the developer platform to intervene in the way information groups change, such as customizing the effective time rules for work experience for employees in special positions.

[0049] Specifically, the data assembly process can be as follows: based on the change type (add / update / termination), call the corresponding field mapping rules to convert the field values ​​in the effective data of the document into the field format of the master data model, execute business logic rules, complete default value filling, version number generation, and dependency processing, and finally output structured data (such as JSON format, database table row data).

[0050] Optionally, the device may include a secondary development extended entry assembly subunit. This subunit performs structured assembly processing (adding, updating, or deleting) on ​​the personnel-related entry information from the secondary development extension. The personnel-related entry information from the secondary development extension includes at least the educational background, occupational information, job assignments, and work experience of the personnel involved. For different types of extended entry information, independent parallel tasks can be initiated for synchronous assembly, improving processing efficiency. Its processing logic is designed separately for the three change types: "add," "update," and "delete." Add new operation: Generate a new journal entry information object, assign values ​​according to the template preset rules (such as the default value of "education experience"), map the corresponding fields in the document (such as "graduating institution", "major", "graduation time"), and generate structured data; Update operation: Query historical entry information in master data by key identifiers (such as personnel ID + education experience ID), compare the field differences of the effective data of the document, overwrite the corresponding fields with the new data, generate updated structured data, and record the differences before and after the change; Deletion operation: Locate historical entry information through key identifiers, mark "deletion identifier" as "yes", record the deletion time (document effective time), and generate structured data containing deletion markers.

[0051] The above method can yield a structured data set of various extended entry information. Each data object contains a unique identifier (such as education experience ID, work experience ID), an association identifier (such as personnel ID, job assignment ID), and complete field values, ensuring consistency with the personnel master data model.

[0052] Furthermore, database transactions can be initiated, and personnel data writing interfaces can be called to write structured data in batches. Anomalies can be monitored during the transaction execution, and transaction rollback can be triggered when a write failure occurs.

[0053] As one possible approach, the secondary development extended entry assembly subunit can execute the following sequence when assembling structured data: 1. Assemble basic personnel information, automatically fill in default field values, generate unique data version numbers, and verify field dependencies. 2. Assemble employment information and organizational assignment information, associating and binding the unique identifiers of the personnel's basic information. 3. The secondary development extended entry assembly subunit assembles the secondary development extended entry information in parallel. The extended entry information includes at least educational background, occupational information, job assignment, and work experience.

[0054] Among them, the parallel assembly education experience of the two-open extended journal entry assembly sub-unit includes: New scenario: Generate new education experience objects and assign values ​​according to the template's preset rules; map fields such as graduation institution, major, and degree in the document to generate JSON information of the changes; and associate the record with the work assignment ID. Update scenario: Query the education experience data before the change based on "Personnel ID + Education Experience ID", generate a JSON snapshot of the information before the change, overwrite the corresponding fields with the new data in the document to generate a JSON snapshot of the information after the change, and record the comparison information of the field differences; Deletion scenario: Query the educational experience data before the change to generate the information JSON before the change, mark the deletion as "yes", record the deletion time as the document approval effective time, and synchronously associate the work assignment ID.

[0055] Optionally, when assembling the second-open extended entry assembly subunit in parallel, the following applies: New scenario: Generate a new job experience object, generate a unique job sequence number according to the rule of "department ID + serial number", map the job name, job start time (default is the document approval effective time) and other fields in the document, generate the changed information JSON and comparison information, and associate the record with the job assignment ID; Update scenario: Query the original job experience data based on the job assignment ID and job number before the change, generate the information JSON before the change, update the end time of the original job experience to the document approval effective time, and generate the new job experience record simultaneously (execute the new scenario process) and mark it as "currently valid". Termination scenario: Query the original employment experience data to generate the JSON information before the change, update the end time to the document approval effective time, change the status to "terminated", and record the termination reason (taken from the document change reason field).

[0056] Optionally, when assembling occupational information in parallel using the two-open extended entry assembly subunit, it includes: New scenario: Generate a new occupational information object and assign values ​​according to the template. If the employee ID after the change is empty in the document, the employee ID before the change will be used. Map specific fields such as occupational qualification and acquisition time to generate JSON information after the change. Record the data ID and the information after the change. Set the job assignment ID to empty. Update scenario: Query the original occupation information based on the employee ID before the change, generate the JSON information before the change, update the end time of the original occupation information to the document approval effective time, map the new data of the document to generate the JSON information after the change and comparison information, and set the job assignment ID to empty.

[0057] Optionally, when allocating work assignment information for the parallel assembly of the two-way extended entry assembly subunit, it includes: New scenario: Generate a new job assignment object and assign values ​​according to the template. If the employee ID is empty after the change, the employee ID before the change will be used. Map the relevant fields such as the assigned department and assigned position to generate the JSON information after the change, and record the data ID and job assignment ID. Update scenario: Query the work assignment object before the change based on "personnel ID + original assignment identifier", generate the information JSON before the change and record the data ID, map the new data of the document to generate the information JSON after the change and comparison information, and associate the record with the work assignment ID.

[0058] Optionally, the device may include a transaction execution unit, which, when performing data writing, specifically includes: Initiate an independent database transaction with repeatable read isolation level, prioritizing personnel basic information → employment information → organization allocation information → extended entry information, and call the personnel data write interface to batch write structured data. During transaction execution, monitor the database return status in real time. If an exception such as primary key conflict, excessive field length, or network interruption causes write failure, immediately trigger transaction rollback and undo all executed write operations. After all data is successfully written, commit the transaction and asynchronously trigger post-processing such as index update and data change notification sending.

[0059] Optionally, the transaction execution unit is also used to record transaction execution logs, which include transaction ID, data snapshot, execution time, success / failure status, and error code (if failure). The data snapshot contains complete JSON data before and after various information is assembled, as well as field difference comparison information, supporting data traceability and auditing.

[0060] Optionally, the device can record the execution log of the data assembly and writing process in real time. The execution log includes a snapshot of the data to be written after assembly, the triggered business rules, and operation context information. In response to the detection of data writing failure or transaction interruption, it can automatically initiate a retry based on the execution log stored in the log recording unit.

[0061] Specifically, the entire process, from data assembly to data writing completion, is recorded in real time. The execution log is stored in a structured format and includes at least a snapshot of the assembled data to be written, the triggered business rule ID and execution result, and operation context information (business type identifier, document number, approval effective time, operator ID, transaction ID, and execution time).

[0062] It should be noted that log data can be stored in an independent log database, supporting retrieval by time range, document number, personnel ID, execution status, and other dimensions. Furthermore, log data supports long-term archiving, meeting audit and compliance requirements.

[0063] Understandably, this device can monitor the execution results of the transaction execution unit in real time. When it detects a data write failure (such as database connection interruption or primary key conflict) or a transaction interruption (such as system restart), it automatically triggers a retry process. Based on the execution log stored in the log recording unit, it directly reuses the assembled structured data snapshot, business rule information, and operation context without re-executing the data assembly process, ensuring the accuracy of the retry.

[0064] Optionally, in the event of a data write failure, the device can perform an anomaly analysis on the execution log, generate an anomaly analysis report, and trigger subsequent business processes after the data write is successful. These subsequent business processes include sending notification messages and updating the retrieval index.

[0065] It should be noted that when data writing fails and the retry mechanism fails after execution, anomaly analysis is automatically initiated. The failure logs in the log recording unit are extracted, classified by anomaly type (data format error, primary key conflict, database connection error, business rule conflict, network interruption, etc.), and the specific stage in which the anomaly occurred (data assembly stage, writing stage).

[0066] The embodiments of this application have the following beneficial effects: First, in response to received requests from heterogeneous data sources, the requests are converted into standard query instructions. A batch query is then executed based on these instructions to retrieve target personnel data, which is automatically populated into pending documents. In response to approval instructions for these pending documents, the approved data is retrieved. Based on pre-defined data assembly rules, the approved data is assembled and written into the personnel master data model within a single transaction. This achieves automated loading and population of personnel information. Optimizing multiple, scattered database requests into a single batch query significantly reduces database load. The pre-defined data assembly and writing mechanism transforms error-prone manual coding into an automated standard process, ensuring accurate execution of business rules.

[0067] Corresponding to the personnel document processing method described in the above embodiments, Figure 2 This is a structural block diagram of the personnel document processing device 200 provided in the embodiments of this application.

[0068] The conversion module 210 is used to convert the request information from the heterogeneous data source into a standard query instruction in response to the received request information from the heterogeneous data source. The first acquisition module 220 is used to perform batch queries based on the standard query instructions to obtain target personnel data and automatically populate the target personnel data back into the pending documents. The second acquisition module 230 is used to acquire document effective data in response to the approval effective instruction of the document to be processed; Assembly module 240 is used to assemble the effective data of the document based on preset data assembly rules, and write the assembled data into the personnel master data model within a single transaction.

[0069] Optionally, the first acquisition module 220 is specifically used for: Determine the target personnel document template corresponding to the business type selected by the user, wherein the target personnel document template corresponds to the target business category identifier; Load and activate the target processing rule corresponding to the target business type identifier; Determine the target field loading rule bound to the target business category identifier from the target processing rule; Based on the target field loading rules, the set of personnel information fields to be loaded is automatically identified and determined; Based on the standard query command and the set of personnel information fields to be loaded, the target personnel data is obtained from the personnel master data model.

[0070] Optionally, the device further includes an execution unit for: If the document's effective data includes personnel-related entry information from secondary development and expansion, perform structured assembly processing to add, update, or delete entries. The personnel-related entry information from secondary development and expansion shall at least include the personnel's educational background, occupational information, work assignments, and work experience.

[0071] Optionally, the device further includes an execution unit for: The startup unit is used to initiate a database transaction, call the personnel data writing interface to write the structured data in batches, and monitor for anomalies during the transaction execution; if a write failure is detected, the transaction is rolled back.

[0072] Optional, assembly module 240, specifically used for: The execution log records the data assembly and writing process in real time. The execution log includes a snapshot of the data to be written after assembly, the triggered business rules, and the operation context information. In response to the detection of data write failure or transaction interruption, a retry is automatically initiated based on the execution log stored in the log recording unit; If a data write failure is detected, the execution log is analyzed to identify the cause of the failure and an anomaly analysis report is generated. After the data is successfully written, subsequent business processes are triggered, including sending notification messages and updating the search index.

[0073] The embodiments of this application have the following beneficial effects: First, in response to received requests from heterogeneous data sources, the requests are converted into standard query instructions. A batch query is then executed based on these instructions to retrieve target personnel data, which is automatically populated into pending documents. In response to approval instructions for these pending documents, the approved data is retrieved. Based on pre-defined data assembly rules, the approved data is assembled and written into the personnel master data model within a single transaction. This achieves automated loading and population of personnel information. Optimizing multiple, scattered database requests into a single batch query significantly reduces database load. The pre-defined data assembly and writing mechanism transforms error-prone manual coding into an automated standard process, ensuring accurate execution of business rules.

[0074] in addition, Figure 2 The personnel document processing device shown can be a software unit, hardware unit, or a combination of software and hardware built into existing electronic devices, or it can be integrated into the electronic devices as an independent component, or it can exist as an independent electronic device.

[0075] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0076] Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 5 of this embodiment includes: at least one processor 50 ( Figure 3 (Only one is shown in the diagram) a processor, a memory 51, and a computer program 52 stored in the memory 51 and executable on the at least one processor 50, wherein the processor 50 executes the computer program 52 to implement the steps in any of the above-described embodiments of the personnel document processing methods.

[0077] The electronic device may be a desktop computer, laptop, handheld computer, or cloud server, etc. This electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 5 and does not constitute a limitation on electronic device 5. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0078] The processor 50 may be a central processing unit, or it may be other general-purpose processors, digital signal processors, application-specific integrated circuits, off-the-shelf programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0079] In some embodiments, the memory 51 may be an internal storage unit of the electronic device 5, such as a hard disk or memory of the electronic device 5. In other embodiments, the memory 51 may be an external storage device of the electronic device 5, such as a plug-in hard disk, smart memory card, secure digital card, flash memory card, etc., equipped on the electronic device 5. Further, the memory 51 may include both internal storage units and external storage devices of the electronic device 5. The memory 51 is used to store operating systems, applications, boot loaders, data, and other programs, such as the program code of the computer program. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0080] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the above-described method embodiments.

[0081] This application provides a computer program product that, when run on an electronic device, enables the electronic device to implement the steps described in the various method embodiments above.

[0082] If the integrated unit is implemented as a software functional unit and used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0083] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0085] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0086] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0087] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0088] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0089] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0090] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0091] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0092] In the description of the embodiments of this application, the technical terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the embodiments of this application and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0093] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0094] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for processing personnel documents, characterized in that, include: In response to the received request information from the heterogeneous data source, the request information from the heterogeneous data source is converted into a standard query instruction; Batch queries are executed based on the standard query instructions to obtain target personnel data, and the target personnel data is automatically populated back into the pending documents; In response to the approval activation instruction of the pending document, obtain the document activation data; Based on preset data assembly rules, the effective data of the document is assembled, and the assembled data is written into the personnel master data model within a single transaction.

2. The method according to claim 1, characterized in that, The step of performing batch queries based on the standard query instructions to obtain target personnel data includes: Determine the target personnel document template corresponding to the business type selected by the user, wherein the target personnel document template corresponds to the target business category identifier; Load and activate the target processing rule corresponding to the target business type identifier; Determine the target field loading rule bound to the target business category identifier from the target processing rule; Based on the target field loading rules, the set of personnel information fields to be loaded is automatically identified and determined; Based on the standard query command and the set of personnel information fields to be loaded, the target personnel data is obtained from the personnel master data model.

3. The method according to claim 1, characterized in that, The data assembly of the effective data of the document based on the preset data assembly rules includes: Based on the change rules corresponding to the target business type identifier and the key identifiers in the document effective data, determine the change type corresponding to each information group; Based on the preset data assembly rules and the change types corresponding to each information group, the effective data of the document is assembled into structured data that meets the requirements of the personnel master data model.

4. The method according to claim 1, characterized in that, Also includes: If the document's effective data includes personnel-related entry information from secondary development and expansion, perform structured assembly processing to add, update, or delete entries. The personnel-related entry information from secondary development and expansion shall at least include the personnel's educational background, occupational information, work assignments, and work experience.

5. The method according to claim 1, characterized in that, Also includes: Initiate a database transaction, call the personnel data write interface to write the structured data in batches, and monitor for anomalies during the transaction execution process; If a write failure is detected, a transaction rollback is triggered.

6. The method according to claim 1, characterized in that, The process of assembling the effective data of the aforementioned document also includes: The execution log records the data assembly and writing process in real time. The execution log includes a snapshot of the data to be written after assembly, the triggered business rules, and the operation context information. In response to the detection of data write failure or transaction interruption, a retry is automatically initiated based on the execution log stored in the log recording unit; If a data write failure is detected, the execution log is analyzed to identify the cause of the failure and an anomaly analysis report is generated. After the data is successfully written, subsequent business processes are triggered, including sending notification messages and updating the search index.

7. A personnel document processing method and apparatus, characterized in that, include: The conversion module is used to convert the request information from the heterogeneous data source into a standard query instruction in response to the received request information from the heterogeneous data source. The first acquisition module is used to perform batch queries based on the standard query instructions to obtain target personnel data and automatically populate the target personnel data back into the pending documents. The second acquisition module is used to acquire document activation data in response to the approval activation instruction of the document to be processed; The assembly module is used to assemble the effective data of the document based on preset data assembly rules, and write the assembled data into the personnel master data model within a single transaction.

8. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which is loaded by a processor to perform the steps of the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the steps of the method according to any one of claims 1 to 6.

Images