Method and system for consistent recovery of failed nodes of finance and tax automation tasks

Abstract

The application discloses a kind of failure node of finance and tax automation task and state consistency recovery method and system, comprising the following steps: step S1, receive instruction, read data;Step S2, disassemble or restore to multiple node technical units;Step S3, generate node snapshot;Step S4, execute failure influence range identification and subsequent node control;Step S5, generate recovery strategy and the set of nodes to be continued to run;Step S6, execute before verification and dispatch issue of continuation;Step S7, execute result receiving and idempotent state update;Step S8, execute state consistency correction, and again check data version, node state and idempotent identification again.The system includes node snapshot module, failure identification module, subsequent freezing module, front verification module, continuation scheduling module, idempotent callback module, state correction module and archive monitoring module.The application forms the state machine chain that can be calculated, can be tracked, can be recovered, and stability can be maintained when a large number of enterprises are simultaneously processed.

Description

Technical Field

[0001] This invention relates to a method and system for recovering automated financial and tax tasks, and more particularly to a method and system for resuming failed nodes and restoring state consistency in automated financial and tax tasks. Background Technology

[0002] In the process of accounting agencies providing bulk services to enterprises, the recovery from failed financial and tax automation tasks is a critical link affecting the efficiency and accuracy of automation. If this link is not handled adequately, it will directly affect subsequent voucher generation, report retrieval, tax declaration, deduction inspection, or file collection.

[0003] When existing automated tax and finance tasks fail, they typically require either a complete rerun or manual correction. It's difficult to determine which nodes can be retained and which need to be restarted based on node snapshots, data versions, and external confirmations, easily leading to duplicate declarations, deductions, or voucher generation. This not only manifests as operational efficiency issues but also as inconsistencies between data status, external execution confirmations, manual confirmation boundaries, and process dependencies. If the system relies solely on page buttons or simple task statuses for control, it struggles to determine the next step—whether to continue, wait, roll back, or re-execute—in cases of expired tax authority authorization, changes in bank document formats, updated report data versions, delayed manual confirmation, or duplicate robot callbacks.

[0004] Therefore, an implementation solution is needed that appropriately upgrades the existing business logic to unify business rules, data fields, process status, and exception handling into system control. Summary of the Invention

[0005] To address the shortcomings of the aforementioned technologies, this invention provides a method and system for resuming failed tasks and restoring state consistency in automated financial and tax tasks. Through data structuring, node-based processing, rule-based judgment, and state-based control, existing business logic can operate stably in environments with multiple enterprises, multiple payment periods, and multiple external systems.

[0006] To solve the above technical problems, the technical solution adopted by this invention is: a method for resuming failed nodes and restoring state consistency in financial and tax automation tasks, comprising the following steps: Step S1: Receive failure recovery instructions for the enterprise's target payment period and read data to form the context of the task to be recovered; Step S2: Based on the task context to be restored formed in step S1, the task context to be restored is decomposed or restored into multiple node technical units according to the financial and tax automation process. Step S3: Based on the node technical units and their input data obtained in step S2, standardize and version the output and subsequent dependency information of failed nodes, predecessor nodes, and successors to generate node snapshots. Step S4: Based on the node snapshots, data versions, exception types, subsequent dependencies, and external receipts obtained in Step S3, identify the scope of impact of the execution failure and control subsequent nodes. Step S5: Based on the anomaly type and node risk level obtained in Step S3, and combined with the enterprise configuration and manual confirmation status in Step S1, generate a recovery strategy and a set of nodes to be run. Step S6: Perform pre-resumption verification and scheduling on the set of nodes to be resumed output in step S5, and verify them. Step S7: Receive the execution result and update the idempotent state; Step S8: Correct the consistency of the execution status based on the node execution result and status update record written in step S7, and re-verify the data version, node status and idempotency flag when the subsequent node calls the node execution result.

[0007] Preferably, the method specifically includes the following steps: Step S1: Read the task instance, failed node identifier, enterprise configuration, tax type configuration, payment period status, manual confirmation status, external receipt, execution log, and attachment records to form the context of the task to be recovered; the enterprise configuration is used to determine whether the node is allowed to automatically resume, whether manual confirmation is required, and the available execution resources; Step S2: Write the enterprise identifier, payment period, business type, node type, input data, execution conditions, output results, exception code, callback identifier, data version, node risk level, resource lock identifier, and subsequent dependencies into each node technical unit; Step S3: The node snapshot should include at least the following: data summary before processing, data summary after processing, source data version, processing result version, manually confirmed version, external receipt number, screenshot or file address, exception type and exception reason; Step S4: Set the successor nodes that depend on the output results of failed nodes, expired data versions, or conflicting external receipts to the successor frozen or pending verification state, and retain the completed nodes whose input version, output version, and external receipt are consistent. Step S5, recovery strategies include automatic continuation, delayed retry, manual confirmation, abnormal suspension, external status verification, skipping or archiving; Step S6: Verify enterprise authorization, billing status, configuration status, resource lock, manual confirmation, data version, and idempotency identifier; after successful verification, acquire the resource lock, send the task parameters to the corresponding execution end, and update the node status from pending execution to execution. Step S7: Receive the execution result returned by the execution end, generate or verify the idempotent key based on the enterprise identifier, billing period, business type, node type, data version, external serial number and callback serial number; when the state corresponding to the idempotent key has been completed, reject duplicate updates and record duplicate callback logs; when the state corresponding to the idempotent key has not been completed and the external receipt is valid, write it into the business table, status table, log table and attachment table to form the node execution result;

[0008] Step S8: If the verification passes, the corresponding successor node is unfrozen and the successor node is triggered to enter the executable judgment; if the verification fails, the old result is marked as expired and returned to step S3 or step S5 for reprocessing; after completion, a traceable archive record is generated.

[0009] Preferably, in step S2, the automated financial and tax process includes at least one of the following: initialization, tax register collection, checklist authentication, invoice collection, bank collection, individual income tax data copying, cumulative or special deduction collection, document confirmation, AI accounting processing, voucher generation, closing, manual verification, tax payment confirmation, declaration, payment, tax payment certificate collection, omission detection, social security collection, social security declaration confirmation, social security declaration, social security deduction confirmation, social security deduction, social security inspection, and file collection.

[0010] Preferably, in step S3, the source data version is calculated from the update time, summary value, or external serial number of invoices, bank statements, payrolls, vouchers, reports, configuration items, tax bureau lists, social security details, manual confirmation records, and attachments; the processing result version is calculated from the rule code, input version, execution terminal identifier, and processing time.

[0011] Preferably, the subsequent freezing in step S4 includes: freezing the successor nodes that directly depend on the output results of the failed node based on the node snapshot, data version and successor dependency relationship generated in step S3; marking the nodes that indirectly depend on the failed node and have entered the pre-execution waiting state as pending verification; and performing external status verification on nodes that have been successfully submitted to the external tax bureau, bank or deduction system and have valid external receipts without resubmitting.

[0012] Preferably, in step S5, the recovery strategy is determined based on the exception code; when data is missing or the field format is inconsistent, it enters the data repair queue and freezes the nodes that depend on the data; when the enterprise authorization expires, it enters the authorization reminder queue; when the external system times out or the robot goes offline, it enters the delayed retry queue; when manual confirmation times out, it performs automatic confirmation, pending reminder or exception suspension according to the enterprise configuration; when the data version changes, it re-executes the corresponding node verification and generates a new version result.

[0013] Preferably, in step S5, the idempotency identifier is generated by combining at least two of the following: enterprise identifier, payment period, tax type or business type, node type, source data version, processing result version, and external serial number; for actions such as declaration, deduction, cancellation, correction, voucher deletion, and data overwrite, the risk level and confirmer identifier are also written into the idempotency verification information.

[0014] Preferably, the state consistency correction in step S8 includes: comparing the node execution result, execution log, external receipt, node snapshot, and manual confirmation record formed in step S7; when the task status is failed but the external receipt shows success, transferring the node to external status verification and rewriting the success receipt; when the task status is successful but the input data version has changed, marking the node result as expired and freezing the successor node; when duplicate callbacks occur, keeping the original state unchanged and writing to the audit log.

[0015] A system for resuming failed tasks and restoring state consistency in financial and tax automation tasks, used to implement the above methods, includes: Node snapshot module: Used to receive and standardize business input data; Failure identification module: used to identify processing conditions and generate processing nodes; Subsequent freeze module: used to execute core business rules and perform data verification; Pre-verification module: used to verify enterprise payment period, authorized online status, configuration status, tax type activation status, manual confirmation status, resource lock status, data version, and idempotency identifier; The continuation scheduling module is used to write nodes that have passed the pre-verification into a queue and distribute them to the adaptation execution end. Idempotent callback module: Used to receive the execution result. The input includes callback serial number, external receipt, screenshot address, error code and execution identifier. Status correction module: used to save processing results for subsequent processes to call; Archive monitoring module: Used to save recovery reports and attachments, and periodically monitor authorized online status, robot survival status, queue length, failure rate, callback delay and external system response time; its monitoring results serve as input parameters for resume scheduling, delayed retry, anomaly alerts or canary activation.

[0016] In this invention, step S2 completes the disassembly of node technical units, step S3 generates node snapshots and data versions, step S4 determines the freezing range based on snapshots and subsequent dependencies, step S5 outputs the recovery strategy and the set of nodes to be run, step S6 completes verification and scheduling, step S7 completes the receiving of execution results and idempotent updates, and step S8 completes state consistency correction and subsequent unfreezing, thereby forming a computable, traceable, and recoverable state machine chain.

[0017] Compared to existing single-point automation solutions, this invention transforms the failure recovery of financial and tax automation tasks into a computable state machine and data processing chain. In this chain, machine execution, manual confirmation, anomaly recovery, and result archiving are all incorporated into a unified technical framework, thus maintaining stability when processing large numbers of enterprises simultaneously. This invention focuses on failure recovery for financial and tax automation tasks, structuring enterprise information, payment terms, business data, rule results, manual confirmation, and external receipts to establish traceable data states and process nodes. The system completes automatic processing through a rule engine, process engine, and execution-end interface, and controls operations based on data version, node status, and idempotency flags in abnormal situations. This invention improves the accuracy of automated processing, anomaly recovery capabilities, and stability of multi-enterprise batch processing on the existing financial and tax business logic of WhaleCalculator. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the components of the financial and tax automation task failure recovery system of the present invention.

[0019] Figure 2 This is a schematic diagram of the main process for failure recovery in this invention.

[0020] Figure 3 This is a schematic diagram of the abnormal control in steps S4 to S8 of the present invention. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0022] This invention is based on the existing accounting and tax outsourcing business logic of WhaleCalculator, and performs structured modeling of key objects in the recovery of failed accounting and tax automation tasks. These objects include at least the enterprise, payment period, tax type, task node, data version, execution resources, human role, rule results, and external receipts. These objects form a traceable state chain in the database, enabling the system to maintain clear boundaries between automated execution, manual confirmation, and anomaly recovery.

[0023] This invention breaks down the failure recovery of automated financial and tax tasks into multiple technical units that can be identified, scheduled, verified, and recovered by a computer. Each technical unit has input data, execution conditions, output results, exception codes, callback identifiers, and subsequent dependencies. The system combines these technical units through a rule engine and a process engine to obtain a stable automated processing procedure.

[0024] like Figure 1The system shown includes a node snapshot module, a failure identification module, a subsequent freeze module, a pre-verification module, a continuation scheduling module, an idempotent callback module, a status correction module, and an archive monitoring module. Each module performs data snapshot, failure identification, impact scope control, pre-continuation verification, task scheduling, callback idempotent control, status consistency recovery, and attachment log archiving, respectively. Enterprise, payment period, invoice, bank, payroll, voucher, report, social security, manual confirmation, and external receipt data first enter the node snapshot module, then the failure identification module identifies failed nodes, the subsequent freeze module controls affected nodes, the pre-verification module determines whether continuation is possible, the continuation scheduling module sends the execution to the execution end, the idempotent callback module receives the execution result, the status correction module writes back the consistency status, and the archive monitoring module saves screenshots, receipts, reports, logs, and recovery reports.

[0025] In terms of data storage, the system preferably sets up a main business database, a task status database, a log database, and file object storage. The main business database stores business data such as enterprise, account set, tax type, account, voucher, invoice, bank statement, payroll, assets, and inventory; the task status database stores node status, queue status, lock status, and callback status; the log database stores robot execution logs, manual confirmation logs, and exception recovery logs; and the file object storage stores screenshots, receipt images, report files, and attached figures.

[0026] On the execution side, the system can connect with e-tax bureau robots, individual income tax synchronization assistants, bank data collection programs, invoice collection programs, OCR recognition services, voucher generation services, and quality inspection scoring services. Each execution terminal does not directly determine the business process, but completes controlled actions according to the task parameters issued by the server, and returns the execution results, external page status, screenshot address, error reason, and callback serial number to the server.

[0027] In terms of security and compliance, the system sets idempotent flags and permission checks for high-risk actions involving declaration, deduction, cancellation, correction, voucher generation, and data overwriting. Idempotent flags can be generated by combining enterprise identifier, payment period, tax type, node type, data version, and external serial number; permission checks can distinguish between main account, consultant accountant, quality inspection accountant, robot account, and interface account to prevent low-privilege roles from triggering irreversible operations.

[0028] Node Snapshot Module: Used to receive and standardize business input data; the input of this module includes enterprise identifier, payment period, tax type, source business data, manual confirmation record and external receipt, and the output includes standardized data object, source data version, processing result version, node snapshot number and snapshot summary; its preferred implementation is to calculate the summary value of the data before and after processing, and save the screenshot, file address and anomaly reason.

[0029] Failure identification module: used to identify processing conditions and generate processing nodes; the input of this module includes node status, execution log, exception code, external receipt and node snapshot, and the output includes failure node identifier, failure type, exception level, affected successor nodes and processing suggestions; its preferred implementation is to classify according to data exception, authorization exception, external system exception, manual confirmation exception, resource conflict exception and duplicate callback exception.

[0030] Subsequent Freeze Module: Used to execute core business rules and data verification; the input of this module includes node dependencies, source data version, processing result version and failure identification result, and the output includes a frozen node list, a node to be verified list, a node to be retained list and the reason for freezing; its preferred implementation is to freeze only nodes that depend on failed nodes or expired data versions, and retain completed nodes with valid external receipts and consistent data versions.

[0031] Pre-verification module: Used to verify enterprise payment period, authorized online status, configuration status, tax type activation status, manual confirmation status, resource lock status, data version and idempotency flag, and output whether continued operation is allowed and whether continued operation is not allowed. The continuation scheduling module is used to write nodes that have passed the pre-verification into a queue and send them to the adapted execution end. The inputs include the nodes to be continued, the execution end capabilities, resource locks and retry policies, and the outputs include the execution status, robot task number and callback address. Idempotent callback module: Used to receive the execution result. The input includes callback serial number, external receipt, screenshot address, error code and execution identifier. The output includes node final status, duplicate callback log and archive record. Status Correction Module: Used to save processing results for subsequent process calls; the input of this module includes the node execution result formed in step S7, node snapshot, external receipt, manual confirmation record, repeated callback log and subsequent node call request, and the output includes the corrected node status, expiration mark, subsequent unfreezing result, audit log and archive record; its preferred implementation is to perform a consistency comparison of the business table, status table, log table and attachment table before writing the final status.

[0032] Archive monitoring module: Used to save recovery reports and attachments, and periodically monitor authorized online status, robot survival status, queue length, failure rate, callback delay and external system response time; its monitoring results serve as input parameters for resume scheduling, delayed retry, anomaly alerts or canary activation.

[0033] This invention preferably uses the following data fields: company_id, period, source_type, source_id, data_version, rule_code, rule_result, node_status, manual_role, confirm_status, external_receipt_no, idempotent_key, and archive_path. Field names can be adjusted according to specific database specifications, but the meaning of the fields should support process judgment, status tracking, idempotent control, and exception recovery.

[0034] The method for resuming failed tasks and restoring state consistency in tax automation tasks first establishes a data object model for task failure recovery, associating and storing enterprise, payment period, source data, rule results, execution status, human role, and external receipts. The system uses a rule engine to determine whether each processing node meets the execution conditions and a workflow engine to determine whether subsequent processing should proceed to automatic processing, manual confirmation, exception suspension, or result archiving. When data loss, version changes, duplicate external callbacks, or incomplete manual confirmation occur, the system performs isolation processing based on idempotency indicators and node status to prevent errors from propagating to subsequent nodes. Figure 2 This is a schematic diagram of the main process for failure recovery in this invention, corresponding to steps S1 to S8, which specifically includes the following steps: Step S1: Receive the failure recovery instruction for the enterprise's target payment period, read the task instance, failure node identifier, enterprise configuration, tax type configuration, payment period status, manual confirmation status, external receipt, execution log and attachment records to form the task context to be recovered; the enterprise configuration is used to determine whether the node is allowed to automatically continue, whether manual confirmation is required, and the available execution resources.

[0035] Step S2: Based on the task context to be restored formed in Step S1, disassemble or restore multiple node technical units according to the financial and tax automation process, and write the enterprise identifier, payment period, business type, node type, input data, execution conditions, output results, exception code, callback identifier, data version, node risk level, resource lock identifier and subsequent dependency relationship into each node technical unit.

[0036] Step S3: Based on the node technical units and their input data obtained in step S2, standardize and version the output and subsequent dependency information of failed nodes, predecessor nodes, and successors to generate a node snapshot; the node snapshot includes at least the data summary before processing, the data summary after processing, the source data version, the processing result version, the manually confirmed version, the external receipt number, the screenshot or file address, the exception type, and the exception reason.

[0037] Step S4: Based on the node snapshot, data version, exception type, subsequent dependency and external receipt obtained in step S3, perform failure impact scope identification and subsequent node control. Set the subsequent nodes that depend on the output results of the failed node, expired data version or conflicting external receipt to a frozen or pending verification state, and retain the completed nodes whose input version, output version and external receipt are consistent.

[0038] Step S5: Based on the anomaly type and node risk level obtained in Step S3, and combined with the enterprise configuration and manual confirmation status in Step S1, generate a recovery strategy and a set of nodes to be continued; the recovery strategy includes automatic resumption, delayed retry, manual confirmation, anomaly suspension, external status verification, skipping or archiving.

[0039] Step S6: Perform pre-run verification and scheduling on the set of nodes to be run output in step S5. Verify enterprise authorization, billing status, configuration status, resource lock, manual confirmation, data version, and idempotency flag. After the verification is passed, acquire the resource lock, send the task parameters to the corresponding execution end, and update the node status from pending execution to execution.

[0040] "Execution" refers to a node completing a controlled action according to its node type, such as reading invoices or bank data, generating vouchers, executing rule judgments, sending declaration parameters to the robot, saving tax bureau screenshots, receiving external receipts, or generating archived records; it is not simply clicking a page button.

[0041] Step S7, Receiving Execution Results and Updating Idempotent Status: Receive the execution results returned by the execution end, and generate or verify idempotent keys based on enterprise identifier, billing period, business type, node type, data version, external serial number, and callback serial number; when the state corresponding to the idempotent key has been completed, reject duplicate updates and record duplicate callback logs; when the state corresponding to the idempotent key has not been completed and the external receipt is valid, write it to the business table, status table, log table, and attachment table to form the node execution result.

[0042] Step S8: Correct the consistency of the execution status based on the node execution result and status update record written in step S7, and re-verify the data version, node status and idempotency flag when the subsequent node calls the node execution result; if the verification passes, unfreeze the corresponding subsequent node and trigger the subsequent node to enter the executable judgment; if the verification fails, mark the old result as expired and return to step S3 or step S5 for reprocessing, and generate a traceable archive record after completion.

[0043] Figure 3 This is a schematic diagram of the anomaly control of the present invention, mainly corresponding to steps S4 to S8, which show that data anomalies, authorization anomalies, external system anomalies, manual confirmation anomalies, resource conflict anomalies, and duplicate callback anomalies respectively enter the freezing, retry, pending, waiting lock, idempotent rejection, or external status verification process.

[0044] The business data and target payment period generated in step S1 serve as inputs for standardization and data version generation in step S2; the data version output in step S2 serves as the basis for generating processing nodes and node snapshots in step S3; the nodes, dependencies, and exception codes output in step S3 serve as inputs for rule judgment in step S4; the rule results and risk levels output in step S4 serve as the basis for selecting automatic processing, manual confirmation, exception suspension, or archiving in step S5; the processing results, manual confirmation records, and external receipts output in step S5 serve as the basis for verifying data version, node status, and idempotency flags when subsequent nodes are called in step S6.

[0045] During the data standardization process in step S2 and the node generation process in step S3, if source data is missing or field formats are inconsistent, the system does not directly terminate the entire process. Instead, it sets the data to a pending state and blocks subsequent nodes that depend on it. This approach prevents erroneous data from entering subsequent accounting or reporting processes.

[0046] When determining the processing direction in step S5: If a manual confirmation timeout occurs, the system does not directly terminate the entire process. Instead, it executes an automatic confirmation, alerts the consultant / accountant, or suspends the process based on the company's configuration. This approach balances automation efficiency with the limitations of manual review.

[0047] When calling the result of the preceding node in step S6: if a subsequent node discovers a data version change, the system does not directly terminate the entire process, but instead re-executes the verification of this node and generates a new version result. This approach ensures that the data used in the process is consistent throughout.

[0048] Duplicate callbacks mainly occur during the result feedback stage of step S7. The system determines whether the callback has been processed based on the callback serial number, external serial number, node identifier, and idempotent key. If it has been processed, the original node state remains unchanged, and only the audit log is written. This log is then used as the basis for verification during the state consistency correction in step S8.

[0049] To further improve authorization stability and business continuity, the system can be configured with scheduled inspection tasks to monitor authorization online status, robot liveness status, task queue length, failure rate, callback latency, and external system response time. Inspection results can be used as input parameters for scheduling weights, process branches, or manual reminders.

[0050] To avoid maintenance difficulties caused by hard-coding business rules, the system can configure rules as database tables or rule scripts. Rule items should at least include the applicable enterprise scope, applicable payment period, trigger conditions, comparison fields, thresholds, processing actions, prompts, and whether to block the process. When policies or enterprise practices change, maintenance personnel only need to adjust the rule configuration, without rewriting the entire program.

[0051] In a specific application example, the accounting agency migrates multiple companies into the system before the tax filing period begins. The system automatically generates a processing plan for the current period based on the company profile, accounting status, and business configuration. During execution, the system decides whether to execute automatically or require manual confirmation based on the real-time status. After execution, the system saves receipts, screenshots, structured results, and logs, thus forming a traceable and complete processing loop.

[0052] The server used in this invention can adopt a microservice architecture, with each module communicating with each other through HTTP interfaces, RPC interfaces, or message queues; it can also adopt a monolithic application architecture. As long as it can implement the data structure, state control, process judgment, and exception handling described in this application, it belongs to the equivalent implementation of this invention.

[0053] The robot execution terminal used in this invention can run on a server environment or on the local computer of the accounting agency. When deployed on a local computer, the task issued by the server can include task type, enterprise identifier, payment period, login method, execution parameters and callback address. After the local robot executes the task, it returns the result through the callback address.

[0054] Each module of this invention can be implemented by a software program or by a combination of software and hardware devices. A storage medium storing a computer program that implements the method of this invention, which can complete the corresponding steps when the processor executes the program, is also within the scope of protection of this invention.

[0055] In terms of database table design, the system can set up a main enterprise table, an accounting period table, a configuration table, a node table, a result table, a log table, and an attachment table. The main enterprise table stores the enterprise name, taxpayer identification number, tax bureau affiliation, taxpayer qualification, activated accounting period, and service status. The accounting period table stores the enterprise's opening, closing, filing, and archiving status for each accounting period. The configuration table stores thresholds, switches, rules, and human roles related to recovery from failed financial and tax automation tasks. The node table stores the inputs, outputs, status, version, and dependencies of each processing node. The result table stores structured processing results. The log table stores the execution process. The attachment table stores screenshots, receipts, reports, voucher attachments, or other file addresses.

[0056] In terms of interface design, the system can provide task creation, status query, manual confirmation, anomaly repair, result callback, and report export interfaces. The task creation interface receives the enterprise, payment period, and business type; the status query interface returns the node status, failure reason, and next action; the manual confirmation interface receives the confirmer, confirmation opinion, and confirmed data version; the anomaly repair interface receives the repaired fields or configurations; the result callback interface receives the receipt, screenshot, external serial number, and error code returned by the execution end; and the report export interface is used to export archiveable files.

[0057] In terms of rule configuration, each rule should ideally include a rule code, rule name, applicable enterprise scope, applicable billing period scope, applicable business type, input fields, conditional expression, threshold, exception level, processing action, and prompt text. The rule code is used for log tracking, the conditional expression is used for automatic computer execution, the exception level is used to determine whether to block the process, and the processing action is used to indicate whether to proceed to automatic workflow, manual confirmation, exception suspension, or result archiving.

[0058] In terms of state machine design, node states should include at least the following: not started, pending execution, executing, waiting for resources, awaiting manual confirmation, suspended due to an exception, skipped, completed, archived, and invalidated. State transitions must meet preset conditions; no node may directly enter the completed state if it lacks prerequisite data, lacks authorization, has inconsistent data versions, or has resource lock conflicts. Every change in the state machine is written to the log to reconstruct the complete processing chain.

[0059] In terms of access control, the system can classify users into main accounts, administrators, accounting staff, consultant accountants, quality inspection accountants, robot accounts, and interface accounts. The main account can maintain global configurations, the administrator can assign companies and view progress, the accounting staff can handle basic accounting, the consultant accountants can confirm documents and taxes, the quality inspection accountants can confirm quality inspection results, the robot account can only execute tasks issued by the server, and the interface account can only call authorized interfaces.

[0060] In terms of audit trail, the system prioritizes recording the operator, operation time, operation source, pre-operation data, post-operation data, execution terminal identifier, and external receipts. For actions involving taxes, deductions, cancellations, corrections, voucher deletions, data overwriting, and manual confirmation, the system can also require secondary confirmation or record the reasons for confirmation to ensure that the responsible node can be located in case of subsequent disputes.

[0061] Regarding data version control, the system can generate version numbers for both source data and processing results. The source data version is calculated based on the update time of invoices, bank statements, payroll data, vouchers, reports, configurations, or attachments; the processing result version is calculated based on the rule code, input version, and processing time. When subsequent nodes detect a change in the input version, the system automatically marks the old result as expired and requires reprocessing or reconfirmation.

[0062] In terms of exception code design, the system can categorize exceptions into data exceptions, authorization exceptions, external system exceptions, rule exceptions, manual confirmation exceptions, resource conflict exceptions, and duplicate callback exceptions. Each type of exception corresponds to a different handling action: data exceptions enter the repair queue, authorization exceptions enter the authorization reminder queue, external system exceptions enter the delayed retry queue, rule exceptions enter the configuration verification queue, manual confirmation exceptions enter the pending reminder, resource conflict exceptions enter the waiting lock, and duplicate callback exceptions enter the audit log.

[0063] In a specific application example, the system is applied to an accounting agency with hundreds of clients. After the administrator selects the target payment period and starts batch accounting and tax filing, the system executes step S1 to read the enterprise configuration, payment period status, tax type configuration, authorization status, manual confirmation status, execution log, and external receipts; step S2 generates tax list collection, invoice collection, bank collection, AI accounting processing, voucher generation, closing, tax confirmation, declaration, payment, and inspection nodes; if the bank collection node fails, the system executes step S3 to generate a snapshot of the failed node and a bank data version, and then executes step S4 to freeze the AI ​​accounting processing, voucher generation, closing, and declaration nodes that depend on bank transactions, while retaining the completed invoice collection node with valid external receipts; after the consultant accountant restores the authorization, the system executes step S5 to generate an automatic continuation strategy, executes step S6 to only issue the bank collection node, executes step S7 to receive the collection results and write the new version, and executes step S8 to unfreeze subsequent nodes and continue the subsequent process.

[0064] In a specific application example, the system is applied to cross-regional accounting agencies. In cross-regional accounting agencies, the system writes the tax bureau region, login method, and tax-handling mobile phone number into the node technical unit in step S2, and generates regional resource locks and login resource locks in step S3. When the tax bureau in a certain region times out, step S4 only sets the relevant nodes in that region to pending verification or regional suspension, step S5 determines the recovery strategy as delayed retry, step S6 continues to schedule the invoice collection, declaration, or payment nodes of enterprises in other regions, and step S8 re-triggers the executable judgment after the region recovers based on the monitoring results.

[0065] In a specific application example, the system is integrated with WeChat Work, SMS assistant, or customer confirmation page. When the tax confirmation node requires confirmation from the consultant accountant, the system binds the current tax data version to the confirmation page in step S3. If the confirmer confirms on the old version page, but subsequent step S8 finds that the report or tax version has changed, the system refuses to use the old confirmation record, resets the tax confirmation node to pending confirmation, and freezes the declaration and payment nodes. After the confirmer reconfirms based on the new version, step S6 schedules the declaration or deduction node.

[0066] In a specific application example, the system integrates with object storage to save attachments. After the execution end completes the declaration or deduction, it returns a screenshot from the tax bureau, an external receipt number, a callback serial number, and an error code to step S7. The system generates an idempotent key using the enterprise identifier, payment period, tax type, node type, data version, external receipt number, and callback serial number. If the same callback serial number arrives repeatedly, step S7 rejects the duplicate writing of the business result, only records the duplicate callback log, and step S8 keeps the final state of the node unchanged and writes the screenshot, receipt, report, and log to the archive record.

[0067] This invention can also be configured with a simulation execution mode. In simulation execution mode, the system does not submit irreversible actions to external tax authorities, banks, or deduction interfaces. Instead, it calculates the expected state, expected tax amount, expected anomalies, and expected processing time based on existing data and rules. The simulation results can be used by administrators to identify configuration problems before formal execution, reducing concentrated failures during the tax filing period.

[0068] This invention can also set up a gray-scale activation mechanism. For new rules, new regions, or new enterprise types, the system first enables automatic processing for a small number of enterprises, recording the success rate, failure rate, number of manual confirmations, and average processing time; the activation scope is then expanded once the indicators meet preset conditions. This mechanism can reduce the system risks associated with a one-time full rollout of new features.

[0069] This invention can also include a manual correction feedback mechanism. When a human modifies the system's automatic results, the system doesn't just overwrite the original result; instead, it records the modified fields, the original value, the new value, the reason for the modification, and the person who made the modification. This feedback can be used to subsequently optimize rule thresholds, configure default values, or model parameters, allowing the system to gradually align with the actual processing habits of accounting firms.

[0070] This invention can also include a statistical analysis module to calculate processing time, failure rate, manual intervention rate, automatic completion rate, and number of repeated callbacks by enterprise, department, personnel, payment period, node, and anomaly type. The statistical results can be used for management evaluation, as well as for optimizing queue scheduling, rule configuration, and robot resource allocation.

[0071] In terms of deployment, this invention can be deployed in a public cloud environment, a private server of an accounting agency, or a hybrid cloud environment. For data involving sensitive tax login information, bank information, and customer data, encrypted storage, anonymized display, and access auditing can be adopted; the robot execution end and the server can communicate using HTTPS, signature tokens, or dedicated lines.

[0072] Without altering the technical concept of this invention, the rule engine in the system can be replaced with a decision table, script engine, or machine learning model; the task queue can be replaced with RabbitMQ, Kafka, Redis queues, or database queues; the database can be replaced with MySQL, PostgreSQL, domestic databases, or other relational databases; and the object storage can be replaced with a local file system or cloud storage.

[0073] In terms of interface display, the system can provide multiple views according to enterprise, payment period, node, and anomaly dimensions. The enterprise dimension is used to view all nodes in the recovery of failed financial and tax automation tasks for a single enterprise; the payment period dimension is used to view the processing progress of all enterprises under the same payment period; the node dimension is used to view the queue, success, failure, and pending confirmation quantity of a certain node; and the anomaly dimension is used to summarize issues by anomaly code, region, responsible role, or handling suggestions. Through this interface design, managers do not need to go into each enterprise's ledger to view each item to grasp the overall operation status.

[0074] Regarding report output, the system can automatically generate technical or business reports based on the processing results. Report content includes basic company information, payment terms, processing nodes, input data sources, rule matching status, manual confirmation records, exception handling records, external receipts, attachment paths, and final status. For nodes requiring log entries, the report can also include screenshots, receipt images, report files, or operation log summaries. This report can serve as a basis for internal quality control, as well as for customer communication, subsequent audits, and the division of responsibilities among agencies.

[0075] In terms of parameter configuration, the system can set different default parameters for different accounting agencies, such as automatic confirmation amount threshold, waiting timeout period, number of retries, minimum quality inspection score, field confidence threshold, task aging time, anomaly alert frequency, and archive retention period. Enterprise-level configuration takes precedence over agency-level configuration, and temporary payment period configuration takes precedence over regular enterprise configuration. Through multi-level configuration priorities, the system can manage most enterprises in batches while also retaining special processing methods for individual enterprises.

[0076] In terms of verifying the technical effectiveness, the average processing time, number of manual interventions, number of repeated executions, anomaly recovery time, data error rate, and archive integrity rate can be statistically analyzed before and after implementing this invention. Because this invention unifies the modeling of business objects, data versions, processing nodes, and external receipts, the system can reduce duplicate data entry, duplicate data distribution, and manual investigation caused by unclear status, and can quickly locate affected nodes when anomalies occur.

[0077] The above embodiments are not intended to limit the present invention, and the present invention is not limited to the examples given above. Any changes, modifications, additions or substitutions made by those skilled in the art within the scope of the technical solution of the present invention are also within the protection scope of the present invention.

Claims

1. A method for resuming failed tasks and restoring state consistency in automated financial and tax tasks, characterized by: Includes the following steps: Step S1: Receive failure recovery instructions for the enterprise's target payment period and read data to form the context of the task to be recovered; Step S2: Based on the task context to be restored formed in step S1, the task context to be restored is decomposed or restored into multiple node technical units according to the financial and tax automation process. Step S3: Based on the node technical units and their input data obtained in step S2, standardize and version the output and subsequent dependency information of failed nodes, predecessor nodes, and successors to generate node snapshots. Step S4: Based on the node snapshots, data versions, exception types, subsequent dependencies, and external receipts obtained in Step S3, identify the scope of impact of the execution failure and control subsequent nodes. Step S5: Based on the anomaly type and node risk level obtained in Step S3, and combined with the enterprise configuration and manual confirmation status in Step S1, generate a recovery strategy and a set of nodes to be run. Step S6: Perform pre-resumption verification and scheduling on the set of nodes to be resumed output in step S5, and verify them. Step S7: Receive execution result and update idempotent state; Step S8: Correct the consistency of the execution status based on the node execution result and status update record written in step S7, and re-verify the data version, node status and idempotency flag when the subsequent node calls the node execution result.

2. The method for resuming failed nodes and restoring state consistency in automated financial and tax tasks according to claim 1, characterized in that: The method specifically includes the following steps: Step S1: Read the task instance, failed node identifier, enterprise configuration, tax type configuration, payment period status, manual confirmation status, external receipt, execution log, and attachment records to form the context of the task to be recovered; the enterprise configuration is used to determine whether the node is allowed to automatically resume, whether manual confirmation is required, and the available execution resources; Step S2: Write the enterprise identifier, payment period, business type, node type, input data, execution conditions, output results, exception code, callback identifier, data version, node risk level, resource lock identifier, and subsequent dependencies into each node technical unit; Step S3: The node snapshot should include at least the following: data summary before processing, data summary after processing, source data version, processing result version, manually confirmed version, external receipt number, screenshot or file address, exception type and exception reason; Step S4: Set the successor nodes that depend on the output results of failed nodes, expired data versions, or conflicting external receipts to the successor frozen or pending verification state, and retain the completed nodes whose input version, output version, and external receipt are consistent. Step S5, recovery strategies include automatic continuation, delayed retry, manual confirmation, abnormal suspension, external status verification, skipping or archiving; Step S6: Verify enterprise authorization, billing status, configuration status, resource lock, manual confirmation, data version, and idempotency identifier; after successful verification, acquire the resource lock, send the task parameters to the corresponding execution end, and update the node status from pending execution to execution. Step S7: Receive the execution result returned by the execution end, generate or verify the idempotent key based on the enterprise identifier, billing period, business type, node type, data version, external serial number and callback serial number; when the state corresponding to the idempotent key has been completed, reject duplicate updates and record duplicate callback logs; when the state corresponding to the idempotent key has not been completed and the external receipt is valid, write it into the business table, status table, log table and attachment table to form the node execution result; Step S8: If the verification passes, the corresponding successor node is unfrozen and the successor node is triggered to enter the executable judgment; if the verification fails, the old result is marked as expired and returned to step S3 or step S5 for reprocessing; after completion, a traceable archive record is generated.

3. The method for resuming failed nodes and restoring state consistency in automated financial and tax tasks according to claim 2, characterized in that: In step S2, the automated financial and tax process includes at least one of the following: initialization, tax register collection, checklist authentication, invoice collection, bank collection, individual income tax data copying, cumulative or special deduction collection, document confirmation, AI accounting processing, voucher generation, settlement, manual verification, tax payment confirmation, declaration, payment, tax payment certificate collection, omission detection, social security collection, social security declaration confirmation, social security declaration, social security deduction confirmation, social security deduction, social security inspection, and file collection.

4. The method for resuming failed nodes and restoring state consistency in automated financial and tax tasks according to claim 2, characterized in that: In step S3, the source data version is calculated from the update time, summary value, or external serial number of invoices, bank statements, payrolls, vouchers, reports, configuration items, tax bureau lists, social security details, manual confirmation records, and attachments; the processing result version is calculated from the rule code, input version, execution terminal identifier, and processing time.

5. The method for resuming failed nodes and restoring state consistency in automated financial and tax tasks according to claim 2, characterized in that: The subsequent freezing in step S4 includes: freezing the successor nodes that directly depend on the output results of the failed node based on the node snapshot, data version and successor dependency relationship generated in step S3; marking nodes that indirectly depend on the failed node and have entered the pre-execution waiting state as pending verification; and performing external status verification on nodes that have been successfully submitted to external tax authorities, banks or deduction systems and have valid external receipts without resubmitting.

6. The method for resuming failed nodes and restoring state consistency in automated financial and tax tasks according to claim 2, characterized in that: In step S5, the recovery strategy is determined based on the exception code; When data is missing or the field format is inconsistent, it enters the data repair queue and freezes the nodes that depend on the data; when enterprise authorization expires, it enters the authorization reminder queue; when external system times out or robot goes offline, it enters the delayed retry queue; when manual confirmation times out, it performs automatic confirmation, pending reminder or abnormal suspension according to the enterprise configuration; when the data version changes, it re-executes the corresponding node verification and generates the new version result.

7. The method for resuming failed nodes and restoring state consistency in automated financial and tax tasks according to claim 2, characterized in that: In step S5, the idempotency identifier is generated by combining at least two of the following: enterprise identifier, payment period, tax type or business type, node type, source data version, processing result version, and external serial number. For actions such as declaration, deduction, cancellation, correction, voucher deletion, and data overwrite, the risk level and confirmer identifier are also written into the idempotency verification information.

8. The method for resuming failed nodes and restoring state consistency in automated financial and tax tasks according to claim 2, characterized in that: The state consistency correction in step S8 includes: comparing the node execution result, execution log, external receipt, node snapshot, and manual confirmation record formed in step S7; when the task status is failed but the external receipt shows success, the node is transferred to external status verification and a success receipt is added; when the task status is successful but the input data version has changed, the node result is marked as expired and the successor node is frozen; when duplicate callbacks occur, the original state is kept unchanged and written to the audit log.

9. A system for resuming failed tasks and restoring state consistency in financial and tax automation tasks, used to implement the method described in any one of claims 1-8, characterized in that: include: Node snapshot module: Used to receive and standardize business input data; Failure identification module: used to identify processing conditions and generate processing nodes; Subsequent freeze module: used to execute core business rules and perform data verification; Pre-verification module: used to verify enterprise payment period, authorized online status, configuration status, tax type activation status, manual confirmation status, resource lock status, data version, and idempotency identifier; The continuation scheduling module is used to write nodes that have passed the pre-verification into a queue and distribute them to the adaptation execution end. Idempotent callback module: Used to receive the execution result. The input includes callback serial number, external receipt, screenshot address, error code and execution identifier. Status correction module: used to save processing results for subsequent processes to call; Archive monitoring module: Used to save recovery reports and attachments, and to periodically monitor authorized online status, robot survival status, queue length, failure rate, callback latency and external system response time; The monitoring results serve as input parameters for continued operation scheduling, delayed retry, anomaly alerts, or canary deployment.

Images