A method, medium and device for auditing and checking asset statement data

Abstract

The application discloses an asset statement data auditing and checking method, medium and equipment, which first receives an auditing formula based on statement row and column coordinates, and carries out lexical and syntactic analysis to generate an abstract syntax tree; subsequently, a cell dependency graph is constructed based on the tree structure, and executable code is dynamically generated through compilation conversion to efficiently execute data checking. The core lies in that when checking fails, a cause-effect reasoning engine is started, upstream data nodes are reversely traversed according to the dependency graph, node value adjustment in a reasonable value range is carried out and simulation execution is carried out, confidence score of each node is calculated by combining adjustment amplitude and historical error frequency, high-probability root cause cells are accurately determined, and a diagnosis report containing information and recommended adjustment value of the root cause cells is generated. The above scheme not only improves the auditing efficiency of asset statements, but also accurately locates the root of error data, and improves the intelligent level of statement auditing.

Description

Technical Field

[0001] This application relates to the field of data processing and intelligent diagnosis, specifically to a method, medium, and device for auditing and verifying asset report data. Background Technology

[0002] In asset management within administrative and public institutions, generating reports based on asset data is a crucial task. To ensure the accuracy and compliance of the report data, it is typically necessary to validate the data according to pre-defined audit rules. For example, this might involve verifying whether the values ​​in specific columns of a report equal the sum of their related sub-items, or verifying whether specific coded fields conform to prescribed format standards. The reporting system must execute data validation according to these rules and logic, and then provide the validation results to relevant personnel for data correction until the data passes validation.

[0003] Currently, a common approach to validation is to execute audit rules using SQL statements. Each SQL statement corresponds to one or more validation rules, identifying data that does not conform to the rules by querying the database. However, this method has significant efficiency bottlenecks in practical applications. Due to the large number of rules involved in report auditing, a single audit by a single unit requires executing numerous SQL queries, placing enormous pressure on the database and network I / O. During centralized reporting periods, when a large number of units submit and audit reports simultaneously, system processing time increases significantly, making it difficult to meet the demands for efficient processing.

[0004] Furthermore, existing verification methods have another significant drawback: when a verification rule fails, the system typically only reports the rule failure, without automatically and accurately pinpointing the specific data source causing the failure. For example, when the system indicates "total assets are not equal to the sum of all sub-items," the reporting personnel still need to manually check all related sub-item data, examining and comparing them one by one to find out which data item(s) was entered incorrectly. This manual checking process is inefficient, prone to oversights, and highly dependent on the professional experience of the operators, especially when there are many data items and complex interrelationships, seriously affecting the overall efficiency and data quality of report compilation.

[0005] Therefore, existing technologies urgently need a method that can automatically and accurately locate the root cause of data errors when verification fails, so as to quickly and clearly indicate the specific data location that caused the violation of the rules, thereby replacing inefficient and error-prone manual inspection and improving the intelligence level and processing efficiency of report review. Summary of the Invention

[0006] In view of the above problems, this application provides a technical solution for auditing and verifying asset statement data, which solves the technical problem that relying on manual verification in asset statement data auditing leads to low efficiency and makes it impossible to quickly and accurately locate the root cause of the data failure.

[0007] To achieve the above objectives, in a first aspect, this application provides a method for auditing and verifying asset statement data, the method comprising the following steps:

[0008] S1: Receive the audit formula of the asset report, wherein the audit formula is a logical judgment expression containing data cell references based on the row and column coordinates of the report;

[0009] S2: Perform lexical and syntactic analysis on the audit formula to generate an abstract syntax tree, wherein the leaf nodes of the abstract syntax tree are data cell references or constant values, and the non-leaf nodes are operators;

[0010] S3: Based on the abstract syntax tree, construct a cell dependency graph, wherein the nodes of the dependency graph represent data cells, and the edges represent the computational dependencies between data cells;

[0011] S4: Traverse the abstract syntax tree, and through compilation and transformation, map the data cell references to access instructions for the asset report data matrix in the memory data area, and map the operators to the corresponding operation instructions to dynamically generate executable code;

[0012] S5: Load the asset report data of the unit to be audited into the memory data area to obtain the asset report data matrix, execute the executable code, and verify the asset report data;

[0013] S6: When the verification fails, start the causal reasoning engine and perform the following operations:

[0014] Based on the cell dependency graph, starting from the formula node that failed the validation, all upstream data nodes are traversed in reverse order.

[0015] For the upstream data nodes that are traversed, the values ​​are adjusted within a preset reasonable range, and the executable code is simulated to obtain the simulation verification results;

[0016] Based on the simulation verification results, for each upstream data node that is traversed, a confidence score is calculated as the root cause of the verification failure. The confidence score is calculated based on the value adjustment range of the upstream data node and its error frequency in historical verification.

[0017] The upstream data node with the highest confidence score is identified as a high-probability root cause cell, and a diagnostic report containing information about the high-probability root cause cell and suggested adjustment values ​​is generated.

[0018] Furthermore, step S4 specifically includes:

[0019] Traverse the abstract syntax tree, identify data cell references in the abstract syntax tree, and generate corresponding access instructions based on the data cell references. The access instructions are used to obtain the corresponding values ​​from the asset report data matrix and to convert operators and logical judgments into corresponding basic operation instructions.

[0020] A separate Java class method is generated for each of the aforementioned audit formulas. The generated Java code is compiled into bytecode, and the bytecode is loaded into the runtime environment using dynamic class loading.

[0021] Furthermore, in step S5, the asset report data of the entity to be audited is loaded into the memory data area to obtain the asset report data matrix, which includes:

[0022] Obtain the predefined mapping relationship between report row and column coordinates and globally unique identifiers, and convert the report row and column coordinates of data cells in the report data into the corresponding globally unique identifiers based on the mapping relationship;

[0023] Using the globally unique identifier as the key and the values ​​in the data cells as the values, a hash table is constructed as the asset report data matrix.

[0024] Furthermore, in step S5, executing the executable code to verify the asset report data includes:

[0025] The compiled executable code corresponding to each audit formula is categorized according to the formula category to which each executable code belongs, and a hash table index is built using the formula category code as the key to construct a formula method hash table. The key of the formula method hash table is the formula category code, and the value is a list of formula methods belonging to that formula category.

[0026] Based on the formula category code to be verified, the corresponding formula method list is searched from the formula method hash table;

[0027] Iterate through the list of formula methods, and for each formula method, perform the following operations:

[0028] Call the formula method;

[0029] During the execution of the formula method, the values ​​of the data cells referenced by the formula method are obtained by querying the loaded asset report data matrix. Logical judgment is performed based on the obtained data cell values ​​to obtain the actual verification result of Boolean type.

[0030] The actual verification result is associated with the report identifier and audit formula identifier that generated the actual verification result and stored in the database.

[0031] Furthermore, after generating the abstract syntax tree in step S2, the following steps are also included:

[0032] The abstract syntax tree is converted into a declarative constraint model, wherein the logical statements of the abstract syntax tree are converted into one or more declarative constraints, each declarative constraint defining a mathematical relationship that must be satisfied between the data cells associated with it.

[0033] In step S5, after executing the executable code to verify the asset report data, the following steps are also included:

[0034] If the verification fails, the declarative constraint model corresponding to the verification formula that failed is activated. The declarative constraint model is solved by reversible calculation to calculate the feasible value range of one or more data cells that can make the declarative constraint condition true.

[0035] Based on the cell dependency graph, all upstream audit formulas that have computational dependencies with the audit formula that failed the current verification are identified, forming a rule influence set;

[0036] Based on historical business rule execution data, the business impact weight is calculated for each audit formula in the rule impact set. Root cause impact analysis is performed based on the rule impact set and the business impact weight to generate a rule impact ripple diagram. The rule impact ripple diagram is used to visually display the rule error propagation path caused by the root cause cell of the current verification failure, and the severity of the affected nodes on the error propagation path is marked according to the business impact weight.

[0037] The feasible value range and the influence effect diagram of the rule are recorded in the diagnostic report.

[0038] Furthermore, in step S5, after obtaining the asset report data matrix, the following steps are also included:

[0039] The system monitors data cells in the asset report data matrix that are referenced by any audit formula in the cell dependency graph. When a change in the value of any monitored data cell is detected, the system automatically and asynchronously calls all executable code segments corresponding to the audit formulas that directly depend on that data cell to perform streaming verification and generate streaming verification results. The streaming verification includes: verifying only the audit formulas that have become pending verification due to the change in the value of the data cell.

[0040] Based on historical cell value data, a value fluctuation benchmark is established for each audit formula and its associated data cell. When a change in the value of the monitored data cell is detected, if the difference between the current value of the monitored data cell and the value fluctuation benchmark exceeds a preset difference, a value anomaly prompt is generated.

[0041] Furthermore, the method also includes:

[0042] When the streaming validation result indicates that any audit formula fails validation, based on the cell dependency graph, a set of other audit formulas that have a cascading relationship with the currently failed audit formula in business logic is determined, and a cascading risk warning is generated.

[0043] The verification health score and comprehensive risk index of the current asset report are dynamically calculated and updated. The verification health score is obtained by weighting the pass rate of the current streaming verification of all audit formulas and the severity of the numerical anomaly prompts. The comprehensive risk index is obtained by integrating the number of audit formulas that failed the streaming verification and their business importance weights, the number of audit formulas involved in the cascading risk prompts and their business importance weights, and the severity of the numerical anomaly prompts.

[0044] The health score, the comprehensive risk index, the abnormal value prompts, and the cascading risk prompts are all recorded and updated in the diagnostic report.

[0045] Furthermore, after generating the abstract syntax tree, the following two construction processes are executed in parallel based on the same set of abstract syntax trees:

[0046] Perform step S3 to construct a cell dependency graph for causal reasoning;

[0047] The construction of the execution rule semantic graph includes the following steps:

[0048] Analyzing the structure of the abstract syntax tree, the audit formula is parsed into structured logical constraints that represent the numerical relationships between cells; wherein, the structured logical constraints include equality constraints that define the operational relationships between cells and inequality constraints that limit the range of cell values;

[0049] The equality constraints and inequality constraints are used as semantic metadata and associated with the corresponding nodes in the cell dependency graph to form an enhanced rule semantic graph; wherein, the equality constraints are associated with the cell nodes that are the calculation results, and the inequality constraints are associated with the constrained cell nodes.

[0050] Before loading the asset report data of the entity to be audited, the structured logical constraints in the enhanced rule semantic graph are traversed to verify whether there are logical contradictions between the structured logical constraints that cannot be satisfied simultaneously, and the set of audit formulas with contradictions is summarized.

[0051] When step S6 is executed and the causal reasoning engine is started, the enhanced rule semantic graph is queried to obtain the structured logical constraints corresponding to the target formula that caused the current verification failure. Based on the structured logical constraints, a business semantic explanation describing the direct cause of the current verification failure is generated.

[0052] The business semantic interpretation is fused with the root cause diagnosis results obtained by the causal reasoning engine and output together to the diagnosis report.

[0053] In a second aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the asset report data audit and verification method as described in the first aspect of this application.

[0054] In a third aspect, this application provides an electronic device having a computer program stored thereon, including a processor and a storage medium, wherein the computer program is stored on the storage medium, and when executed by the processor, the computer program implements the asset report data audit and verification method as described in the first aspect of this application.

[0055] Unlike existing technologies, the above-mentioned technical solution involves a method, medium, and device for auditing and verifying asset report data. This method first receives audit formulas based on the row and column coordinates of the report and performs lexical and syntactic analysis to generate an abstract syntax tree. Subsequently, a cell dependency graph is constructed based on this tree structure, and executable code is dynamically generated through compilation and conversion for efficient data verification. Its core lies in: when verification fails, a causal inference engine is activated, traversing upstream data nodes in reverse according to the dependency graph. By adjusting node values ​​within a reasonable range and simulating execution, the confidence score of each node is calculated based on the adjustment magnitude and historical error frequency. This accurately identifies high-probability root cause cells and generates a diagnostic report containing their information and suggested adjustment values. This solution not only improves the efficiency of asset report auditing but also accurately locates the root cause of erroneous data, enhancing the intelligence level of report auditing.

[0056] The above description of the invention is merely an overview of the technical solution of this application. In order to enable those skilled in the art to better understand the technical solution of this application and to implement it based on the description and drawings, and to make the above-mentioned objectives and other objectives, features and advantages of this application easier to understand, the following description is provided in conjunction with the specific embodiments and drawings of this application. Attached Figure Description

[0057] The accompanying drawings are only used to illustrate the principles, implementation methods, applications, features, and effects of specific embodiments of this application and other related content, and should not be considered as limitations on this application.

[0058] In the accompanying drawings of the instruction manual:

[0059] Figure 1 This is a flowchart of the asset report data audit and verification method described in the first exemplary embodiment of this application;

[0060] Figure 2 This is a flowchart of the asset report data audit and verification method described in the second exemplary embodiment of this application;

[0061] Figure 3 This is a flowchart of the asset report data audit and verification method described in the third exemplary embodiment of this application;

[0062] Figure 4 This is a flowchart of the asset report data audit and verification method described in the fourth exemplary embodiment of this application;

[0063] Figure 5 This is a flowchart of the asset report data audit and verification method described in the fifth exemplary embodiment of this application;

[0064] Figure 6 This is a flowchart of the asset report data audit and verification method described in the sixth exemplary embodiment of this application;

[0065] Figure 7 This is a flowchart of the asset report data audit and verification method described in the seventh exemplary embodiment of this application;

[0066] Figure 8 This is a flowchart of the asset report data audit and verification method described in the eighth exemplary embodiment of this application;

[0067] Figure 9 This is a flowchart of the asset report data audit and verification method described in the ninth exemplary embodiment of this application;

[0068] Figure 10 This is a schematic diagram of an electronic device according to an exemplary embodiment of this application;

[0069] The reference numerals used in the above figures are explained as follows:

[0070] 10. Electronic equipment; 101. Processor; 102. Storage medium. Detailed Implementation

[0071] To explain in detail the possible application scenarios, technical principles, specific feasible solutions, and the objectives and effects that this application can achieve, the following detailed description is provided in conjunction with the listed specific embodiments and accompanying drawings. The embodiments described herein are only used to more clearly illustrate the technical solutions of this application, and are therefore only examples, and should not be used to limit the scope of protection of this application.

[0072] In the first aspect, such as Figure 1 As shown, this application provides a method for auditing and verifying asset statement data, the method comprising:

[0073] S1: Receive the audit formula of the asset report, wherein the audit formula is a logical judgment expression containing data cell references based on the row and column coordinates of the report;

[0074] S2: Perform lexical and syntactic analysis on the audit formula to generate an abstract syntax tree, wherein the leaf nodes of the abstract syntax tree are data cell references or constant values, and the non-leaf nodes are operators;

[0075] S3: Based on the abstract syntax tree, construct a cell dependency graph, wherein the nodes of the dependency graph represent data cells, and the edges represent the computational dependencies between data cells;

[0076] S4: Traverse the abstract syntax tree, and through compilation and transformation, map the data cell references to access instructions for the asset report data matrix in the memory data area, and map the operators to the corresponding operation instructions to dynamically generate executable code;

[0077] S5: Load the asset report data of the unit to be audited into the memory data area to obtain the asset report data matrix, execute the executable code, and verify the asset report data;

[0078] S6: When the verification fails, start the causal reasoning engine.

[0079] In this embodiment, the audit formula conforms to the specifications of the "Integrated Budget Management Technical Standard" and includes logical judgment expressions based on data cell references based on report row and column coordinates, such as "CZ01[1,2]>0" (meaning that the value of the cell in the first row and second column of report code CZ01 must be greater than 0). It supports syntax such as custom functions, categorized summary functions, looping row and column wildcards, and previous period number identifiers.

[0080] An Abstract Syntax Tree (AST) is a tree-like data structure formed by transforming a formula through lexical and syntactic analysis. Leaf nodes are data cell references (such as "CZ01[1,2]") or constant values ​​(such as "0"), while non-leaf nodes are operators (such as ">", "+") or functions (such as "SUBSTRING ()"). It is used to clearly represent the syntactic structure and computational logic of the formula.

[0081] Cell dependency graphs are directed graphs built on abstract syntax trees. Nodes represent data cells (such as "CZ01_001_JE1", which is a globally unique identifier for a specific cell in report CZ01), and edges represent computational dependencies between cells (such as the value of cell A being obtained by summing cells B and C, so there are edges B→A and C→A), used to trace the upstream and downstream relationships in data computation.

[0082] In step S1, the system receives the ministerial standard audit formula issued by the finance department through the integrated budget management platform, or the audit formula customized by the user based on the compilation instructions and conforming to the ministerial standard syntax. The audit formula must contain explicit data cell references (based on report row and column coordinates) and logical judgment relationships (such as equal to, greater than, not equal to, etc.) to ensure that it can be recognized by the subsequent parsing module.

[0083] In step S2, Antlr (a parser generation tool) is used to define the lexical and grammatical rules for the standard verification formula, and the corresponding grammar file (such as a .g4 file) is written. After the parser reads the content of the verification formula, lexical analysis is performed first, which breaks down the verification formula into the smallest semantic units (lexical units). For example, "CZ01 [1,2]>0" is broken down into "CZ01", "[", "1", ",", "2", "]", ">", and "0". Then, grammatical analysis is performed, which combines the lexical units into a valid grammatical structure according to the grammar rules, and finally generates an abstract syntax tree.

[0084] Taking the audit formula “CZ01[1,2]>0” as an example, the root node of its abstract syntax tree is the logical operator ">", the left child node is the data cell reference “CZ01[1,2]”, and the right child node is the constant value “0”. If the audit formula is “CZ01[1,3]=CZ01[1,1]+CZ01[1,2]”, then the root node is “=", the left child node is “CZ01[1,3]”, and the right child node is “+”. The two child nodes of “+” are “CZ01[1,1]” and “CZ01[1,2]”.

[0085] In step S3, based on the abstract syntax tree generated in step S2, all data cell reference nodes in the tree are traversed to determine the computational dependencies between cells: if there is a logic "cell A = cell B + cell C" in the abstract syntax tree, then cell A depends on cells B and cell C; if there is a logic "cell D > SUM (cell E1: cell E10)", then cell D depends on cells E1 to E10.

[0086] The above dependencies are mapped to a directed graph, using the globally unique identifier of each cell as a node and the direction of the edges as "dependency → dependent". For example, if cell A depends on B and C, then the dependency graph contains edges "B→A" and "C→A", which are used for root cause tracing when subsequent validation fails.

[0087] In step S4, the abstract syntax tree generated in step S2 is traversed, and the syntax tree is converted into executable code according to preset code generation rules, specifically including:

[0088] Cell reference mapping: This maps row and column coordinate references in the abstract syntax tree (such as "CZ01[1,2]") to access instructions for the asset report data matrix in the memory data area. For example, through the "row and column coordinates - globally unique identifier" mapping relationship, "CZ01[1,2]" is converted into the globally unique identifier "CZ01_001_JE2", and the access instruction is "dataMap.get ("CZ01_001_JE2")" (where dataMap is a hash table in the memory data area).

[0089] Operator and function mapping: This maps operators (such as "+", ">"), logical expressions (such as "AND", "OR"), and user-defined functions (such as "DATE_COMPARE()") in the abstract syntax tree to their corresponding basic arithmetic instructions. For example, ">" is mapped to the ">" operator in Java, and "SUM (cell E1: cell E10)" is mapped to a code snippet that iterates through cells E1 to E10 and sums them.

[0090] After the executable code is generated, each audit formula corresponds to an independent method (such as a Java method), which contains complete verification logic. The generated code is compiled into bytecode and loaded into the runtime environment through dynamic class loading technology (such as Java's ClassLoader). It takes effect without restarting the system, ensuring the flexibility of rule iteration.

[0091] In step S5, the asset report data of the entity to be audited is retrieved from the database. Based on a predefined mapping relationship of "report row and column coordinates - globally unique identifier" (this mapping is constructed based on report metadata issued by the Ministry of Finance, which includes information such as the row and column position of the cell, the globally unique identifier, and the data type), the row and column coordinates of the data cells are converted into globally unique identifiers. Using the globally unique identifier as the key and the cell value as the value, a hash table is constructed as the asset report data matrix and loaded into the memory data area. The loaded executable code is then called to verify the asset report data matrix in the memory data area. During execution, the code retrieves the required cell values ​​from the data matrix through access instructions, performs calculations and logical judgments, and outputs a boolean verification result (true for pass, false for failure).

[0092] Furthermore, such as Figure 2 As shown, step S6 specifically includes:

[0093] S6-1: Based on the cell dependency graph, starting from the formula node that failed the validation, traverse all upstream data nodes in reverse order;

[0094] S6-2: For the upstream data nodes that have been traversed, adjust their values ​​within a preset reasonable range, and simulate the execution of the executable code to obtain the simulation verification result;

[0095] S6-3: Based on the simulation verification results, for each upstream data node that has been traversed, calculate its confidence score as the root cause of the verification failure. The confidence score is calculated based on the value adjustment range of the upstream data node and its error frequency in historical verification.

[0096] S6-4: Identify the upstream data node with the highest confidence score as the high-probability root cause cell and generate a diagnostic report containing the information of the high-probability root cause cell and suggested adjustment values.

[0097] Specifically, starting from the cell corresponding to the failed verification formula (e.g., when the formula “CZ01 [1,3]=CZ01 [1,1]+CZ01 [1,2]” fails, the corresponding cell is “CZ01[1,3]”), based on the cell dependency graph constructed in step S3, all upstream data nodes (i.e. “CZ01 [1,1]” and “CZ01 [1,2]”) are traversed in reverse.

[0098] For each upstream data node traversed, its value is adjusted within a preset reasonable range (this range is determined based on business rules or historical data, such as "the original value of an asset must not be negative and must not exceed 10 times the average original value of similar assets"). After each adjustment, the executable code generated in step S4 is simulated and executed, and the simulation verification result is recorded (if the simulation verification passes after adjustment, the node is determined to be a potential root cause).

[0099] Specifically, the confidence score for each upstream node is calculated based on the following two dimensions, using the following formula:

[0100] Confidence score = 1 - (the proportion of the adjustment range to the reasonable range) × weight of historical error frequency;

[0101] If only a small adjustment is needed (such as a 5% adjustment to pass the simulation verification), then the probability that this node is the root cause is higher, and the smaller the percentage of adjustment, the higher the score. At the same time, the percentage of errors this node has made in past verifications is also considered; the higher the error frequency, the greater the historical weight, and the higher the score.

[0102] Then, the upstream data node with the highest confidence score is identified as the high-probability root cause cell, and a diagnostic report is generated. The diagnostic report includes the root cause cell's globally unique identifier, row and column coordinates, current value, and suggested adjustment value (based on the reasonable value that made the verification pass in the simulation adjustment).

[0103] The above solution converts the audit formula into executable code and verifies it based on an in-memory data matrix, avoiding frequent database queries typical of traditional SQL methods and effectively improving audit efficiency. The method also directly generates code based on the syntax parsing of the ministry's audit formula, reducing the workload of development, testing, and operations personnel and adapting to the rapid iteration of ministry rules. Through cell dependency graphs and causal reasoning engines, the root cause of verification failures is automatically located, avoiding the inefficiency and errors of manual cell-by-cell checks. Reporting personnel can quickly modify data based on diagnostic reports, improving report compilation efficiency.

[0104] In some embodiments, such as Figure 3 As shown, step S4 specifically includes:

[0105] S301: Traverse the abstract syntax tree, identify data cell references in the abstract syntax tree, and generate corresponding access instructions based on the data cell references. The access instructions are used to obtain the corresponding values ​​from the asset report data matrix and to convert operators and logical judgments into corresponding basic operation instructions.

[0106] S302: Generate an independent Java class method for each of the audit formulas, compile the generated Java code into bytecode, and load the bytecode into the runtime environment through dynamic class loading.

[0107] In this embodiment, the access instruction is a code snippet used to retrieve the value of a specified cell from the asset report data matrix in the memory data area. It is constructed based on the globally unique identifier of the cell, such as "dataMap.get("CZ01_001_JE2")" in Java, to ensure the speed and accuracy of data access.

[0108] Basic operation instructions refer to executable code fragments formed by converting operators, logical judgments, and functions in the audit formula. For example, "+" is converted to "a+b", and "SUM ()" is converted to "IntStream.rangeClosed (1,10).map(i->dataMap.get ("CZ01_001_JE"+i)).sum ()", to ensure the correct execution of the formula logic.

[0109] Specifically, the data cell references are first identified by traversing the leaf nodes in the abstract syntax tree and filtering out all data cell references (such as "CZ01[1,2]"). Based on the predefined "report row and column coordinates - globally unique identifier" mapping relationship (this mapping comes from the report metadata issued by the Ministry of Finance), the row and column coordinates are converted into globally unique identifiers (such as "CZ01[1,2]" is converted into "CZ01_001_JE2"). The globally unique identifier is then used as a parameter to generate an access instruction.

[0110] Then, the operators and logical statements are converted. Specifically, the non-leaf nodes in the abstract syntax tree are traversed to convert the operators (such as "+", "-", " / ", ">", "<", "==", etc.) and logical statements (such as "&&", "||, etc.) into the corresponding basic operation instructions.

[0111] For function nodes in the abstract syntax tree (such as "SUBSTRING (cell A,1,6)" and "SUM (cell B1:cell B5)"), basic operation instructions are generated based on the preset function implementation logic. For example, "SUBSTRING (CZ01[2,1],1,6)" (extracting the first 6 characters of the string "CZ01[2,1]") is converted to "getCellValue (dataMap, "CZ01_002_JE1").toString ().substring (0, 6)".

[0112] Then, a separate Java class method is generated for each received audit formula. The method name contains the unique identifier of the formula (such as "validateFormula_0001", where "0001" is the formula number). The parameter of the Java class method is the asset report data matrix (hash table) in the memory data area, and the return value is the validation result of boolean type. If the formula involves multi-cell calculation (such as "CZ01[1,3]=CZ01[1,1]+CZ01[1,2]"), the corresponding method contains the complete logic of multi-cell access, summation operation and equality judgment.

[0113] During compilation and dynamic loading, all generated Java class methods are integrated into a Java source file (e.g., "ReportValidationRules.java"), which is then compiled into bytecode files (.class files) by a Java compiler (e.g., javac). Dynamic class loading technology (e.g., URLClassLoader) is then used to load the bytecode files into the system runtime environment, generating callable class instances. After loading, the system can obtain the method corresponding to each formula through reflection (e.g., Class.getMethod()), allowing validation to be performed without restarting the system and supporting real-time updates and iterations of formulas.

[0114] In other embodiments, hot updating of formula code is achieved through dynamic class loading, avoiding class loading conflicts and memory leaks. Specifically, this includes the following steps:

[0115] Class loader isolation: Create an independent custom class loader (such as inheriting Java's ClassLoader) for each formula update. Different versions of the formula class are loaded by different class loaders, avoiding conflicts caused by "class overriding with the same name".

[0116] Old class unloading trigger: After the new formula class is loaded and verified, the class loader reference corresponding to the old formula class is actively destroyed. At the same time, the memory of the old class is reclaimed through the JVM's garbage collection (GC) mechanism to avoid memory leaks.

[0117] Atomicity guarantee for updates: The atomic operation of "load first, switch later" is adopted. After the new formula class is loaded and the test verification is performed (to ensure no syntax errors), the old method list in the formula method hash table is replaced with the new method list to avoid the intermediate state of "some formulas are available and some are not available" during the update process.

[0118] The above solution converts the audit formulas into native Java methods, avoiding the execution overhead of the interpreted formula engine, effectively improving the calculation speed and meeting the efficiency requirements of batch auditing large-scale reports. Dynamic class loading technology allows the code corresponding to the audit formulas to be updated without restarting the system. When the finance department issues new departmental rules or adjusts existing rules, code generation, compilation, and loading can be completed quickly, adapting to rapid changes in business rules and reducing system downtime.

[0119] In some embodiments, such as Figure 4 As shown, in step S5, the asset report data of the entity to be audited is loaded into the memory data area to obtain the asset report data matrix, which includes:

[0120] S401: Obtain the predefined mapping relationship between report row and column coordinates and globally unique identifiers, and convert the report row and column coordinates of data cells in the report data into the corresponding globally unique identifiers based on the mapping relationship;

[0121] S402: Using the globally unique identifier as the key and the value in the data cell as the value, construct a hash table as the asset report data matrix.

[0122] A hash table (HashMap) is a data structure that stores data based on key-value pairs. It uses a hash function to map keys to memory addresses, enabling fast data insertion, retrieval, and deletion (with an average time complexity of O(1)). In this embodiment, the hash table is used as the storage medium for the asset report data matrix, where the key is a globally unique identifier for the cell, and the value is the cell's numerical value.

[0123] In this embodiment, the mapping relationship is constructed based on the issued report metadata. The metadata includes the code of each report (e.g., "CZ01"), row information (row number, row identifier, row name), column information (column number, column identifier, column name), and a globally unique identifier for each cell (generated by combining the report code, row identifier, and column identifier). For example, if the row identifier corresponding to the first row of report CZ01 is "001" and the column identifier corresponding to the second column is "JE2", then the globally unique identifier for that cell is "CZ01_001_JE2". The correspondence between "report code + row number + column number" and "globally unique identifier" is then stored in the system configuration table or cache to ensure that the mapping relationship can be quickly queried when data is loaded.

[0124] Then, the asset report data of the entity to be audited is queried from a relational database (such as MySQL or Oracle). The query results include fields such as report code, row number, column number, cell value, and entity identifier. For example, the report data record of a certain entity is "Entity code: 35010001, Report code: CZ01, Row number: 1, Column number: 2, Value: 15000.00".

[0125] Then, for each queried report data, the "report code + row number + column number" is converted into the corresponding globally unique identifier based on the obtained mapping relationship. For example, "CZ01,1,2" in the above record is converted into "CZ01_001_JE2".

[0126] Then, using the converted globally unique identifier as the key and the cell value (converted to BigDecimal, String, etc. according to business requirements to ensure that the numerical precision matches the data type) as the value, a hash table (such as a HashMap in Java) is constructed. This hash table is the asset report data matrix. For example, the above record is stored in the hash table as "key:CZ01_001_JE2,value:15000.00".

[0127] The constructed hash table is then loaded into the system's preset memory data area. The memory data area adopts a thread-safe design (such as using ConcurrentHashMap) to support multi-threaded concurrent access, ensuring data security and access efficiency during batch audits.

[0128] The above scheme uses globally unique identifiers instead of row and column coordinates as the keys for data storage and access, avoiding the ambiguity of "the same row and column coordinates corresponding to different cells" in different reports (e.g., [1,2] in report CZ01 and [1,2] in report CZ02 are different cells, with their globally unique identifiers being "CZ01_001_JE2" and "CZ02_001_JE2" respectively), ensuring the accuracy of data location. The report data of the units to be audited is loaded into the memory data area all at once. During the verification process, there is no need to repeatedly query the database; interaction with the database only occurs during data loading and result saving, reducing the number of database queries and I / O overhead, and supporting concurrent audits for more units.

[0129] In some embodiments, in step S5, executing the executable code to verify the asset report data includes:

[0130] The compiled executable code corresponding to each audit formula is categorized according to the formula category to which each executable code belongs, and a hash table index is built using the formula category code as the key to construct a formula method hash table. The key of the formula method hash table is the formula category code, and the value is a list of formula methods belonging to that formula category.

[0131] Based on the formula category code to be verified, the corresponding formula method list is searched from the formula method hash table.

[0132] In this embodiment, the formula category code is used as a unique identifier to classify audit formulas. It is divided based on business logic or verification dimensions, such as "basic information verification type (code: 01)", "total asset verification type (code: 02)" and "liability balance verification type (code: 03)". Formulas of the same category are usually used to verify the data compliance of a certain business module in the report.

[0133] During validation, the formula category code to be executed is determined based on the type of report to be audited (such as a balance sheet or a fixed asset schedule) or the validation scope selected by the user. For example, when auditing a balance sheet, the formulas corresponding to category codes "02" (total assets) and "03" (liabilities balance) must be executed. Then, based on the determined formula category code, the corresponding formula method list is retrieved from the constructed formula method hash table. For example, entering code "02" retrieves a List collection containing methods such as "validateFormula_0005".

[0134] like Figure 5 As shown, the formula method list is then traversed, and for each formula method, the following operations are performed:

[0135] S501: Method to call this formula;

[0136] S502: During the execution of the formula method, the value of the data cell referenced by the formula method is obtained by querying the loaded asset report data matrix, and logical judgment is performed based on the obtained data cell value to obtain the actual verification result of Boolean type;

[0137] S503: Associate the actual verification result with the report identifier and audit formula identifier that generated the actual verification result and store them in the database.

[0138] Specifically, the formula method is invoked via reflection (such as Method.invoke()), passing the constructed asset report data matrix (hash table) as a parameter. For example, calling "validateFormula_0005 (dataMap)" will take the dataMap as the in-memory data matrix of the entity to be audited.

[0139] During the execution of the formula method, the required cell values ​​are retrieved from the data matrix through access instructions, basic operation instructions are executed to complete the calculation and logical judgment, and the actual validation result of boolean type is output (true for pass, false for failure). For example, the formula method "validateFormula_0005" validates "Total Assets = Current Assets + Non-current Assets". If the value of "Total Assets" in the asset report data matrix is ​​equal to the sum of the values ​​of "Current Assets" and "Non-current Assets", it returns true; otherwise, it returns false.

[0140] The actual verification results are then associated with the corresponding report identifier (e.g., "35010001_CZ01_2025"), audit formula identifier (e.g., "FORMULA_0005"), verification time, and unit code to form a verification result record. All generated verification result records are then batch-stored into a pre-defined audit verification result table. The table structure must include at least the following fields: unique identifier for verification result (primary key), unit code to be audited, report identifier (unit code + report code + year), audit formula identifier, formula category code verification result (1 indicates pass, 0 indicates failure), verification time, and operator (automatically filled by the system). After storage, the report's audit status is updated, allowing the front-end system to query verification results, view erroneous formulas, and locate problematic data. The audit status includes any one of the following: pending audit, audited, audited, or audited failed.

[0141] The above solution manages validation methods by category using a hash table based on formulas. This allows for batch validation of all formulas from a specific business module at once, avoiding the inefficiency of querying and calling formulas one by one. Users can select specific categories of formulas for validation based on their actual needs, reducing unnecessary validation operations and saving system resources and time. Validation results are stored in association with information such as report identifiers, formula identifiers, and unit codes, allowing for traceability of the validation results, execution time, and operator for each formula. This meets the auditing requirements of the finance department for the report review process, ensuring the traceability and compliance of data validation.

[0142] In some embodiments, after generating the abstract syntax tree in step S2, the following steps are also included:

[0143] The abstract syntax tree is converted into a declarative constraint model, wherein the logical statements of the abstract syntax tree are converted into one or more declarative constraints, each declarative constraint defining a mathematical relationship that must be satisfied between the data cells associated with it.

[0144] In step S5, after executing the executable code and verifying the asset report data, as follows... Figure 6 As shown, it also includes the following steps:

[0145] S601: If the verification fails, activate the declarative constraint model corresponding to the verification formula that failed, solve the declarative constraint model through reversible calculation, and calculate the feasible value range of one or more data cells that can make the declarative constraint condition true.

[0146] S602: Based on the cell dependency graph, determine all upstream audit formulas that have computational dependencies with the audit formula that failed the current verification, and form a rule influence set;

[0147] S603: Calculate the business impact weight for each audit formula in the rule impact set based on historical business rule execution data, perform root cause impact analysis based on the rule impact set and the business impact weight, and generate a rule impact ripple diagram. The rule impact ripple diagram is used to visually display the rule error propagation path caused by the root cause cell of the current verification failure, and mark the affected nodes on the error propagation path according to the severity of the business impact weight.

[0148] S604: Record the feasible value range and the rule influence ripple diagram in the diagnostic report.

[0149] In this embodiment, the declarative constraint model refers to a model that describes the relationship between cells in the form of "constraints" based on the transformation of an abstract syntax tree. It does not focus on the calculation process, but only defines the "mathematical relationship that must be satisfied", such as "total assets cell value = current assets cell value + non-current assets cell value" and "accounts payable cell value ≤ total liabilities cell value × 30%".

[0150] Specifically, after the verification fails in step S5, the following operations are performed: Based on the identifier of the failed formula, the corresponding declarative constraint model is retrieved from the declarative constraint model library. For example, when the formula "FORMULA_0010" (CZ01[1,3]=CZ01[1,1]+CZ01[1,2]) fails, its corresponding equality constraint model is activated. Then, based on the mathematical relationships in the constraint model, some known cell values ​​(such as cells confirmed by the user) are fixed, and the variable cells involved in the verification failure are used as the solution target. Reversible calculations are performed through linear programming or numerical iteration methods to solve for the feasible value range of the variable cells. For example, if the known value of cell CZ01_001_JE1 is 1 million yuan and the value of CZ01_001_JE2 is 500,000 yuan, the constraint model requires "CZ01_001_JE3=100+50=150 million yuan", but the current value of CZ01_001_JE3 is 140 million yuan (verification failed). By reversible calculation, fixing the values ​​of CZ01_001_JE1 and CZ01_001_JE2, the feasible value range of CZ01_001_JE3 is found to be "[1.5 million yuan, 1.5 million yuan]" (exact value). If the constraint model is "CZ01_002_JE5 ≤ CZ01_001_JE3 × 0.3", and the known value of CZ01_001_JE3 is 2 million yuan, while the current value of CZ01_002_JE5 is 700,000 yuan (verification failed), then the feasible value range of CZ01_002_JE5 is found to be "[0 million yuan, 600,000 yuan]".

[0151] Then, based on the constructed cell dependency graph, all upstream dependent formulas of the failed formula are traced and verified. First, the upstream cells that the failed formula directly depends on are identified (e.g., formula A depends on cells X and Y). All audited formulas that "reference this upstream cell" are found (e.g., formulas B and C reference cell X, formula D references cell Y). These upstream formulas (B, C, and D) are summarized to form a rule influence set.

[0152] Then, based on historical business rule execution data (such as the number of business adjustments caused by formula validation failures in the past 3 years and the degree of impact on the summary report results), the business impact weight of each formula is calculated through weighted statistics. For example, formula B (current assets = cash + accounts receivable) has resulted in 5 report re-compilations due to past failures, so its business impact weight is set to 0.8; and formula D (accounts receivable aging ≤ 3 years) has only resulted in 1 data note supplementation due to past failures, so its business impact weight is set to 0.2.

[0153] Then, starting with the failed validation formula, using upstream formulas as intermediate nodes, and the root cause cell as the source node, a directed graph is constructed. Nodes are labeled with severity based on their business impact weight: those with a business impact weight greater than 0.7 are marked in red, those in the range [0.3, 0.7] are marked in yellow, and those less than 0.3 are marked in green. The error propagation path is then marked (e.g., root cause cell X → formula B → formula A), forming a visual rule-based impact diagram. The feasible value range and the rule-based impact diagram are then recorded in the diagnostic report.

[0154] The above solution provides a feasible correction range for erroneous data through reversible calculation, and predicts and displays the potential impact of the current error on other related business rules in the system by combining the rule impact ripple graph with business weights, thereby providing multi-dimensional decision support.

[0155] In some embodiments, in step S5, after obtaining the asset report data matrix, such as Figure 7 As shown, it also includes the following steps:

[0156] S701: Monitor the data cells in the asset report data matrix that are referenced by any audit formula in the cell dependency graph. When the value of any monitored data cell changes, automatically and asynchronously call all executable code segments corresponding to the audit formulas that directly depend on the data cell to perform streaming verification and generate streaming verification results. The streaming verification includes: verifying only the audit formulas that have become pending verification due to the change in the value of the data cell.

[0157] S702: Based on historical cell value data, establish a value fluctuation benchmark for each audit formula's associated data cell. When a change in the value of the monitored data cell is detected, determine if the difference between the current value of the monitored data cell and the value fluctuation benchmark exceeds a preset difference. If so, generate a value anomaly prompt.

[0158] In this embodiment, during streaming validation, only the executable code corresponding to the formula to be validated is called, without traversing all formulas. Specifically, this includes: obtaining the cell values ​​referenced by the formula to be validated (including the changed key cell values) from the asset report data matrix, then executing the formula logic judgment, generating a Boolean-type streaming validation result. If the streaming validation passes, the formula status is updated to "passed"; if it fails, the formula status is marked as "failed" and the error information is recorded. Preferably, the streaming validation result is fed back to the user in real time via a front-end WebSocket or a timed refresh mechanism.

[0159] The system then periodically collects historical data from the database for each key cell, including "unit code, cell identifier, report year / quarter, value, and modification time," forming a historical data database. For each key cell, a fluctuation benchmark is calculated based on the historical data database using statistical methods. Specifically, if the historical data sample size is ≥10, the range of "mean ± 2 standard deviations" is used as the numerical fluctuation benchmark, which can cover more than 95% of normal fluctuations; if the historical data sample size is <10, the range of "1.2 times the historical maximum and minimum values" is used as the benchmark range (to increase the tolerance).

[0160] When a change in the value of a key cell is detected, the following judgment is performed: extract the range of the value fluctuation baseline of the cell, calculate the difference between the current value and the baseline range, and if the difference exceeds the preset threshold (such as being triggered if it exceeds the baseline range), generate a value anomaly prompt and display the value anomaly prompt synchronously on the front-end page.

[0161] The above solution is based on a data cell monitoring mechanism that relies on the graph. Once the data changes, a local recalculation (streaming validation) is immediately triggered, relying solely on the formula of that cell, enabling rapid feedback. Simultaneously, by comparing the current value with historical fluctuation benchmarks, abnormal numerical changes exceeding reasonable ranges are identified.

[0162] In some embodiments, such as Figure 8 As shown, the method further includes:

[0163] S801: When the streaming verification result indicates that any audit formula fails verification, based on the cell dependency graph, determine the set of other audit formulas that have a cascading relationship with the currently failed audit formula in business logic, and generate a cascading risk warning.

[0164] S802: Dynamically calculate and update the verification health score and comprehensive risk index of the current asset report; wherein, the verification health score is obtained by weighting the pass rate of the current streaming verification of all audit formulas and the severity of the numerical anomaly prompts; the comprehensive risk index is obtained by integrating the number of audit formulas that failed due to streaming verification and their business importance weights, the number of audit formulas involved in the cascading risk prompts and their business importance weights, and the severity of the numerical anomaly prompts.

[0165] S803: Record and update the health score, the comprehensive risk index, the abnormal value prompt, and the cascading risk prompt together in the diagnostic report.

[0166] In step S801, the "business logic dependency" relationship between audit formulas, excluding "calculation dependency," is examined. This means that the failure of one formula may cause other formulas to "logically lose validity" or "become meaningless for subsequent validation." For example, if "formula A (cash and cash equivalents > 0) fails, the validation of formula B (cash and cash equivalents as a percentage of current assets > 10%) becomes meaningless," then A and B have a cascading relationship. When any audit formula fails validation, the corresponding set of affected formulas is matched from the cascading relationship database based on the formula identifier of the failed streaming validation. For example, if formula A fails, affected formula B is matched.

[0167] In step S802, based on the streaming verification results and numerical anomaly prompts, the verification health score is calculated according to the following formula: Verification health score = base score × pass rate weight + anomaly correction score × anomaly weight; and considering multiple risk factors, the comprehensive risk index is calculated according to the following formula: Comprehensive risk index = failure formula risk score + cascade risk score + numerical anomaly risk score.

[0168] The above solution upgrades the verification result from a binary judgment of pass / fail to a quantitative assessment by verifying the health score and comprehensive risk index. This helps users intuitively grasp the overall quality of reports, and finance departments can manage unit reports in a tiered manner based on scores (e.g., ≥90 points pass directly, <60 points require key review). Cascading risk alerts help users prioritize handling failed formulas with a wide impact, avoiding wasting time on invalid formulas and improving error correction efficiency. The comprehensive risk index clearly defines the risk level, and users can allocate correction resources according to the index (e.g., high-risk reports are processed first, low-risk reports are processed later), optimizing workflows.

[0169] In some embodiments, after generating the abstract syntax tree, the following two construction processes are performed in parallel based on the same set of abstract syntax trees:

[0170] Perform step S3 to construct a cell dependency graph for causal reasoning;

[0171] Construction of the semantic graph of execution rules, such as Figure 9 As shown, the specific steps include:

[0172] S901: Analyze the structure of the abstract syntax tree and parse the audit formula into structured logical constraints that represent the numerical relationships between cells; wherein, the structured logical constraints include equality constraints that define the operational relationships between cells and inequality constraints that limit the range of cell values;

[0173] S902: The equality constraints and inequality constraints are associated as semantic metadata with the corresponding nodes in the cell dependency graph to form an enhanced rule semantic graph; wherein, the equality constraints are associated with the cell nodes that are the calculation results, and the inequality constraints are associated with the constrained cell nodes.

[0174] S903: Before loading the asset report data of the entity to be audited, traverse the structured logical constraints in the enhanced rule semantic graph, verify whether there are logical contradictions between the structured logical constraints that cannot be satisfied simultaneously, and summarize the set of audit formulas with contradictions.

[0175] S904: When step S6 is executed and the causal reasoning engine is started, the enhanced rule semantic graph is queried to obtain the structured logical constraints corresponding to the target formula that caused the current verification failure, and a business semantic explanation describing the direct cause of the current verification failure is generated based on the structured logical constraints.

[0176] S905: The business semantic interpretation and the root cause diagnosis results obtained by the causal reasoning engine are fused together and output to the diagnosis report.

[0177] In this embodiment, the rule semantic graph refers to an enhanced graph formed by associating "structured logical constraints" as semantic metadata on the basis of the cell dependency graph. It not only includes the calculation relationship of "who depends on whom", but also the "business meaning of the dependency relationship" (such as "total assets depend on current assets and non-current assets, so as to meet the total balance").

[0178] Structured logical constraints refer to the structured descriptions of the explicit relationships between cells parsed from the abstract syntax tree. They are divided into equality constraints (such as "A=B+C") and inequality constraints (such as "A≤B×0.3"), and are the core semantic metadata of the rule semantic graph.

[0179] Logical contradiction verification refers to performing a consistency check on all structured logical constraints in the rule semantic graph before loading data, and determining whether there are any constraints that cannot be satisfied simultaneously (such as "Constraint 1: A=B+C; Constraint 2: A=B+D; Constraint 3: C≠D", which cannot be satisfied simultaneously).

[0180] Business semantic interpretation refers to converting the technical reasons for validation failure (such as "the formula returns false") into a natural language description that is understandable to business personnel (such as "the total asset cell value (1.4 million yuan) is not equal to the total value of current assets (1 million yuan) and non-current assets (500,000 yuan) (1.5 million yuan)").

[0181] In step S901, the abstract syntax tree is traversed first, and logical statements are parsed into equality constraints or inequality constraints. For example, the formula “CZ01[1,3]=CZ01[1,1]+CZ01[1,2]” is parsed into equality constraints:

[0182] Equality(CZ01_001_JE3, Sum(CZ01_001_JE1,CZ01_001_JE2)) is used, and the semantic label "asset total balance constraint" is added.

[0183] The formula “CZ01[2,5]≤CZ01[1,3]×0.3” can be analyzed as an inequality constraint:

[0184] LessOrEqual(CZ01_002_JE5, Multiply(CZ01_001_JE3,0.3)) is used to annotate the semantic label "accounts payable percentage constraint".

[0185] In step S902, the parsed structured logical constraints are used as semantic metadata and associated with the corresponding nodes of the cell dependency graph constructed in Task 1, specifically including:

[0186] Equality constraints are associated with "cell nodes that are the results of calculations", for example, the equality constraint above is associated with the node of cell CZ01_001_JE3;

[0187] Inequality constraints are associated with the "constrained cell node", for example, the above inequality constraint is associated with the node of cell CZ01_002_JE5;

[0188] After association, the graph node contains complete information including "cell identifier - dependency list - semantic constraint list - semantic tag", forming an enhanced rule semantic graph.

[0189] In step S903, before loading the report data of the unit to be audited, logical contradiction verification is performed based on the rule semantic graph. Specifically, this includes: traversing the rule semantic graph, collecting the structured logical constraints associated with all cell nodes to form a global constraint set. The "Constraint Satisfaction Problem (CSP)" algorithm is then used to perform a consistency check on the global constraint set. The consistency check specifically includes the following:

[0190] Convert each constraint into a CSP variable (cell) and constraint function (such as "X=Y+Z", "X≤Y×0.3").

[0191] Use backtracking or arc consistency algorithm to determine if there are variable values ​​that can simultaneously satisfy all constraints;

[0192] If it does not exist, then a logical contradiction is determined, and the contradictory constraint combination is recorded. For example, constraint 1 is "X=Y+Z", constraint 2 is "X=Y+W", and constraint 3 is "Z≠W". The algorithm determines that the three cannot be satisfied at the same time and records the contradictory combination (constraint 1, constraint 2, constraint 3).

[0193] Then, all constraints with logical contradictions are grouped and classified according to the severity of the contradiction. The severity of the contradiction includes at least a severe level and a general level. The severe level refers to contradictions in the core balance formula, such as "Total Assets = Liabilities + Net Assets" versus "Total Assets = Liabilities + Net Assets + 100". The general level refers to contradictions in non-core formulas. All contradictory results are summarized into a rule contradiction report and pushed to the development or operation and maintenance personnel. The contradictory formulas are corrected before the data is loaded (such as deleting incorrect constraints or adjusting constraint logic).

[0194] In step S905, when the causal reasoning engine is started, the following operations are performed:

[0195] Query semantic constraints: Based on the identifier of the target formula that failed the validation, query the rule semantic graph to obtain the structured logical constraints and semantic tags corresponding to the formula. For example, when the formula "FORMULA_0010" fails, the constraint "Equality (CZ01_001_JE3,Sum (CZ01_001_JE1, CZ01_001_JE2))" and the semantic tag "asset total balance constraint" are retrieved.

[0196] Generate business semantic interpretation: Based on the specific data of the current validation failure, convert structured logical constraints into natural language interpretations, specifically including:

[0197] Extract the current value of the cell referenced by the failed formula (e.g., CZ01_001_JE3=1.4 million yuan, CZ01_001_JE1=1 million yuan, CZ01_001_JE2=50 million yuan).

[0198] Organize the language according to semantic tags and constraint logic: "[Total Asset Balance Constraint Failed] According to the departmental standard rules, the value of the total asset cell (CZ01 report, row 1, column 3) should be equal to the sum of current assets (row 1, column 1, RMB 1 million) and non-current assets (row 1, column 2, RMB 500,000) (RMB 1.5 million), but the current total asset value is RMB 1.4 million, which does not meet the balance constraint."

[0199] In step S905, the business semantic interpretation is integrated with the "root cause diagnosis results" (high probability root cause cells, suggested adjustment values) obtained by the causal reasoning engine and added to the "failure cause explanation" section of the diagnosis report, so that the diagnosis report has both technical root causes and business meanings, meeting the understanding needs of different roles (technical personnel, reporting personnel, financial management personnel).

[0200] The above solution detects logical inconsistencies in the rules before data loading, avoiding "all unit reports fail to validate" errors caused by formula design flaws, reducing invalid audit operations, and saving system resources and time. Through business semantic interpretation, the technical "formula failure" is transformed into "balance constraint not satisfied," which is easily understood by business personnel. Report editors can clearly understand the meaning of the error without needing to understand formula syntax, reducing training costs and lowering the operational threshold.

[0201] In a second aspect, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the asset report data audit and verification method as described in the first aspect of the present invention.

[0202] The computer-readable storage medium may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0203] The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD ROM); the magnetic surface memory may be a disk storage device or a magnetic tape storage device.

[0204] The volatile memory may be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct memory bus random access memory (DRRAM). The computer-readable storage media described in the embodiments of the present invention are intended to include these and any other suitable types of memory.

[0205] like Figure 10 As shown, in a third aspect, the present invention provides an electronic device 10, including a processor 101 and a storage medium 102, wherein a computer program is stored on the storage medium, and the computer program, when executed by the processor, implements the asset report data audit and verification method as described in the first aspect of the present invention.

[0206] In some embodiments, the processor may be implemented by software, hardware, firmware, or a combination thereof, and may use at least one of the following: circuit, single or multiple application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), central processing units (CPUs), controllers, microcontrollers, and microprocessors, thereby enabling the processor to execute some or all of the steps or any combination of the steps in the asset report data audit and verification method described in the various embodiments of this application.

[0207] Finally, it should be noted that although the above embodiments have been described in the text and drawings of this application, this should not limit the scope of patent protection of this application. Any technical solutions that are based on the essential concept of this application and utilize the content described in the text and drawings of this application, resulting in equivalent structural or procedural substitutions or modifications, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of patent protection of this application.

Claims

1. A method for auditing and verifying asset statement data, characterized in that, The method includes: S1: Receive the audit formula of the asset report, wherein the audit formula is a logical judgment expression containing data cell references based on the row and column coordinates of the report; S2: Perform lexical and syntactic analysis on the audit formula to generate an abstract syntax tree, wherein the leaf nodes of the abstract syntax tree are data cell references or constant values, and the non-leaf nodes are operators; S3: Based on the abstract syntax tree, construct a cell dependency graph, wherein the nodes of the dependency graph represent data cells, and the edges represent the computational dependencies between data cells; S4: Traverse the abstract syntax tree, and through compilation and transformation, map the data cell references to access instructions for the asset report data matrix in the memory data area, and map the operators to the corresponding operation instructions to dynamically generate executable code; S5: Load the asset report data of the unit to be audited into the memory data area to obtain the asset report data matrix, execute the executable code, and verify the asset report data; S6: When the verification fails, start the causal reasoning engine and perform the following operations: Based on the cell dependency graph, starting from the formula node that failed the validation, all upstream data nodes are traversed in reverse order. For the upstream data nodes that are traversed, the values ​​are adjusted within a preset reasonable range, and the executable code is simulated to obtain the simulation verification results; Based on the simulation verification results, for each upstream data node that is traversed, a confidence score is calculated as the root cause of the verification failure. The confidence score is calculated based on the value adjustment range of the upstream data node and its error frequency in historical verification. The upstream data node with the highest confidence score is identified as a high-probability root cause cell, and a diagnostic report containing information about the high-probability root cause cell and suggested adjustment values ​​is generated. After generating the abstract syntax tree in step S2, the following steps are also included: The abstract syntax tree is converted into a declarative constraint model, wherein the logical statements of the abstract syntax tree are converted into one or more declarative constraints, each declarative constraint defining a mathematical relationship that must be satisfied between the data cells associated with it. In step S5, after executing the executable code to verify the asset report data, the following steps are also included: If the verification fails, the declarative constraint model corresponding to the verification formula that failed is activated. The declarative constraint model is solved by reversible calculation to calculate the feasible value range of one or more data cells that can make the declarative constraint condition true. Based on the cell dependency graph, all upstream audit formulas that have computational dependencies with the audit formula that failed the current verification are identified, forming a rule influence set; Based on historical business rule execution data, the business impact weight is calculated for each audit formula in the rule impact set. Root cause impact analysis is performed based on the rule impact set and the business impact weight to generate a rule impact ripple diagram. The rule impact ripple diagram is used to visually display the rule error propagation path caused by the root cause cell of the current verification failure, and the severity of the affected nodes on the error propagation path is marked according to the business impact weight. The feasible value range and the influence effect diagram of the rule are recorded in the diagnostic report.

2. The asset statement data verification method as described in claim 1, characterized in that, Step S4 specifically includes: Traverse the abstract syntax tree, identify data cell references in the abstract syntax tree, and generate corresponding access instructions based on the data cell references. The access instructions are used to obtain the corresponding values ​​from the asset report data matrix and to convert operators and logical judgments into corresponding basic operation instructions. A separate Java class method is generated for each of the aforementioned audit formulas. The generated Java code is compiled into bytecode, and the bytecode is loaded into the runtime environment using dynamic class loading.

3. The asset statement data verification method as described in claim 1, characterized in that, In step S5, the asset report data of the entity to be audited is loaded into the memory data area to obtain the asset report data matrix, which includes: Obtain the predefined mapping relationship between report row and column coordinates and globally unique identifiers, and convert the report row and column coordinates of data cells in the report data into the corresponding globally unique identifiers based on the mapping relationship; Using the globally unique identifier as the key and the values ​​in the data cells as the values, a hash table is constructed as the asset report data matrix.

4. The asset statement data verification method as described in claim 1, characterized in that, In step S5, executing the executable code to verify the asset report data includes: The compiled executable code corresponding to each audit formula is categorized according to the formula category to which each executable code belongs, and a hash table index is built using the formula category code as the key to construct a formula method hash table. The key of the formula method hash table is the formula category code, and the value is a list of formula methods belonging to that formula category. Based on the formula category code to be verified, the corresponding formula method list is searched from the formula method hash table; Iterate through the list of formula methods, and for each formula method, perform the following operations: Call the formula method; During the execution of the formula method, the values ​​of the data cells referenced by the formula method are obtained by querying the loaded asset report data matrix. Logical judgment is performed based on the obtained data cell values ​​to obtain the actual verification result of Boolean type. The actual verification result is associated with the report identifier and audit formula identifier that generated the actual verification result and stored in the database.

5. The asset statement data verification method as described in claim 1, characterized in that, In step S5, after obtaining the asset report data matrix, the following steps are also included: The system monitors data cells in the asset report data matrix that are referenced by any audit formula in the cell dependency graph. When a change in the value of any monitored data cell is detected, the system automatically and asynchronously calls all executable code segments corresponding to the audit formulas that directly depend on that data cell to perform streaming verification and generate streaming verification results. The streaming verification includes: verifying only the audit formulas that have become pending verification due to the change in the value of the data cell. Based on historical cell value data, a value fluctuation benchmark is established for each audit formula and its associated data cell. When a change in the value of the monitored data cell is detected, if the difference between the current value of the monitored data cell and the value fluctuation benchmark exceeds a preset difference, a value anomaly prompt is generated.

6. The asset statement data auditing and verification method as described in claim 5, characterized in that, The method further includes: When the streaming validation result indicates that any audit formula fails validation, based on the cell dependency graph, a set of other audit formulas that have a cascading relationship with the currently failed audit formula in business logic is determined, and a cascading risk warning is generated. The verification health score and comprehensive risk index of the current asset report are dynamically calculated and updated. The verification health score is obtained by weighting the pass rate of the current streaming verification of all audit formulas and the severity of the numerical anomaly prompts. The comprehensive risk index is obtained by integrating the number of audit formulas that failed the streaming verification and their business importance weights, the number of audit formulas involved in the cascading risk prompts and their business importance weights, and the severity of the numerical anomaly prompts. The health score, the comprehensive risk index, the abnormal value prompts, and the cascading risk prompts are all recorded and updated in the diagnostic report.

7. The asset statement data auditing and verification method as described in claim 1, characterized in that, After generating the abstract syntax tree, the following two construction processes are performed in parallel based on the same set of abstract syntax trees: Perform step S3 to construct a cell dependency graph for causal reasoning; The construction of the execution rule semantic graph includes the following steps: Analyzing the structure of the abstract syntax tree, the audit formula is parsed into structured logical constraints that represent the numerical relationships between cells; wherein, the structured logical constraints include equality constraints that define the operational relationships between cells and inequality constraints that limit the range of cell values; The equality constraints and inequality constraints are used as semantic metadata and associated with the corresponding nodes in the cell dependency graph to form an enhanced rule semantic graph; wherein, the equality constraints are associated with the cell nodes that are the calculation results, and the inequality constraints are associated with the constrained cell nodes. Before loading the asset report data of the entity to be audited, the structured logical constraints in the enhanced rule semantic graph are traversed to verify whether there are logical contradictions between the structured logical constraints that cannot be satisfied simultaneously, and the set of audit formulas with contradictions is summarized. When step S6 is executed and the causal reasoning engine is started, the enhanced rule semantic graph is queried to obtain the structured logical constraints corresponding to the target formula that caused the current verification failure. Based on the structured logical constraints, a business semantic explanation describing the direct cause of the current verification failure is generated. The business semantic interpretation is fused with the root cause diagnosis results obtained by the causal reasoning engine and output together to the diagnosis report.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the asset report data audit and verification method as described in any one of claims 1 to 7.

9. An electronic device having a computer program stored thereon, characterized in that, It includes a processor and a storage medium, wherein a computer program is stored on the storage medium, and the computer program, when executed by the processor, implements the asset report data audit and verification method as described in any one of claims 1 to 7.

Images