A method for asynchronous accounting of a financial system subsidiary account

Abstract

The application provides a financial system detailed account asynchronous accounting method, relates to the technical field of financial accounting, and comprises the following steps: storing voucher data to a voucher data storage layer and marking a processing state as to be processed; searching whether there is a to-be-processed task associated with the subject of the voucher data; updating a task processing start position marker in the to-be-processed task according to the accounting date of the current voucher and the voucher serial number; calculating a dynamic aggregation waiting time length according to the business activity quantitative index of the subject, and determining a trigger time stamp by using the dynamic aggregation waiting time length; sequentially generating detailed account entries when the trigger time stamp expires; and updating the business activity quantitative index of the subject according to the current accounting result after the task state is set as completed, so as to obtain a complete detailed account corresponding to the voucher data. The application realizes reliable asynchronous decoupling of financial voucher input and detailed account generation, and reduces the complexity of historical voucher supplementary recording operation.

Description

Technical Field

[0001] This invention relates to the field of financial accounting technology, and in particular to a method for asynchronous accounting of detailed ledgers in a financial system. Background Technology

[0002] In the field of accounting software, one of the core functions is recording financial vouchers and automatically generating detailed account ledgers, enabling businesses to monitor cash flow and account balances in real time. Currently, the most prevalent accounting method is synchronous accounting. Its workflow is as follows: accounting staff enter financial vouchers sequentially according to the time of business transactions. Each time a voucher is saved, the system immediately triggers calculation logic, calculating the new ending balance for that account based on the voucher's content and adding it to the detailed account ledger. Furthermore, the beginning and ending data of adjacent detailed account entries are strictly contiguous. This method is logically intuitive, provides real-time visibility of accounts, and operates stably in single-user sequential operation scenarios.

[0003] However, since the synchronous accounting method is based on the premise of "orderly entry of vouchers and orderly generation of ledgers", this strong constraint leads to two inherent defects: First, it does not support the supplementary entry of vouchers for historical periods. Once the financial staff finds that there are early omissions in the entered vouchers, they can only set up special accounts to adjust the accounts, or delete all vouchers after the supplementary entry date and then re-enter them one by one. The operation is extremely cumbersome and has low fault tolerance. Second, the concurrent processing capability is limited. When multiple users enter vouchers at the same time or the system imports them in batches, in order to ensure the continuity of the beginning and end data, the system can only process each voucher serially, which forms a performance bottleneck. Moreover, when the concurrency control is not strict, dirty read problems may occur, which may lead to the risk of data inconsistency between the detailed ledger and the actual account balance.

[0004] Chinese invention patent application number 201910760169.X discloses an intelligent matching method and system for financial accounting data. It extracts original invoices and accounting subject information from a financial system database, constructs a deep neural network model including word feature extraction, invoice feature extraction, subject feature extraction, and an attention network, performs feature matching calculations on the original documents and candidate accounting subjects, and recommends the optimal subject option to financial personnel in a probability-ranked manner, thereby reducing the error rate and operational cost of manual subject matching. However, its overall processing framework is a single-inference execution, lacking task state management and execution progress tracking. Summary of the Invention

[0005] In view of this, the present invention provides a method for asynchronous accounting of financial system ledgers to solve the technical problems of lack of tracking of task execution progress and inability to automatically recover after abnormal task interruption in existing asynchronous accounting processing technology. Under the premise of ensuring the consistency of ledger data, reliable asynchronous decoupling of financial voucher entry and ledger generation is achieved.

[0006] The technical solution of this invention is implemented as follows: On the one hand, the present invention provides a method for asynchronous accounting of detailed ledgers in a financial system, comprising: S1. Store the voucher data in the voucher data storage layer and mark the processing status as pending. Search for whether there is a pending task associated with the voucher data subject based on the subject dimension. If not, create and register a new pending task based on the current voucher information. If it exists, aggregate the current voucher information into the existing pending task. S2. Update the task processing start position marker in the pending task based on the current voucher's posting date and voucher number to obtain the updated task processing start position marker; read the detailed ledger generation progress marker corresponding to the account in the account posting progress table, and identify whether it belongs to a historical period voucher entry scenario based on the positional relationship between the current voucher and the detailed ledger generation progress marker: If it is, then write the task to the starting point marker as the task processing start position marker and reset the trigger timestamp; If it does not belong to the category, the task is written to the starting point as a progress marker for the detailed ledger; the updated pending tasks are obtained. S3. Calculate the dynamic aggregation waiting time based on the business activity metric of the subject, and determine the trigger timestamp based on the dynamic aggregation waiting time; during the task waiting period, if the cancellation flag of the pending task is detected to be set, perform accelerated convergence processing on the trigger timestamp to obtain the adjusted trigger timestamp. S4. When the trigger timestamp expires, starting from the position indicated by the task writing start mark, extract all pending vouchers for the account in ascending order of posting date and voucher number, and generate detailed ledger entries in sequence; use atomic operations to write the detailed ledger entries into the account detailed ledger table, update the processing status of all vouchers processed in this operation to processed, and simultaneously advance the detailed ledger generation progress mark; if the atomic operation is executed successfully, the task status is set to completed; if the atomic operation fails, the task status is rolled back to pending and the trigger timestamp is recalculated according to the adaptive retry scheduling strategy. S5. Once the task status is set to "completed", update the business activity metrics of the account based on the accounting results to obtain a complete ledger corresponding to the voucher data.

[0007] Based on the above technical solutions, preferably, the task includes a unique task identifier. Subject Code , Starting point date component Component of starting positioning point number Task write start point marker wp, cancellation flag Task status Retry counter Reason for the most recent failure Task creation time Task last update time ,in, The initial value is the posting date of the current voucher. , The initial value is the voucher number of the current voucher. , and Together they form the starting positioning point ; Task status includes pending, in progress, completed, and failed; Cancellation mark This is a boolean field, initially set to false. Retry Counter The initial value is 0.

[0008] Based on the above technical solutions, preferably, the offset mark... The specific processing steps include: Read the voucher type field of the current voucher ,in This indicates a normal voucher. Indicates a cancellation document; In the scenario of creating and registering a new task, if Then Set to true, otherwise retain the initial value false; In scenarios where current credential information is aggregated into existing tasks, if Then, in the existing tasks Update to true, if and If it is already true, then it remains unchanged.

[0009] Based on the above technical solutions, preferably, step S2 specifically includes: Let the posting date of the current voucher be... The voucher number is Read the current voucher account and its current subsidiary ledger from the account posting progress table to generate a progress marker. ,in The date of the last voucher used to generate the subsidiary ledger entry. The voucher number for the last time a detailed ledger entry was generated; position tuple The starting position marker of existing task processing in the pending tasks If a comparison is made, ,or and Then Overwrite Get the updated task processing start position marker. ; Set the current voucher posting date Date component of the progress marker for the detailed ledger generation Comparison: like ,or and If the scenario is identified as a historical voucher entry scenario, the task start point marker will be set to the updated task processing start position marker. and reset the trigger timestamp; Otherwise, in a normal supplementary scenario, the task is written to the starting point marker and set as the progress marker for generating the detailed ledger. Once the task is determined, it is written to the starting point marker.

[0010] Based on the above technical solutions, the preferred method for calculating the dynamic aggregation waiting time is as follows: Statistics In the most recent statistical period Number of vouchers entered ,by As a metric for business activity, calculate dynamic aggregation wait time. : in, Based on aggregation delay, This is the activity adjustment coefficient. This is the minimum lower bound for the dynamic aggregation waiting time; At the current moment The trigger timestamp is dynamically determined based on the activity level of the subject, calculated as a baseline. : in This represents the current dynamic aggregation wait time for this subject.

[0011] Based on the above technical solutions, preferably, the reset trigger timestamp specifically includes: When the scenario is identified as a historical period voucher entry, the current time is used. Based on this, combined with the currently determined dynamic aggregation waiting time for the subject. The trigger timestamp is reset to obtain the reset trigger timestamp. .

[0012] Based on the above technical solutions, preferably, the accelerated convergence processing of the trigger timestamp specifically includes: While the task is waiting for its trigger timestamp to expire, continuously monitor the cancellation flag in the pending tasks. ; If detected If true, then calculate the current time. Remaining time until the trigger timestamp and with compression coefficient The remaining time is compressed proportionally, and the trigger timestamp is updated to the accelerated convergence trigger timestamp: in, This indicates the timestamp that triggers accelerated convergence.

[0013] Based on the above technical solutions, preferably, step S4 specifically includes: S41. When the trigger timestamp expires, the task status will be changed. Updated from pending to processing; S42. Using the position indicated by the task writing start point marker as the starting boundary, read all pending vouchers in ascending order of posting date and voucher number, generate corresponding subsidiary ledger entries for each voucher, and obtain the set of subsidiary ledger entries processed in this operation. S43. Write the set of subsidiary ledger entries into the account subsidiary ledger table using atomic operations, update the processing status of all vouchers in this process to processed synchronously, and advance the subsidiary ledger generation progress mark to the position of the last voucher in this process. S44. If the atomic operation is executed successfully, then the task status will be changed. Set to completed; if the atomic operation fails, change the task status to completed. The process is rolled back to pending processing, and the trigger timestamp is recalculated according to the adaptive retry scheduling strategy before returning to S41 for re-execution, resulting in the incremental write result of the detailed ledger entry.

[0014] Based on the above technical solutions, preferably, the adaptive retry scheduling strategy adopts an exponential backoff mechanism based on the number of retries, specifically including: When an atomic operation fails, the reason for the failure is recorded in the most recent failure reason field. and the retry counter Add one; Retry counter Does it meet the requirements? ,in The maximum number of retries is preset as follows: like If successful, the task status will be... Set as failed and terminate retry; like Then based on the current number of retries The retry interval is dynamically extended exponentially, and the backoff trigger timestamp is calculated. : in, For the current moment, For the base interval of retry, This is the maximum retry interval limit. This is the current retry counter value.

[0015] Furthermore, the adaptive retry scheduling strategy further includes an automatic recovery mechanism for suspended tasks: The task storage layer is scanned periodically according to a preset inspection cycle to check the task status. Tasks that are being processed and whose duration exceeds a preset timeout threshold are identified as suspended tasks. The suspended task The process is rolled back to pending status, and the backoff trigger timestamp is recalculated according to the exponential backoff mechanism. This ensures that suspended tasks can automatically re-enter the execution process after the system recovers, thereby guaranteeing the final completion of the detailed account generation task in the event of system anomalies.

[0016] The present invention has the following advantages over the prior art: (1) By maintaining the task processing start position mark during the voucher entry stage and comparing it with the detailed account generation progress mark during the trigger execution stage, the voucher entry scenario and normal addition scenario during the historical period are clearly distinguished, reducing the complexity of historical voucher supplementation operation; (2) By dynamically calculating the aggregated waiting time based on the quantitative indicators of subject business activity, the triggering time interval can be adaptively adjusted according to the change of subject voucher entry frequency. The waiting window is appropriately narrowed during the business peak period and appropriately extended during the business slow period, so that the system can run at a reasonable processing frequency under different business loads, effectively balancing data timeliness and system resource consumption. (3) By continuously detecting the reversal flag and introducing an accelerated convergence processing mechanism, tasks containing reversal vouchers are subjected to proportional compression, which advances their trigger time and shortens the duration of the abnormal state of the books caused by the reversal voucher, thus realizing differentiated processing priority for specific types of vouchers. (4) By incorporating the writing of detailed ledger entries, updating of voucher processing status, and advancing of detailed ledger generation progress markers into the same atomic operation, the risk of omissions or duplicate calculations caused by system interruptions during asynchronous processing is eliminated, ensuring semantic consistency between progress markers and data status, and providing a reliable foundation for idempotent execution during task retries. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a method for asynchronous accounting of detailed ledgers in a financial system according to the present invention. Figure 2 This is a task status diagram of an asynchronous accounting method for a financial system ledger according to the present invention; Figure 3 The logic diagram for determining the starting point of the writing in the asynchronous accounting method for financial system ledgers of the present invention; Figure 4 This is a schematic diagram of atomic operations for an asynchronous accounting method for a financial system ledger according to the present invention. Detailed Implementation

[0019] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0020] like Figure 1 and Figure 2 As shown, the present invention provides a method for asynchronous accounting of detailed ledgers in a financial system, comprising: S1. Store the voucher data in the voucher data storage layer and mark its processing status as pending. Search for pending tasks associated with the voucher data subject based on the subject dimension. If none exist, create and register a new pending task based on the current voucher information. If a task exists, aggregate the current voucher information into the existing pending tasks. Each task includes a unique task identifier. Subject Code , Starting point date component Component of starting positioning point number Task write start point marker wp, cancellation flag Task status Retry counter Reason for the most recent failure Task creation time Task last update time ,in, The initial value is the posting date of the current voucher. , The initial value is the voucher number of the current voucher. , and Together they form the starting positioning point ; Task status includes pending, in progress, completed, and failed; Cancellation mark This is a boolean field, initially set to false. Retry Counter The initial value is 0.

[0021] Understandably, the task write start point marker wp consists of a date component and a sequence number component, with an initial value and a starting location point. The same applies. The purpose of searching by the subject to which the voucher data belongs is to ensure that, within the same dynamic aggregation waiting time, if there is already a task waiting to be executed for the same subject, it is not necessary to recreate it. Instead, the information of the current voucher is merged into the existing task, thereby merging multiple detailed ledger calculation requests generated by the same subject within this window into one execution, avoiding duplicate triggering.

[0022] Specifically, the cancellation mark The specific processing steps include: Read the voucher type field of the current voucher ,in This indicates a normal voucher. Indicates a cancellation document; In the scenario of creating and registering a new task, if Then Set to true, otherwise retain the initial value false; In scenarios where current credential information is aggregated into existing tasks, if Then, in the existing tasks Update to true, if and If it is already true, then it remains unchanged.

[0023] S2. Update the task processing start position marker in the pending task based on the current voucher's posting date and voucher number to obtain the updated task processing start position marker; read the detailed ledger generation progress marker corresponding to the account in the account posting progress table, and identify whether it belongs to a historical period voucher entry scenario based on the positional relationship between the current voucher and the detailed ledger generation progress marker: If it belongs to the historical period voucher entry scenario, the task is written to the starting point mark as the task processing start position mark and the trigger timestamp is reset; If it does not belong to the historical period voucher entry scenario, the task is written to the starting point as the detailed ledger generation progress marker; the updated pending task is obtained.

[0024] This invention maintains a task processing start position marker during the voucher entry stage and compares it with the detailed ledger generation progress marker during the trigger execution stage. This clearly distinguishes between historical voucher entry scenarios and normal append scenarios, thereby determining the writing start point when the current task is triggered. For historical supplementary entry scenarios, the system can regenerate all detailed ledgers from the earliest affected voucher position, eliminating the need for operators to manually delete subsequent vouchers and re-enter them one by one, thus reducing the complexity of historical voucher supplementary entry operations.

[0025] like Figure 3 As shown, specifically, step S2 includes: Let the posting date of the current voucher be... The voucher number is Read the current voucher account and its current subsidiary ledger from the account posting progress table to generate a progress marker. ,in The date of the last voucher used to generate the subsidiary ledger entry. The voucher number for the last time a detailed ledger entry was generated; position tuple The starting position marker of existing task processing in the pending tasks If a comparison is made, ,or and Then Overwrite Get the updated task processing start position marker. ; Set the current voucher posting date Date component of the progress marker for the detailed ledger generation Comparison: like ,or and If the scenario is identified as a historical voucher entry scenario, the task start point marker will be set to the updated task processing start position marker. and reset the trigger timestamp; Otherwise, in a normal supplementary scenario, the task is written to the starting point marker and set as the progress marker for generating the detailed ledger. Once the task is determined, it is written to the starting point marker.

[0026] By identifying and responding to historical supplementary entry scenarios through task processing start position markers and detailed ledger generation progress markers, the recalculation boundary of detailed ledgers affected by historical supplementary entry vouchers can be correctly determined without additional manual intervention. At the same time, by resetting the trigger timestamp, the aggregation process of supplementary entry vouchers is incorporated into the same delayed processing framework as normal vouchers, avoiding unexpected multiple immediate triggers to the system.

[0027] S3. Calculate the dynamic aggregation waiting time based on the business activity metric of the subject, and determine the trigger timestamp based on the dynamic aggregation waiting time; during the task waiting period, if the cancellation flag of the pending task is detected to be set, perform accelerated convergence processing on the trigger timestamp to obtain the adjusted trigger timestamp. Specifically, the calculation method for dynamic aggregation waiting time is as follows: Statistics In the most recent statistical period Number of vouchers entered ,by As a metric for business activity, calculate dynamic aggregation wait time. : in, Based on aggregation delay, This is the activity adjustment coefficient. This is the minimum lower bound for the dynamic aggregation waiting time; At the current moment The trigger timestamp is dynamically determined based on the activity level of the subject, calculated as a baseline. : in This represents the current dynamic aggregation wait time for this subject.

[0028] This invention dynamically calculates the aggregated waiting time based on the quantifiable indicators of subject business activity, enabling the triggering time interval to adaptively adjust with the frequency of subject voucher entry. During periods of concentrated business, the waiting window is appropriately narrowed, while during periods of low business activity, it is appropriately extended. This allows the system to operate at a reasonable processing frequency under different business loads, effectively balancing data timeliness and system resource consumption.

[0029] Furthermore, resetting the trigger timestamp specifically includes: When the scenario is identified as a historical period voucher entry, the current time is used. Based on this, combined with the currently determined dynamic aggregation waiting time for the subject. The trigger timestamp is reset to obtain the reset trigger timestamp. .

[0030] In one embodiment of the present invention, the accelerated convergence processing of the trigger timestamp specifically includes: While the task is waiting for its trigger timestamp to expire, continuously monitor the cancellation flag in the pending tasks. ; If detected If true, then calculate the current time. Remaining time until the trigger timestamp and with compression coefficient The remaining time is compressed proportionally, and the trigger timestamp is updated to the accelerated convergence trigger timestamp: in, Indicates the timestamp that triggers accelerated convergence. .

[0031] Understandably, the compressed waiting time is still greater than zero; it only triggers the process earlier and does not affect the basic process of voucher aggregation. If the task's... If the flag has been set, the compressed state will not be restored even if the newly merged vouchers are normal vouchers.

[0032] The dynamic aggregation waiting time mechanism enables the same scheduling logic to adaptively match the business rhythm of different subjects at different times, without the need to configure trigger parameters separately for each subject. The reversal acceleration convergence mechanism, without changing the overall task scheduling framework, applies differentiated processing to tasks containing reversal vouchers, shortening the exposure time of their abnormal book status.

[0033] This invention continuously detects reversal flags and introduces an accelerated convergence processing mechanism to apply proportional compression to tasks containing reversal vouchers, thus advancing their trigger time and shortening the duration of abnormal accounting conditions caused by reversal vouchers. Without changing the overall task scheduling framework, it achieves differentiated processing priorities for specific types of vouchers.

[0034] Preferably, the compression coefficient in the accelerated convergence processing is based on the proportion of the write-off amount, specifically including: Let the sum of the absolute values ​​of all merged voucher amounts in the current pending task be... Among them, the reversal voucher ( The sum of the absolute values ​​of the amounts of the vouchers marked as true is Define the percentage of write-off amount : in It is a very small positive number, used to prevent Division by zero exception .

[0035] by As input, the dynamic compression coefficient is calculated through piecewise power mapping. : in, The upper limit of the compression factor is satisfied. The compression coefficient corresponding to the offset ratio is close to zero (almost no compression, waiting time is close to the original value). This represents the lower limit of the compression factor, corresponding to a write-off ratio approaching [value missing]. The compression factor at that time (maximum compression, trigger time is significantly advanced); For curvature control parameters, Positive integers, control Follow The shape of the changing response curve: when It degenerates into linear interpolation when... When, function exist It grows faster when it is smaller. When the value is relatively large, it tends to level off, allowing the compression coefficient to respond quickly to the presence of offsetting factors in the low-proportion stage, while it tends to stabilize in the high-proportion stage, preventing excessive premature triggering caused by extreme values; when When the time (when used in reciprocal form) is used, the opposite response curve is presented, which can be selected based on the system's sensitivity preference to the timeliness of the cancellation.

[0036] That is, the compression intensity of reversal tasks with different risks of abnormal exposure on the books is differentiated. Small and sporadic reversal vouchers with small amounts are triggered earlier with a milder pace, while large-volume reversals (such as large-scale red-ink reversals at the end of the month) are triggered earlier with the greatest pace. Thus, under the premise of keeping the overall scheduling framework unchanged, priority processing resources will be tilted towards the tasks with the most severe abnormal exposure on the books, further shortening the exposure time of abnormal exposure on the books in major reversal scenarios.

[0037] Using dynamic compression coefficients The dynamically accelerated convergence trigger timestamp is calculated as follows: The waiting time after compression is still greater than zero (due to...) (Guarantee); once If set, the compressed state will not be restored; During each inspection, it was detected that When true, it is based on the latest version of the current batch. , Real-time recalculation dynamically reflects the impact of newly incorporated vouchers on the write-off ratio during the task waiting period.

[0038] S4. When the trigger timestamp expires, starting from the position indicated by the task writing start point marker, extract all pending vouchers for the account in ascending order of posting date and voucher number, and generate detailed ledger entries in sequence; use atomic operations to write the detailed ledger entries into the account detailed ledger table, update the processing status of all vouchers processed in this operation to processed, and simultaneously advance the detailed ledger generation progress marker; if the atomic operation is executed successfully, set the task status to completed; if the atomic operation fails, roll back the task status to pending and recalculate the trigger timestamp according to the adaptive retry scheduling strategy, and re-execute this step starting from the task writing start point marker. like Figure 4 As shown, specifically, step S4 includes: S41. When the trigger timestamp expires, the task status will be changed. Updated from pending to processing; S42. Using the position indicated by the task writing start point marker as the starting boundary, read all pending vouchers in ascending order of posting date and voucher number, generate corresponding subsidiary ledger entries for each voucher, and obtain the set of subsidiary ledger entries processed in this operation. S43. Write the set of subsidiary ledger entries into the account subsidiary ledger table using atomic operations, update the processing status of all vouchers in this process to processed synchronously, and advance the subsidiary ledger generation progress mark to the position of the last voucher in this process. S44. If the atomic operation is executed successfully, then the task status will be changed. Set to completed; if the atomic operation fails, change the task status to completed. The process is rolled back to pending processing, and the trigger timestamp is recalculated according to the adaptive retry scheduling strategy before returning to S41 for re-execution, resulting in the incremental write result of the detailed ledger entry.

[0039] This invention eliminates the risk of omissions or duplicate calculations caused by system interruptions during asynchronous processing by incorporating the writing of detailed ledger entries, updating the voucher processing status, and advancing the progress marker of detailed ledger generation into a single atomic operation. It also ensures the semantic consistency between the progress marker and the data status, providing a reliable foundation for idempotent execution during task retries.

[0040] In one embodiment of the present invention, the adaptive retry scheduling strategy employs an exponential backoff mechanism based on the number of retries, specifically including: When an atomic operation fails, the reason for the failure is recorded in the most recent failure reason field. and the retry counter Add one; Before each return to S41 execution, check the retry counter. Does it meet the requirements? ,in The maximum number of retries is preset as follows: like If successful, the task status will be... Set as failed and terminate retry; like Then based on the current number of retries The retry interval is dynamically extended exponentially, and the backoff trigger timestamp is calculated. : in, For the current moment, This is the base retry interval, representing the waiting time for the first retry. To set an upper bound on the backoff time as the maximum retry interval, an upper bound is set to prevent the waiting time from increasing indefinitely under continuous failure conditions. This is the current retry counter value. The backoff multiplier is based on the current number of retries. Decrease by one as the exponent, and it grows exponentially with the number of retries, causing the waiting time for each retrieval to increase exponentially.

[0041] In one embodiment of the present invention, the adaptive retry scheduling strategy further includes an automatic recovery mechanism for suspended tasks: The task storage layer is scanned periodically according to a preset inspection cycle to check the task status. Tasks that are being processed and whose duration exceeds a preset timeout threshold are identified as suspended tasks. The suspended task The process is rolled back to pending status, and the backoff trigger timestamp is recalculated according to the exponential backoff mechanism. This ensures that suspended tasks can automatically re-enter the execution process after the system recovers, thereby guaranteeing the final completion of the detailed account generation task in the event of system anomalies.

[0042] Understandably, suspended tasks are usually caused by anomalies such as service crashes or network interruptions. The task remains stuck in the processing state and cannot proceed automatically. The system will suspend the task. Rollback to pending processing, retry counter will be activated. Reset to 0, and recalculate the backoff trigger timestamp according to the above-mentioned exponential backoff mechanism. This allows the system to automatically re-enter the execution process after system recovery, preventing tasks from remaining in an intermediate state for an extended period and causing the relevant account details to fail to update, thus enhancing the reliability of the system's continuous operation in the production environment.

[0043] S5. Once the task status is set to "completed", update the business activity metrics of the account based on the accounting results to obtain a complete ledger corresponding to the voucher data.

[0044] In task status Once the setting is complete, update the business activity metrics for this account based on the current accounting results. That is, to re-count the subjects In the most recent statistical period The number of voucher entries within a given period reflects the latest business activity for that account during the current time period. Since the accounting frequency is not fixed—for example, a large number of voucher entries often occur at the end of the month while the middle of the month is relatively stable—this is achieved by updating the data after each task is completed. It can be used in the next mission based on the latest Recalculate dynamic aggregation wait time Without manual intervention, a complete feedback loop is formed, which includes execution completion, activity update, next waiting time calculation, and triggering execution, resulting in a complete detailed ledger corresponding to the voucher data.

[0045] This invention decouples voucher entry from detailed ledger generation and utilizes task aggregation and delayed triggering based on account dimensions to enable the financial system to reliably complete the asynchronous generation of detailed ledgers without interrupting voucher entry. While supporting high-concurrency voucher entry, it ensures the eventual consistency of detailed ledger data, thus achieving reliable asynchronous decoupling between financial voucher entry and detailed ledger generation.

[0046] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for asynchronous accounting of detailed ledgers in a financial system, characterized in that, include: S1. Store the voucher data in the voucher data storage layer and mark the processing status as pending. Based on the subject dimension, search for whether there are any pending tasks associated with the voucher data subject. If not, create and register a new pending task based on the current voucher information. If they exist, aggregate the current voucher information into the existing pending tasks. S2. Update the task processing start position marker in the pending task based on the current voucher's posting date and voucher number to obtain the updated task processing start position marker; read the detailed ledger generation progress marker corresponding to the account in the account posting progress table, and identify whether it belongs to a historical period voucher entry scenario based on the positional relationship between the current voucher and the detailed ledger generation progress marker: If it is, then write the task to the starting point marker as the task processing start position marker and reset the trigger timestamp; If it does not belong to the category, the task will be written to the starting point as the progress marker for the detailed ledger generation. Receive the updated pending tasks; S3. Calculate the dynamic aggregation waiting time based on the business activity metric of the subject, and determine the trigger timestamp based on the dynamic aggregation waiting time. If the cancellation flag of the pending task is set during the task waiting period, the trigger timestamp is accelerated to obtain the adjusted trigger timestamp. S4. When the trigger timestamp expires, take the position indicated by the task writing start mark as the starting boundary, extract all pending vouchers of the account in ascending order of posting date and voucher number, and generate detailed ledger entries in sequence; use atomic operations to write the detailed ledger entries into the account detailed ledger table, update the processing status of all vouchers processed in this operation to processed, and simultaneously advance the detailed ledger generation progress mark. If the atomic operation is executed successfully, the task status is set to completed; if the atomic operation fails, the task status is rolled back to pending and the trigger timestamp is recalculated according to the adaptive retry scheduling strategy. S5. Once the task status is set to "completed", update the business activity metrics of the account based on the accounting results to obtain a complete ledger corresponding to the voucher data.

2. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 1, characterized in that: The task includes a unique task identifier. Subject Code , Starting point date component Component of starting positioning point number Task write start point marker wp, cancellation flag Task status Retry counter Reason for the most recent failure Task creation time Task last update time ,in, The initial value is the posting date of the current voucher. , The initial value is the voucher number of the current voucher. , and Together they form the starting positioning point ; Task status includes pending, in progress, completed, and failed; Cancellation mark This is a boolean field, initially set to false. Retry Counter The initial value is 0.

3. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 2, characterized in that: The offset mark The specific processing steps include: Read the voucher type field of the current voucher ,in This indicates a normal voucher. Indicates a cancellation document; In the scenario of creating and registering a new task, if Then Set to true, otherwise retain the initial value false; In scenarios where current credential information is aggregated into existing tasks, if Then, in the existing tasks Update to true, if and If it is already true, then it remains unchanged.

4. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 2, characterized in that: Step S2 specifically includes: Let the posting date of the current voucher be... The voucher number is Read the current voucher account and its current subsidiary ledger from the account posting progress table to generate a progress marker. ,in The date of the last voucher used to generate the subsidiary ledger entry. The voucher number for the last time a detailed ledger entry was generated; position tuple The starting position marker of existing task processing in the pending tasks If a comparison is made, ,or and Then Overwrite Get the updated task processing start position marker. ; Set the current voucher posting date Date component of the progress marker for the detailed ledger generation Comparison: like ,or and If the scenario is identified as a historical voucher entry scenario, the task start point marker will be set to the updated task processing start position marker. and reset the trigger timestamp; Otherwise, in a normal supplementary scenario, the task is written to the starting point marker and set as the progress marker for generating the detailed ledger. Once the task is determined, it is written to the starting point marker.

5. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 4, characterized in that: The method for calculating the dynamic aggregation waiting time is as follows: Statistics In the most recent statistical period Number of vouchers entered ,by As a metric for business activity, calculate dynamic aggregation wait time. : ； in, Based on aggregation delay, This is the activity adjustment coefficient. This is the minimum lower bound for the dynamic aggregation waiting time; At the current moment The trigger timestamp is dynamically determined based on the activity level of the subject, calculated as a baseline. : ； in This represents the current dynamic aggregation wait time for this subject.

6. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 5, characterized in that: The reset trigger timestamp specifically includes: When the scenario is identified as a historical period voucher entry scenario, the current time is used. Based on this, combined with the currently determined dynamic aggregation waiting time for the subject. The trigger timestamp is reset to obtain the reset trigger timestamp. .

7. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 2, characterized in that: The accelerated convergence processing of the trigger timestamp specifically includes: While the task is waiting for its trigger timestamp to expire, continuously monitor the cancellation flag in the pending tasks. ; If detected If true, then calculate the current time. Remaining time until the trigger timestamp and with compression coefficient The remaining time is compressed proportionally, and the trigger timestamp is updated to the accelerated convergence trigger timestamp: ； in, This indicates the timestamp that triggers accelerated convergence.

8. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 1, characterized in that: Step S4 specifically includes: S41. When the trigger timestamp expires, the task status will be changed. Updated from pending to processing; S42. Using the position indicated by the task writing start point marker as the starting boundary, read all pending vouchers in ascending order of posting date and voucher number, generate corresponding subsidiary ledger entries for each voucher, and obtain the set of subsidiary ledger entries processed in this operation. S43. Write the set of subsidiary ledger entries into the account subsidiary ledger table using atomic operations, update the processing status of all vouchers in this process to processed synchronously, and advance the subsidiary ledger generation progress mark to the position of the last voucher in this process. S44. If the atomic operation is executed successfully, then the task status will be changed. Set to completed; if the atomic operation fails, change the task status to completed. The process is rolled back to pending processing, and the trigger timestamp is recalculated according to the adaptive retry scheduling strategy before returning to S41 for re-execution, resulting in the incremental write result of the detailed ledger entry.

9. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 8, characterized in that: The adaptive retry scheduling strategy employs an exponential backoff mechanism based on the number of retries, specifically including: When an atomic operation fails, the reason for the failure is recorded in the most recent failure reason field. and the retry counter Add one; Retry counter Does it meet the requirements? ,in The maximum number of retries is preset as follows: like If successful, the task status will be... Set as failed and terminate retry; like Then based on the current number of retries The retry interval is dynamically extended exponentially, and the backoff trigger timestamp is calculated. : ； in, For the current moment, For the base interval of retry, This is the maximum retry interval limit. This is the current retry counter value.

10. The method for asynchronous accounting of detailed ledgers in a financial system as described in claim 9, characterized in that: The adaptive retry scheduling strategy also includes an automatic recovery mechanism for suspended tasks: The task storage layer is scanned periodically according to a preset inspection cycle to check the task status. Tasks that are being processed and whose duration exceeds a preset timeout threshold are identified as suspended tasks. The suspended task The process is rolled back to pending status, and the backoff trigger timestamp is recalculated according to the exponential backoff mechanism. This ensures that suspended tasks can automatically re-enter the execution process after the system recovers, thereby guaranteeing the final completion of the detailed account generation task in the event of system anomalies.

Images