An intelligent filling and verification method for electronic tax invoices

Abstract

The present invention relates to an intelligent filling and verification method for electronic tax invoices, comprising the following steps: obtaining display condition combination rules of electronic tax invoice fields to obtain a decision path for field visibility; judging the visibility state of the field corresponding to the decision node under the current condition combination; obtaining the temporal relationship of the triggering conditions on the decision path to determine the final visibility of the field; for fields with abnormal display, using a backtracking algorithm to infer the logical operation process of the display condition combination; for fields with hidden errors, using a forward reasoning algorithm to infer the logical operation process of the hidden condition combination; using a rule engine technology to dynamically control the visibility of the field; using case reasoning technology to analyze historical cases of field visibility control. The present invention can intelligently control the display and hiding of electronic tax invoice fields, improve the accuracy and efficiency of invoice filling, and provide users with a more friendly operation experience.

Description

Technical Field

[0001] The present invention relates to the field of electronic tax verification, and in particular to an intelligent filling and verification method for electronic tax invoices. Background Art

[0002] The visibility of electronic tax invoice fields depends on the combination of multiple conditions, including business rules, user role permissions, form filling status, etc. When the visibility of a field changes, it may affect the visibility of other fields. However, since electronic tax invoices involve many fields, there are intricate logical relationships between fields, the combination rules of display conditions are diverse, and the temporal relationship of triggering conditions is difficult to clarify, resulting in huge challenges in the dependency chain analysis of field visibility.

[0003] At present, the dependency chain analysis model of the visibility of electronic tax invoice fields lacks an in-depth understanding of business scenarios and a comprehensive grasp of the logical relationship between fields. In complex tax business scenarios, the dependencies between fields are intricately intertwined, the combination rules of display conditions are diverse, and the timing relationship of triggering conditions is difficult to clarify. This leads to problems such as conditional judgment errors and missing boundary conditions when performing logical operations on conditional combinations, which in turn cause field display anomalies. At the same time, the existing dependency chain analysis model is difficult to effectively express and analyze the complex logical relationship between fields, and cannot accurately locate the root cause of the display anomaly, making the problem troubleshooting and repair process time-consuming and labor-intensive. Summary of the invention

[0004] In order to solve the problems existing in the above-mentioned prior art, the purpose of the present invention is to provide an intelligent filling and verification method for electronic tax invoices. The intelligent filling and verification method for electronic tax invoices can intelligently control the display and hiding of electronic tax invoice fields, improve the accuracy and efficiency of invoice filling, and provide users with a more friendly operation experience.

[0005] The method for intelligent filling and verification of an electronic tax invoice according to the present invention comprises the following steps:

[0006] S1. Obtain the display condition combination rules of the electronic tax invoice fields, build a field visibility dependency chain model, and obtain the decision path of field visibility by analyzing the logical relationship between fields and the temporal relationship of trigger conditions;

[0007] S2. Obtain a decision node of the field visibility dependency chain model, and determine the visibility status of the field corresponding to the decision node under the current condition combination;

[0008] S3, obtaining the timing relationship of the trigger conditions on the decision path, analyzing the dynamic change process of the field visibility through the state transition diagram, and determining the final visibility of the field;

[0009] S4. For the fields with abnormal display, a backtracking algorithm is used to infer the logical operation process of the display condition combination, and the condition combination that causes the field display abnormality is located through logic chain analysis;

[0010] S5. For the fields with hidden errors, a forward reasoning algorithm is used to infer the logical operation process of the hidden condition combination, and the condition combination that causes the field hiding error is located through logic chain analysis;

[0011] S6. According to the logical operation result of the decision path and the condition combination, the visibility of the field is dynamically controlled by using the rule engine technology to achieve adaptive adjustment of the visibility of the field;

[0012] S7. Use case-based reasoning technology to analyze historical cases of field visibility control, obtain the optimal field display solution, and apply it to the current electronic tax invoice field visibility control.

[0013] Preferably, the step S1 specifically includes:

[0014] Establish a field display rule matrix based on the electronic tax invoice field rule data, and use the mapping relationship between field identifiers and display condition intervals to store field display rules;

[0015] A field association directed graph is constructed for the field display rule matrix, and the degree of association between fields is determined by a conditional association strength calculation formula, and the conditional association strength calculation formula is as follows:

[0016] R=N1 / N2

[0017] Wherein, R represents the strength of the conditional association; N1 represents the number of times two fields are displayed simultaneously; N2 represents the total number of times the fields are displayed;

[0018] Obtaining the in-degree value of the field node from the field association directed graph to build a field dependency priority queue, and obtaining a field display dependency tree through a decision tree algorithm;

[0019] A field trigger sequence table is established for the field display dependency tree, and the field trigger relationships are sorted using a topological sorting tool to obtain an ordered table of field display trigger paths.

[0020] Preferably, the step S2 specifically includes:

[0021] Obtaining a field identifier and a decision node identifier, and using a mapping tool to construct a field decision mapping table, wherein the field decision mapping table records the corresponding relationship between the field identifier and the decision node identifier;

[0022] Extracting a conversion condition from a decision node according to the decision node identifier, and converting the conversion condition into a Boolean expression of an AND operator, an ANOVA operator, or a NON operator by using a Boolean expression parsing tool;

[0023] Constructing an operation truth table for the Boolean expression, and recording the Boolean conditions in the rows and the node identifiers in the columns to obtain the Boolean expression operation result;

[0024] If the Boolean expression operation result is a true value, the display state of the field identifier is set to display in the field display state table;

[0025] If the Boolean expression operation result is a false value, the display state of the field identifier is set to hidden in the field display state table.

[0026] Preferably, the step S3 specifically includes:

[0027] Acquire a trigger sequence table according to the decision path, the trigger sequence table records field identifiers and trigger timestamps, and sort the trigger timestamps by a timing sorting tool to obtain a field trigger timing table;

[0028] Constructing a finite state transition diagram for the field trigger timing table, marking display state nodes, hidden state nodes and read-only state nodes in the finite state transition diagram, and calculating the transition function between nodes by a state machine operation tool to obtain a field state transition rule table;

[0029] Construct a state space graph according to the field state transition rule table, set directed edges in the state space graph to represent state transition paths, and verify the state values ​​in the state transition paths using a state verification tool to obtain a state verification result table;

[0030] An abnormal status record table is constructed for the status check result table, and the abnormal status of the field is recorded to obtain a field abnormal type table.

[0031] Preferably, the step S4 specifically includes:

[0032] Acquire a display exception table according to the decision path, and use a backtracking algorithm to traverse from the end of the display condition combination to the starting end to obtain a condition combination backtracking sequence of the display exception field;

[0033] Constructing an operation error point location table for the condition combination backtracking sequence, using a Boolean operation calculator to perform decomposition operations on the Boolean expression to obtain an operation error condition node sequence;

[0034] A fault node graph is established based on the conditional node sequence of the operation error. If the operation results of the preceding node and the succeeding node are inconsistent, the node is marked as the fault source node.

[0035] A fault cause chain is constructed for the fault source node, and a cause analyzer is used to perform forward reasoning and reverse reasoning on the conditional values ​​of the fault source node to obtain a complete combination relationship of the fault conditions.

[0036] Preferably, the step S5 specifically includes:

[0037] Acquire the identifier and condition combination of the hidden error field according to the decision path, perform hierarchical operation on the condition nodes using a forward reasoning algorithm, and obtain a condition hierarchical table of the hidden error field;

[0038] Constructing a node operation graph for the conditional hierarchy table, and using a rule inference calculator to perform priority sorting operations on the logical operation symbols between the nodes in the operation graph to obtain a logical error table of the operation nodes;

[0039] Construct an error condition location table according to the logic error table, use a rule validator to forward deduce the operation rules of the error condition nodes in the location table, and record the operation nodes whose operation results do not match the expected Boolean values ​​as error source nodes;

[0040] A conditional attribution table is constructed for the error source node, and a conditional attribution device is used to forward trace the error source node, and a trigger path from the error source node to the hidden error field is recorded to obtain a conditional attribution chain for the hidden error.

[0041] Preferably, the step S6 specifically includes:

[0042] Acquire a display condition expression according to the decision path, extract Boolean operation symbols and condition parameters from the display condition expression by a rule extraction tool, and obtain a rule table of display conditions;

[0043] Calculate the expression result according to the value of the condition parameter and obtain the result table of rule determination;

[0044] Obtaining a field identifier through the result table, updating a display mark according to the result table, and setting the display mark whose rule determination result is true to a display state;

[0045] For the state of the display mark, an instruction execution tool is used to generate a state adjustment instruction, and the switching operation of the field display state is executed through the state adjustment instruction to obtain a dynamic control instruction of the field.

[0046] Preferably, the step S7 specifically includes:

[0047] Obtain the scenario feature library based on the invoice type and field identifier, use the feature tagger to mark the feature values ​​of the invoice amount area, taxpayer type, commodity category, and settlement method, and obtain the scenario feature matrix;

[0048] Constructing a similarity comparison table for the scene feature matrix, calculating the degree of feature dimension matching, and calculating the feature similarity between the current scene and the historical case to obtain a case similarity ranking set;

[0049] Constructing a rule extraction table according to the case similarity sorting set, using a rule annotator to mark condition parameters and threshold parameters in the display rule, scoring the degree of matching of the rule conditions, and extracting the display rule from the case with the highest similarity;

[0050] A rule mapping table is constructed for the display rule, and a rule mapper is used to convert the numerical parameters in proportion and the category parameters according to the mapping relationship to obtain a field display scheme.

[0051] The intelligent filling and verification method of an electronic tax invoice described in the present invention has the following advantages:

[0052] The intelligent filling and verification method of an electronic tax invoice of the present invention can quickly determine the visibility status of the field by constructing a field visibility dependency chain model and a decision path, thereby reducing the time for manual inspection and adjustment; the field visibility dependency chain model can flexibly respond to the needs and changes of different electronic tax invoices, and can easily adapt to new fields and conditions by adjusting the rules in the rule engine; through intelligent filling and verification, as well as dynamic control of field visibility, invoice problems caused by errors or omissions are significantly reduced, thereby reducing fines and additional costs caused by invoice errors; accurate field display and intelligent verification functions enable users to complete the filling and review of electronic tax invoices more easily, thereby improving user experience; using case reasoning technology, the optimal field display solution can be quickly found based on historical cases, thereby improving the degree of intelligence. The intelligent filling and verification method of electronic tax invoices can intelligently control the display and hiding of electronic tax invoice fields, improve the accuracy and efficiency of invoice filling, and provide users with a more friendly operation experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 It is a flow chart of an intelligent filling and verification method of an electronic tax invoice described in the present invention. DETAILED DESCRIPTION

[0054] like Figure 1 As shown, the intelligent filling and verification method of an electronic tax invoice described in the present invention comprises the following steps:

[0055] S1. Obtain the display condition combination rules of the electronic tax invoice fields, build a field visibility dependency chain model, and obtain the decision path of field visibility by analyzing the logical relationship between fields and the temporal relationship of trigger conditions;

[0056] S2. Obtain the decision node of the field visibility dependency chain model, and determine the visibility status of the field corresponding to the decision node under the current condition combination;

[0057] S3. Obtain the temporal relationship of the trigger conditions on the decision path, analyze the dynamic change process of the field visibility through the state transition diagram, and determine the final visibility of the field;

[0058] S4. For the fields with abnormal display, a backtracking algorithm is used to infer the logical operation process of the display condition combination, and the condition combination that causes the field display abnormality is located through logic chain analysis;

[0059] S5. For the fields with hidden errors, a forward reasoning algorithm is used to infer the logical operation process of the hidden condition combination, and the condition combination that causes the field hiding error is located through logic chain analysis;

[0060] S6. Based on the logical operation results of the decision path and condition combination, the rule engine technology is used to dynamically control the visibility of the field to achieve adaptive adjustment of the field visibility;

[0061] S7. Use case-based reasoning technology to analyze historical cases of field visibility control, obtain the optimal field display solution, and apply it to the current electronic tax invoice field visibility control.

[0062] Furthermore, in this embodiment, step S1 specifically includes:

[0063] Establish a field display rule matrix based on the electronic tax invoice field rule data, and use the mapping relationship between field identifiers and display condition intervals to store field display rules;

[0064] A field association directed graph is constructed for the field display rule matrix, and the degree of association between fields is determined by the conditional association strength calculation formula. The conditional association strength calculation formula is as follows:

[0065] R=N1 / N2

[0066] Among them, R represents the strength of conditional association; N1 represents the number of times two fields are displayed at the same time; N2 represents the total number of times the field is displayed;

[0067] Obtain the in-degree value of the field node from the field association directed graph to build a field dependency priority queue, and obtain the field display dependency tree through the decision tree algorithm;

[0068] A field trigger sequence table is established for the field display dependency tree, and the field trigger relationships are sorted using a topological sorting tool to obtain an ordered table of field display trigger paths;

[0069] Specifically, according to the electronic tax invoice field rule data, a field display rule matrix is ​​constructed, field identifiers are recorded in matrix rows, display condition value intervals are recorded in matrix columns, and the display rules of the electronic tax invoice fields are stored using a mapping relationship between field identifiers and display condition intervals;

[0070] For the field display rule matrix, a field association directed graph is constructed. The field identifiers are stored in the directed graph nodes. The display condition association strength between the fields is marked in the directed graph edges. The degree of association between the fields is determined by the condition association strength calculation formula. The condition association strength calculation formula is as follows:

[0071] R=N1 / N2

[0072] Among them, R represents the strength of conditional association; N1 represents the number of times two fields are displayed at the same time; N2 represents the total number of times the field is displayed;

[0073] Obtain the field node in-degree value from the field association directed graph, build a field dependency priority queue, sort the fields in the queue according to the node in-degree value, use the decision tree algorithm to process the field combination data in the priority queue, and obtain the field display dependency tree;

[0074] A field trigger sequence table is constructed through the field display dependency tree, the hierarchical relationship of the nodes in the field display dependency tree is recorded in the sequence table, and the field trigger relationship in the sequence table is sorted using a topological sorting tool to obtain an ordered table of the trigger path of the field display;

[0075] Here is an example:

[0076] The field display rule matrix describes the key rules for displaying fields in electronic tax invoices. For example, in a VAT electronic invoice, if the value range of the tax-inclusive amount field is between 1,000 and 5,000 yuan, the invoice note field is displayed as optional, and if it exceeds 5,000 yuan, the invoice note field is displayed as required. By recording the display rule association between the tax-inclusive amount and invoice note fields in the matrix, a display condition mapping relationship between the fields is constructed.

[0077] The field association directed graph depicts the logical dependency between invoice fields. Take the goods list as an example. When the goods name field is displayed, the corresponding specification model field, measurement unit field, and unit price field all need to be displayed in conjunction. By calculating the frequency of simultaneous display of these fields, the association strength between the fields is obtained. For example, in 1,000 invoice samples, the goods name and specification model appear at the same time 950 times, and the association strength of the two fields is 0.95. Based on this, a complete field association graph can be constructed.

[0078] The field dependency priority queue reflects the triggering order of field display. In the process of filling in the seller information, the seller name field as the basic information has the highest priority, followed by the seller's taxpayer identification number, and the seller's address, telephone number and other fields have lower priority. By processing the priority relationship between the fields through the decision tree algorithm, the display dependency tree of the seller information field group can be obtained, which clearly shows the hierarchical triggering relationship between the fields;

[0079] The field trigger sequence table records the complete link of field display. In the motor vehicle invoice, the display of the engine number field depends on the selection of the vehicle type field, and the display of the frame number field depends on the filling of the engine number field. By determining this continuous trigger relationship through topological sorting, the field display trigger path from vehicle type to engine number and then to frame number can be obtained, ensuring the integrity and coherence of field display.

[0080] The purchaser information filling in the electronic invoice also reflects the association of field display. When the purchaser is an enterprise, the purchaser's taxpayer identification number field is displayed as required, and when the purchaser is an individual, this field is hidden. At the same time, the purchaser's telephone field is optional in the enterprise purchaser scenario, and is required in the individual purchaser scenario. This field display rule is stored in the display rule matrix, and the corresponding dependency relationship is established in the field association diagram;

[0081] The product details of the electronic invoice show complex field dependencies. The product line nature field determines the display rules of subsequent fields. When the product line nature is a normal line, regular fields such as product name, specification model, unit price, etc. are displayed. When it is a discount line, the specification model is hidden and only the discount amount is displayed. Such rules are organized and managed through dependency trees and trigger paths to ensure the accuracy of field display.

[0082] Furthermore, in this embodiment, step S2 specifically includes:

[0083] Obtaining field identifiers and decision node identifiers, using a mapping tool to construct a field decision mapping table, the field decision mapping table records the correspondence between the field identifiers and the decision node identifiers;

[0084] Extract the conversion condition from the decision node according to the decision node identifier, and convert the conversion condition into a Boolean expression of AND operator, OR operator and NOT operator by using a Boolean expression parsing tool;

[0085] Construct an operation truth table for the Boolean expression, record the Boolean conditions in the rows, record the node identifiers in the columns, and obtain the Boolean expression operation results;

[0086] If the Boolean expression operation result is a true value, the display state of the field identifier is set to display in the field display state table;

[0087] If the Boolean expression operation result is a false value, the display status of the field identifier is set to hidden in the field display status table;

[0088] Specifically, a field decision mapping table is constructed according to the decision path of field visibility, and the field identifier and the corresponding decision node identifier are recorded in the mapping table. The conversion conditions are extracted from the decision nodes through the Boolean expression parsing tool, and the conversion conditions are expressed in the Boolean expression format, where the operators include: the AND operator "∧", the OR operator "∨", and the NOT operator "￢", and the Boolean expression set of the node conversion is obtained;

[0089] Obtain a Boolean operation rule table from the node conversion Boolean expression set, record the expression operation rules in the rule table according to the field identifier, use a Boolean expression parsing tool to decompose the operation rules of the conversion conditions, sort the priorities of the Boolean operation symbols, mark the operation order of the conversion conditions according to the operation priority, and obtain a Boolean operation sequence table;

[0090] Construct an operation truth table for the Boolean operation sequence table of the node conversion conditions, record the Boolean conditions in the truth table rows, record the node identifiers in the truth table columns, use a Boolean operation calculator to calculate the Boolean expression, perform Boolean operations one by one in the order of priority, and operate from left to right and from top to bottom to obtain a numerical matrix of the operation results;

[0091] The field display state table is constructed through the operation result value matrix, the field identifier and the corresponding Boolean operation result are recorded in the state table, the operation result is traversed by the state determination tool, the field display state is set to display when the Boolean operation result is true, and the field display state is set to hide when the Boolean operation result is false, so as to obtain the state mark set of the field display;

[0092] Here is an example:

[0093] The field decision mapping table records the correspondence between fields and decision nodes. For example, in the invoice type selection scenario, the field identifier "invoice type" corresponds to the decision node "type judgment". The node conversion condition includes two options: VAT ordinary invoice and VAT special invoice. The conversion condition is extracted through Boolean expression analysis to obtain the Boolean expression "option 1 ∨ option 2", which represents the OR operation relationship between the two options.

[0094] The Boolean operation rule table shows the operation rules of condition combinations. Taking taxpayer type judgment as an example, the Boolean expression "general taxpayer ∧ annual sales > 500,000" means that the field is displayed when two conditions are met at the same time. The operation priority is the highest in brackets, followed by the negation operation, then the and operation, and finally the or operation. The expression is parsed and operated in this order;

[0095] The operation truth table describes the calculation process of the node condition. In the product detail table, the product row Boolean expression "Normal row ∧ unit price > 0" means that the amount is displayed when the product is a normal row and the unit price is greater than 0. The expression is Boolean operated. When the value of the normal row is true and the value of the unit price greater than 0 is true, the operation result is true, otherwise the operation result is false.

[0096] The field display status table records the display status corresponding to the operation result. In the invoice note information, when the Boolean operation result is true, the field is displayed as a required item, and when the Boolean operation result is false, the field is displayed as an optional item. The final display status of the field is determined by status judgment, realizing precise control of the field display rules;

[0097] The invoice details show a complex Boolean operation scenario. The display of fields such as product line type, product name, and specification model depends on the combination of multiple conditions. The display conditions of the fields are described by the Boolean expression "(product line ∧ unit price>0) ∨ (discount line ∧ amount<0)". When the product line meets the conditions and the unit price is a positive number, or the discount line meets the conditions and the amount is a negative number, the relevant fields are displayed.

[0098] The purchaser information filling reflects the conditional nested Boolean operation. The display status of the taxpayer identification number is judged by the expression "corporate purchaser ∧ (general taxpayer ∨ small-scale taxpayer)". When the purchaser is a corporate and meets any of the general taxpayer or small-scale taxpayer conditions, the taxpayer identification number field is displayed as required. In other cases, it is displayed as hidden, reflecting a multi-level logical judgment relationship.

[0099] Invoice issuance limit management integrates multiple Boolean conditions. The expression "(special invoice ∧ amount > 10,000) ∨ (ordinary invoice ∧ amount > 5,000)" describes the amount limits of different invoice types. When a special invoice is issued and the amount exceeds 10,000, or an ordinary invoice is issued and the amount exceeds 5,000, the invoice splitting prompt is triggered, reflecting the flexible use of conditional combinations.

[0100] Furthermore, in this embodiment, step S3 specifically includes:

[0101] The trigger sequence table is obtained according to the decision path. The trigger sequence table records the field identifier and the trigger timestamp, and the trigger timestamp is sorted by the timing sorting tool to obtain the field trigger timing table;

[0102] Construct a finite state transition diagram for the field trigger timing table, annotate display state nodes, hidden state nodes and read-only state nodes in the finite state transition diagram, and calculate the transition function between nodes through the state machine operation tool to obtain the field state transition rule table;

[0103] A state space graph is constructed according to the field state transition rule table, a directed edge is set in the state space graph to represent the state transition path, and a state verification tool is used to verify the state value in the state transition path to obtain a state verification result table;

[0104] Construct an abnormal status record table for the status check result table, and record the abnormal status of the field to obtain a field abnormal type table; the abnormal status of the field is recorded as follows:

[0105] If the displayed field is actually hidden, the record will be displayed abnormally;

[0106] If a hidden field is actually displayed, a hidden exception is recorded;

[0107] If a read-only field is actually editable, the record permission is abnormal;

[0108] Specifically, a trigger sequence table is constructed according to the decision path, the field identifier and trigger timestamp are recorded in the sequence table, the field trigger timestamps are sorted using a timing sorting tool, the order of field triggering and the waiting time are marked in the timing diagram, and the field trigger timing table is obtained;

[0109] Construct a finite state transition diagram through the field trigger timing table, mark the three node types of display state, hidden state, and read-only state in the state diagram, use the state machine operation tool to calculate the transition function between nodes, modify the state value if the field trigger condition is met, and keep the original state value if the trigger condition is not met, and obtain the field state transition rule table;

[0110] A state space graph is constructed for the field state conversion rule table. A directed edge is defined in the space graph to represent the state conversion path. A state verification tool is used to verify the state value in the conversion path. If the current state of the field conflicts with the rule, a state error is recorded. If the field state continuously changes beyond the threshold, a state abnormality is recorded to obtain a state verification result table.

[0111] Construct an abnormal status record table through the status check result table, mark the field status error type in the record table, use the abnormality detection tool to classify the status error, and obtain the field abnormality type table;

[0112] The abnormal status of the record field is as follows:

[0113] If the displayed field is actually hidden, the record will be displayed abnormally;

[0114] If a hidden field is actually displayed, a hidden exception is recorded;

[0115] If a read-only field is actually editable, the record permission is abnormal;

[0116] Here is an example:

[0117] The trigger sequence table reflects the timing rules of the electronic invoice field display. Taking the product details as an example, the product name field is displayed at the trigger timestamp 10:00:01, the unit price field is displayed at 10:00:02, and the amount field is displayed at 10:00:03. The display order between fields is determined by time sequence sorting, and the waiting time between adjacent fields is recorded as 1 second, forming a complete field trigger chain;

[0118] The finite state transition diagram describes the change process of the field display state. Taking the invoice header information as an example, the initial state of the purchaser type field is displayed. When the individual purchaser is selected, the taxpayer identification number field state changes from display to hidden, and the address and telephone field state changes from optional to required, reflecting the interdependence between the field states.

[0119] The state space diagram shows the complete path of field state transitions. In the sales commodity classification scenario, the commodity type field status changes from display to read-only, and the commodity code field status changes from hidden to display. If the commodity type field is modified in the read-only state, the record state is wrong. If the commodity code frequently switches display states within 500 milliseconds, the record state is abnormal.

[0120] The abnormal status record table marks the error type displayed in the field. In the ordinary invoice issuance scenario:

[0121] If the unit price amount field should be displayed but is actually hidden, it will be recorded as a display exception;

[0122] If the discount information field should be hidden but is actually displayed, it will be recorded as a hidden error;

[0123] If the invoice code field should be read-only but is actually editable, it will be recorded as a permission exception;

[0124] The motor vehicle sales invoice reflects a complex state transition scenario. The vehicle type field status changes from display to read-only, and the engine number field status changes from hidden to display and then to read-only. If the engine number field is modified in the read-only state, the record permission is abnormal. If the frame number field changes the display state frequently, the record display is abnormal.

[0125] The issuance of red-letter invoices demonstrates the continuity of state transitions. The original invoice number field is initially displayed, and becomes read-only after the correct invoice number is entered. The return amount field changes from hidden to displayed. If the original invoice number is modified in the read-only state, an abnormal permission is recorded. If the return amount exceeds the original invoice amount, an abnormal value is recorded.

[0126] The process of issuing special invoices shows the time sequence of status changes. When the purchaser type is selected as a general taxpayer, the taxpayer identification number field status changes from hidden to displayed, and the tax rate field changes from read-only to optional. If the format of the taxpayer identification number is incorrect, the display status will remain and the format abnormality will be recorded. If the tax rate selection is incorrect, the status will return to read-only and the value selection abnormality will be recorded.

[0127] Furthermore, in this embodiment, step S4 specifically includes:

[0128] Obtain the display exception table according to the decision path, and use the backtracking algorithm to traverse from the end of the display condition combination to the starting end to obtain the condition combination backtracking sequence of the display exception field;

[0129] A table of operation error points is constructed for the condition combination backtracking sequence, and a Boolean operation calculator is used to decompose the Boolean expression to obtain a sequence of conditional nodes with operation errors.

[0130] A fault node graph is established based on the conditional node sequence of the operation error. If the operation results of the preceding node and the succeeding node are inconsistent, the node is marked as the fault source node.

[0131] Construct a fault cause chain for the fault source node, and use the cause analyzer to perform forward and reverse reasoning on the conditional values ​​of the fault source node to obtain a complete combination relationship of the fault conditions;

[0132] Specifically, a display exception table is constructed according to the decision path, and the identifier of the abnormal field and the display condition combination are recorded in the display exception table. A backtracking algorithm is used to traverse from the end of the condition combination to the starting end, and the value of each condition node is backtracked layer by layer according to the field dependency relationship. The identifier of the condition node and the corresponding Boolean value are recorded to obtain a backtracking sequence of the condition combination of the display abnormal field;

[0133] The operation error point location table is constructed by displaying the condition combination backtracking sequence of the abnormal field, the Boolean expression of the condition node is recorded in the location table, the Boolean expression is disassembled by using the Boolean operation calculator, and the Boolean value corresponding to each Boolean operator of AND operation, OR operation and NOT operation is calculated in order of priority to obtain the condition node sequence of the operation error;

[0134] Construct a fault node map for the sequence of conditional nodes with operation errors, mark the precondition node and successor condition node of each error node in the node map, and use the error locator to compare the Boolean operation results between nodes. If the operation results of the precondition node and the successor node do not match, mark the node as the fault source node, and obtain the set of fault nodes that cause display abnormality;

[0135] The fault cause chain is constructed through the set of fault nodes that cause display anomalies. The condition combination relationship of the fault source node is recorded in the cause chain. The cause analyzer is used to infer the condition value of the fault source node. The combination of trigger conditions is obtained through forward reasoning, and the expected value of the condition is obtained through reverse reasoning, thus obtaining the complete combination relationship of the fault condition.

[0136] Here is an example:

[0137] The display exception table describes the display errors of the fields in the electronic invoice. Taking the seller information as an example, when the taxpayer identification number field is abnormal, the backtracking algorithm traces back from this field and finds that the taxpayer identity field is selected as a general taxpayer and the annual sales revenue field value is 600000. The combination of the two conditions should trigger the display of the taxpayer identification number, but the actual status is hidden, so the display exception is recorded;

[0138] The operation error point location table presents the Boolean operation process of the condition combination. In the special VAT invoice, the display condition of the commodity detail field includes that the seller is a general taxpayer and the unit price of the commodity is greater than 0. The Boolean operation calculator disassembles the condition and finds that the seller identity judgment result is true and the unit price judgment result is true, but the operation result is false, so the operation error point is recorded. The fault node map shows the dependency relationship of the error conditions. In the motor vehicle invoice, the engine number field is displayed abnormally. The precondition is that the vehicle type should be displayed when the vehicle type is a new car and the purchaser is an individual user. The display status of the successor node frame number is associated with the display status of the engine number field. The error locator finds that the operation result of the engine number node does not meet the precondition and marks it as the fault source.

[0139] The fault cause chain reflects the abnormal transmission process. Take the red-ink invoice as an example. When the original invoice code field is filled in correctly but the original invoice number field cannot be displayed, forward reasoning finds that the original invoice type is selected correctly and the code number association is normal. Reverse reasoning finds that the original invoice number field is expected to be displayed. By comparison, it is found that the actual state is hidden, and the fault condition combination is located.

[0140] The display rules of electronic invoice fields are reflected in multiple scenarios. The discount line amount field in the ordinary invoice is displayed when the product line type is discount and the amount is less than 0. Retrospective analysis found that the product line type was selected correctly but the amount was a positive number, resulting in an abnormal display status of the field. Through calculation and decomposition, it was located that an error occurred in the amount judgment link;

[0141] The display logic of the input tax field in the special invoice is relatively complex. It is displayed when the buyer is a general taxpayer, the goods are taxable, and the tax rate is not zero. When an abnormal display occurs, it is found through layer-by-layer backtracking that the buyer's identity is correctly judged, the taxability of the goods is correctly judged, but the tax rate judgment result is wrong, and the fault is located at the tax rate node;

[0142] The self-issued invoice scenario reflects multiple condition judgments. The payee field is displayed when the settlement method is cash and the amount is greater than 5,000, and when the seller is a trading company and the goods are regulated goods. Retrospective analysis found that the settlement method and amount conditions were met, but there was a deviation in the judgment of the product attributes, resulting in an abnormal display status of the payee field.

[0143] Furthermore, in this embodiment, step S5 specifically includes:

[0144] Obtain the identifier and condition combination of the hidden error field according to the decision path, use the forward reasoning algorithm to perform hierarchical operations on the condition nodes, and obtain the conditional hierarchical table of the hidden error field;

[0145] A node operation graph is constructed for the conditional hierarchy table, and a rule inference calculator is used to perform priority sorting operations on the logical operation symbols between the nodes in the operation graph to obtain a logical error table of the operation nodes;

[0146] Construct an error condition location table based on the logic error table, use a rule validator to forward deduce the operation rules of the error condition nodes in the location table, and record the operation nodes whose operation results do not match the expected Boolean values ​​as error source nodes;

[0147] A conditional attribution table is constructed for the error source node, and a conditional attributor is used to forward trace the error source node, record the trigger path from the error source node to the hidden error field, and obtain the conditional attribution chain of the hidden error;

[0148] Specifically, a hidden field error table is constructed according to the decision path, and the identifier and condition combination of the hidden error field are recorded in the error table. The forward reasoning algorithm is used to start from the starting condition node, and the Boolean value of each node is calculated layer by layer according to the hierarchical relationship of the condition nodes. The operation results of each layer of condition nodes are recorded to obtain the conditional hierarchical table of the hidden error field.

[0149] A node operation graph is constructed by a conditional hierarchical table with hidden error fields, logical operation symbols between nodes are recorded in the operation graph, and the logical operation symbols are prioritized using a rule-based inference calculator. Starting from the highest priority operation symbol, the Boolean value of each conditional node is calculated in order of priority, and the input value and output value of each operation node are recorded to obtain a logical error table of the operation node.

[0150] Construct an error condition location table for the logical error table of the operation node, record the operation rules of the error condition node in the location table, use the rule verifier to forward deduce the rule operation process, if the operation result does not match the expected Boolean value, then record the operation node as the error source node, and obtain the source node table of hidden errors;

[0151] A conditional attribution table is constructed through the source node table of the hidden error. The triggering rules of the error source node are recorded in the attribution table. The error source node is forward tracked using the conditional attributor to record the complete triggering path from the error source node to the hidden error field. The expected state of each node is determined through rule verification to obtain the conditional attribution chain of the hidden error.

[0152] Here is an example:

[0153] The hidden field error table records the abnormal hidden status of the invoice field. Taking the special VAT invoice as an example, the purchaser's address field should be displayed after the taxpayer identification number is correctly filled in. Starting from the starting condition taxpayer identity judgment, the taxpayer type is calculated to be a general taxpayer, and the taxpayer identification number format is correct. The address field should be in the display state, but the actual state is hidden, which constitutes a hidden error;

[0154] The node operation diagram shows the calculation process of the condition combination. In the motor vehicle invoice, the engine number field should be displayed when the vehicle type is a new car and the buyer is an individual user. The rule reasoning calculator first processes the AND operator to calculate the combination of the vehicle type and the buyer type. If the input values ​​are all true and the output value is false, the logic error of the operation node is recorded.

[0155] The error condition location table reflects the source of hidden errors. In the red-ink invoice, the original invoice number field is displayed when the invoice code is correct and the amount is greater than 0. The rule validator deduces the operation process and finds that the invoice code verification result is true, the amount judgment result is true, but the final output is false, and the operation node is recorded as the error source;

[0156] The conditional attribution table records the error transmission path. In the ordinary invoice, the display rule of the discount line requires that the product type is a discount and the amount is less than 0. The conditional attribution starts tracing from the error source node and finds that the product type is selected correctly but the amount is judged incorrectly, resulting in the relevant fields of the discount line being incorrectly hidden;

[0157] The commodity details of special invoices reflect multi-level conditional judgments. The commodity code field is displayed when the commodity type is goods and the tax rate is not zero. Forward reasoning finds that the commodity type condition is met and the tax rate condition is met, but the code field is still hidden. Through rule verification, it is located that an error occurs in the compound condition operation link;

[0158] The invoice remark information shows the correlation of the condition combination. When the invoice amount exceeds 5,000 and the product is a controlled product, the remark field is displayed. Forward tracing finds that the amount condition and the product attribute condition are met, but the remark field is not displayed. Through attribution analysis, the fault is located at the condition combination operation node.

[0159] The display rules of the bank account field reflect the hierarchical relationship of the conditions. It is displayed when the settlement method is transfer and the amount is greater than 10,000. Forward reasoning finds that the settlement method and amount are judged correctly, but the result of the condition combination operation is wrong, resulting in the bank account field being incorrectly hidden, showing the complete process of error location and attribution.

[0160] Furthermore, in this embodiment, step S6 specifically includes:

[0161] Obtaining a display condition expression according to the decision path, extracting Boolean operation symbols and condition parameters from the display condition expression through a rule extraction tool, and obtaining a rule table of display conditions;

[0162] The expression result is calculated according to the value of the condition parameter, and the result table of the rule determination is obtained; the result of the rule determination is realized through the condition determination tool;

[0163] Obtain the field identifier through the result table, update the display mark according to the result table, and set the display mark of the rule judgment result to the true value to the display state; updating the display mark is achieved through the state update tool;

[0164] For the state of the display mark, a state adjustment instruction is generated by using an instruction execution tool, and the switching operation of the field display state is executed through the state adjustment instruction to obtain a dynamic control instruction of the field;

[0165] Specifically, a display rule base is constructed according to the decision path, field identifiers and corresponding display condition expressions are recorded in the rule base, Boolean operation symbols, condition parameters and threshold parameters are extracted from the condition expressions using rule extraction tools, rules are hierarchically numbered according to the dependency relationship of the condition expressions, and a rule table of display conditions is obtained;

[0166] A rule determination table is constructed by displaying the rule table of the conditions, and the value range and determination criteria of the condition parameters are recorded in the determination table. The condition determination tool is used to calculate the expression result according to the parameter value. In each level of Boolean operation, the combination determination of the preceding rule and the following rule is performed according to the priority order of the negation operation, the AND operation, and the OR operation to obtain the result table of the rule determination.

[0167] Construct a visibility state table for the result table of rule determination, record the field identifier and display mark in the state table, use the state update tool to change the field display mark according to the determination result, if the determination result is a true value, set the display mark to display, if the determination result is a false value, set the display mark to hide, and obtain the display mark table of the field;

[0168] A control instruction table is constructed through the display mark table of the field, update information of the display mark is recorded in the instruction table, and a state adjustment instruction is generated according to the change of the display mark by using an instruction execution tool;

[0169] Perform field status switching operations on preset display rules and hidden rules to obtain dynamic control instructions for the field;

[0170] Here is an example:

[0171] The display rule library records the display conditions of the electronic invoice fields. Taking the special VAT invoice as an example, the rule expression of the taxpayer identification number field in the purchaser information area is "the purchaser type is an enterprise and the taxpayer identity is a general taxpayer". The rule extraction tool parses the AND operator, the purchaser type parameter and the taxpayer identity parameter, and numbers the rule as a level 1 display rule.

[0172] The rule judgment table shows the value judgment of the condition parameters. In the motor vehicle invoice, the display of the engine number field depends on the compound condition of "the vehicle type is a new car and the purchaser type is an individual". The condition judgment tool first judges the non-operation condition, then executes the AND operation condition, and finally processes the OR operation condition. When the vehicle type parameter is "new car" and the purchaser type is "individual", the judgment result is true;

[0173] The visibility status table reflects the display status of the field. In the red-ink invoice, the display rule of the original invoice information field group includes "the invoice type is red-ink and the original invoice code is valid". The status update tool updates the display marks of the invoice code field, invoice number field, and invoice date field to the display status at the same time according to the rule judgment result;

[0174] The control instruction table records the execution process of the status change. In a common invoice, the display rule for the discount line is "the product line type is discount and the discount amount is less than 0". After receiving the display mark change information, the instruction execution tool generates display instructions for the relevant fields of the discount line and executes the dynamic switching of the field status.

[0175] The commodity details of special invoices reflect complex rule judgments. The commodity code field is displayed under the condition that "the commodity type is goods and the tax rate is not zero tax rate". The judgment process first verifies the commodity type condition, and then judges the tax rate condition. When both conditions are met, the display mark is updated and the display control instruction is generated;

[0176] The invoice remark information shows a combination of multiple rules. When "the invoice amount is greater than 5,000 or the commodity type is a controlled commodity", the remark field is displayed. The conditional judgment tool first processes the amount comparison and commodity type judgment, and then performs the or operation judgment, and dynamically controls the field display status according to the judgment result. The bank account information reflects the hierarchical relationship of the rules. When the "settlement method is transfer and the amount is greater than 10,000" condition is displayed, the rule extraction tool marks the rule as a high priority, and the display instruction is immediately triggered when the judgment result is true, reflecting the real-time nature of rule execution;

[0177] Furthermore, based on business needs and user roles, pre-defined condition combination rules for triggering field display and hiding are used. During the filling process of electronic tax invoices, the user input data and system status are obtained in real time and matched with the pre-defined display rules and hiding rules. When a display rule or hiding rule that meets the conditions is matched, the corresponding field visibility status is triggered to change, that is, the corresponding field is displayed or hidden;

[0178] That is, a permission control table is constructed according to the electronic invoice field identifier, and the user role information is read using the identity identifier to obtain a field permission table with permission verification marks;

[0179] Construct a display rule table for the field permission table with permission verification mark, use the data validator to read the field filled value, perform numerical range verification and format specification verification on the field filled value, and obtain the rule table after field verification;

[0180] A rule comparison table is constructed through the rule table after field verification, and a rule checker is used to match the current Boolean value of the field to determine whether the current value of the field meets the display rule value conditions, and a rule matching table for the field is obtained;

[0181] A state change table is constructed for the rule matching table of the field, and a state switcher is used to perform state conversion. If the field value meets the display rule and passes the permission check, it is converted to the display state. If the field value triggers the hidden rule or fails the permission check, it is converted to the hidden state.

[0182] Specifically, a permission control table is constructed based on the fields of the electronic tax invoice, and the field identifier and role permission mark are recorded in the control table. The identity identifier is used to read the user role information, and the display permission of the general user to the basic fields, the display permission of the administrator to all fields, and the display permission of the auditor to the key fields are set. The permission marks are grouped according to the business field to which the field belongs, and a field table with permission verification marks is obtained;

[0183] A display rule table is constructed through a field table with permission verification marks. The field value range of the display condition is recorded in the rule table. The data validator is used to read the field value in real time. The value range of the numeric field is verified, the format specification of the text field is verified, and the time interval of the date field is verified. The verified data is converted into a standard Boolean variable to obtain a rule table after field verification.

[0184] A rule comparison table is constructed for the rule table after field verification, and the preset display rules and hiding rules are recorded in the comparison table. A rule checker is used to match the current Boolean value of the field to determine whether the current value of the field meets the value conditions of the display rule and whether the current value of the field triggers the restriction conditions of the hiding rule, thereby obtaining the rule matching table of the field.

[0185] A state change table is constructed through the rule matching table of the field, and the field identifier and display state value are recorded in the change table. A state switcher is used to perform state conversion according to the rule matching result. When the field value meets the display rule and passes the permission check, it is converted to display. When the field value triggers the hiding rule or fails the permission check, it is converted to hiding, and the state change instruction of the field is obtained;

[0186] Here is an example:

[0187] The permission control table describes the permission allocation rules for fields. Taking VAT special invoices as an example, the taxpayer identification number field in the seller information area is displayed to all users, the bank account field is only displayed to administrators, and the void mark field is only displayed to auditors. When the identity identifier reads the user role as a cashier, the bank account field is granted display permission, while the void mark field is not granted display permission.

[0188] The display rule table records the field value validation rules. In the motor vehicle invoice, the engine number field requires a 6- to 8-digit alphanumeric combination, and the frame number field requires a 17-digit alphanumeric combination. The data validator verifies the length and format of the engine number input value, and converts it to a Boolean true value if the verification passes, and converts it to a Boolean false value if the verification fails.

[0189] The rule comparison table shows the matching process of the preset rules. In the red-ink invoice, the preset display rule of the original invoice code field is "invoice type is red ink", and the preset display rule of the original invoice amount field is "original invoice code is filled in". When the rule checker determines that the invoice type is selected as red ink, the original invoice code field matches the display rule;

[0190] The status change table records the switching process of the field display status. In ordinary invoices, the display rule of the discount line amount field is "product line type is discount", and the hiding rule is "discount amount is greater than or equal to 0". The status switcher matches the result of the rule. When the product line type is selected as discount and the discount amount is less than 0, it switches to the display state.

[0191] The input tax amount field in the special invoice reflects complex permission control. This field requires the user to have administrator permissions and meet the display rule of "the purchaser is a general taxpayer". After the identity identifier determines the user's permissions, the rule verifier verifies the identity of the purchaser. The display status is triggered only when both conditions are met.

[0192] The invoice note information displays multiple rule combinations. The note field is displayed to all users. At the same time, the preset display rule "invoice amount is greater than 5,000 or the product type is a controlled product" is set. The rule checker first verifies the amount condition and then the product type condition. The display status is triggered when either of the two conditions is met.

[0193] The bank account information reflects the strictness of the validation rules. The account number field requires the input of numbers with a length between 12 and 19 digits. The data validator performs format and length checks on the input value. The bank name field requires selection from a preset list. After the validation passes, the field is displayed.

[0194] Furthermore, in this embodiment, step S7 specifically includes:

[0195] Obtain the scenario feature library based on the invoice type and field identifier, use the feature tagger to mark the feature values ​​of the invoice amount area, taxpayer type, commodity category, and settlement method, and obtain the scenario feature matrix;

[0196] Construct a similarity comparison table for the scene feature matrix, calculate the matching degree of feature dimensions, and calculate the similarity between the current scene and historical case features to obtain a case similarity ranking set; calculate the matching degree of feature dimensions through the case reasoning algorithm, and calculate the similarity between the current scene and historical case features through the Manhattan distance formula;

[0197] A rule extraction table is constructed based on the case similarity sorting set, and the condition parameters and threshold parameters in the display rule are marked by the rule annotator, the matching degree of the rule conditions is scored, and the display rule is extracted from the case with the highest similarity;

[0198] A rule mapping table is constructed for the display rules, and a rule mapper is used to convert numerical parameters in proportion and to convert category parameters according to mapping relationships to obtain a field display scheme;

[0199] Specifically, a scenario feature library is constructed based on historical invoice data. Invoice types, field identifiers, and display rules are recorded in the feature library. A feature tagger is used to mark the scenario feature values ​​of four dimensions: invoice amount range, taxpayer type, commodity category, and settlement method. Corresponding feature weights are set for the feature values ​​of each dimension. Historical cases are grouped according to invoice types to obtain a scenario feature matrix.

[0200] A similarity comparison table is constructed through the scene feature matrix. The feature values ​​of the current invoice scene are recorded in the comparison table. The matching degree of the feature dimension is calculated using the case reasoning algorithm. The weighted similarity is calculated according to the weight ratio of the feature dimension. The feature similarity between the current scene and the historical case is calculated using the Manhattan distance formula to obtain a sorted set of case similarities.

[0201] A rule extraction table is constructed for the sorted set of case similarities, and the display rules of historical cases are recorded in the rule extraction table. The condition parameters and threshold parameters in the display rules are marked by a rule annotator, and the matching degree of the rule conditions is scored. The display rules are extracted from the cases with the highest similarity to obtain the combination of the optimal display rules.

[0202] A rule mapping table is constructed by combining the optimal display rules, and the parameter mapping from the historical rules to the current scene is recorded in the mapping table. A rule mapper is used to convert the parameter type of the display rule, convert the numerical parameters according to the ratio, and convert the category parameters according to the mapping relationship. The converted rules are displayed and controlled to obtain the display scheme of the field.

[0203] Here is an example:

[0204] The scenario feature library records the characteristic attributes of electronic invoices. Taking the special VAT invoice as an example, the feature tagger marks the amount range as 5,000 to 10,000, the taxpayer type as a general taxpayer, the commodity category as goods, and the settlement method as transfer. The amount dimension weight is 0.3, the taxpayer dimension weight is 0.3, the commodity dimension weight is 0.2, and the settlement dimension weight is 0.2, forming a complete scenario feature vector.

[0205] The similarity comparison table shows the scene matching process. In the motor vehicle invoice, the current scene features are amount 8000, general taxpayer, motor vehicle, and transfer, and the historical case features are amount 9000, general taxpayer, motor vehicle, and cash. The case reasoning algorithm calculates the similarity of the amount dimension as 0.9, the taxpayer dimension as 1.0, the commodity dimension as 1.0, and the settlement dimension as 0.8, and obtains a weighted similarity of 0.93.

[0206] The rule extraction table reflects the selection process of display rules. In the red-letter invoice, the historical case with the highest similarity contains the original invoice code display rule "the invoice type is red-letter and the amount is greater than 5000". The rule annotator marks the invoice type as a category parameter and the amount as a numerical parameter. The rule matching score is 0.95, and this rule is selected as the optimal display rule.

[0207] The rule mapping table records the adaptation process of rule conversion. In the ordinary invoice discount line rule, the numerical parameter 10% in the historical rule "Discount amount is less than 10% of the original amount" needs to be converted. The rule mapper adjusts the ratio to 8% based on the amount range of the current scenario and generates a new display rule.

[0208] The commodity details of special invoices reflect multi-dimensional feature matching. The current scenario features are amount 15,000, general taxpayer, goods, and transfer, which are matched with the historical case features of amount 16,000, general taxpayer, goods, and transfer. The similarity of the four dimensions exceeds 0.9, and the display rules of this case are adopted;

[0209] The invoice note information shows the rule parameter conversion. The historical rule "the amount is greater than 5,000 or the product is a controlled product" needs to be adapted. The rule mapper adjusts the amount threshold to 6,000 according to the current scenario, and the product category mapping remains unchanged, forming a new display rule.

[0210] Bank account information reflects the category parameter mapping. The "settlement method is bank remittance" in the historical rule is converted to the "settlement method is transfer" in the current scenario, keeping the numerical parameters unchanged to achieve scenario adaptation of the rule, reflecting the flexibility of rule conversion.

[0211] In the description of the present invention, it is necessary to understand that the directions or positional relationships indicated by directional words such as "front, back, up, down, left, right", "lateral, vertical, horizontal" and "top, bottom" are usually based on the directions or positional relationships shown in the drawings. They are only for the convenience of describing the present invention and simplifying the description. Unless otherwise specified, these directional words do not indicate or imply that the device or element referred to must have a specific direction or be constructed and operated in a specific direction. Therefore, they cannot be understood as limiting the scope of protection of the present invention.

[0212] For those skilled in the art, various other corresponding changes and deformations can be made according to the technical solutions and concepts described above, and all of these changes and deformations should fall within the protection scope of the claims of the present invention.

Claims

1. An intelligent filling and verification method for electronic tax invoices, characterized in that: The following steps are involved: S1. Obtain the display condition combination rules of the electronic tax invoice fields, build a field visibility dependency chain model, and obtain the decision path of field visibility by analyzing the logical relationship between fields and the temporal relationship of trigger conditions; S2. Obtain the decision nodes of the field visibility dependency chain model, and determine the visibility status of the fields corresponding to the decision nodes under the current condition combination; S3. Obtain the temporal relationship of the trigger conditions on the decision path, analyze the dynamic change process of field visibility through the state transition diagram, and determine the final visibility of the field; S4. For fields with abnormal display, a backtracking algorithm is used to infer the logical operation process of the display condition combination, and the condition combination that causes the abnormal field display is located through logical chain analysis; S5. For fields with hidden errors, a forward reasoning algorithm is used to infer the logical operation process of the hidden condition combination, and the condition combination that causes the field hiding error is located through logical chain analysis; S6. According to the decision path and the logical operation result of the condition combination, the rule engine technology is used to dynamically control the visibility of the field to achieve adaptive adjustment of the field visibility; S7. The case reasoning technology is used to analyze the historical cases of field visibility control to obtain the optimal field display solution, and apply it to the current electronic tax invoice field visibility control; The step S1 specifically includes: establishing a field display rule matrix according to the electronic tax invoice field rule data, and storing the field display rules by using the mapping relationship between the field identifier and the display condition interval; constructing a field association directed graph for the field display rule matrix, and determining the degree of association between fields by using a condition association strength calculation formula, and the condition association strength calculation formula is as follows: R=N1 / N2, wherein R represents the condition association strength; N1 represents the number of times two fields are displayed at the same time; N2 represents the total number of times the field is displayed; obtaining the field node in-degree value from the field association directed graph to construct a field dependency priority queue, and obtaining a field display dependency tree by processing with a decision tree algorithm; establishing a field trigger sequence table for the field display dependency tree, and sorting the field trigger relationship by a topological sorting tool to obtain a field display trigger path ordered table; The step S3 specifically includes: obtaining a trigger sequence table according to the decision path, the trigger sequence table records the field identifier and the trigger timestamp, and sorting the trigger timestamp through a timing sorting tool to obtain a field trigger timing table; constructing a finite state transition graph for the field trigger timing table, marking display state nodes, hidden state nodes and read-only state nodes in the finite state transition graph, and calculating the transition function between nodes through a state machine operation tool to obtain a field state transition rule table; constructing a state space graph according to the field state transition rule table, setting directed edges in the state space graph to represent the state transition path, and verifying the state value in the state transition path through a state verification tool to obtain a state verification result table; constructing an abnormal state record table for the state verification result table, and recording the abnormal state of the field to obtain a field abnormal type table.

2. The method for intelligent filling and verification of electronic tax invoices according to claim 1 is characterized in that: The step S2 specifically includes: obtaining a field identifier and a decision node identifier, using a mapping tool to construct a field decision mapping table, the field decision mapping table records the correspondence between the field identifier and the decision node identifier; extracting a conversion condition from the decision node according to the decision node identifier, and converting the conversion condition into a Boolean expression with an operator, or an operator and a non-operator through a Boolean expression parsing tool; constructing an operation truth table for the Boolean expression, and recording the Boolean conditions in the rows and the node identifiers in the columns to obtain a Boolean expression operation result; if the Boolean expression operation result is a true value, then setting the display state of the field identifier to display in the field display state table; if the Boolean expression operation result is a false value, then setting the display state of the field identifier to hide in the field display state table.

3. The intelligent filling and verification method of electronic tax invoice according to claim 1 is characterized in that: The step S4 specifically includes: obtaining a display exception table according to the decision path, traversing from the end of the display condition combination to the starting end using a backtracking algorithm to obtain a condition combination backtracking sequence of the display exception field; constructing an operation error point positioning table for the condition combination backtracking sequence, and using a Boolean operation calculator to decompose the Boolean expression to obtain a condition node sequence of operation errors; establishing a fault node map according to the condition node sequence of operation errors, if the operation results of the preceding node and the succeeding node do not match, marking the node as a fault source node; constructing a fault cause chain for the fault source node, and performing forward reasoning and reverse reasoning on the condition value of the fault source node through a cause analyzer to obtain a complete combination relationship of the fault conditions.

4. The intelligent filling and verification method of electronic tax invoice according to claim 1 is characterized in that: The step S5 specifically includes: obtaining the identifier and condition combination of the hidden error field according to the decision path, using the forward reasoning algorithm to perform hierarchical operations on the condition nodes to obtain the conditional hierarchical table of the hidden error field; constructing a node operation graph for the conditional hierarchical table, using a rule reasoning calculator to perform priority sorting operations on the logical operation symbols between the nodes in the operation graph to obtain a logical error table of the operation nodes; constructing an error condition positioning table according to the logical error table, using a rule validator to forward deduce the operation rules of the error condition nodes in the positioning table, and recording the operation nodes whose operation results do not match the expected Boolean values ​​as error source nodes; constructing a conditional attribution table for the error source nodes, using a conditional attributor to forward trace the error source nodes, recording the triggering path from the error source nodes to the hidden error field, and obtaining the conditional attribution chain of the hidden error.

5. The intelligent filling and verification method of electronic tax invoice according to claim 1 is characterized in that: The step S6 specifically includes: obtaining a display condition expression according to the decision path, extracting Boolean operation symbols and condition parameters from the display condition expression through a rule extraction tool to obtain a rule table of display conditions; calculating expression results according to the values ​​of the condition parameters, and obtaining a result table of rule determination; obtaining a field identifier through the result table, updating a display mark according to the result table, and setting the display mark with a true value as a display state for the rule determination result; for the state of the display mark, using an instruction execution tool to generate a state adjustment instruction, executing a field display state switching operation through the state adjustment instruction, and obtaining a dynamic control instruction for the field.

6. The method for intelligent filling and verification of electronic tax invoices according to claim 1 is characterized in that: The step S7 specifically includes: obtaining a scenario feature library according to the invoice type and field identifier, using a feature tagger to mark feature values ​​for the invoice amount area, taxpayer type, commodity category, and settlement method, and obtaining a scenario feature matrix; constructing a similarity comparison table for the scenario feature matrix, calculating the degree of feature dimension matching, and calculating the similarity between the current scenario and historical case features, and obtaining a case similarity sorting set; constructing a rule extraction table according to the case similarity sorting set, using a rule tagger to mark condition parameters and threshold parameters in the display rules, scoring the degree of rule condition matching, and extracting display rules from the cases with the highest similarity; constructing a rule mapping table for the display rules, using a rule mapper to convert numerical parameters in proportion, and convert category parameters according to a mapping relationship, and obtaining a field display solution.

Images