A cross-period automatic calculation method and system based on a two-dimensional data model and an event-driven state machine

Abstract

The application relates to the technical field of information processing, and discloses a cross-period automatic calculation method and system based on a double-dimension data model and an event-driven life cycle state machine, which are used for solving the problems of data structure and rule coupling, state scattered management, and cross-period recalculation inconsistency after parameter change in existing periodic object processing. The system constructs a directory data structure containing a static dimension layer and a dynamic dimension layer, and realizes decoupled interaction of a rule engine and a state machine through a static binding channel and a dynamic binding channel. A scheduling unit performs legality verification and state transition of a life cycle state machine based on an event trigger, a rule engine generates structured calculation instructions and forms a data closed loop. Through a dynamic dimension freezing and future period path reconstruction mechanism, history data irreversibility and cross-period state consistency control are realized.

Description

Technical Field

[0001] This invention relates to the field of information processing and automatic calculation technology, and in particular to a cross-cycle automatic calculation method and system based on a two-dimensional data model and an event-driven state machine. Background Technology

[0002] Existing financial software (including ERP, accounting systems, and lightweight financial tools) generally provides functions such as depreciation, amortization, prepaid expense carry-forward, and consumable expense accounting, but their processing methods have the following shortcomings:

[0003] 1.1 Relying on manual configuration of templates or rules

[0004] Users need to manually set parameters such as subject, period, method, ratio, and allocation dimension, as the system lacks automatic recognition capabilities.

[0005] 1.2 Limited degree of automation

[0006] Most systems require manual intervention to perform operations such as "accrual", "carry forward", and "generate vouchers", making it difficult to achieve fully unattended operation throughout the entire process.

[0007] 1.3 Weak adaptability to business changes

[0008] When asset value, benefit period, amortization method, prepayment amount, or consumable consumption changes, the existing system has difficulty automatically recalculating the future amortization period after the change, and maintaining the continuity of accounting processing without affecting the historical data already recorded.

[0009] 1.4 Lack of a unified lifecycle management mechanism

[0010] Depreciation, amortization, prepaid expenses, and consumable expenses are usually scattered across different modules. The lack of a unified state machine scheduling mechanism and rule engine leads to data inconsistency across modules and makes it impossible to form a unified event-driven processing flow.

[0011] 1.5 Unable to form a closed-loop data flow from business documents to accounting entries.

[0012] The existing system cannot achieve full-process automation of automatic identification, automatic modeling, automatic calculation, automatic document generation, and automatic write-back.

[0013] Therefore, a new technical solution is needed to achieve intelligent identification, automatic modeling, automatic calculation, automatic document generation, and automatic write-back of various types of periodic fees, and to achieve closed-loop data processing across modules and cycles through a unified scheduling mechanism. Summary of the Invention

[0014] 3.1 Technical problems to be solved

[0015] Existing periodic object processing systems (including but not limited to depreciation, amortization, expense allocation, and consumable consumption systems) may encounter the following technical problems when performing cross-period automatic calculations in complex cross-period processing scenarios:

[0016] 3.1.1 The coupling between the object data structure and the computational logic leads to the need to rebuild the model or manually intervene when parameters change;

[0017] 3.1.2 The lack of cross-cycle state preservation and consistency control mechanisms makes it difficult to guarantee the immutability of historical data when value or lifetime changes occur;

[0018] 3.1.3 State management is scattered across different modules, lacking a unified event-driven state progression framework;

[0019] 3.1.4 The lack of a closed-loop write-back mechanism between the periodic calculation results and the original data of the object easily leads to the risk of data inconsistency;

[0020] 3.1.5 Lack of conflict detection and transaction compensation mechanisms in the event of multiple concurrent or abnormal events.

[0021] Therefore, there is an urgent need for an automatic calculation and scheduling framework that guarantees cross-cycle state consistency, decouples the rule layer from the state layer, supports dynamic recalculation, and ensures the immutability of historical data.

[0022] 3.2 Technical Solution

[0023] To address the aforementioned technical problems, this invention provides a cross-cycle automatic calculation method based on a two-dimensional binding model and an event-driven lifecycle state advancement mechanism, comprising the following steps:

[0024] 3.2.1 Constructing a Two-Dimensional Data Model

[0025] Establish a directory unit, the directory unit comprising:

[0026] (1) Immutable static dimension layer, used to store attributes that do not usually change automatically during the life cycle of an object;

[0027] (2) A dynamic dimension layer can be advanced to store state data that is automatically updated with periodic events or business events.

[0028] The two-dimensional structure satisfies:

[0029] (1) Static dimensions are updated only when a business event is triggered;

[0030] (2) The dynamic dimension is automatically updated only through a state machine-driven algorithm;

[0031] (3) Static and dynamic dimensions are decoupled from the rule engine through independent binding channels.

[0032] This two-dimensional structure enables the decoupling of the rule layer and the data layer.

[0033] 3.2.2 Constructing an event-driven scheduling mechanism

[0034] The scheduling unit establishes a unified event management framework, including:

[0035] (1) Periodic event queue;

[0036] (2) Business event queue;

[0037] (3) Exception event queue;

[0038] The scheduling unit further includes:

[0039] (1) Event priority sorting module;

[0040] (2) Lifecycle state locking module;

[0041] (3) State conflict detection module;

[0042] (4) Transaction compensation module;

[0043] The scheduling unit allows only a single object to be in a unique and valid lifecycle state at any given time, and performs validity verification on state transitions.

[0044] 3.2.3 Lifecycle Status Advancement

[0045] The lifecycle state machine executes the following process based on the current state and the triggering event:

[0046] (1) Read the current dynamic dimension snapshot;

[0047] (2) Execution status legality verification;

[0048] (3) Look up the state transition mapping table;

[0049] (4) Update dynamic dimensions;

[0050] (5) Generate structured accounting instructions.

[0051] The state progression process does not directly modify static dimensions.

[0052] 3.2.4 Cross-cycle calculation and recalculation mechanism

[0053] The rules engine is based on:

[0054] (1) Current static dimension;

[0055] (2) Current dynamic dimension;

[0056] (3) Current lifecycle status;

[0057] Execution cycle calculation.

[0058] When a change in value or lifespan occurs, this invention performs the following:

[0059] (1) Freeze historical dynamic dimension snapshots;

[0060] (2) Construct a new benchmark for calculating future cycles;

[0061] (3) Reconstructing future cycle calculation paths based on remaining lifetime;

[0062] (4) Keep historical cumulative data irreversible.

[0063] This mechanism ensures that historical periodic data is not tampered with, while also supporting automatic recalculation for future periods.

[0064] 3.2.5 Structured Instruction Generation Mechanism

[0065] While performing periodic calculations, the rules engine reads the corresponding calculation rules and asset-fee account mapping rules from the rule base based on the object's category, trigger event type, and current lifecycle state. It automatically determines the corresponding debit and credit account identifiers and generates structured accounting instructions, including:

[0066] (1) Loan account identifier;

[0067] (2) Amount;

[0068] (3) Period number;

[0069] (4) Lifecycle status identifier;

[0070] (5) Rule source identifier;

[0071] (6) Version number;

[0072] (7) Dimensional snapshot information;

[0073] The structured instructions are decoupled from the formal accounting entry generation process, supporting cross-system adaptation.

[0074] 3.2.6 Closed-loop consistency write-back mechanism

[0075] The synchronization and archiving unit performs the following checks before writing back:

[0076] (1) Verification of consistency between book amount;

[0077] (2) Lifecycle state consistency verification;

[0078] (3) Version conflict detection;

[0079] (4) Reentry detection;

[0080] Only if the verification passes:

[0081] (1) Update dynamic dimensions;

[0082] (2) Write back to the lifecycle state;

[0083] (3) Archive calculation instructions and status change records;

[0084] A closed-loop data flow is formed, consisting of directory units → rule engine → account units → synchronization and archiving units → directory units.

[0085] 3.3 Technical Effects

[0086] Through the above technical solution, the present invention achieves the following technical effects:

[0087] 3.3.1 Decouple the rule layer from the lifecycle layer to reduce system coupling;

[0088] 3.3.2 Provide a cross-cycle state consistency guarantee mechanism;

[0089] 3.3.3 Supports automatic reconfiguration for future cycles under parameter changes;

[0090] 3.3.4 Ensure the immutability of historical periodic data;

[0091] 3.3.5 Improve state stability under multiple concurrent events;

[0092] 3.3.6 Reduce the risk of exception handling through a transaction compensation mechanism;

[0093] 3.3.7 provides a unified cross-module event scheduling framework;

[0094] 3.3.8 Construct a scalable intermediate layer architecture for automatic computation of lifecycle objects;

[0095] 3.3.9 The structured accounting instruction mechanism decouples the periodic calculation logic from the accounting entry generation logic, enabling the determination of debit and credit accounts to be completed automatically under event-driven and lifecycle state control. It also supports dynamic rule expansion, cross-system adaptation, and cross-period recalculation, thereby improving the system's scalability and traceability.

[0096] 3.4 Core Innovations of this Invention

[0097] 3.4.1 Two-Dimensional Binding Decoupling Model

[0098] By employing a dual-track structure of an immutable static dimension layer and a progressive dynamic dimension layer, the data model and computational logic are decoupled.

[0099] 3.4.2 Event-Driven Lifecycle Advancement Algorithm

[0100] A unified state progression mechanism for cross-cycle objects is achieved through a multi-source event queue and a state mapping table.

[0101] 3.4.3 Cross-cycle recalculation retention mechanism

[0102] Historical data is not destroyed when parameters change, and dynamic recalculation is achieved by reconstructing future cycle paths.

[0103] 3.4.4 Structured Accounting Instruction Mechanism

[0104] Versioned and structured accounting instructions are used to decouple the calculation layer from the journal entry generation layer.

[0105] 3.4.5 Closed-loop consistency control mechanism

[0106] Data consistency is ensured through a closed-loop system using a verification module and version control mechanism. Terminology Definition

[0107] To facilitate understanding of the technical solutions of this invention, the terms used in this invention are defined and explained below. Those skilled in the art should understand that these definitions are only used to describe the technical content of this invention.

[0108] 4.1 Directory Unit

[0109] This refers to the data structure used for storing, maintaining, and updating objects (including fixed assets, intangible assets, prepaid fees, consumables, etc.) with static and dynamic dimensions.

[0110] The directory unit is the core data carrier of this invention, supporting automatic advancement across cycles, lifecycle management, and closed-loop synchronization.

[0111] 4.2 Static Dimensions

[0112] This refers to attributes that typically remain unchanged or change minimally throughout an object's lifecycle. Static dimensions do not update automatically with periodic events, but only change when triggered by business events, including but not limited to:

[0113] 4.2.1 Original Value

[0114] 4.2.2 Service life

[0115] 4.2.3 Depreciation / Amortization Method

[0116] 4.2.4 Asset type or expense type

[0117] 4.2.5 Service Cycle

[0118] 4.2.6 Supplier Information

[0119] Static dimensions are passed to the rule engine through the static binding channel for rule selection and lifecycle modeling.

[0120] 4.3 Dynamic Dimensions

[0121] These are attributes that update according to periodic changes or event triggers, and are the core data source for automatic cross-period progression, including but not limited to:

[0122] 4.3.1 Accumulated Depreciation / Accumulated Amortization / Accumulated Consumption

[0123] 4.3.2 Remaining useful life or remaining service life

[0124] 4.3.3 Book Value

[0125] 4.3.4 Lifecycle Status

[0126] 4.3.5 Consumption Record

[0127] Dynamic dimensions are bidirectionally bound to the rule engine through dynamic binding channels, enabling automatic advancement and write-back synchronization across cycles.

[0128] 4.4 Static Binding Channel

[0129] This refers to the data channel used to pass static dimension parameters between the directory unit and the rule engine. The rule engine obtains the static parameter information required for rule selection, lifecycle template matching, and business attribute identification through this channel.

[0130] 4.5 Dynamic Binding Channel

[0131] This refers to the data channel used to transmit dynamic dimension parameters between the directory unit and the rule engine and state machine unit, supporting dynamic business processing such as periodic calculation, state update, result write-back synchronization, and automatic advancement across periods.

[0132] 4.6 Rule Engine

[0133] This refers to the module that automatically selects applicable rules and performs calculations based on the directory dimension. The rule engine performs rule matching and periodic calculations based on static and dynamic dimensions, including:

[0134] 4.6.1 Dimensional Parser

[0135] 4.6.2 Rule Selector

[0136] 4.6.3 Computation Engine

[0137] 4.6.4 Instruction Generator

[0138] The rules engine can handle various types of expenses, including depreciation, amortization, prepaid expense carry-forward, and consumable expense.

[0139] 4.7 Lifecycle State Machine

[0140] An event-driven model used to manage the lifecycle states and state transitions of objects, including but not limited to:

[0141] 4.7.1 Created

[0142] 4.7.2 Activation

[0143] 4.7.3 Depreciating

[0144] 4.7.4 Amortizing

[0145] 4.7.5 Consumable

[0146] 4.7.6 Consumption

[0147] 4.7.7 Paused

[0148] 4.7.8 Resumed

[0149] 4.7.9 Under Adjustment

[0150] 4.7.10 Retired

[0151] 4.7.11 Disposed

[0152] The state machine automatically advances its lifecycle based on periodic events, business events, or abnormal events.

[0153] 4.8 Events

[0154] External or internal signals that trigger rule execution or state transitions include:

[0155] 4.8.1 Periodic events (such as month-end accruals)

[0156] 4.8.2 Consumption events (such as consumable requisition)

[0157] 4.8.3 Events that change value (such as additional capitalization)

[0158] 4.8.4 Lifespan Change Events

[0159] 4.8.5 Pause / Resume Events

[0160] 4.8.6 Incident Handling

[0161] Events are captured by the scheduling unit or by the triggering engine and passed to the state machine.

[0162] 4.9 Structured Accounting Instructions (Posting Instruction)

[0163] The structured data objects generated by the rule engine based on the calculation results include:

[0164] 4.9.1 Loan Account Identification

[0165] 4.9.2 Amount

[0166] 4.9.3 Description Information

[0167] 4.9.4 Recommended Lifecycle Status

[0168] Information during period 4.9.5

[0169] Furthermore, structured accounting instructions may also include rule source identifiers, version numbers, and dimension snapshot information, which can be used for cross-period traceability, conflict detection, and cross-system adaptation.

[0170] 4.10 Account Unit

[0171] This refers to the module used to receive structured accounting instructions, generate formal accounting entries and write them to the external general ledger system. It is also responsible for updating the book balance and feeding back the entry results and lifecycle status information to the synchronization and archiving unit for state consistency writing back.

[0172] 4.11 Synchronization & Archive Unit

[0173] This refers to the function used to receive authoritative accounting results from external general ledger systems and write the updated dynamic dimensions, lifecycle status, and related information back to the directory unit. It is also responsible for synchronizing or archiving structured accounting instructions, formal accounting entries, and lifecycle change records to external systems to achieve data closure and compliance traceability.

[0174] 4.12 Cross-Period Automation

[0175] This refers to the system automatically executing based on periodic events without human intervention:

[0176] 4.12.1 Rule Selection

[0177] 4.12.2 State Machine Advancement

[0178] 4.12.3 Amount Calculation

[0179] 4.12.4 Journal Entry Generation

[0180] 4.12.5 Write-back Synchronization

[0181] Enables continuous and automatic handling of object lifecycles.

[0182] 4.13 Closed-Loop Automation

[0183] This refers to the complete cycle of directory unit → rule engine → account unit → synchronization and archiving unit → directory unit, enabling the system to automatically identify, calculate, generate, write back, and enter the next cycle.

[0184] 4.14 Orchestration Unit

[0185] This refers to the event-driven scheduling module used to coordinate the execution order of the directory unit, rule engine unit, lifecycle state machine, account unit, and synchronization and archiving unit.

[0186] Based on its internal state management mechanism, the scheduling unit identifies, distributes, and schedules periodic events, business events, and abnormal events, driving processes such as rule selection, state machine advancement, amount calculation, journal entry generation, and write-back synchronization.

[0187] The scheduling unit decouples the various units through task queues, status control, and exception compensation strategies, enabling the system to operate in a consistent manner across different business systems and supporting automatic advancement across cycles and unattended execution.

[0188] The scheduling unit can invoke the triggering engine to capture events and complete event enqueueing and dispatching. Attached Figure Description

[0189] 5.1 Figure 1 is a schematic diagram of the overall architecture of the system of the present invention.

[0190] This diagram illustrates the interaction between the middleware system of this invention and external business systems and external ledger systems. It shows the overall data flow of the input system, scheduling unit, directory unit, rule engine and state machine unit, account unit, synchronization and archiving unit, and output system, demonstrating the system-level closed-loop structure of this invention. The scheduling unit is responsible for process coordination, while the rule engine and state machine unit are responsible for rule execution and state progression.

[0191] 5.2 Figure 2 is a schematic diagram of the lifecycle state structure of the Directory Unit of the present invention.

[0192] This diagram illustrates the lifecycle structure of the catalog unit using a hierarchical state machine, including states such as new, activated, running, paused, decommissioned pending, under adjustment, and under disposal. Among them, the running state is a composite state, which contains two sub-states: accruing (303) and amortizing (308). It also shows the triggering relationship of events such as pause, decommissioning, and adjustment on the running state and the transition paths between each state.

[0193] Figure 3 is a schematic diagram of the internal structure of the rule engine and state machine unit of the present invention.

[0194] This diagram illustrates the internal processing flow of the rule engine and state machine unit, including modules such as the dimension parser, rule selector, state machine controller, trigger engine, calculation engine, and structured accounting instruction generator. The scheduling unit passes static and dynamic dimension parameters to this unit, where the rule engine performs rule matching and periodic calculations, the state machine controller executes lifecycle state transitions, and finally generates structured accounting instructions. The rule selector reads corresponding calculation rules and account mapping rules from the rule base based on object category, event type, and lifecycle state, realizing an automated rule execution and state progression mechanism.

[0195] 5.4 Figure 4 is a schematic diagram of the process for generating accounting entries using the Account Unit of the present invention.

[0196] This diagram illustrates the processing steps of an account unit, including receiving and parsing structured accounting instructions, generating debits and credits, updating balances, and providing feedback on lifecycle status information. Ultimately, it outputs formal accounting entries to the external general ledger system. The account unit serves as the core of the conversion between structured accounting instructions and formal accounting entries, ensuring the accuracy, continuity, and traceability of accounting processes.

[0197] Figure 5.5 is a schematic diagram of the write-back and archive process of the Synchronization & Archive Unit of the present invention.

[0198] This diagram illustrates how, after receiving authoritative accounting results from an external general ledger system, the system sequentially performs dynamic dimension updates, lifetime updates, cumulative consumption updates, balance synchronization, and lifecycle stage updates, before writing the updated dimensions back to the directory unit. The synchronization and archiving unit is also responsible for archiving structured accounting instructions, formal accounting entries, and lifecycle change records to the external system, achieving data closure, accounting consistency, and compliance record keeping.

[0199] 5.6 Figure 6 is a data flow diagram (DFD) of the present invention.

[0200] This diagram illustrates the data interaction relationships between the external input system, scheduling unit, directory unit, rule engine and state machine unit, account unit, and synchronization and archiving unit. Static binding channel (C1) and dynamic binding channel (C2) are used for dimensional parameter interaction between the directory unit and the rule engine and state machine unit. The scheduling unit is responsible for driving rule selection, state progression, periodic calculation, and the generation of structured accounting instructions. The account unit generates formal accounting entries based on structured accounting instructions. The synchronization and archiving unit writes the authoritative accounting results from the external general ledger system back to the directory unit, achieving a closed-loop data flow of directory unit → rule engine and state machine unit → account unit → synchronization and archiving unit → directory unit, supporting automatic cross-period progression and unattended execution. Detailed Implementation

[0201] To enable those skilled in the art to better understand the technical solution of the present invention, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. The embodiments of the present invention are only used to illustrate the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0202] 6.1 System Overall Structure (corresponding to Figure 1)

[0203] As shown in Figure 1, this invention provides a cross-cycle automatic calculation system based on a directory unit, a rule engine and state machine unit, an account unit, and a synchronization and archiving unit. The system receives business data through an input system, and the scheduling unit coordinates the execution order of the directory unit, rule engine and state machine unit, account unit, and synchronization and archiving unit to realize processing flows such as rule selection, lifecycle state advancement, amount calculation, accounting entry generation, and write-back synchronization.

[0204] The various units collaborate through data flow, with the scheduling unit responsible for process coordination but not involved in specific rule calculations or accounting, thereby achieving system decoupling and scalability.

[0205] 6.2 Lifecycle State Structure (corresponding to Figure 2)

[0206] As shown in Figure 2, the directory unit records the lifecycle status of objects, including Created, Active, Running, Paused, Retired Pending Disposal, Adjusting, and Disposed.

[0207] The Running state is a composite state, which contains two sub-states: Depreciating (303) and Amortizing (308). Once an object enters the Running state, the rule selector automatically determines the corresponding sub-state based on the object category and current business attributes.

[0208] The lifecycle state machine drives state transitions based on periodic events, business events, or abnormal events, and the state changes are recorded by the catalog unit for automatic cross-cycle advancement and subsequent calculation path selection.

[0209] 6.3 Rule Engine and State Machine Structure (corresponding to Figure 3)

[0210] As shown in Figure 3, the rule engine and state machine unit includes modules such as dimension parser, rule selector, state machine controller, trigger engine, calculation engine and structured accounting instruction generator.

[0211] The rules engine performs rule matching, amount calculation, and structured accounting instruction generation based on static and dynamic dimensions; the state machine controller performs lifecycle state transitions based on event types.

[0212] The rule selector reads the corresponding calculation rules and account mapping rules from the rule base based on the object category, event type, and current lifecycle state, thereby realizing an automated rule execution and state advancement mechanism.

[0213] 6.4 Accounting Entry Generation Process (corresponding to Figure 4)

[0214] As shown in Figure 4, after receiving the structured accounting instruction, the account unit sequentially executes the processing steps such as instruction parsing, debit / credit generation, balance update, and feedback of lifecycle status information, and writes the formal accounting entries into the external general ledger system.

[0215] Account units serve as the core of the conversion between structured accounting instructions and formal accounting entries, ensuring the accuracy, continuity, and traceability of accounting processes.

[0216] 6.5 Write-back and archiving process (corresponding to Figure 5)

[0217] As shown in Figure 5, after receiving the authoritative accounting results from the external general ledger system, the synchronization and archiving unit sequentially performs processing steps such as dynamic dimension update, lifetime update, cumulative consumption update, balance synchronization and lifecycle stage update, and writes the updated dimensions back to the catalog unit.

[0218] The synchronization and archiving unit is also responsible for archiving structured accounting instructions, formal accounting entries, and lifecycle change records to external systems to achieve data closure, accounting consistency, and compliance traceability.

[0219] 6.6 Data flow closed loop and automatic cross-cycle advancement (corresponding to Figure 6)

[0220] As shown in Figure 6, the static binding channel (C1) and the dynamic binding channel (C2) are used for the interaction of dimensional parameters between the directory unit and the rule engine and state machine unit. The scheduling unit is responsible for driving rule selection, state advancement, periodic calculation and structured accounting instruction generation.

[0221] The account unit generates formal accounting entries based on structured accounting instructions, and the synchronization and archiving unit writes the authoritative accounting results from the external general ledger system back to the directory unit, forming a closed-loop data flow of directory unit → rule engine and state machine unit → account unit → synchronization and archiving unit → directory unit, enabling automatic progress across cycles and unattended execution.

[0222] 6.7 Example:

[0223] 6.7.1 Amortization Treatment

[0224] The following example of the straight-line amortization of an intangible asset illustrates the specific application of this invention.

[0225] 6.7.1.1 Input the system to receive the invoice; the dimension parser will automatically extract it:

[0226] (1) Original value 12,000

[0227] (2) Benefit period: 12 months

[0228] (3) Amortization method: Straight line method

[0229] 6.7.1.2 The system automatically creates a directory unit and puts it into active state.

[0230] 6.7.1.3 At the end of the month, a periodic event is triggered, which is captured by the scheduling unit and drives the state machine to enter the "amortization in progress" state.

[0231] 6.7.1.4 The calculation engine calculates the amortization amount for this period: 12,000 ÷ 12 = 1,000

[0232] Before generating accounting instructions, the system automatically reads the corresponding amortization expense account and accumulated amortization account mapping rules from the rule base according to the asset category and current life cycle status, and writes the determined debit and credit account identifiers into the structured accounting instructions.

[0233] 6.7.1.5 The instruction generator generates accounting instructions:

[0234] (1) Debit: Amortization expenses 1,000

[0235] (2) Credit: Accumulated amortization of 1,000

[0236] 6.7.1.6 The account unit generates formal accounting entries and updates the balance.

[0237] 6.7.1.7 Synchronization and Archive Unit Write-back:

[0238] (1) Accumulated amortization = 1,000

[0239] (2) Remaining lifespan = 11

[0240] (3) Book value = 11,000

[0241] At the same time, the structured accounting instructions and status change records for this period will be archived.

[0242] Before writing back, the system performs consistency checks on the book value and validity checks on the lifecycle state of the dynamic dimension to prevent state rollback or recalculation of amounts due to concurrent events or repeated triggering. The system only updates the dynamic dimension and writes it back to the directory unit after the verification passes, ensuring the uniqueness and consistency of state advancement across lifecycles.

[0243] 6.7.1.8 After the synchronization and archiving unit completes archiving, the directory unit prepares to enter the next cycle.

[0244] This embodiment demonstrates that the present invention can automatically identify, calculate, generate, and write back data without manual configuration, thereby achieving a closed loop of uniqueness and data consistency in cross-cycle state advancement.

[0245] 6.7.2 Fixed Asset Depreciation Treatment

[0246] The following example, using the straight-line depreciation method for an office equipment fixed asset, illustrates the specific application process of the method of this invention.

[0247] 6.7.2.1 Directory Dimension Analysis

[0248] The input system receives a purchase invoice for an office computer. The dimension parser automatically extracts the following static and dynamic dimensions from the business document:

[0249] (1) Static dimension:

[0250] a. Original value: 9,600 yuan

[0251] b. Service life: 36 months

[0252] c. Depreciation method: Straight-line method

[0253] d. Asset type: Office equipment

[0254] e. Supplier: An office equipment company

[0255] (2) Dynamic Dimensions (Initialization):

[0256] a. Accumulated depreciation: 0

[0257] b. Remaining lifespan: 36

[0258] c. Book value: 9,600

[0259] d. Lifecycle status: Created

[0260] The system automatically creates directory units and establishes two-way binding with the rule engine through static and dynamic binding channels.

[0261] 6.7.2.2 Rule Selection and State Machine-Driven Approach

[0262] Rule selection and state machine progression are coordinated by the scheduling unit.

[0263] Once the catalog unit enters the "Active" state, the event-driven state machine automatically selects the depreciation rule based on the object type (fixed asset). The system recognizes that the asset belongs to the "Office Equipment" category of fixed assets and matches the preset industry rule:

[0264] (1) Depreciation method: Straight-line method

[0265] (2) Depreciation period: monthly

[0266] (3) Depreciation formula: Original value ÷ useful life

[0267] The lifecycle state machine automatically transitions from "Active" to "Depreciating".

[0268] 6.7.2.3 Periodic Triggering and Current Period Depreciation Calculation

[0269] When the month-end periodic event is triggered, the calculation engine calculates the current period's depreciation amount based on the current lifecycle status and depreciation rules:

[0270] The depreciation amount payable this period is RMB 266.67.

[0271] 6.7.2.4 Generation of Structured Accounting Instructions

[0272] The instruction generator combines the calculation results with state changes to generate structured accounting instructions, including:

[0273] (1) Debit: Administrative Expenses - Depreciation 266.67

[0274] (2) Credit: Accumulated Depreciation 266.67

[0275] (3) Description: Depreciation of office computers

[0276] (4) Recommended lifecycle status: Depreciating

[0277] (5) Period: the current month

[0278] This structured instruction can be adapted to the native format of different financial software.

[0279] 6.7.2.5 Accounting Entries Generation and Book Updates

[0280] The account unit receives accounting instructions and performs the following operations:

[0281] (1) Analyze the debit and credit accounts and amounts;

[0282] (2) Generate formal accounting entries;

[0283] (3) Write to the external general ledger system;

[0284] (4) Update the book balance of the relevant accounts;

[0285] (5) Feed back the lifecycle status information to the synchronization and archiving unit for writing back consistency confirmation.

[0286] 6.7.2.6 Write-back synchronization and directory update

[0287] The synchronization and archiving unit receives authoritative accounting results from the external general ledger system and writes the following information back to the catalog unit:

[0288] (1) Accumulated depreciation: 266.67

[0289] (2) Remaining lifespan: 35 years

[0290] (3) Book value: 9,333.33

[0291] (4) Lifecycle status: Depreciating

[0292] (5) Current Event: Periodic Provision

[0293] At the same time, archive the current period's structured accounting instructions, formal accounting entries, and lifecycle change records.

[0294] Before writing back, the system compares the version number of the dynamic dimensions. If a version conflict or re-entry write-back is detected, the update is automatically aborted and compensation logic is triggered to ensure that historical depreciation records are irreversible and state progression is unreversible. The compensation logic includes rolling back uncommitted dynamic dimension updates and restoring the state to the most recent valid version, ensuring that only one valid version of the object exists at any given time. After a successful write-back, the dynamic dimension version number is automatically incremented for validity checks in subsequent cycles.

[0295] 6.7.2.7 Automatic propulsion across cycles

[0296] The system will automatically trigger again at the end of the following month:

[0297] (1) Periodic events

[0298] (2) The state machine remains in the "accrual" state.

[0299] (3) Automatically calculate depreciation

[0300] (4) Automatically generate accounting instructions

[0301] (5) Automatically generate journal entries

[0302] (6) Automatic write-back

[0303] (7) Automatically advance to the next cycle

[0304] 6.7.3 Dynamic Costing of Consumables

[0305] The following example, using the expense processing of a batch of office consumables (such as printing paper, ink cartridges, etc.), illustrates the dynamic expense processing mechanism of this invention in the consumables scenario.

[0306] 6.7.3.1 Directory Dimension Analysis

[0307] The input system receives an office supplies purchase invoice, and the dimension parser automatically extracts the following dimensions from the business document:

[0308] (1) Static dimension:

[0309] a. Product Name: Printing Paper (A4)

[0310] b. Amount: 480 yuan

[0311] c. Category: Office Supplies

[0312] d. Supplier: An office supplies company

[0313] e. Fee type: Consumables

[0314] (2) Dynamic Dimensions (Initialization):

[0315] a. Cumulative consumption: 0

[0316] b. Remaining quantity: 5 packs

[0317] c. Book value: 480 yuan

[0318] d. Lifecycle status: Created

[0319] e. Consumption Record: Empty

[0320] The system automatically creates directory units and establishes binding relationships with the rule engine through static binding channels and dynamic binding channels.

[0321] 6.7.3.2 Selection of Dynamic Costing Rules for Consumables

[0322] The selection of consumable rules and the advancement of the state machine are coordinated by the scheduling unit.

[0323] The rules engine identifies the object as belonging to the "Supplies" type based on static dimensions and automatically matches preset dynamic feeination rules for Supplies, including:

[0324] (1) Rules for determining the amount threshold

[0325] If the amount is lower than the preset threshold (e.g., 500 yuan), it can be expensed in one go.

[0326] (2) Category Judgment Rules

[0327] Office supplies are usually fast-moving consumables and can be dynamically expensed based on consumption records.

[0328] (3) Consumption record-driven rules

[0329] If a consumption event exists, the actual consumption amount will be expensed.

[0330] (4) Lifecycle state machine rules

[0331] a. Created

[0332] b. Consumable

[0333] c. Consuming

[0334] d. Completely consumed (Depleted)

[0335] The system determines the lifecycle status from "Created" to "Consumable" based on the amount and category.

[0336] 6.7.3.3 Consumption Event Triggering and Current Period Cost Calculation

[0337] In actual business operations, users record the consumption event of "receiving 2 packs of printing paper" in the system.

[0338] The triggering engine captures the event, and the state machine automatically transitions from "Consumable" to "Consuming".

[0339] The calculation engine calculates the current period's expensed amount based on dynamic dimensions:

[0340] (1) Unit price: 480 ÷ 5 = 96 yuan / pack

[0341] (2) Consumption this period: 2 packs

[0342] (3) Expenses for this period: 96 × 2 = 192 yuan

[0343] 6.7.3.4 Generation of Structured Accounting Instructions

[0344] The instruction generator combines the calculation results with state changes to generate structured accounting instructions, including:

[0345] (1) Debit: Management Expenses - Office Supplies 192

[0346] (2) Credit: Inventory Supplies 192

[0347] (3) Description: Expensing of printing paper consumption

[0348] (4) Recommended lifecycle state: Consuming

[0349] (5) Quantity consumed this period: 2 packs

[0350] (6) Remaining quantity: 3 packs

[0351] This structured instruction can be adapted to the native format of different financial software.

[0352] 6.7.3.5 Accounting Entries Generation and Book Updates

[0353] The account unit receives accounting instructions and performs the following operations:

[0354] (1) Analyze the debit and credit accounts and amounts;

[0355] (2) Generate formal accounting entries;

[0356] (3) Write to the external general ledger system;

[0357] (4) Update the book balance of the relevant accounts;

[0358] (5) Feed back the lifecycle status information to the synchronization and archiving unit for writing back consistency confirmation.

[0359] 6.7.3.6 Write-back Synchronization and Directory Update

[0360] The synchronization and archiving unit receives authoritative accounting results from the external general ledger system and writes the following information back to the catalog unit:

[0361] (1) Total amount consumed: 192

[0362] (2) Remaining quantity: 3 packs

[0363] (3) Book value: RMB 288

[0364] (4) Lifecycle status: Consuming

[0365] (5) This period's events: Consumption records (2 packs)

[0366] It also archives current consumption events, expensing instructions, and lifecycle change records.

[0367] When processing each consumption event, the system performs state validity checks based on the state machine to prevent objects from being illegally consumed while in the "exhausted" or "paused" state. Before writing back, a remaining quantity consistency check is performed to ensure that consumption events are not counted repeatedly due to concurrent commits. When the system detects that the dynamic dimension version number corresponding to a consumption event is inconsistent with the current directory unit version number, it refuses to perform cost estimation calculations and records the conflict event.

[0368] 6.7.3.7 Automatic processing after complete consumption

[0369] When recording "3 packs of printer paper used" again later:

[0370] (1) Expensed amount for this period: 96 × 3 = 288

[0371] (2) Remaining quantity: 0

[0372] (3) Book value: 0

[0373] The lifecycle state machine automatically transitions from "Consuming" to "Depleted". The system automatically completes final expense and closes the catalog unit.

[0374] 6.7.3.8 Automatic propulsion across cycles

[0375] Throughout the process:

[0376] (1) The system automatically identifies the type of Supplies.

[0377] (2) Automatically determine whether to expense on a one-time basis or expense based on consumption.

[0378] (3) Automatically handle consumption events

[0379] (4) Automatically generate journal entries

[0380] (5) Automatic write-back

[0381] (6) Automatically advance the life cycle

[0382] It achieves closed-loop automation of the entire lifecycle of consumable costing without human intervention.

[0383] 6.7.4 Changes in the value of fixed assets

[0384] The following example illustrates the automatic processing mechanism of this invention in value change scenarios, using a fixed asset undergoing value adjustment (such as additional costs, capitalized expenditures, or impairment) during its use.

[0385] 6.7.4.1 Directory Dimension Initialization

[0386] The system has created catalog units based on the original purchase invoices, with the following static and dynamic dimensions:

[0387] (1) Static dimension:

[0388] a. Original value: 100,000 yuan

[0389] b. Service life: 60 months

[0390] c. Depreciation method: Straight-line method

[0391] d. Asset type: Machinery and equipment

[0392] (2) Dynamic Dimension (Initial):

[0393] a. Accumulated depreciation: 20,000

[0394] b. Remaining lifespan: 48

[0395] c. Book value: 80,000

[0396] d. Lifecycle Status: Depreciating

[0397] The system has entered its normal depreciation cycle.

[0398] 6.7.4.2 Value Change Event Triggering

[0399] The identification of value change events and the advancement of the state machine are coordinated by the scheduling unit.

[0400] During the use of the assets, the company incurred additional capitalized expenditures of RMB 15,000 (such as the replacement of key components).

[0401] When the input system receives the business document, it triggers the engine to recognize the "value change event" and transmits the event to the state machine controller.

[0402] The state machine automatically transitions from the "Depreciating" state to the "Adjusting" state based on the event type.

[0403] 6.7.4.3 Selection of Value Change Rules

[0404] The rules engine automatically selects the "value adjustment rule" based on the event type, including:

[0405] (1) Additional cost capitalization rules

[0406] The additional amount will be included in the original value of the asset.

[0407] (2) Remaining useful life recalculation rules

[0408] The original service life will remain unchanged, and the remaining service life will continue as originally planned.

[0409] (3) Rules for recalculating the depreciation base

[0410] New book value = Original book value + Additional amount.

[0411] (4) Rules for recalculating subsequent depreciation

[0412] New depreciation expense = New book value ÷ Remaining useful life.

[0413] 6.7.4.4 Value Change Calculation

[0414] Based on the above rules, the system automatically calculates:

[0415] (1) New original value: 100,000 + 15,000 = 115,000

[0416] (2) New book value: 80,000 + 15,000 = 95,000

[0417] (3) Remaining lifespan: 48 (unchanged)

[0418] (4) New month depreciation: 95,000 ÷ 48 ≈ 1,979.17 yuan

[0419] The calculation engine writes the above results into structured accounting instructions.

[0420] After the calculation engine completes the above calculation, the system automatically reads the mapping rules between the corresponding asset account and the counterparty account from the rule base according to the event type and the current life cycle status, determines the debit and credit account identifiers and writes them into the structured accounting instruction object, and then encapsulates the calculation results and the account identifiers together into a structured accounting instruction.

[0421] Upon triggering a value change event, the system automatically freezes the dynamic dimension snapshot before the change and marks it as a historical immutable version. Subsequent periodic calculations are performed based on the new dynamic dimension version number. The system ensures that historical depreciation records are not retroactively modified by comparing version numbers and reconstructs future periodic calculation paths based on remaining lifetime, achieving consistency control for cross-period recalculations. The historically frozen records are only allowed to be read and do not participate in subsequent calculation path changes. Any modification requests to the frozen version are rejected to ensure the irreversibility of historical periodic data.

[0422] 6.7.4.5 Generation of Structured Accounting Instructions

[0423] The instruction generator generates the following structured accounting instructions:

[0424] (1) Debit: Fixed Assets—Machinery and Equipment 15,000

[0425] (2) Credit: Bank deposit 15,000

[0426] (3) Description: Additional capitalized expenditures on machinery and equipment

[0427] (4) Recommended lifecycle status: Adjusting

[0428] (5) New original value: 115,000

[0429] (6) New book value: 95,000

[0430] (7) New depreciation amount: 1,979.17

[0431] 6.7.4.6 Accounting Entries Generation and Book Updates

[0432] The account unit performs the following operations:

[0433] (1) Parse the instruction content;

[0434] (2) Generate formal accounting entries;

[0435] (3) Write to the external general ledger system;

[0436] (4) Update the balance of asset accounts;

[0437] (5) Feed back the lifecycle status information to the synchronization and archiving unit for writing back consistency confirmation.

[0438] 6.7.4.7 Write-back Synchronization and Directory Update

[0439] The synchronization and archiving unit receives authoritative accounting results from the external general ledger system and writes the following back to the catalog unit:

[0440] (1) Original value: 115,000

[0441] (2) Accumulated depreciation: 20,000 (unchanged)

[0442] (3) Remaining lifespan: 48

[0443] (4) New book value: 95,000

[0444] (5) New Moon Depreciation: 1,979.17

[0445] (6) Lifecycle status: Depreciating

[0446] (7) Current Event: Value Change (Additional Capitalization)

[0447] While writing back to the directory unit, the synchronization and archiving unit archives the value change instructions, formal entries, and lifecycle change records.

[0448] 6.7.4.8 Automatic propulsion across cycles

[0449] In the next cycle, the system will automatically:

[0450] (1) Use the new depreciation base

[0451] (2) Use the new depreciation amount

[0452] (3) Automatically generate depreciation entries

[0453] (4) Automatic write-back

[0454] (5) Automatically advance the life cycle

[0455] The entire process requires no human intervention, automating depreciation after value changes.

[0456] 6.7.5 Overview of Other Examples

[0457] In addition to the embodiments described above, this invention is also applicable to various recurring expense processing scenarios. The following optional implementation methods are all based on the directory dimension system, unified coordination of scheduling units, rule engine, lifecycle state machine, structured accounting instructions, and synchronization and archiving mechanisms of this invention, and are natural extensions of the technical solution of this invention.

[0458] 6.7.5.1 Changes in the useful life of fixed assets

[0459] When the useful life of a fixed asset changes due to technological upgrades, maintenance conditions, or policy adjustments, the input system receives the useful life change event. The scheduling unit coordinates event identification and state machine progression. The rules engine recalculates the remaining useful life and subsequent depreciation based on the changed useful life, generating structured accounting instructions. The synchronization and archiving unit writes the updated dimensions back to the catalog unit and archives relevant records, achieving automatic updates to the depreciation plan.

[0460] 6.7.5.2 Changes in the value of fixed assets

[0461] When fixed assets undergo additional capitalization expenditures, impairment, or value adjustments, the system automatically identifies the value change event and the scheduling unit drives the state machine to enter the "Adjusting" state. The rule engine recalculates the original value, book value, and subsequent depreciation based on the change type; the account unit generates formal accounting entries; and the synchronization and archiving unit writes the new dimensions back to the directory unit and archives the value change instructions, formal entries, and lifecycle change records, thus achieving automated depreciation processing after value changes.

[0462] 6.7.5.3 Asset Disposal

[0463] When an asset is sold, scrapped, or transferred, the input system triggers a disposal event. The scheduling unit coordinates the state machine to transition from "Depreciating" to "Disposed." The rules engine automatically calculates the disposal gain or loss and generates disposal accounting instructions; the account unit generates formal accounting entries; the synchronization and archiving unit updates the lifecycle status to "Disposed" and archives the disposal record, finally closing the catalog unit.

[0464] 6.7.5.4 Early write-off of prepaid expenses

[0465] When prepaid expenses need to be written off in advance due to contract termination, service interruption, or policy changes, the system automatically identifies the early write-off event and the scheduling unit drives the state machine to enter the "Adjusting" state. The rules engine calculates the amount to be written off based on the remaining service period and generates write-off accounting instructions; it also synchronously writes back to the directory unit from the archive unit and archives the write-off records, thus realizing the automatic early carry-forward of prepaid expenses.

[0466] 6.7.5.5 Abnormal Event Handling (Pause / Resume)

[0467] When an asset or expense object needs to have its accrual suspended due to reasons such as disuse, maintenance, or freezing, the scheduling unit coordinates the identification of the suspension event and the advancement of the state machine, causing the state machine to transition from the "Depreciating" or "Amortizing" state to the "Paused" state. After the recovery event is triggered, the scheduling unit drives the state machine to restore to its original state and continue the cycle processing; it also writes back and archives relevant records with the archiving unit to ensure accounting continuity.

[0468] 6.7.5.6 Extended Scenarios for Dynamic Costing of Supplies

[0469] In addition to the foregoing embodiments, the present invention also supports:

[0470] (1) One-time expense based on amount threshold

[0471] (2) Category-based automatic classification

[0472] (3) Dynamic expense based on consumption records

[0473] (4) Automatic expense based on inventory changes

[0474] (5) Intelligent prediction based on historical usage patterns

[0475] All rule selection, event recognition, and state machine advancement are uniformly coordinated by the scheduling unit; the synchronization and archiving unit is responsible for writing back and archiving, realizing full lifecycle automation of consumable costing.

[0476] 6.7.5.7 Unified processing of multiple types of fees

[0477] The directory dimension system, scheduling unit, rule engine, and state machine framework of this invention are highly versatile and applicable to:

[0478] (1) Depreciation of fixed assets

[0479] (2) Amortization of intangible assets

[0480] (3) Carry forward of prepaid expenses

[0481] (4) Dynamic costing of consumables

[0482] (5) Long-term deferred expenses

[0483] (6) Amortization of low-value consumables in installments

[0484] (7) Allocation of equipment rental costs

[0485] (8) Feating the service contract period

[0486] All types are processed automatically through a unified directory structure, scheduling unit coordination, rule engine processing, state machine advancement, and synchronization and archiving mechanisms.

[0487] In all extended scenarios, the system ensures the uniqueness of cross-cycle state progression, the irreversibility of historical data, and the reconfigurability of future cycle computation paths through a lifecycle state machine, dynamic dimensional version control, consistency verification, and write-back closed-loop mechanism, thereby achieving unified automated processing of multiple types of cycle objects. In all implementations, the dual-dimensional data model, dual-binding channels, event-driven state machine, version control mechanism, and consistency verification mechanism together constitute a cross-cycle state consistency control framework. Its technical effect is to guarantee the irreversibility of historical data, the unique and legitimate nature of state transitions, and support for the dynamic reconfiguration of future computation paths.

[0488] 6.7.6 Example of Cross-Period Freeze and Recalculation Mechanism

[0489] The following example illustrates the cross-period freeze and future recalculation mechanism of this invention, using a fixed asset whose parameters change after several depreciation periods as an example.

[0490] 6.7.6.1 Initial cycle execution

[0491] A certain fixed asset:

[0492] (1) Original value: 120,000 yuan

[0493] (2) Service life: 60 months

[0494] (3) Depreciation method: Straight-line method

[0495] The system has been performing depreciation normally for 24 months.

[0496] At this point, the dynamic dimension data in the directory unit is:

[0497] (1) Accumulated depreciation: RMB 48,000

[0498] (2) Remaining lifespan: 36 months

[0499] (3) Book value: RMB 72,000

[0500] (4) Lifecycle status: Depreciating

[0501] (5) Version number: V1

[0502] 6.7.6.2 Parameter Change Event Trigger

[0503] At the beginning of the 25th month, a value change event occurred: an additional capitalized expenditure of RMB 18,000.

[0504] The scheduling unit captures the business event and temporarily transfers the object's state to:

[0505] Adjusting

[0506] 6.7.6.3 Historical Freeze Mechanism

[0507] Before performing any recalculation, the present invention performs the following freeze operation:

[0508] (1) Generate an immutable snapshot of the current dynamic dimension:

[0509] a. Accumulated depreciation: 48,000

[0510] b. Remaining lifespan: 36

[0511] c. Book value: 72,000

[0512] d. Lifecycle Status: Accruing

[0513] e. Version number: V1

[0514] (2) Mark the snapshot as a "historical frozen record" and prohibit subsequent modifications;

[0515] (3) Increment the directory unit version number to V2;

[0516] (4) The dynamic dimension of the new version is calculated independently under V2.

[0517] This freezing mechanism ensures that historical depreciation data from periods 1 to 24 are not retroactively modified.

[0518] 6.7.6.4 Future Computing Path Restructuring

[0519] In version V2, the system performs the following steps:

[0520] (1) Update static dimensions:

[0521] a. New original value: 120,000 + 18,000 = 138,000

[0522] (2) Constructing a new dynamic computing benchmark:

[0523] a. New book value: 72,000 + 18,000 = 90,000

[0524] b. Remaining life expectancy: 36 months

[0525] Recalculate future depreciation:

[0526] a. New month depreciation: 90,000 ÷ 36 = 2,500 yuan

[0527] This calculation only affects V2 and subsequent cycles.

[0528] 6.7.6.5 Consistency Verification Mechanism

[0529] Before writing back V2 data, synchronize with the archive unit and perform the following:

[0530] (1) Version conflict check confirms that the current version is still V2 to prevent concurrent writes;

[0531] (2) Verify the consistency of the cumulative amount to confirm that the frozen snapshot is consistent with the book record;

[0532] (3) Verify the legality of the status. The "adjustment in progress" status can be legally converted back to "accrual in progress".

[0533] Write-back will only be performed if all validations pass.

[0534] 6.7.6.6 Write-back and Restore

[0535] After the write-back is complete, the directory unit is updated as follows:

[0536] (1) Accumulated depreciation: 48,000 (historically frozen)

[0537] (2) Remaining lifespan: 36

[0538] (3) New book value: 90,000

[0539] (4) New Moon Depreciation: 2,500

[0540] (5) Lifecycle status: Accruing

[0541] (6) Current version: V2

[0542] 6.7.6.7 Automatic progression in subsequent cycles

[0543] At the end of the 25th month:

[0544] (1) The system performs a depreciation of 2,500 based on V2;

[0545] (2) Accumulated depreciation is updated to 50,500;

[0546] (3) The carrying amount was updated to 87,500;

[0547] (4) Status is being maintained and accrued.

[0548] Subsequent cycles are all executed based on V2.

[0549] Enhanced technical effect explanation: Through the above mechanism, the present invention achieves the following:

[0550] (1) Historical periodic data cannot be retrospectively modified;

[0551] (2) Automatic reconfiguration in future cycles after parameter changes;

[0552] (3) Supports version control;

[0553] (4) Prevent concurrent write conflicts;

[0554] (5) Ensure data consistency across cycles.

[0555] This mechanism differs from the traditional method of changing parameters by overwriting historical data or manually adjusting them.

[0556] 6.7.7 Example of Concurrency Conflict and Compensation Mechanism

[0557] The following example illustrates the conflict detection, version isolation, compensation rollback, and recalculation mechanisms of this invention under concurrent conditions.

[0558] 6.7.7.1 Concurrency Scenario Settings

[0559] The dynamic dimensions of a certain fixed asset's current catalog unit are as follows:

[0560] (1) Accumulated depreciation: RMB 60,000

[0561] (2) Remaining lifespan: 24 months

[0562] (3) Book value: RMB 40,000

[0563] (4) Lifecycle status: Depreciating

[0564] (5) Dynamic dimension version number: V3

[0565] Within the same time window, the scheduling unit captures the following two events almost simultaneously:

[0566] (1) Periodic event: Depreciation accrual in the 37th month

[0567] (2) Value change event: Additional capitalized expenditure of RMB 10,000

[0568] Two events enter the event queue, forming a concurrent processing scenario.

[0569] 6.7.7.2 Event Locking Mechanism

[0570] The scheduling unit executes the following upon receiving an event:

[0571] (1) Add a lifecycle state lock to the directory unit;

[0572] (2) Read the current dynamic dimension version number V3;

[0573] (3) Add the two events to the event queue;

[0574] (4) Sort according to the preset priority rules:

[0575] (5) Business parameter change events have a higher priority than periodic accrual events.

[0576] Therefore, value change events take precedence.

[0577] 6.7.7.3 First Event Execution (Value Change) The system executes the following steps:

[0578] (1) Freeze the dynamic dimension snapshot of the initial version V3;

[0579] (2) Generate the target version number V4, and build a new dynamic dimension under V4 (do not change the currently effective version number before writing back);

[0580] (3) Construct a new dynamic dimension based on the newly added capitalized amount;

[0581] (4) Reconstruct the depreciation benchmark for future cycles;

[0582] Before writing back, the following are executed: (1) Version consistency verification (verify that the starting version number is V3 and the effective version number of the current directory unit is still V3, and confirm that the target version number for this write-back is V4, so as to prevent version drift caused by concurrent writing); (2) Lifecycle status validity verification.

[0583] After successful verification, the data is written back, and the effective version number of the directory unit is updated to V4.

[0584] 6.7.7.4 Second Event Conflict Detection

[0585] When the periodic accrual event begins execution, the system detects:

[0586] (1) The version number read by this event is V3;

[0587] (2) The current directory unit version number has been updated to V4;

[0588] The system determined that the event was a version conflict.

[0589] 6.7.7.5 Conflict Resolution Strategies

[0590] The system executes the following compensation process:

[0591] (1) Suspend the calculation of accrual for the current period;

[0592] (2) Discard calculation results based on V3;

[0593] (3) Re-read the current version V4 of the directory unit;

[0594] (4) Re-execute cycle calculation based on the dynamic dimensions of V4;

[0595] (5) Generate a new structured instruction object;

[0596] This mechanism avoids:

[0597] (1) Recurring depreciation based on the old version;

[0598] (2) Accrued incorrectly before the change in value;

[0599] (3) Duplicate amount or lifecycle status rollback.

[0600] 6.7.7.6 Reentry Detection Mechanism

[0601] If the same periodic event is submitted repeatedly due to network latency or system retries, the system will execute:

[0602] (1) Check whether the current lifecycle status has been processed for this cycle;

[0603] (2) Verify whether the corresponding structured instruction record already exists for the verification period identifier;

[0604] If it already exists, refuse to execute it again.

[0605] This mechanism ensures that:

[0606] (1) Only one valid accrual record is generated in the same period;

[0607] (2) Avoid repeated write-backs and repeated cost confirmations.

[0608] 6.7.7.7 Compensation and Rollback Mechanism

[0609] If an exception occurs during the write-back process (e.g., an error is returned by the external general ledger system), the system will execute:

[0610] (1) Roll back dynamic dimension updates that have not yet been committed;

[0611] (2) Restore to the most recent valid version;

[0612] (3) Retain error event logs;

[0613] (4) Wait for re-triggering;

[0614] This compensation mechanism ensures that:

[0615] (1) No half-update state is generated;

[0616] (2) No rollback anomalies occur in the lifecycle state;

[0617] (3) The dynamic dimension always maintains consistency.

[0618] 6.7.7.8 Technical Effect Description

[0619] Through the above-described concurrent conflict detection and compensation mechanism, this invention achieves the following:

[0620] (1) Version isolation in the case of multiple concurrent events;

[0621] (2) Conflict identification and recalculation mechanism based on version number;

[0622] (3) Prevent duplicate accruals and status rollback;

[0623] (4) Ensure that a directory unit has only one valid state at any given time;

[0624] (5) Implement safe rollback and retry control under abnormal conditions;

[0625] This ensures that cross-cycle automatic calculations remain stable, consistent, and recoverable even in high-concurrency environments.

Claims

1. A cross-cycle automatic calculation method based on a two-dimensional data model and an event-driven lifecycle state machine, applied to an information processing system, characterized in that, include: Construct a directory unit to establish a two-dimensional data structure for the target object. The two-dimensional data structure includes a static dimension layer that remains unchanged under periodic events and is updated only when a business event is triggered, and a dynamic dimension layer for storing the dynamic dimension layer that is updated as periodic events, business events or abnormal events progress. The dynamic dimension layer includes at least a lifecycle state and a dynamic dimension version number. An independent binding channel is established between the directory unit and the rule engine, including a static binding channel, which is used to transmit the static dimension layer data to the rule engine to realize rule selection and calculation path determination; And a dynamic binding channel, used to transfer the dynamic dimension layer data between the directory unit and the rule engine and lifecycle state machine, and to support write-back updates and version control; The scheduling unit receives and manages the event queue, which includes at least a periodic event queue and a business event queue. The scheduling unit prioritizes the events entering the queue and applies a lifecycle state lock to the target object, so that the target object is only in one lifecycle state at any given time. Under the trigger of the scheduling unit, the lifecycle state machine reads the current snapshot of the dynamic dimension layer and performs state transition validity verification. Based on the preset state transition mapping table, it completes the lifecycle state transition and generates the state transition result. The rule engine performs cycle calculations based on the static dimension layer data, the dynamic dimension layer data, and the current lifecycle state, and generates calculation results. Based on the calculation results, the state transition results, and the account mapping rules in the rule base, a structured accounting instruction is generated, which includes at least an account identifier and an amount. The synchronization and archiving unit receives authoritative accounting results returned by the external general ledger system and performs at least version consistency verification and conflict detection before writing back to the directory unit. When the verification passes, the dynamic dimension layer is updated and a new dynamic dimension version number is generated and written back to the directory unit. At the same time, the structured accounting instructions, formal accounting entries and lifecycle change records are archived to ensure data consistency between the directory unit, rule engine and state machine unit, account unit and synchronization and archiving unit.

2. A cross-cycle automatic calculation system based on a dual-dimensional data model and an event-driven lifecycle state machine, characterized in that, include: The directory unit is used to build and maintain a two-dimensional data structure for the target object, including a static dimension layer and a dynamic dimension layer. The dynamic dimension layer at least includes a lifecycle state and a dynamic dimension version number. The rule engine and state machine unit includes a dimension parser, a rule selector, a state machine controller, a legality verification module, a calculation engine, and an accounting instruction generator. It is used to perform rule matching, lifecycle state advancement, periodic calculation, and generate structured accounting instructions based on static and dynamic dimension layers. The scheduling unit is used to receive periodic events, business events, or abnormal events and perform event priority sorting, lifecycle state locking, state conflict detection, and processing flow coordination. The account unit is used to receive the structured accounting instructions, generate formal accounting entries to write into the external general ledger system, and output execution confirmation and result verification information; The synchronization and archiving unit is used to receive authoritative accounting results from external general ledger systems and perform version consistency checks, conflict detection, and write-back control. When the checks pass, it updates the dynamic dimension layer, generates a new version number, and writes it back to the directory unit. At the same time, it archives structured accounting instructions, formal accounting entries, and lifecycle change records. The directory unit establishes data interaction connections with the rule engine and state machine unit through static binding channels and dynamic binding channels, respectively, to achieve cross-cycle state advancement and data consistency control.

3. The method according to claim 1, characterized in that, The static dimension layer includes at least one of the following: original value, useful life or benefit period, depreciation / amortization method, object category, service period, and supplier information.

4. The method according to claim 1, characterized in that, The dynamic dimension layer includes at least one of the following: accumulated depreciation / accumulated amortization / accumulated consumption, remaining useful life or remaining service period, book value, consumption records, lifecycle status, and dynamic dimension version number.

5. The method according to claim 1, characterized in that, The lifecycle state machine includes multiple lifecycle states and a termination state.

6. The method according to claim 1, characterized in that, The events include at least one of the following: periodic trigger events, consumption events, value change events, lifespan change events, pause events, recovery events, disposal events, and abnormal events.

7. The method according to claim 1, characterized in that, In the state advancement step, the lifecycle state machine determines the target state by looking up the state transition mapping table, and only executes the state transition when the validity check passes.

8. The method according to claim 1, characterized in that, The verification in the closed-loop consistency verification and write-back steps includes at least one of the following: book value consistency verification, lifecycle state consistency verification, version conflict detection, and reentrancy detection.

9. The method according to claim 1, characterized in that, When a value change event or a lifetime change event occurs, a cross-cycle freeze and recalculation mechanism is executed, including freezing the dynamic dimension snapshot before the change and marking it as a read-only historical version, incrementing the dynamic dimension version number, building a new future cycle calculation benchmark under the new version, and reconstructing the future cycle calculation path based on the remaining lifetime.

10. The method according to claim 1, characterized in that, The structured accounting instructions further include at least one of period identifier, lifecycle status identifier, and rule source identifier.

11. The system according to claim 2, characterized in that, The scheduling unit includes an event priority sorting module, a lifecycle state locking module, a state conflict detection module, and a transaction compensation module, and based on preset priority rules, it prioritizes business parameter change events over periodic accrual events.

12. The system according to claim 2, characterized in that, The rule selector in the rule engine and state machine unit reads calculation rules and asset-fee account mapping rules from the rule base based on object category, event type, and current lifecycle state to determine the debit account identifier and credit account identifier in the structured accounting instruction.

13. The system according to claim 2, characterized in that, The synchronization and archiving unit includes a result receiver, a version consistency checker, a conflict detector, a rollback controller, a dynamic dimension updater, a lifecycle updater, a dimension writer, and an archiver. When the version consistency check fails or a conflict is detected, the write-back is stopped and the rollback control is triggered to restore the state to the most recent valid version.

Images