Report data verification methods, devices, computer equipment, and storage media

Abstract

This application relates to the field of big data verification technology, specifically to a method, apparatus, computer device, storage medium, and computer program product for verifying report data. In response to a verification initiation request, it determines the report to be verified, and based on its report type, determines the target verification rule parsing data corresponding to the report. It then determines the data to be verified based on the verification elements, determines the target verification program based on the verification type, and finally verifies the data to be verified based on the target verification program and the target verification rule parsing data to obtain the verification result corresponding to the report. Based on the scenario of fund report data verification, the verification rule parsing data is decomposed and pre-stored. Business personnel can initiate verification based on the report to be verified, and then directly obtain the verification rules according to the report type to perform the verification. This eliminates the need to redevelop the rule engine, reducing the learning cost for business personnel. The pre-stored verification rules in the database also facilitate flexible rule adjustments by business personnel.

Description

Technical Field

[0001] This application relates to the field of big data verification technology, and in particular to a report data verification method, apparatus, computer equipment, storage medium and computer program product. Background Technology

[0002] With the integration of the financial industry and information technology, and economic development, more and more users are choosing to manage their personal account resources through banks or fund companies. This often necessitates submitting basic fund information and financial statements to users or regulatory agencies. Generally, before submitting such fund statements, strict data verification is required according to regulations to ensure the accuracy of the data.

[0003] In traditional technologies, fund report data validation is typically performed using rule engines or by directly using fixed validation rules in the program code. However, this validation method has a high learning curve for business personnel, making it impossible for them to configure validation rules themselves. It usually requires the assistance of developers, resulting in low validation efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a report data verification method, device, computer equipment, storage medium, and computer program product that can improve the efficiency of report data verification, addressing the technical problem of low verification efficiency of the aforementioned traditional verification methods.

[0005] Firstly, this application provides a method for validating report data. The method includes:

[0006] In response to the verification start request, the report to be verified is determined, and the target verification rule parsing data corresponding to the report to be verified is determined from the pre-stored verification rule parsing data according to the report type of the report to be verified. The verification rule parsing data includes verification elements and verification type.

[0007] The data to be verified in the report to be verified is determined based on the verification element.

[0008] The target verification procedure is determined from each preset verification procedure according to the verification type;

[0009] Based on the target verification program and the target verification rule parsing data, the data to be verified is verified to obtain the verification result corresponding to the report to be verified.

[0010] In one embodiment, the verification types include non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, cross-reference verification, comparison relationship verification, and verification that at least one condition is met. The types of the preset verification programs include database verification types and memory verification types. Determining the target verification program from each preset verification program according to the verification type includes:

[0011] If the verification type is any one of the following: non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, and reconciliation relationship verification, then the target verification program is determined to be a database verification type.

[0012] If the verification type is a comparison relationship verification or at least one of the condition verifications is satisfied, the target verification program is determined to be a memory verification type.

[0013] In one embodiment, the step of verifying the data to be verified based on the target verification program and the target verification rule parsing data includes:

[0014] When the target verification program is a database verification type, the data is parsed based on the target verification rules, and the data to be verified is directly verified in the database according to the execution logic of the target verification program.

[0015] When the target verification program is a memory verification type, after the target verification rule parsing data and the data to be verified are obtained from the database and stored in memory, the data to be verified is verified according to the execution logic of the target verification program based on the target verification rule parsing data.

[0016] In one embodiment, when the target validation procedure is a database validation type, the execution logic of the target validation procedure is a dynamic structured query language generated according to the validation type.

[0017] In one embodiment, the process of acquiring and pre-storing the verification rule parsing data includes:

[0018] Obtain a verification rule file and parse the verification rule file to obtain the verification rule parsing data; the verification rule parsing data also includes at least one of verification conditions and verification type auxiliary information;

[0019] The verification type and verification element in the parsed data of the verification rules are stored in the preset rule table of the database;

[0020] If a verification condition exists in the parsed data of the verification rule, the verification condition is stored in the preset condition table of the database.

[0021] If verification type auxiliary information corresponding to the verification type exists in the verification rule parsing data, the verification type auxiliary information is stored in the preset auxiliary information table of the database.

[0022] In one embodiment, the number of preset auxiliary information tables is multiple; when verification type auxiliary information corresponding to the verification type exists in the verification rule parsing data, storing the verification type auxiliary information into the preset auxiliary information table of the database includes:

[0023] The target auxiliary information table is determined from each of the preset auxiliary information tables according to the verification type;

[0024] The verification type auxiliary information is stored in the target auxiliary information table.

[0025] In one embodiment, after obtaining the parsed data of the verification rules and before pre-storing it in the database, the method further includes:

[0026] The validity of the data parsed by the verification rules is checked.

[0027] In one embodiment, the validity check of the parsed data of the verification rules includes:

[0028] Check whether the verification element exists in the report definition of the report to be verified;

[0029] Check whether the elements involved in the verification conditions exist in the report definition;

[0030] Check whether the verification type belongs to one of the preset verification types.

[0031] Secondly, this application also provides a report data verification device, the device comprising:

[0032] The report and rule determination module is used to respond to the verification start request, determine the report to be verified, and determine the target verification rule parsing data corresponding to the report to be verified from the pre-stored verification rule parsing data according to the report type of the report to be verified. The verification rule parsing data includes verification elements and verification types.

[0033] The verification data determination module is used to determine the verification data of the report to be verified based on the verification elements.

[0034] The verification procedure determination module is used to determine the target verification procedure from each preset verification procedure according to the verification type;

[0035] The verification execution module is used to parse the data based on the target verification program and the target verification rules, verify the data to be verified, and obtain the verification result corresponding to the report to be verified.

[0036] In one embodiment, the verification types include non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, cross-reference verification, comparison relationship verification, and verification of at least one condition. The types of the preset verification program include database verification type and memory verification type.

[0037] The verification procedure determination module is further configured to determine the target verification procedure as a database verification type when the verification type is any one of the non-empty verification, the element non-existence verification, the enumeration value verification, the value range verification, the fixed format verification, and the reconciliation relationship verification; and to determine the target verification procedure as a memory verification type when the verification type is comparison relationship verification or at least one of the condition verifications.

[0038] In one embodiment, the verification execution module is further configured to, when the target verification program is a database verification type, parse the data based on the target verification rules and directly verify the data to be verified in the database according to the execution logic of the target verification program; and when the target verification program is a memory verification type, after obtaining the target verification rule parsing data and the data to be verified from the database into memory, verify the data to be verified based on the target verification rule parsing data and according to the execution logic of the target verification program.

[0039] In one embodiment, when the target verification program is a database verification type, the execution logic of the target verification program determined by the verification program determination module is a dynamic structured query language generated according to the verification type.

[0040] In one embodiment, the device further includes:

[0041] The rule parsing module is used to obtain a verification rule file and parse the verification rule file to obtain the verification rule parsing data; the verification rule parsing data also includes at least one of verification conditions and verification type auxiliary information.

[0042] The rule pre-storage module is used to store the verification type and verification element in the verification rule parsing data into a preset rule table of the database; if there is a verification condition in the verification rule parsing data, store the verification condition into a preset condition table of the database; if there is verification type auxiliary information corresponding to the verification type in the verification rule parsing data, store the verification type auxiliary information into a preset auxiliary information table of the database.

[0043] In one embodiment, the number of the preset auxiliary information tables is multiple;

[0044] The rule pre-storage module is further configured to determine a target auxiliary information table from each of the preset auxiliary information tables according to the verification type; and store the verification type auxiliary information into the target auxiliary information table.

[0045] In one embodiment, the device further includes:

[0046] The rule validity check module is used to check the validity of the parsed data of the verification rules.

[0047] In one embodiment, the rule validity checking module is further configured to check whether the verification element exists in the report definition of the report to be verified; check whether the elements involved in the verification condition exist in the report definition; and check whether the verification type belongs to one of the preset verification types.

[0048] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method described above.

[0049] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0050] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described method.

[0051] The aforementioned report data verification method, apparatus, computer equipment, storage medium, and computer program product, in response to a verification initiation request, determine the report to be verified, and, based on the report type, determine the target verification rule parsing data corresponding to the report to be verified from pre-stored verification rule parsing data. The verification rule parsing data includes verification elements and verification types. Based on the verification elements, determine the data to be verified in the report to be verified; based on the verification type, determine the target verification program from various preset verification programs; and finally, based on the target verification program and the target verification rule parsing data, verify the data to be verified to obtain the verification result corresponding to the report to be verified. According to the scenario of fund report data verification, the verification rule parsing data, which contains verification rules corresponding to the report type, is decomposed and pre-stored. This allows business personnel to initiate a verification initiation request based on the report to be verified, and then directly obtain the verification rules based on the report type to be verified to perform the verification. This eliminates the need to redevelop the complex programming language of the rule engine, reducing the learning cost for business personnel. The pre-stored verification rules in the database also facilitate flexible rule adjustments by business personnel. Attached Figure Description

[0052] Figure 1 This is a diagram illustrating the application environment of a report data validation method in one embodiment.

[0053] Figure 2 This is a flowchart illustrating a report data validation method in one embodiment;

[0054] Figure 3 This is a flowchart illustrating the steps of determining the target verification procedure in one embodiment;

[0055] Figure 4 This is a flowchart illustrating the steps for verifying the data to be verified in one embodiment.

[0056] Figure 5 This is a flowchart illustrating the steps of acquiring and pre-storing the verification rule parsing data in one embodiment;

[0057] Figure 6 This is a flowchart illustrating the step of pre-storing verification type auxiliary information in one embodiment;

[0058] Figure 7 This is a schematic diagram of the data flow in a report data verification method in one embodiment;

[0059] Figure 8 This is a structural block diagram of a report data verification device in one embodiment;

[0060] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0061] It should be noted that the user information (including but not limited to user device information, user personal information, and report information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0062] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0063] The report data verification method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system stores the report data to be verified and the verification rule parsing data that server 104 needs to process. The data storage system can be integrated on server 104 or placed in the cloud or on another network server. Specifically, in response to the verification start request initiated by terminal 102, server 104 determines the report to be verified and, based on the report type, determines the target verification rule parsing data corresponding to the report from the pre-stored verification rule parsing data. The verification rule parsing data includes verification elements and verification types. Based on the verification elements, server 104 determines the data to be verified in the report. Based on the verification type, server 104 determines the target verification program from various preset verification programs. Based on the target verification program and the target verification rule parsing data, server 104 verifies the data to be verified to obtain the verification result corresponding to the report. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0064] In one embodiment, such as Figure 2 As shown, a report data validation method is provided, which can be applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0065] S200: In response to the verification start request, determine the report to be verified, and determine the target verification rule parsing data corresponding to the report to be verified from the pre-stored verification rule parsing data according to the report type of the report to be verified. The verification rule parsing data includes verification elements and verification type.

[0066] The verification initiation request is initiated by business personnel on the terminal. This can be triggered directly after the business personnel have configured the required reports and verification rules for the report data verification process on the terminal, or it can be triggered by the business personnel operating the verification initiation control on the terminal. It can be understood that the reports to be verified can be determined based on their information, which can be carried in the verification initiation request or pre-stored in the database after configuration by the business personnel. The report information may include at least one of the following: report number, report name, product to which the report belongs, and report type. Therefore, the report to be verified can be determined based on the report number or report name, or it can be determined based on the product to which the report belongs and the report type. Taking fund report verification as an example, the product to which the report belongs can be the fund's main code or fund name, and the report type can be annual report, monthly report, or daily report, etc. Therefore, when a fund product and the report type are selected as annual report, the reports to be verified shown in Table 1 below can be obtained.

[0067] Table 1 Example of a report to be verified

[0068] Fund Code Report types Element ID Element name Element value 123456 annual report 2023 Start date of the reporting period 2018-10-01 2024 End of reporting period 2018-12-31 3583 Is it a MOM fund? no 0010 Fund categories Open currency … … …

[0069] Specifically, the validation rule parsing data is the data obtained by classifying and parsing at least one validation rule for each report type. It can be understood as data obtained by breaking down the information items of a validation rule. For example, it may include the validation elements and validation type of a single validation rule, as well as the validation conditions and auxiliary information for the validation type. After parsing, the validation rule parsing data can be directly pre-stored in the database, establishing a one-to-one correspondence with the report type, for subsequent calls based on the report type to be validated during the validation process. The validation rule parsing data pre-stored in the database can be obtained by classifying and parsing validation rule files entered or imported in batches by business personnel on the terminal, or it can be obtained by business personnel directly performing CRUD operations in the database. It can be understood that the validation rule parsing data for the same validation rule can be only for one report type, or it can correspond to validation rules for multiple report types, as long as it conforms to the correspondence between the report types and the validation rule parsing data set by the business personnel.

[0070] Furthermore, the target validation rule parsing data is the data obtained after classifying and parsing the validation rules corresponding to the determined report to be validated. After determining the report to be validated, it can be determined from the pre-stored validation rule parsing data in the database, based on the correspondence between the report type and the validation rule parsing data. It can be understood that the target validation rule parsing data is the validation rule used to validate the report to be validated, and may include one or more validation rules. In addition, after classification, the various pieces of information in the validation rule parsing data can be stored separately in different preset tables in the database. For example, validation type and validation element can be stored in a preset rule table, validation conditions in a preset condition table, and validation type auxiliary information in a preset auxiliary information table.

[0071] S400: Determine the data to be verified in the report based on the verification elements.

[0072] In this context, an element is a data item in the report. As shown in Table 1, each element in the report includes an element ID, an element name, and an element value. The element ID represents the number of each element, and the element value represents the specific content or value of the element with the corresponding element name in the report. Validation elements represent the elements in the report to be validated that are involved in the data parsing the target validation rules, i.e., the validation rules themselves.

[0073] Specifically, the data to be verified is used to characterize the element values ​​corresponding to the elements of the report to be verified. It can be determined after obtaining the parsed data of the target verification rules, based on the verification elements contained in the parsed data of the target verification rules. When determining the data to be verified for the report to be verified, it can be obtained by confirming the verification elements in the original report of the report to be verified, or it can be obtained by confirming the original report after database processing, as long as it contains the element values ​​corresponding to the verification elements.

[0074] S600: Determine the target verification program from the preset verification programs according to the verification type.

[0075] Specifically, the validation type is used to characterize what form of validation needs to be performed on the data to be validated in the target validation rule parsing data, that is, in the validation rule. The number of validation types is not fixed and can be set according to the needs of the actual report validation process. For example, in this embodiment, the validation types may include eight types: non-empty validation, element non-existence validation, enumeration value validation, value range validation, fixed format validation, cross-reference validation, comparison validation, and validation that at least one condition is met.

[0076] It is understandable that each verification type has its own rule definition. For example, the rule for non-empty verification is that the element value corresponding to the element to be verified cannot be empty; the rule for element non-existence verification is that the element to be verified does not exist in the determined data to be verified, such as the element of cumulative net asset value growth rate not existing in the annual report; the rule for enumeration value verification is that the element value of the element to be verified must be one of the preset valid enumeration values, such as the element value of fund type must be any one of equity fund, mixed fund, bond fund, money market fund, QDII, fund of funds, and commodity fund; the rule for value range verification is that the element value of the element to be verified must be within a preset reasonable value range, such as the element value of fund unit net asset value on the benchmark date must be within a preset reasonable range (0-200); the rule for fixed format verification is that the element value of the element to be verified must meet a preset fixed format, such as the element value of fund transaction... The element values ​​of the Easy Code must exist and be six digits; the rules for verifying the reconciliation relationship are defined as follows: the element values ​​of the verification element must meet the preset reconciliation relationship, such as the element value of the verification element - the total accrued interest of trading financial assets must be equal to the sum of the element values ​​of verification elements such as stocks, precious metal investments - gold contracts on the Shanghai Gold Exchange, bonds, asset-backed securities, funds, and others; the rules for verifying the comparison relationship are defined as follows: the verification element must meet the preset comparison relationship with another verification element, such as the element value of the verification element - the effective date of the fund contract must be less than or equal to the element value of the verification element - the data range, and the element value of the verification element - before the change of the fund management company name must not be equal to the element value of the verification element - after the change of the fund management company name; the rule for verifying at least one condition is defined as follows: at least one element value of each verification element must meet the preset condition, such as the element value of at least one of the verification elements - the appointment of a fund manager and the dismissal of a fund manager must be "yes".

[0077] Furthermore, the preset verification program represents a verification program developed according to the rule definition of the verification type, which can be used to verify the data to be verified according to the rule definition of the verification type. It can be understood that each verification type corresponds to a preset verification program developed using at least one language, thus enabling report verification in different devices or operating environments, such as on the database side or the server side. Therefore, the verification type in the data can be parsed according to the target verification rule, the target verification program can be determined among the preset verification programs, and then the verification of the data to be verified can be completed based on the target verification program.

[0078] S800: Based on the target verification program and target verification rules, the data to be verified is parsed, and the verification result corresponding to the report to be verified is obtained.

[0079] Specifically, based on the target verification program and the parsed data of the target verification rules, there is no single way to verify the data to be verified. One approach is to obtain the corresponding data to be verified one by one according to each verification rule in the parsed data of the target verification rules and start the corresponding target verification program to perform the verification. Another approach is to first classify the verification rules in the parsed data of the target verification rules according to the verification type, obtaining at least one sub-target verification rule parsed data, and then obtain the data to be verified corresponding to each sub-target verification rule parsed data and start the corresponding target verification program to perform the verification. It can be understood that the target verification programs corresponding to the parsed data of each sub-target verification rule are different. In this approach, the target verification programs involved can run in parallel for verification, thereby shortening the verification time and improving verification efficiency.

[0080] Furthermore, depending on the programming language used by the target validation program, validation can be performed directly within the database or by reading the data to be validated into memory. Alternatively, when validating the data, all the data to be validated involved in the parsing of the target validation rules or sub-target validation rules can be retrieved all at once and stored in an intermediate table of the database or in memory. Then, the corresponding target validation program can be started to validate each data entry sequentially, reducing the number of data retrievals and lowering resource consumption.

[0081] It is understandable that the preset verification program is a general-purpose program developed based on the rule definition of the verification type. When implementing verification, it needs to parse data based on the target verification rules. For example, it needs to obtain the verification elements involved in the rule definition from the preset rule table of the data. Under some verification types, it also needs to obtain verification type auxiliary information such as preset valid enumeration values, preset reasonable value ranges, and preset fixed formats from the preset auxiliary information table. The target verification program can obtain the above information by passing parameters or by retrieving it from a preset path in the database.

[0082] Furthermore, the verification results for the reports to be verified may include, but are not limited to, verification passed and verification failed. It can be understood that verification passed means the report to be verified has passed the verification of all verification rules in the target verification rule parsing data, while verification failed means that at least one verification rule in the target verification rule parsing data of the report to be verified failed the verification. In addition, all verification results for the reports to be verified generated during the verification process are persistently stored in the database for subsequent data analysis and querying.

[0083] It's understandable that the method for determining whether a validation passes or fails is not fixed and can be determined based on the rule definition for the specific validation type. Taking a validation rule with validation element A and validation type non-empty validation as an example: if all values ​​of validation element A in the obtained data to be validated (i.e., the report) are not empty, then the report passes the validation rule, and the validation result is "validation passed." If at least one value of validation element A in the obtained data to be validated (i.e., the report) is empty, then the report fails the validation rule, and the validation result is "validation failed." Similarly, the method for determining whether a validation passes or fails can be deduced from the rule definitions for each validation type above, and will not be elaborated upon here.

[0084] The above-mentioned report data verification method, based on the scenario of fund report data verification, decomposes and pre-stores verification rule parsing data corresponding to the report type. This allows business personnel to initiate a verification request based on the report to be verified, and then directly obtain the verification rules according to the report type to be verified to perform the verification. There is no need to redevelop the complex programming language of the rule engine, reducing the learning cost for business personnel. The method of pre-storing verification rules in the database also makes it easy for business personnel to flexibly adjust the rules.

[0085] In one embodiment, the verification types include non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, cross-reference verification, comparison relationship verification, and verification of at least one condition. The types of preset verification programs include database verification types and memory verification types.

[0086] The database validation type represents a preset validation program built using a dynamic Structured Query Language (SQL), which can validate report data on the database side. The memory validation type represents a preset validation program built using a computer-readable programming language, such as C, C++, or Java, which can validate report data on the server side.

[0087] Specifically, based on the rule definitions of verification types such as non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, and cross-reference verification, it can be seen that they can all be expressed using some judgment statements or user-defined functions in the database. For example, non-empty verification can be expressed using a statement similar to `is not null`, and cross-reference verification can be expressed using user-defined functions in the database. However, for verification types such as comparison relationship verification and at least one condition satisfaction verification, their logical relationships are more complex and not easily expressed using the structured query language of the database. Therefore, the preset verification program can be divided into database verification type and memory verification type according to the verification type. Furthermore, in one embodiment, such as Figure 3As shown, S600 includes the following S620 to S640, wherein:

[0088] S620: When the verification type is any one of non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, and reconciliation verification, the target verification program is determined to be a database verification type. Specifically, when determining the target verification program from the preset verification programs based on the verification type, it can also be determined whether the target verification program is a database verification type.

[0089] Furthermore, when the target validation procedure is a database validation type, the validation of the report data needs to be implemented on the database side. Therefore, in one embodiment, such as Figure 4 As shown, S800 parses the data based on the target verification program and target verification rules, and verifies the data to be verified, including S820: when the target verification program is a database verification type, it parses the data based on the target verification rules and directly verifies the data to be verified in the database according to the execution logic of the target verification program.

[0090] Specifically, when the target validation program is a database validation type, its execution logic is a dynamically structured query language generated based on the validation type, that is, a dynamically structured query language generated based on the rule definition of the validation type. When validating the report to be validated, the validation rules in the target validation rule parsing data are first classified according to the validation type to obtain at least one sub-target validation rule parsing data. Then, the data to be validated involved in each sub-target validation rule parsing data is acquired all at once and stored in different intermediate tables in the database. Finally, based on the preset rule table and the preset auxiliary information table, the target validation program corresponding to each sub-target validation rule parsing data is started to validate the data to be validated in each intermediate table.

[0091] S640: If the verification type is a comparison-based verification or at least one of the conditions is met, the target verification program is determined to be a memory verification type. Specifically, when determining the target verification program from the preset verification programs based on the verification type, it can also be determined whether the target verification program is a memory verification type.

[0092] Furthermore, when the target verification program is a memory verification type, the verification of the report data needs to be implemented on the server side. Therefore, in one embodiment, such as Figure 4 As shown, S800 verifies the data to be verified based on the target verification program and target verification rule parsing data, and also includes S840: when the target verification program is a memory verification type, after retrieving the target verification rule parsing data and the data to be verified from the database into memory, the data to be verified is verified according to the execution logic of the target verification program based on the target verification rule parsing data.

[0093] Specifically, when the target verification program is a memory verification type, its execution logic is a computer-readable programming language generated based on the verification type, that is, a computer-readable programming language generated based on the rule definition of the verification type. When verifying the report to be verified, the data to be verified and the target verification rule parsing data must first be obtained from the report to be verified, the preset rule table, and the preset auxiliary information table, and stored in memory. Then, each verification rule in the target verification rule parsing data is classified according to the verification type to obtain at least one sub-target verification rule parsing data. Based on the verification elements of each sub-target verification rule parsing data, multiple sub-data to be verified are extracted from the data to be verified. Finally, the corresponding target verification program is started based on each sub-target verification rule parsing data to verify the sub-data to be verified.

[0094] In this embodiment, for the six verification types—non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, and reconciliation verification—the verification rules are directly calculated using the database. Since these six verification types typically account for over 95% of the verification types in fund reports, performing these verifications in the database significantly reduces data transmission and verification time, thus improving verification efficiency. Furthermore, for other verifications that are difficult to implement using a database, verification is performed through the application program, ensuring the completeness of the verification function.

[0095] It is understandable that before starting the verification process, the verification rules corresponding to each report type need to be configured in the database for use during report data verification. Therefore, in one embodiment, the method further includes S100: obtaining and pre-storing the verification rule parsing data. Figure 5 As shown, S100 includes the following steps:

[0096] S120: Obtain the verification rule file and parse the verification rule file to obtain the verification rule parsing data; the verification rule parsing data also includes at least one of the verification conditions and verification type auxiliary information.

[0097] Specifically, the validation rule file can be generated from validation rules entered or imported in batches by business personnel at the terminal. That is, the validation rule file includes at least one validation rule for each report type. After obtaining the validation rule file, the validation rules in the file can be decomposed to obtain the validation rule parsing data. Taking the validation rule file shown in Table 2 as an example, the decomposed validation rule parsing data includes validation elements, validation types, validation conditions, and validation type auxiliary information. Furthermore, in order to determine the target validation rule parsing data based on the report type of the report to be validated, the validation rule parsing data also needs to include the report type. To determine the specific content corresponding to each rule, the validation rule parsing data also needs to be stored according to the rule number.

[0098] Table 2 Example of Verification Rule File

[0099]

[0100] S140: Store the verification type and verification element from the parsed data of the verification rule into the preset rule table of the database. Specifically, the verification type and verification element, as mandatory contents of the verification rule, are stored one by one into the preset rule table constructed in the database according to the rule number.

[0101] S160: If there are verification conditions in the data parsed for the verification rules, store the verification conditions in the preset condition table of the database.

[0102] Specifically, a verification condition can be understood as requiring verification only for data in the report that meets that condition. As shown in Table 2, verification conditions can include condition type, condition element, and condition auxiliary information. The condition type represents the value type of the condition element, such as enumeration type or numeric type. Taking the verification condition corresponding to verification rule RULE5 in Table 2 as an example, since its rule definition is whether the proportion of shares held by the ETF linked fund to the total shares meets the preset reconciliation relationship, it is necessary to first determine whether the condition element—whether the fund is an ETF—meets the "yes" condition. When verification conditions exist in the data parsed by the verification rule, each existing verification condition must be stored in the preset condition table constructed in the database according to the rule number. It is understandable that since each verification condition may include multiple data items such as condition type, condition element, and condition auxiliary information, using a separate preset condition table (different from the preset rule table) for storage facilitates the understanding and maintenance of the verification rules.

[0103] S180: If there is verification type auxiliary information corresponding to the verification type in the verification rule parsing data, store the verification type auxiliary information in the preset auxiliary information table of the database.

[0104] Specifically, some validation types lack auxiliary information, such as non-empty validation and element non-existence validation. If the validation rule parsing data contains auxiliary information corresponding to the validation type, such as validation types like enumeration value validation, value range validation, fixed format validation, cross-reference validation, comparison validation, and validation requiring at least one condition to be met, then the corresponding auxiliary information for each validation type should be stored in a pre-defined auxiliary information table built in the database, according to the rule number.

[0105] In one embodiment, the number of preset auxiliary information tables is multiple. For example... Figure 6 As shown, S140 includes the following steps:

[0106] S181: Determine the target auxiliary information table from each preset auxiliary information table according to the verification type.

[0107] Specifically, since the auxiliary information for certain validation types may include multiple data items—for example, the auxiliary information for validation rule RULE6 in Table 2 includes relation types and comparison elements—and within a single validation rule, the same validation element may have multiple relation types and comparison elements, a separate preset auxiliary information table is used to store these validation rules for ease of understanding and maintenance. It is understandable that multiple preset auxiliary information tables can be constructed in the database based on the validation types for which auxiliary information exists. Examples of preset auxiliary information tables include: reconciliation relation tables, enumeration value tables, range value tables, element-to-element value relation tables, and multi-element rule tables. Furthermore, based on the correspondence between validation types and preset auxiliary information tables, the target auxiliary information table is determined from each preset auxiliary information table.

[0108] S182: Store the verification type auxiliary information into the target auxiliary information table. Specifically, after determining the target auxiliary information table, the verification type auxiliary information corresponding to the verification type can be stored into its corresponding target auxiliary information table one by one according to the rule number.

[0109] In one embodiment, after S120 and before S140, S160, and S180, S100 further includes: performing a validity check on the parsed data of the validation rules. It is understood that only the parsed data of the validation rules that passes the validity check will be pre-stored in the database. Performing a validity check before pre-stored the parsed data of the validation rules can reduce invalid execution in report data validation and improve the efficiency of report data validation.

[0110] In one embodiment, the validity check of the parsed data for verification rules includes: checking whether the verification element exists in the report definition of the report to be verified; checking whether the elements involved in the verification conditions exist in the report definition; and checking whether the verification type belongs to one of the preset verification types. The report definition is the collection of all elements in the report to be verified, providing a standardized description of the name, meaning, and number of each data item in the report. The report definition can be obtained from official data released by regulatory agencies or after the report verification party has defined it in a standardized manner. It can be understood that the validity check of the parsed data for verification rules only passes if the verification element exists in the report definition of the report to be verified, the elements involved in the verification conditions exist in the report definition, and the verification type belongs to one of the preset verification types. If any one of these conditions is not met, the validity check of the parsed data for verification rules fails and needs to be re-verified.

[0111] The following is Figure 7 Using the data flow diagram of the report data verification method shown in the figure as an example, a detailed embodiment of the report data verification method provided in this application will be described.

[0112] Specifically, the report data verification method mainly includes the following two modules: (1) the rule management part, whose main function is to parse the verification rules and store them in the database; (2) the data verification part, whose main function is to verify the fund report data according to the verification rules and store the verification results in the database.

[0113] The rule management section includes the entry and parsing of rules. A parsed rule contains the following:

[0114] (1) Elements that need to be validated, such as fund master code, fund name, etc. After the report is generated, the elements include element ID, element name and element value.

[0115] (2) Verification conditions: Verification is only required if certain conditions are met; such as whether it is a MOM fund, whether the fund category is QDII, etc.; all conditions are derived from report information.

[0116] (3) Verification type, the verification types include the following eight categories: 1) Not empty, the element value cannot be empty; 2) The element does not exist; for example, the cumulative net value growth rate element cannot exist in the report; 3) The element value is an enumerated value, such as the valid values ​​of fund type are: equity fund, mixed fund, bond fund, money market fund, QDII, fund of funds, commodity fund; 4) The value is a certain range, such as the reasonable range of fund unit net value on the benchmark date: 0 to 200; 5) The value is a fixed format, such as the fund trading code must be present and be a six-digit number; 6) The values ​​satisfy the reconciliation relationship, such as the total accrued interest on trading financial assets = stocks + precious metal investment - gold contracts of the gold exchange + bonds + asset-backed securities + funds + others; 7) The values ​​satisfy the relationship, such as the effective date of the fund contract <= the data range, before the change of the fund management company name! = after the change of the fund management company name; 8) At least one condition is met, such as at least one of the following elements should have the value "yes": appointing a fund manager, dismissing a fund manager.

[0117] As we can understand, a complete validation rule includes the report type and the three pieces of information described above: the element to be validated, the validation conditions, the validation type, and auxiliary information for the validation type. After the validation rules are entered by the user or imported in batches, they need to be validated for validity and parsed into the database.

[0118] The rule validity verification includes the following three aspects:

[0119] (1) The element exists in the report definition, and the report definition contains the definition of the report element;

[0120] (2) If the element in the verification condition exists in the report definition, it is verified in the same way as (1);

[0121] (3) Verification type validation: Only the eight rules in the above rule types are allowed.

[0122] Rules that pass verification are parsed and stored in the database. To store the information required for various rules, the following tables are designed to store rule-related information: (1) Rule table; (2) Condition table; (3) Relationship table; (4) Enumerated value table; (5) Range value table; (6) Value relationship table between elements; (7) Multi-element rule table. During parsing, verification conditions are stored in the Condition table, and rule type and element information are stored in the Rule table. According to different verification types, auxiliary information is filled into the corresponding tables. The specific operations are as follows:

[0123] (1) Not empty; no auxiliary information;

[0124] (2) The element does not exist; there is no auxiliary information.

[0125] (3) The element value is an enumeration value; the auxiliary information is an enumeration value, which should be filled into the enumeration value table;

[0126] (4) The value is a certain range; the auxiliary information is the starting value of the range, which should be filled in the range value table;

[0127] (5) Values ​​are in a fixed format; auxiliary information is a regular expression, which is filled into the rule table.

[0128] (6) The values ​​satisfy a reciprocal relationship; the auxiliary information is the reciprocal relationship expression, which should be filled into the reciprocal relationship table;

[0129] (7) Values ​​satisfy a relationship; auxiliary information includes the elements being compared and the type of relationship, which should be filled into the value relationship table between elements;

[0130] (8) At least one condition is met; select the first element and its value and store it in the rule table; store the remaining elements in the multi-element rule table.

[0131] Furthermore, the data validation section is used to validate the data in the reports. During validation, the data to be validated is obtained according to the validation conditions, the validation is performed, and the validation results are stored in the database. In specific operations, it is divided into database calculation validation and application calculation validation, depending on the validation type.

[0132] The database verification calculation includes the following steps:

[0133] (1) Read the elements and rules to be verified according to the verification conditions and put them into the intermediate table;

[0134] (2) For validation types 1, 3, 4, and 5, directly verify whether the value in the intermediate table meets the conditions; use database non-null checks, value ranges, and regular expression matching to determine whether the element conforms to the rules;

[0135] (3) If the element of type 2 does not exist, directly verify that the element does not exist in the intermediate table;

[0136] (4) For verification type 6, it is necessary to use the database's custom function to read all the element values ​​in the reconciliation relationship into a temporary variable, calculate the value of the expression based on the reconciliation expression, and compare it with the element values ​​in the rule; for example, the total accrued interest on trading financial assets = stocks + precious metal investment - gold exchange gold contracts + bonds + asset-backed securities + funds + others, it is necessary to read the values ​​of stocks, precious metal investment - gold exchange gold contracts, bonds, asset-backed securities, funds, and others respectively, calculate their sum, and then compare it with the total accrued interest on trading financial assets;

[0137] (5) Then the verification results are stored directly in the database. The entire process is processed in the database, without the need to read the data into memory.

[0138] Application verification calculations include the following steps:

[0139] (1) Read the elements to be verified, associated elements and rules into memory according to the verification conditions;

[0140] (2) For verification type 7, the application performs verification based on the verification element value, the element value to be compared and the relationship, and obtains the verification result;

[0141] (3) For verification type 8, the application performs verification based on the verification element value, associated element value and target value, and obtains the verification result;

[0142] (4) Then store the verification results in the database.

[0143] In this embodiment, the applicable verification condition types and verification types can be decomposed according to the scenario of fund report data verification. This allows business personnel to configure verification rules based on these verification condition types and verification types, without the need to use the rule engine's DSL language, reducing the learning cost for business personnel and making it easier for them to flexibly adjust the rules.

[0144] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to 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 embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0145] Based on the same inventive concept, this application also provides a report data verification device for implementing the report data verification method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more report data verification device embodiments provided below can be found in the limitations of the report data verification method described above, and will not be repeated here.

[0146] In one embodiment, such as Figure 8 As shown, a report data verification device is provided, including: a report and rule determination module 810, a verification data determination module 820, a verification program determination module 830, and a verification execution module 840, wherein:

[0147] The report and rule determination module 810 is used to determine the report to be verified and, based on the report type of the report to be verified, determine the target verification rule parsing data corresponding to the report to be verified from the pre-stored verification rule parsing data. The verification rule parsing data includes verification elements and verification types.

[0148] The verification data determination module 820 is used to determine the verification data of the report to be verified based on the verification elements.

[0149] The verification procedure determination module 830 is used to determine the target verification procedure from each preset verification procedure according to the verification type;

[0150] The verification execution module 840 is used to parse data based on the target verification program and target verification rules, verify the data to be verified, and obtain the verification result corresponding to the report to be verified.

[0151] In this embodiment, based on the scenario of fund report data verification, verification rule parsing data corresponding to the report type is decomposed and pre-stored. This allows business personnel to initiate a verification request based on the report to be verified, and then directly obtain the verification rules according to the report type to be verified to perform the verification. There is no need to redevelop the complex programming language of the rule engine, which reduces the learning cost for business personnel. The method of pre-storing verification rules in the database also makes it easier for business personnel to flexibly adjust the rules.

[0152] In one embodiment, the verification types include non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, cross-reference verification, comparison relationship verification, and verification of at least one condition. The types of the preset verification program include database verification type and memory verification type.

[0153] The verification program determination module 830 is also used to determine the target verification program as a database verification type when the verification type is any one of non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, and reconciliation relationship verification; and to determine the target verification program as a memory verification type when the verification type is comparison relationship verification or at least one of the condition verifications is met.

[0154] In one embodiment, the verification execution module 840 is further configured to, when the target verification program is a database verification type, parse the data based on the target verification rules and directly verify the data to be verified in the database according to the execution logic of the target verification program; when the target verification program is a memory verification type, after retrieving the target verification rule parsing data and the data to be verified from the database into memory, verify the data to be verified based on the target verification rule parsing data and according to the execution logic of the target verification program.

[0155] In one embodiment, when the target verification program is a database verification type, the execution logic of the target verification program determined by the verification program determination module 830 is a dynamic structured query language generated based on the verification type.

[0156] In one embodiment, the apparatus further includes:

[0157] The rule parsing module is used to obtain the verification rule file and parse the verification rule file to obtain the verification rule parsing data; the verification rule parsing data also includes at least one of the following: verification conditions and verification type auxiliary information;

[0158] The rule pre-storage module is used to store the verification type and verification element in the parsed data of the verification rule into the preset rule table of the database; if there is a verification condition in the parsed data of the verification rule, the verification condition is stored into the preset condition table of the database; if there is verification type auxiliary information corresponding to the verification type in the parsed data of the verification rule, the verification type auxiliary information is stored into the preset auxiliary information table of the database.

[0159] In one embodiment, the number of preset auxiliary information tables is multiple;

[0160] The rule pre-storage module is also used to determine the target auxiliary information table from each preset auxiliary information table according to the verification type; and to store the verification type auxiliary information into the target auxiliary information table.

[0161] In one embodiment, the device further includes:

[0162] The rule validity check module is used to check the validity of the parsed data of the validation rules.

[0163] In one embodiment, the rule validity checking module is further used to check whether the verification element exists in the report definition of the report to be verified; check whether the elements involved in the verification conditions exist in the report definition; and check whether the verification type belongs to one of the preset verification types.

[0164] Each module in the aforementioned report data verification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0165] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs in the non-volatile storage media to run. The database stores report data to be verified and verification rule parsing data. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a report data verification method.

[0166] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0167] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0168] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0169] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0170] 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 a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data verification logic devices, etc., and are not limited to these.

[0171] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0172] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for validating report data, characterized in that, The method includes: In response to the verification start request, the report to be verified is determined, and the target verification rule parsing data corresponding to the report to be verified is determined from the pre-stored verification rule parsing data according to the report type of the report to be verified. The verification rule parsing data includes verification elements and verification type. The data to be verified in the report to be verified is determined based on the verification element. The target verification procedure is determined from each preset verification procedure according to the verification type; When the target verification program is a database verification type, the data is parsed based on the target verification rules, and the data to be verified is directly verified in the database according to the execution logic of the target verification program to obtain the verification result corresponding to the report to be verified; the database verification type indicates that the target verification program is constructed using a dynamic structured query language. When the target verification program is a memory verification type, after the target verification rule parsing data and the data to be verified are retrieved from the database into memory, the data to be verified is verified according to the execution logic of the target verification program based on the target verification rule parsing data to obtain the verification result corresponding to the report to be verified; the memory verification type indicates that the target verification program is constructed using a computer-readable programming language.

2. The method according to claim 1, characterized in that, The verification types include non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, cross-reference verification, comparison relationship verification, and verification that at least one condition is met. The types of the preset verification program include database verification type and memory verification type. The step of determining the target verification program from each preset verification program according to the verification type includes: If the verification type is any one of the following: non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, and reconciliation relationship verification, then the target verification program is determined to be a database verification type. If the verification type is a comparison relationship verification or at least one of the condition verifications is satisfied, the target verification program is determined to be a memory verification type.

3. The method according to claim 2, characterized in that, When the target validation program is a database validation type, the execution logic of the target validation program is a dynamic structured query language generated based on the validation type.

4. The method according to any one of claims 1 to 3, characterized in that, The process of acquiring and pre-storing the verification rule parsing data includes: Obtain a verification rule file and parse the verification rule file to obtain the verification rule parsing data; the verification rule parsing data also includes at least one of verification conditions and verification type auxiliary information; The verification type and verification element in the parsed data of the verification rules are stored in the preset rule table of the database; If a verification condition exists in the parsed data of the verification rule, the verification condition is stored in a preset condition table in the database. If the verification type auxiliary information corresponding to the verification type exists in the verification rule parsing data, the verification type auxiliary information is stored in the preset auxiliary information table of the database.

5. The method according to claim 4, characterized in that, The number of the preset auxiliary information tables is multiple; when verification type auxiliary information corresponding to the verification type exists in the verification rule parsing data, storing the verification type auxiliary information into the preset auxiliary information table of the database includes: The target auxiliary information table is determined from each of the preset auxiliary information tables according to the verification type; The verification type auxiliary information is stored in the target auxiliary information table.

6. The method according to claim 4, characterized in that, After obtaining the parsed data of the verification rules, and before pre-storing it in the database, the method further includes: The validity of the data parsed by the verification rules is checked.

7. The method according to claim 6, characterized in that, The validity check of the parsed data of the verification rules includes: Check whether the verification element exists in the report definition of the report to be verified; Check whether the elements involved in the verification conditions exist in the report definition; Check whether the verification type belongs to one of the preset verification types.

8. A report data verification device, characterized in that, The device includes: The report and rule determination module is used to respond to the verification start request, determine the report to be verified, and determine the target verification rule parsing data corresponding to the report to be verified from the pre-stored verification rule parsing data according to the report type of the report to be verified. The verification rule parsing data includes verification elements and verification types. The verification data determination module is used to determine the verification data of the report to be verified based on the verification elements. The verification procedure determination module is used to determine the target verification procedure from each preset verification procedure according to the verification type; The verification execution module is used to, when the target verification program is a database verification type, parse data based on the target verification rules, and directly verify the data to be verified in the database according to the execution logic of the target verification program to obtain the verification result corresponding to the report to be verified; the database verification type indicates that the target verification program is constructed using a dynamic structured query language; when the target verification program is a memory verification type, after retrieving the target verification rule parsing data and the data to be verified from the database into memory, verify the data to be verified based on the target verification rule parsing data and according to the execution logic of the target verification program to obtain the verification result corresponding to the report to be verified; the memory verification type indicates that the target verification program is constructed using a computer-readable programming language.

9. The apparatus according to claim 8, characterized in that, The verification types include non-empty verification, element non-existence verification, enumeration value verification, value range verification, fixed format verification, cross-reference verification, comparison relationship verification, and verification that at least one condition is met. The types of the preset verification program include database verification type and memory verification type. The verification procedure determination module is further configured to determine the target verification procedure as a database verification type when the verification type is any one of the non-empty verification, the element non-existence verification, the enumeration value verification, the value range verification, the fixed format verification, and the reconciliation relationship verification; and to determine the target verification procedure as a memory verification type when the verification type is comparison relationship verification or at least one of the condition verifications.

10. The apparatus according to claim 9, characterized in that, When the target validation program is a database validation type, the execution logic of the target validation program determined by the validation program determination module is a dynamic structured query language generated according to the validation type.

11. The apparatus according to any one of claims 8 to 10, characterized in that, The device further includes: The rule parsing module is used to obtain a verification rule file and parse the verification rule file to obtain the verification rule parsing data; the verification rule parsing data also includes at least one of verification conditions and verification type auxiliary information. The rule pre-storage module is used to store the verification type and verification element in the verification rule parsing data into a preset rule table in the database; if there is a verification condition in the verification rule parsing data, store the verification condition into a preset condition table in the database; if there is verification type auxiliary information corresponding to the verification type in the verification rule parsing data, store the verification type auxiliary information into a preset auxiliary information table in the database.

12. The apparatus according to claim 11, characterized in that, The number of the preset auxiliary information tables is multiple; The rule pre-storage module is also used to determine the target auxiliary information table from each of the preset auxiliary information tables according to the verification type; The verification type auxiliary information is stored in the target auxiliary information table.

13. The apparatus according to claim 11, characterized in that, The device further includes: The rule validity check module is used to check the validity of the parsed data of the verification rules.

14. The apparatus according to claim 13, characterized in that, The rule validity checking module is also used to check whether the verification element exists in the report definition of the report to be verified; to check whether the elements involved in the verification condition exist in the report definition; and to check whether the verification type belongs to one of the preset verification types.

15. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

17. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images