Data checking method and device, computer equipment and storage medium

Abstract

The invention belongs to the technical field of data processing, and relates to a data checking method and device, computer equipment and a storage medium, and the method comprises the steps: querying certificate line data in a to-be-checked state from a head line relation table if a triggered data checking task is received; if the number of the voucher line data is multiple, carrying out fragmentation processing on the voucher line data based on a fragmentation rule to obtain voucher header fragmentation data; based on a multi-thread parallel checking strategy, checking the voucher header fragmented data to obtain a first checking result; performing item-by-item comparison processing of key fields on the voucher header fragmented data based on a voucher row-level checking strategy to obtain a second checking result; and generating a target check result corresponding to the voucher line data based on the first check result and the second check result. In addition, the target checking result can be stored in the block chain. The data checking method and device can be applied to data checking scenes in the financial science and technology field and the digital medical field, and the processing efficiency and processing accuracy of data checking are improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology and can be applied to fields such as fintech and digital healthcare, particularly to data verification methods, devices, computer equipment, and storage media. Background Technology

[0002] In traditional enterprise-level financial systems, the general ledger system serves as the core hub of the financial system, undertaking key functions such as processing accounting vouchers, generating ledgers, preparing financial statements, and reconciling accounts. With increasing corporate governance requirements, the traditional "single-dimensional" accounting model is insufficient to meet the dual demands of refined management and regulatory compliance. Therefore, modern financial systems adopt a "separation of management and legality" architecture, simultaneously generating dual-dimensional vouchers (management and accounting dimensions) for the same business event, enabling multi-perspective presentation and differentiated application of business data.

[0003] However, most current systems face pain points such as "difficulty in reconciliation, difficulty in tracing the source, and slow error correction" during the implementation of the separation of management and accounting. Due to the lack of a unified business transaction identifier, although management and accounting data exist in parallel, it is difficult to establish a strong correlation. This leads to the system relying on a "coarse-to-fine" manual reconciliation method, gradually delving from the subject summary level down to the voucher details, which is inefficient and inaccurate. For example, in the financial insurance sector, when an insurance company uses a traditional financial system for premium accounting, the management dimension counts premium income by business channel, while the accounting dimension records it by accounting subject. Due to the lack of a unified identifier, manual verification is required for each transaction at the end of the month, which is time-consuming and prone to errors. Similarly, in the medical field, a hospital uses a traditional financial system for revenue and expenditure management. The management dimension counts revenue and expenditure by department, while the accounting dimension processes it by accounting subject. Again, due to the lack of a unified identifier, financial personnel find it difficult to quickly and accurately obtain relevant data when conducting departmental revenue and expenditure analysis, affecting the efficiency of financial management and the scientific nature of decision-making. Therefore, there is an urgent need to provide an improved general ledger system to solve the above problems and improve the efficiency and accuracy of financial management. Summary of the Invention

[0004] The purpose of this application is to provide a data verification method, apparatus, computer equipment, and storage medium to solve the technical problems of low processing efficiency and low accuracy in existing data verification methods based on manual reconciliation.

[0005] Firstly, a data verification method is provided, including: Determine whether a triggered data verification task has been received; If so, retrieve the voucher row data that is in the pending inspection state from the preset header row relationship table; If there are multiple voucher line data, the voucher line data is segmented based on a preset segmentation rule to obtain the corresponding voucher header segment data. The voucher header fragment data is verified based on a preset multi-threaded parallel verification strategy to obtain the corresponding first verification result. Based on the preset voucher row-level verification strategy, the key fields of the voucher header fragment data are compared item by item to obtain the corresponding second verification result. Based on the first verification result and the second verification result, a target verification result corresponding to the voucher line data is generated.

[0006] Secondly, a data verification device is provided, comprising: The judgment module is used to determine whether a triggered data verification task has been received; The first query module is used to retrieve the voucher row data that is in the pending inspection state from the preset head row relationship table if the condition is met. The sharding module is used to shard the voucher line data based on a preset sharding rule if there are multiple voucher line data, and obtain the corresponding voucher header shard data. The first verification module is used to perform verification processing on the voucher header fragment data based on a preset multi-threaded parallel verification strategy to obtain the corresponding first verification result. The second verification module is used to perform item-by-item comparison of key fields of the voucher header fragment data based on a preset voucher row-level verification strategy to obtain the corresponding second verification result. The generation module is used to generate a target verification result corresponding to the voucher line data based on the first verification result and the second verification result.

[0007] Thirdly, a computer device is provided, 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 steps of the above-described data verification method.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described data verification method.

[0009] In the above-mentioned data verification method, apparatus, computer equipment, and storage medium, the solution first determines whether a triggered data verification task has been received; if so, it queries the voucher row data in the pending inspection state from a preset header row relationship table; if there are multiple voucher row data, it performs segmentation processing on the voucher row data based on preset segmentation rules to obtain corresponding voucher header segment data; then, it performs verification processing on the voucher header segment data based on a preset multi-threaded parallel verification strategy to obtain the corresponding first verification result; subsequently, it performs item-by-item comparison processing of key fields on the voucher header segment data based on a preset voucher row-level verification strategy to obtain the corresponding second verification result; finally, it generates a target verification result corresponding to the voucher row data based on the first verification result and the second verification result. Thus, unlike the existing manual data verification process, this application, upon receiving a triggered data verification task, intelligently filters out the voucher row data in the pending inspection state from the head row relationship table. When multiple voucher row data are detected, it automatically and accurately performs data verification processing corresponding to the voucher row data based on a combination of sharding rules, multi-threaded parallel verification strategies, and voucher row-level verification strategies. This effectively improves the processing efficiency of data verification and ensures the accuracy of the target verification results. Attached Figure Description

[0010] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 This is a flowchart of an embodiment of the data verification method according to this application; Figure 3 This is a schematic diagram of one embodiment of the data verification device according to this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0012] 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 in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0013] 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.

[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0015] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0016] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0017] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, and a desktop computer, etc.

[0018] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0019] It should be noted that the data verification method provided in this application embodiment is generally executed by a server / terminal device, and correspondingly, the data verification device is generally set in the server / terminal device.

[0020] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0021] Continue to refer to Figure 2 A flowchart illustrating an embodiment of the data verification method according to this application is shown. The order of steps in the flowchart can be changed, and some steps can be omitted, depending on different needs. The data verification method provided in this application embodiment can be applied to any scenario requiring data verification, and thus can be applied to products in these scenarios, such as data verification products in the financial insurance field or the digital healthcare field. The data verification method includes the following steps: Step S201: Determine whether a triggered data verification task has been received.

[0022] In this embodiment, the data verification method operates on an electronic device (e.g., Figure 1The server / terminal device shown can acquire data verification tasks via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future wireless connection methods. The executing entity of this application is specifically a data verification system, which can be simply referred to as the system. The triggering modes for the data verification task may include: Automatic timed triggering: The system administrator presets the trigger time for the verification task in the system according to the company's financial management needs and business characteristics, such as a fixed time every evening, a specific date every week, or the end of each month. When the preset time is reached, the system automatically starts the verification task without manual intervention, ensuring that the system can perform data verification according to a regular schedule and maintain the consistency of system data. Manual submission: In special circumstances, such as major business adjustments or system upgrades, when financial personnel deem immediate verification necessary, they can manually submit the verification task through the system's provided interface. The manual submission method balances management flexibility and can meet the verification needs of the company in different scenarios.

[0023] Furthermore, this application can be applied to task verification scenarios in the fintech and digital healthcare fields. For example, in the fintech field, the aforementioned data verification task could be a daily premium income and fund arrival verification task. The corresponding task information includes: Business background: In the financial insurance industry, insurance companies receive a large number of premium payments from customers every day. These payments enter the company's cash account through various channels (such as bank deductions, online payment platforms, offline counters, etc.). To ensure accurate recording of premium income and secure fund management, it is necessary to regularly verify premium income data against actual fund arrival. Preset trigger time: The system administrator can preset this verification task to be automatically triggered at 10 PM every day. This time is chosen because most business operations have ended by then, and the bank's daily settlement is basically complete, allowing for relatively accurate fund arrival data. At the same time, the system load is relatively low at night, and data verification will not affect normal business operations. Verification process: The system automatically extracts all premium income records for the day from the insurance business system, including policy numbers, policyholder information, and premium amounts; simultaneously, it retrieves the day's fund arrival details from the bank interface or fund management system. Then, it compares each premium income record with the fund arrival information to check if the premiums have been accurately received and if the amounts match. If discrepancies are found, the system records the details, such as the policy numbers that haven't been received and the amount differences, and promptly notifies the relevant finance personnel for processing.

[0024] In the field of digital healthcare, the aforementioned data verification task can be a daily medical expense settlement and medical insurance reimbursement verification task. The corresponding task information includes: Business Background: In a digital healthcare environment, patients incur various medical expenses after visiting a hospital, some of which can be reimbursed through medical insurance. Hospitals need to settle expenses with the medical insurance department to ensure accurate collection of medical expenses and correct execution of medical insurance reimbursement. To promptly identify and resolve issues in the expense settlement and reimbursement process, daily verification of medical expense settlement data and medical insurance reimbursement data is required. Preset Trigger Time: System administrators can preset this verification task to be automatically triggered at 2:00 AM every day. At 2:00 AM, basic medical services at the hospital have ceased, and the medical insurance department's system has completed its daily data updates and processing. Verification at this time yields the latest and most accurate data. Simultaneously, system usage is low during the early morning hours, ensuring no impact on normal hospital medical services. Verification Content: The system extracts the medical expense settlement information for all patients that day from the hospital's medical billing system, including patient name, department visited, expense item, and amount; and obtains detailed medical insurance reimbursement data for the day from the medical insurance interface or medical insurance settlement system. By comparing the data from both sources, the system checks whether medical expenses have been accurately settled and whether the reimbursement ratio and amount comply with regulations. If discrepancies are found, such as unreimbursed expenses or incorrect reimbursement amounts, the system will record them and notify relevant personnel in the hospital's finance and medical insurance departments for timely handling.

[0025] Step S202: If yes, retrieve the voucher row data that is in the pending inspection state from the preset head row relationship table.

[0026] In this embodiment, if a triggered data verification task is received, the pre-built header row relationship table is automatically accessed to check the status value of the "whether it has been verified" field and the voucher row data in the pending verification state are retrieved, that is, the voucher row data with the status value of "not checked" or "check failed".

[0027] The construction process of the aforementioned head row relationship table includes: Uploading raw business data: Each business unit (BU) collects and organizes various raw data generated during its business operations, such as sales contract information in sales operations and purchase order information in procurement operations. Then, through internal data transmission channels such as the corporate intranet or specific data upload interfaces, this raw business data is accurately uploaded to the general ledger system. During the upload process, the integrity and accuracy of the data must be ensured to avoid data loss or incorrect entry.

[0028] Voucher Generation and ID Assignment: After receiving the uploaded raw business data, the voucher engine of the general ledger system begins operation. Based on preset rules and templates, it analyzes and processes the raw business data, automatically generating vouchers for both the management and accounting dimensions. Management dimension vouchers focus on reflecting business management information, such as the department and project to which the business belongs; accounting dimension vouchers focus on recording financial accounting information, such as revenue, costs, and expenses. Simultaneously with voucher generation, the system assigns unique IDs to the voucher header and voucher lines. The voucher header ID identifies the entire voucher, similar to a filename; the voucher line ID distinguishes different line items within the voucher, similar to paragraph numbers in a file.

[0029] Header-line relationship table writing: The system records detailed correspondence information between generated management dimension and accounting dimension vouchers in a dedicated "Header-line Relationship Table." This includes the association between voucher header ID and voucher line ID, and the business correspondence between management dimension vouchers and accounting dimension vouchers. For example, if a sales transaction generates a management dimension voucher header ID of "M001" and an accounting dimension voucher header ID of "N001," the Header-line Relationship Table will record the correspondence between these two, as well as their corresponding voucher line ID information, thereby establishing a bridge of association between management dimension and accounting dimension vouchers.

[0030] The uploading of original business data ensures that the general ledger system can obtain authentic business information. Voucher generation and ID allocation transform business data into standardized voucher formats and establish unique identifiers for each voucher, facilitating subsequent management and verification. Writing to the header row relationship table establishes the link between management and accounting dimension vouchers, enabling subsequent verification to accurately locate the corresponding vouchers for comparison, providing solid metadata support for automated verification.

[0031] Step S203: If there are multiple voucher line data, the voucher line data is fragmented based on a preset fragmentation rule to obtain the corresponding voucher header fragment data.

[0032] In this embodiment, if multiple voucher line data are detected, the voucher line data is intelligently segmented based on preset segmentation rules (such as voucher type, business date range, amount range, etc.) to obtain corresponding voucher header segment data. The segmented data is then grouped according to multi-threaded processing requirements, with each group containing a certain number of voucher line data, preparing data for subsequent multi-threaded parallel execution of the verification logic. Thus, intelligent segmentation and grouping processing, based on the state filtering of the "header line relationship table," achieves intelligent incremental verification, processing only unchecked or failed vouchers, avoiding redundant calculations, and improving system efficiency. Simultaneously, the segmentation and grouping provide a suitable data scale for subsequent multi-threaded parallel processing, facilitating the full utilization of the advantages of multi-threaded processing.

[0033] Step S204: Based on a preset multi-threaded parallel verification strategy, the voucher header fragment data is verified to obtain the corresponding first verification result.

[0034] In this embodiment, the specific implementation process of verifying the voucher header fragment data based on the preset multi-threaded parallel verification strategy to obtain the corresponding first verification result will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0035] Step S205: Based on the preset voucher row-level verification strategy, the key fields of the voucher header fragment data are compared item by item to obtain the corresponding second verification result.

[0036] In this embodiment, the above-mentioned voucher row-level reconciliation strategy includes the following: 1. Data preparation. Obtaining voucher row data: The system reads the row data of relevant vouchers that have completed voucher header reconciliation from the database. This data contains key field information such as accounting segment value, amount, summary, and currency, which come from the management dimension and accounting dimension, respectively. For example, for a sales transaction voucher, both the management dimension and the accounting dimension record data such as the accounting subject involved in the sale, sales amount, business summary, and currency type used. Data organization and alignment: The voucher row data of the management dimension and accounting dimension are organized and aligned according to certain rules (such as voucher number, row number, etc.) to ensure that the data of corresponding rows can be accurately compared. For example, the first row of the management dimension is matched with the first row of the accounting dimension to facilitate subsequent item-by-item comparison.

[0037] 2. Key Field Extraction. **Accounting Segment Value Extraction:** Extract the accounting segment values ​​for both the management and accounting dimensions from the organized voucher line data. The accounting segment value clearly identifies the accounting account corresponding to the voucher line, such as "Accounts Receivable - Customer A" or "Main Business Revenue - Product X." The system accurately retrieves these accounting segment value information from the relevant fields of the voucher line using specific data extraction rules. **Amount Extraction:** Similarly, extract the actual amount of the transaction from both the management and accounting dimensions. The amount is a crucial field in financial data and needs to be accurate to a specified precision (e.g., retaining two decimal places). The system checks the format and data integrity of the amount field to ensure the accuracy of the extracted amount data. **Summary Extraction:** Extract the summary information from the voucher line. The summary further details the content of the business entry. For example, "Sold Product X to Customer A, quantity 100 units, unit price 100 yuan." The system ensures that the extracted summary content is complete and does not omit key information. **Currency Extraction:** Extract the currency type involved in the transaction, such as RMB (CNY) or USD (USD). Currency information is crucial for accurately calculating business amounts. The system will check whether the value of the currency field matches the preset currency list.

[0038] 3. Item-by-Item Comparison. Accounting Segment Value Comparison: Compare the accounting segment values ​​extracted from the management dimension and the accounting dimension. The system uses exact string matching to determine if the two accounting segment values ​​are completely identical. If inconsistencies are found, it indicates a discrepancy in the records of the accounting subjects, which may affect the accuracy of financial accounting. Amount Comparison: Compare the amounts of the management dimension and the accounting dimension. The system not only compares whether the numerical values ​​are equal but also checks whether the precision of the amounts is consistent. For example, if the amount recorded in the management dimension is 100.00 yuan, while the amount recorded in the accounting dimension is 100 yuan (lacking the decimal part), it is considered an inconsistency. Summary Comparison: Compare the summary content of the management dimension and the accounting dimension. Since summaries are usually text information, the system can use text similarity algorithms (such as word frequency-based similarity calculation) for preliminary comparison, and keyword matching rules can also be set. If the key information in the summary (such as business type, transaction object, etc.) is inconsistent, the summary comparison is deemed unsuccessful. Currency comparison: The currencies of the management and accounting dimensions are compared to determine if they are the same. If the currencies are inconsistent, it indicates an error in the currency type recording, which may lead to errors in amount conversion and financial accounting.

[0039] 4. Comparison Result Judgment. Consistency Judgment: If all key fields, including accounting segment value, amount, summary, and currency, are consistent across both the management and accounting dimensions, the comparison result for this voucher line is determined to be consistent. The system will record the comparison status of this voucher line as "consistent." Inconsistency Judgment: If any key field is found to be inconsistent during the comparison process, the comparison result for this voucher line is determined to be inconsistent. The system will record the comparison status of this voucher line as "inconsistent" and record the specific inconsistent field information.

[0040] Once a discrepancy is detected during the comparison process, the system will record the discrepancy details, such as which specific field the difference occurred in; the difference value, i.e., the numerical difference between the management dimension and the accounting dimension in that field; and the source dimension, indicating whether the difference originated from the management dimension or the accounting dimension. This discrepancy information will be written to the "Verification Process Table." Simultaneously, the "Verification Final Status Result Table" will clear the previous verification result, retaining only the latest verification status, ensuring the timeliness and accuracy of the results and promptly reflecting the current verification status of the voucher line data.

[0041] Row-level reconciliation involves a more detailed examination of voucher data, uncovering details that might have been overlooked during header-level reconciliation. Item-by-item comparison of key fields ensures the accuracy of each business entry, guaranteeing consistency between management and accounting dimensions at the business level. A discrepancy recording and result update mechanism promptly identifies and records differences between voucher rows, providing detailed information for subsequent data correction and processing. By clearing the previous reconciliation result and retaining the latest status, the timeliness of the reconciliation results is ensured, enabling finance personnel to promptly understand the current data reconciliation status.

[0042] Step S206: Generate a target verification result corresponding to the voucher line data based on the first verification result and the second verification result.

[0043] In this embodiment, the specific implementation process of generating the target verification result corresponding to the voucher line data based on the first verification result and the second verification result will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0044] Based on the above automated processing flow, this application first determines whether a triggered data verification task has been received; if so, it queries the voucher row data in the pending inspection state from the preset header row relationship table; if there are multiple voucher row data, it performs voucher row data segmentation based on preset segmentation rules to obtain corresponding voucher header segment data; then, it performs verification processing on the voucher header segment data based on a preset multi-threaded parallel verification strategy to obtain the corresponding first verification result; subsequently, it performs item-by-item comparison processing of key fields on the voucher header segment data based on a preset voucher row-level verification strategy to obtain the corresponding second verification result; finally, it generates a target verification result corresponding to the voucher row data based on the first verification result and the second verification result. Thus, unlike the existing manual data verification process, this application, upon receiving a triggered data verification task, intelligently filters out the voucher row data in the pending inspection state from the head row relationship table. When multiple voucher row data are detected, it automatically and accurately performs data verification processing corresponding to the voucher row data based on a combination of sharding rules, multi-threaded parallel verification strategies, and voucher row-level verification strategies. This effectively improves the processing efficiency of data verification and ensures the accuracy of the target verification results.

[0045] In some alternative implementations, step S204 includes the following steps: The voucher header fragment data is processed by weight calculation based on a preset dynamic weight calculation strategy to obtain the corresponding weight value.

[0046] In this embodiment, the specific implementation process of performing weight calculation on the voucher header fragment data based on the preset dynamic weight calculation strategy to obtain the corresponding weight value will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0047] Call the preset thread resources.

[0048] In this embodiment, the aforementioned thread resources may include a high-performance thread pool and a regular thread pool. The high-performance thread pool consists of server nodes with a high number of physical cores and high memory bandwidth, specifically designed to handle high-weight credentials. The regular thread pool refers to the standard configured threads, which handle low-weight credentials. Additionally, a dynamic scheduling strategy can be configured to temporarily upgrade regular threads to high-performance threads based on system load monitoring (e.g., when CPU utilization is <70%).

[0049] Based on the weight value, the thread resources are used to perform thread allocation processing on the voucher header fragment data to obtain the corresponding target thread.

[0050] In this embodiment, the specific implementation process of using the thread resources to perform thread allocation processing on the voucher header fragment data based on the weight value to obtain the corresponding target thread will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0051] The target thread performs verification processing on the voucher header fragment data to obtain a specified verification result corresponding to the voucher header fragment data.

[0052] In this embodiment, the process of verifying the voucher header fragment data includes: First-round verification focusing on key fields: The system uses multi-threaded parallel execution of the verification logic, with each target thread responsible for verifying a corresponding set of voucher header data. The first-round verification mainly focuses on key fields at the voucher header level, such as summary information, which briefly describes the business content corresponding to the voucher; audit status, reflecting whether the voucher has undergone the audit process and the audit result; and posting status, indicating whether the voucher has been entered into the ledger. By comparing the consistency of management dimension vouchers and accounting dimension vouchers in these key fields, the consistency of the two dimensions of vouchers in the business process status is ensured. Result recording and traceability: During the verification process, the system records the verification results of each step in the "Verification Process Table" in real time, including the verified voucher header ID, the verified key fields, and the verification result (consistent or inconsistent). Once all voucher header fragment data has been verified, the system summarizes the results in the "Verification Process Table" to generate the "Verification Final Result Table" (or Verification Result Table), recording the overall situation of this verification task, such as the number of verified vouchers, the number of consistent vouchers, and the number of inconsistent vouchers. This process achieves complete traceability of the verification process, supporting full-process tracking and querying of the verification process and final results.

[0053] The results recording and traceability provide an important basis for subsequent problem investigation and auditing. When data inconsistencies are found, the "verification process table" and "verification final result table" can be consulted to quickly locate the link and specific voucher where the problem occurred, facilitating timely correction and processing.

[0054] Based on the above processing flow, this application obtains a preset dynamic weight calculation strategy; then, based on the dynamic weight calculation strategy, it performs weight calculation processing on the voucher header fragment data to obtain the corresponding weight value; subsequently, based on the weight value, it uses thread resources to perform thread allocation processing on the voucher header fragment data to obtain the corresponding target thread; subsequently, it performs verification processing on the voucher header fragment data based on the target thread to obtain the specified verification result corresponding to the voucher header fragment data. Thus, this application, through voucher header-level verification processing, can quickly identify differences in the business process status of two-dimensional vouchers by focusing on the verification of key fields. Multi-threaded parallel processing improves processing efficiency, enabling the verification of a large amount of voucher header data to be completed in a short time, thereby effectively improving the processing efficiency of data verification.

[0055] In some optional implementations of this embodiment, the step of performing weight calculation processing on the voucher header fragment data based on a preset dynamic weight calculation strategy to obtain the corresponding weight value includes the following steps: Information is collected from the specified voucher header fragment data based on preset weighting factors to obtain corresponding relevant information; wherein, the specified voucher header fragment data is any set of data from all the voucher header fragment data.

[0056] In this embodiment, weighting factors are predefined based on actual business needs, and may include at least: Number of fields: The total number of fields defined in the statistical voucher template (e.g., date, amount, account, etc.), with more fields resulting in higher weight. Number of associated businesses: The number of upstream and downstream business systems or modules associated with the analyzed voucher (e.g., if it involves three systems: purchasing, inventory, and finance, it is counted as 3). Number of data records: The number of data rows in the statistical voucher segment (e.g., 1000 records vs. 10 records). Historical processing time: Referencing the average processing time for the same type of voucher in the past, as a reference value for dynamic adjustment.

[0057] Furthermore, information is collected on the specified voucher header fragment data based on the defined weighted influencing factors to obtain relevant information, including the number of fields in the specified voucher header fragment data, the number of associated business transactions, the number of data records, and the historical processing time.

[0058] Obtain the weight coefficients corresponding to the weight influencing factors.

[0059] In this embodiment, the process of setting the numerical values ​​of the weight coefficients corresponding to the above-mentioned weight influencing factors includes: determining the initial value of each weight coefficient through historical data analysis (such as the coefficient for the number of fields being 0.5, the coefficient for the number of associated businesses being 1.2, etc.), and supporting subsequent adjustments based on actual operating results.

[0060] Call the preset weight calculation formula.

[0061] In this embodiment, the above weight calculation formula may specifically include: weight value = (number of fields × weight coefficient 1) + (number of related business × weight coefficient 2) + (number of data records × weight coefficient 3) + (historical processing time × weight coefficient 4).

[0062] The relevant information and the weight coefficients are calculated and processed based on the weight calculation formula to obtain the corresponding calculation results.

[0063] In this embodiment, the above-mentioned relevant information and corresponding weight coefficients can be substituted into the above-mentioned weight calculation formula for calculation, and the calculated result can be used as the specified weight value of the specified voucher header fragment data.

[0064] The calculation result is used as the specified weight value for the specified voucher header fragment data.

[0065] Based on the above processing flow, this application collects information from specified voucher header fragment data based on preset weight influencing factors to obtain corresponding relevant information. The specified voucher header fragment data is any set of data from all voucher header fragment data. Then, the weight coefficients corresponding to the weight influencing factors are obtained. Next, a preset weight calculation formula is called. Then, the relevant information and weight coefficients are calculated based on the weight calculation formula to obtain the corresponding calculation result. The calculation result is then used as the specified weight value for the specified voucher header fragment data. Thus, this application, by using the weight calculation formula to calculate and process the relevant information and weight coefficients obtained from the information collection of specified voucher header fragment data, can automatically and accurately generate the specified weight value for the specified voucher header fragment data. This achieves dynamic weight allocation processing for voucher header fragment data, improves the calculation efficiency and intelligence of weight value generation, and ensures the accuracy of the obtained weight value.

[0066] In some optional implementations, the step of allocating threads to the voucher header fragment data based on the weight value to obtain the corresponding target thread includes the following steps: Obtain the sharding allocation rule corresponding to the weight value.

[0067] In this embodiment, the above-mentioned sharding allocation rules include: Priority queue: The voucher header shard data is sorted from high to low weight, with high-weight shards entering the scheduling queue first. Thread matching logic: High-weight shards are allocated to the thread with the lowest current load in the high-performance thread pool. Low-weight shards are allocated to the ordinary thread pool in a round-robin fashion. Time period optimization: Based on system load prediction (e.g., historical data analysis showing resource idleness at 3 PM), high-weight tasks are delayed until off-peak hours for processing.

[0068] Based on the fragmentation allocation rules, the thread resources are used to perform thread allocation processing on the voucher header fragmented data to obtain the corresponding designated thread.

[0069] In this embodiment, based on the rules of the aforementioned sharding allocation rules, the aforementioned thread resources can be used to perform thread allocation processing on the aforementioned voucher header sharded data to obtain the corresponding designated thread. Specifically, when the system shards according to the sharding allocation rules, it rationally allocates vouchers to different threads based on weight values, ensuring that voucher shards with high complexity and large data volume are preferentially allocated to threads with higher performance or during periods with more abundant resources, while simple voucher shards with small data volume are allocated to ordinary threads.

[0070] The specified thread is validated based on a preset validation strategy.

[0071] In this embodiment, the memory usage rate of the specified thread can be collected based on a preset time interval. If the memory usage rate of the specified thread is less than a preset memory threshold, it indicates that the load of the specified thread is low, and thus the specified thread is determined to have passed the verification. Conversely, if the memory usage rate of the specified thread is greater than or equal to the memory threshold, it indicates that the load of the specified thread is too high, and thus the specified thread is determined to have failed the verification. The value of the memory threshold is not specifically limited and can be set according to actual business needs.

[0072] If the specified thread passes the verification, then the specified thread will be designated as the target thread corresponding to the credential header fragment data.

[0073] In this embodiment, the specified thread will only be designated as the target thread corresponding to the aforementioned credential header fragment data if the specified thread passes the verification.

[0074] The system also includes optimization features related to thread processing, including: 1. Resource utilization monitoring. Metrics collection: Records thread pool throughput (number of tasks completed / minute), average waiting time, and resource idle rate. Visual dashboard: Real-time display of weight distribution and processing efficiency for each thread pool, for example: High-performance thread pool: 60% of tasks with a weight >80 are currently being processed. Ordinary thread pool: Task backlog <5%. 2. Adaptive optimization. Dynamic weight adjustment: If the processing time of high-weight tasks in high-performance threads is not significantly reduced, the weight of the "historical processing time" factor is automatically reduced. Shard size optimization: Dynamically adjusts shard granularity based on data volume (e.g., splitting into smaller shards when data volume >10,000 records). 3. Exception handling. Timeout reassignment: If a task times out in high-performance threads (e.g., exceeding twice the average processing time), it is marked as an "abnormal task" and reassigned to an ordinary thread. Degradation strategy: When system resources are continuously strained (e.g., CPU >90% for 5 minutes), all new tasks are temporarily downgraded to a uniform weight to avoid resource contention.

[0075] Based on the above processing flow, this application calls preset thread resources; then obtains the sharding allocation rule corresponding to the weight value; subsequently, based on the sharding allocation rule, it uses thread resources to perform thread allocation processing on the voucher header sharded data to obtain the corresponding specified thread; subsequently, it verifies the specified thread based on a preset verification strategy; if the specified thread passes the verification, it is used as the target thread corresponding to the voucher header sharded data. Thus, this application, by using the sharding allocation rule corresponding to the weight value, utilizes thread resources to perform thread allocation processing on the voucher header sharded data to obtain the specified thread, and intelligently verifies the specified thread, thereby using the verified specified thread as the target thread corresponding to the voucher header sharded data. This automatically and intelligently completes the thread allocation processing for the voucher header sharded data, realizing a dynamic weight allocation mechanism that fully utilizes system resources, avoids the problem of uneven thread load, and further improves data verification efficiency.

[0076] In some alternative implementations, step S206 includes the following steps: The first verification result and the second verification result are analyzed to determine whether the contents of the first verification result and the second verification result are both verified as passed.

[0077] In this embodiment, the content of the generated first and second verification results can be analyzed separately to determine whether both the first and second verification results have passed the verification. The content of the first and second verification results can indicate that the verification has passed or failed.

[0078] If all verifications pass, the content corresponding to the voucher line data is generated as the first target verification result that has passed verification.

[0079] In this embodiment, a first target verification result will be generated only when both the voucher header verification and the voucher row verification are passed, that is, when the results of the first verification result and the second verification result are both verified.

[0080] If none of the verifications pass, the content corresponding to the voucher line data is generated as the second target verification result for those that failed the verification.

[0081] In this embodiment, if it is detected that the voucher header verification and voucher row verification have failed, that is, the results of the first verification result and the second verification result are not both verified, a second target verification result will be generated with the content corresponding to the voucher row data as the content of the failed verification.

[0082] Based on the above processing flow, this application analyzes the content of the first and second verification results to determine whether both results have passed verification. If both have passed, a first target verification result is generated, corresponding to the voucher line data. If neither has passed, a second target verification result is generated, corresponding to the voucher line data. Thus, by comprehensively considering the results of both the voucher header and voucher line verifications, this application generates a target verification result where the content corresponding to the voucher line data is verified only when both verifications pass, effectively improving the accuracy of the generated target verification results.

[0083] In some optional implementations of this embodiment, after step S202, the electronic device may further perform the following steps: Obtain the relevant business information corresponding to the voucher line data.

[0084] In this embodiment, the aforementioned relevant business information can report information such as the verification results corresponding to the aforementioned voucher line data, business rule change records, and system operation logs.

[0085] Invoke the preset difference prediction model.

[0086] In this embodiment, the construction process of the aforementioned difference prediction model includes: Data collection and preprocessing: The system collects historical voucher data, including various field information of management and accounting vouchers, verification results, business rule change records, and system operation logs. This data is then cleaned, transformed, and its features are extracted to construct a dataset suitable for training a machine learning model. Model training: A suitable machine learning algorithm, such as decision tree, random forest, or neural network, is selected and used to train the model using the preprocessed dataset. During training, the model learns patterns and rules from historical data, establishing a correlation model between voucher differences and various influencing factors, i.e., the difference prediction model. Difference prediction and early warning: In actual operation, the system inputs the currently generated voucher data and related business information into the trained difference prediction model. The difference prediction model predicts the probability of a difference occurring in the voucher based on the learned rules. When the predicted probability exceeds a set threshold, the system automatically issues an early warning, prompting relevant personnel to check and handle the issue in advance. Continuous optimization: As new data accumulates, the system periodically updates and optimizes the difference prediction model to improve the accuracy and reliability of the prediction.

[0087] Based on the difference prediction model, the voucher line data and the related business information are predicted and processed to obtain the corresponding difference prediction results.

[0088] In this embodiment, the above-mentioned voucher line data and related business information can be input into the difference prediction model, so that the difference prediction model can predict the probability of the voucher line data having a difference based on the learned rules, and use it as the corresponding difference prediction result.

[0089] The difference prediction results are then processed for output.

[0090] In this embodiment, the generated difference prediction results can be sent to relevant personnel via email, interface display, or text message. Furthermore, if the difference prediction results exceed a set difference threshold, the system will automatically issue a warning to prompt relevant personnel to conduct an advance check and take appropriate action.

[0091] Based on the above processing flow, this application obtains relevant business information corresponding to the voucher line data; then calls a preset difference prediction model; subsequently, it performs prediction processing on the voucher line data and relevant business information based on the difference prediction model to obtain the corresponding difference prediction results; and finally, it outputs the difference prediction results. In this way, by using the difference prediction model to predict and process voucher line data and relevant business information, this application can achieve early prediction of voucher differences, enabling financial personnel to take corrective measures before problems occur, avoiding large differences during critical periods, improving the efficiency and accuracy of financial work, and thus ensuring the smooth progress of monthly closing, annual closing, and audit compliance work.

[0092] In some optional implementations of this embodiment, after step S206, the electronic device may further perform the following steps: Call the preset verification result table.

[0093] In this embodiment, the aforementioned verification result table is a pre-constructed data table used to store the verification results of the aforementioned voucher line data.

[0094] The first verification result, the second verification result, and the target verification result are stored in the verification result table.

[0095] In this embodiment, the generated first verification result, second verification result, and target verification result can be recorded in the aforementioned verification result table to record the overall situation of this verification task, such as the number of verified vouchers, the number of consistent vouchers, and the number of inconsistent vouchers. This process achieves complete traceability of the verification trajectory of voucher line data, supporting full-process traceability and query of the verification process and final results.

[0096] Retrieve the data record corresponding to the voucher row data from the header row relationship table.

[0097] In this embodiment, the data record corresponding to the voucher line data can be found by accessing the above-mentioned header row relationship table, so as to update the status value of the "whether it has been verified" field in the data record.

[0098] The data record is updated based on the target verification result.

[0099] In this embodiment, the status value of the "Whether it has been verified" field of the above data record is updated according to the target verification result stored in the above verification result table. If the target verification result is that the two-dimensional vouchers are completely consistent (i.e., the verification passed), the status value is updated to "Checked successfully"; if there is a difference (i.e., the verification failed), it is updated to "Check failed"; for vouchers that have not yet been verified, the status value remains "Not checked".

[0100] The status update operation enables closed-loop feedback of verification results, updating the underlying header row relationship table. Subsequent verification tasks, upon initiation, can determine which vouchers require verification and which have already been successfully verified and require no further processing based on the status values ​​in the header row relationship table. This entire process forms an integrated "generation-association-verification-feedback" mechanism, ensuring the continuity and efficiency of data verification.

[0101] Based on the above processing flow, this application calls a preset verification result table; then, the first verification result, the second verification result, and the target verification result are stored in the verification result table; subsequently, the data record corresponding to the voucher row data is retrieved from the header row relationship table; and then, the data record is updated based on the target verification result. In this way, this application accurately feeds the target verification result back into the basic data through status update processing, providing a status reference for subsequent verification tasks. This helps ensure the consistency of management and accounting vouchers, thereby improving the efficiency and accuracy of financial data management.

[0102] In some alternative implementations, the user information obtained is subject to user consent and complies with relevant laws and policies.

[0103] Furthermore, any software tools or components not belonging to our company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0104] Furthermore, the solution proposed in this application has the following advantages: 1. Intelligent Incremental Verification: Achieving accurate and efficient voucher consistency verification based on status filtering. Before each verification task is initiated, the system automatically performs intelligent filtering based on the "Verified?" field in the "Header Row Relationship Table." Only vouchers with a status of "Unchecked" or "Check Failed" are processed; vouchers that have already been confirmed to be consistent are automatically skipped, avoiding duplicate calculations and wasted resources. This mechanism significantly reduces data scanning and processing volume, improves system operating efficiency, and ensures that verification tasks focus on potential anomalies, achieving the goals of "accurate verification, efficient execution, and optimal resource utilization," truly realizing the evolution of financial verification from "full scan" to "intelligent incremental verification."

[0105] 2. Multi-threaded Parallel Verification: Efficiently Handling Peak Periods of Large-Scale Voucher Processing. For large-scale voucher verification scenarios, the system adopts a "voucher line slicing + multi-threaded parallel processing" strategy. The data to be verified is sliced ​​according to rules and then distributed to multiple threads for parallel execution, significantly improving verification throughput and shortening the processing cycle. It is especially suitable for high-concurrency verification needs such as at the end of the month and the end of the year, effectively alleviating system performance bottlenecks.

[0106] 3. A fully traceable intelligent verification mechanism: ensuring consistency between management and accounting vouchers in the general ledger system. To guarantee consistency between management and accounting vouchers, the system needs to construct a verification mechanism with traceability, high efficiency, and intelligent filtering capabilities. The system will fully record the process and results of each verification task, including verification time, executor, amount of data processed, discrepancies, and final status. All information is persistently stored in the verification process table and the verification final result table, providing strong support for auditing, problem identification, and process optimization.

[0107] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0108] It should be emphasized that, in order to further ensure the privacy and security of the above-mentioned target verification results, the above-mentioned target verification results can also be stored in a node of a blockchain.

[0109] The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0110] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results. Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0111] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0112] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0113] Further reference Figure 3 As a response to the above Figure 2 To implement the method shown, this application provides an embodiment of a data verification device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0114] like Figure 3 As shown, the data verification device 300 described in this embodiment includes: a judgment module 301, a first query module 302, a sharding module 303, a first verification module 304, a second verification module 305, and a generation module 306. Wherein: The judgment module 301 is used to determine whether a triggered data verification task has been received; The first query module 302 is used to query the voucher row data that is in the pending inspection state from the preset head row relationship table if the condition is met. The sharding module 303 is used to shard the voucher line data according to a preset sharding rule if there are multiple voucher line data, so as to obtain the corresponding voucher header shard data. The first verification module 304 is used to perform verification processing on the voucher header fragment data based on a preset multi-threaded parallel verification strategy to obtain the corresponding first verification result. The second verification module 305 is used to perform item-by-item comparison of key fields of the voucher header fragment data based on a preset voucher row-level verification strategy to obtain the corresponding second verification result. The generation module 306 is used to generate a target verification result corresponding to the voucher line data based on the first verification result and the second verification result.

[0115] In some optional implementations of this embodiment, the first verification module 304 includes: The calculation submodule is used to perform weight calculation processing on the voucher header fragment data based on a preset dynamic weight calculation strategy to obtain the corresponding weight value; Calling a submodule is used to invoke predefined thread resources; The allocation submodule is used to perform thread allocation processing on the voucher header fragment data based on the weight value and using the thread resources to obtain the corresponding target thread; The verification submodule is used to perform verification processing on the voucher header fragment data based on the target thread to obtain a specified verification result corresponding to the voucher header fragment data.

[0116] In some optional implementations of this embodiment, the computation submodule includes: The data acquisition unit is used to collect information from specified voucher header fragment data based on preset weighted influencing factors, and obtain corresponding relevant information; wherein, the specified voucher header fragment data is any set of data from all the voucher header fragment data; The first acquisition unit is used to acquire the weight coefficients corresponding to the weight influencing factors. The calling unit is used to invoke the preset weight calculation formula; The calculation unit is used to calculate and process the relevant information and the weight coefficients based on the weight calculation formula to obtain the corresponding calculation results; The first determining unit is used to use the calculation result as the specified weight value of the specified voucher header fragment data.

[0117] In some optional implementations of this embodiment, the allocation submodule includes: The second acquisition unit is used to acquire the sharding allocation rule corresponding to the weight value; The allocation unit is used to perform thread allocation processing on the voucher header fragment data based on the fragment allocation rules and using the thread resources to obtain the corresponding specified thread; The verification unit is used to verify the specified thread based on a preset verification strategy. The second determining unit is used to designate the specified thread as the target thread corresponding to the credential header fragment data if the specified thread passes the verification.

[0118] In some optional implementations of this embodiment, the generation module 306 includes: The analysis submodule is used to perform content analysis on the first verification result and the second verification result, and to determine whether the content of the first verification result and the second verification result are both verified as passed; The first generation submodule is used to generate the first target verification result that corresponds to the voucher line data if all verifications pass. The second generation submodule is used to generate a second target verification result that is not verified if none of the data in the voucher line is verified.

[0119] In some optional implementations of this embodiment, the data verification device further includes: The acquisition module is used to acquire relevant business information corresponding to the voucher line data; The calling module is used to invoke a preset difference prediction model; The prediction module is used to perform prediction processing on the voucher line data and the related business information based on the difference prediction model to obtain the corresponding difference prediction results; The output module is used to process the difference prediction results.

[0120] In some optional implementations of this embodiment, the data verification device further includes: The calling module is used to call the preset verification result table; The storage module is used to store the first verification result, the second verification result, and the target verification result into the verification result table; The second query module is used to query the data record corresponding to the voucher row data from the header row relationship table; The update module is used to perform status update processing on the data record based on the target verification result.

[0121] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0122] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected via a system bus. It should be noted that only the computer device 4 with components 41-43 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0123] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0124] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Of course, the memory 41 may also include both the internal storage unit and its external storage device of the computer device 4. In this embodiment, the memory 41 is typically used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions for data verification methods. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or will be output.

[0125] In some embodiments, the processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or to process data, for example, to execute computer-readable instructions for the data verification method.

[0126] The network interface 43 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 4 and other electronic devices.

[0127] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the data verification method described above.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0129] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A data verification method, characterized in that, Includes the following steps: Determine whether a triggered data verification task has been received; If so, retrieve the voucher row data that is in the pending inspection state from the preset header row relationship table; If there are multiple voucher line data, the voucher line data is segmented based on a preset segmentation rule to obtain the corresponding voucher header segment data. The voucher header fragment data is verified based on a preset multi-threaded parallel verification strategy to obtain the corresponding first verification result. Based on the preset voucher row-level verification strategy, the key fields of the voucher header fragment data are compared item by item to obtain the corresponding second verification result. Based on the first verification result and the second verification result, a target verification result corresponding to the voucher line data is generated.

2. The data verification method according to claim 1, characterized in that, The step of verifying the voucher header fragment data based on a preset multi-threaded parallel verification strategy to obtain the corresponding first verification result specifically includes: The voucher header fragment data is processed by weight calculation based on a preset dynamic weight calculation strategy to obtain the corresponding weight value. Call the preset thread resources; Based on the weight value, the thread resources are used to perform thread allocation processing on the voucher header fragment data to obtain the corresponding target thread; The target thread performs verification processing on the voucher header fragment data to obtain a specified verification result corresponding to the voucher header fragment data.

3. The data verification method according to claim 2, characterized in that, The step of performing weight calculation on the voucher header fragment data based on a preset dynamic weight calculation strategy to obtain the corresponding weight value specifically includes: Information is collected from the specified voucher header fragment data based on preset weighted influencing factors to obtain corresponding relevant information; wherein, the specified voucher header fragment data is any set of data from all the voucher header fragment data; Obtain the weight coefficients corresponding to the weight influencing factors; Call the preset weight calculation formula; The relevant information and the weight coefficients are calculated and processed based on the weight calculation formula to obtain the corresponding calculation results; The calculation result is used as the specified weight value for the specified voucher header fragment data.

4. The data verification method according to claim 2, characterized in that, The step of allocating threads to the voucher header fragment data based on the weight value to obtain the corresponding target thread specifically includes: Obtain the sharding allocation rule corresponding to the weight value; Based on the fragmentation allocation rules, the thread resources are used to perform thread allocation processing on the voucher header fragmentation data to obtain the corresponding specified thread; The specified thread is verified based on a preset verification strategy; If the specified thread passes the verification, then the specified thread will be designated as the target thread corresponding to the credential header fragment data.

5. The data verification method according to claim 1, characterized in that, The step of generating a target verification result corresponding to the voucher line data based on the first verification result and the second verification result specifically includes: The first verification result and the second verification result are analyzed to determine whether the contents of the first verification result and the second verification result are both verified as passed. If all verifications pass, the content corresponding to the voucher line data is generated as the first target verification result that has passed verification; If none of the verifications pass, the content corresponding to the voucher line data is generated as the second target verification result for those that failed the verification.

6. The data verification method according to claim 1, characterized in that, After the step of retrieving the voucher row data in the pending inspection state from the preset header row relationship table, the method further includes: Obtain relevant business information corresponding to the voucher line data; Call the preset difference prediction model; Based on the difference prediction model, the voucher line data and the relevant business information are predicted and processed to obtain the corresponding difference prediction results; The difference prediction results are then processed for output.

7. The data verification method according to claim 1, characterized in that, After the step of generating a target reconciliation result corresponding to the voucher line data based on the first reconciliation result and the second reconciliation result, the method further includes: Call the preset verification result table; Store the first verification result, the second verification result, and the target verification result in the verification result table; Retrieve the data record corresponding to the voucher row data from the header row relationship table; The data record is updated based on the target verification result.

8. A data verification device, characterized in that, include: The judgment module is used to determine whether a triggered data verification task has been received; The first query module is used to retrieve the voucher row data that is in the pending inspection state from the preset head row relationship table if the condition is met. The sharding module is used to shard the voucher line data based on a preset sharding rule if there are multiple voucher line data, and obtain the corresponding voucher header shard data. The first verification module is used to perform verification processing on the voucher header fragment data based on a preset multi-threaded parallel verification strategy to obtain the corresponding first verification result. The second verification module is used to perform item-by-item comparison of key fields of the voucher header fragment data based on a preset voucher row-level verification strategy to obtain the corresponding second verification result. The generation module is used to generate a target verification result corresponding to the voucher line data based on the first verification result and the second verification result.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the data verification method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the data verification method as described in any one of claims 1 to 7.

Images