A financial management system, method, electronic device and storage medium

Abstract

The present disclosure provides a financial management system, method, electronic device and storage medium, the system comprising: a visual configuration platform, a financial domain meta-model library, a dynamic model-driven engine, a financial special rule engine and a data persistence layer, wherein the visual configuration platform is configured to provide a graphical user interface to receive user configuration operations for a target financial business scenario and generate a business scenario configuration data set; the financial domain meta-model library is configured to store predefined financial domain metadata and provide financial semantic constraints and data mapping basis for configuration operations in the visual configuration platform; the dynamic model-driven engine is configured to receive the business scenario configuration data set and dynamically generate or update a runtime component corresponding to the target financial business scenario based on the financial domain meta-model library. According to the embodiments of the present disclosure, the flexibility and professionalism of the financial business construction and operation can be improved, and the technical threshold of the financial domain business configuration is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of financial management technology, and in particular to a financial management system, method, electronic device and storage medium. Background Technology

[0002] With the deepening of digital transformation, corporate financial management faces challenges such as changing business processes, stringent compliance requirements, and complex system integration. In current corporate operations, financial management software is a core tool. Currently, the solutions on the market mainly fall into two categories:

[0003] 1. Traditional packaged accounting software: such as Yonyou and Kingdee. This type of software exists in the form of pre-compiled code, and its functional modules are relatively fixed, forming a "black box" system. When enterprises need to change processes or add new functions, they must undergo secondary development by the vendor or technical personnel, that is, modify the underlying source code, recompile, and deploy. This process is not only time-consuming and labor-intensive, but also poses risks to the stability and security of the system.

[0004] 2. General-purpose low-code platforms: such as OutSystems and Mendix. These platforms provide a visual development environment that allows users to build applications by dragging and dropping components. However, their generality becomes a drawback when applied to the financial field. The components provided by these platforms are basic and lack financial semantics. To build a complete financial management system that complies with accounting standards, developers still need to manually write a large amount of business logic code on top of these general-purpose components, which does not fundamentally lower the technical threshold in the financial field.

[0005] While the aforementioned existing technologies offer general visualization and configuration capabilities, they reveal the following inherent limitations when applied to highly specialized financial fields:

[0006] (1) Lack of domain model and high professional threshold: General low-code platforms do not provide a unified data model and constraint description for core financial concepts. When configuring, financial personnel need to break down professional financial logic into a large number of basic data fields and rules, making the configuration process extremely cumbersome and not actually lowering the threshold for financial experts to use.

[0007] (2) The rule engine is disconnected from the financial logic: the general rule engine does not support the rule patterns and integrity constraints specific to finance, and cannot generate accounting vouchers that conform to the double-entry bookkeeping method natively. To achieve these functions, it is still necessary to write the underlying script, which violates the original intention of low code. Summary of the Invention

[0008] This disclosure provides a financial management system, method, electronic device, and storage medium to solve the problems of fixed functions and the need for secondary development in traditional packaged financial software, as well as the lack of domain models, high professional thresholds, and disconnect between rule engines and financial logic when general low-code platforms are applied to the financial field.

[0009] Firstly, this disclosure provides a financial management system, including a visual configuration platform, a financial domain meta-model library, a dynamic model-driven engine, a financial-specific rule engine, and a data persistence layer, wherein...

[0010] The visual configuration platform is used to provide a graphical user interface to receive configuration operations from users for target financial business scenarios and generate a set of business scenario configuration data.

[0011] The financial domain meta-model library is used to store predefined financial domain metadata and to provide financial semantic constraints and data mapping basis for configuration operations in the visualization configuration platform. The metadata includes at least a subject system model, a voucher model and an accounting dimension model.

[0012] The dynamic model driving engine is used to receive the business scenario configuration data set and dynamically generate or update the runtime components corresponding to the target financial business scenario based on the financial domain metamodel library.

[0013] The dedicated financial rules engine is used to parse and execute the financial rules configured in the visualization configuration platform. The financial rules include pre-configured trigger points. When the dedicated financial rules engine detects that the trigger points are met during business operations, it executes the corresponding rules to generate accounting vouchers that comply with the double-entry bookkeeping method.

[0014] The data persistence layer is used to store the business scenario configuration data set, business document data generated during business operation, and accounting voucher data generated by the financial rule engine.

[0015] Furthermore, the visual configuration platform includes a domain-specific form designer, a process designer, and a financial rule designer, wherein...

[0016] The domain-specific form designer is used to provide financial semantic controls associated with the subject system model and accounting dimension model stored in the financial domain metamodel library, so as to construct the business document interface;

[0017] The process designer is used to define the approval process for financial transactions;

[0018] The financial rule designer is used to configure the financial rules.

[0019] Furthermore, the financial rule designer is specifically used for:

[0020] Configure the trigger points of the financial rules. The trigger points include process node event trigger points and / or document event trigger points. The process node event trigger points include process node identifiers and node status change conditions. The document event trigger points include at least one event type among document saving, submission, and withdrawal.

[0021] Configure the execution conditions and execution actions of the financial rules, wherein the execution action is to generate accounting vouchers through a visual voucher template;

[0022] The visual voucher template reuses the structure defined by the voucher model, supports configuring debit and credit directions for each entry in the accounting voucher, selecting accounting subjects from the subject system model, binding amounts to business document fields, and attaching at least one accounting dimension from the accounting dimension model to at least one entry.

[0023] Furthermore, the visualization configuration platform also includes a report designer, which is used to configure the data retrieval scope and display format of financial statements. The data retrieval scope is based on the subject system model and the accounting dimension model to bind the subject range and dimension fields.

[0024] Furthermore, the subject system model is a tree structure, with each node corresponding to an accounting subject and each accounting subject containing subject code, subject name, subject level, and balance direction attributes; the subject selector control in the visualization configuration platform displays the subject hierarchy based on the tree structure in a tree drop-down or tree selection interface, and limits the selectable levels according to the subject level attributes;

[0025] The voucher model defines the structure of the voucher header and voucher rows, and is reused by the visual voucher template in the financial rule designer;

[0026] The accounting dimension model allows users to select or customize accounting dimensions, which include at least department, project, and employee dimensions.

[0027] Furthermore, the dynamic model-driven engine is also used to perform online migration and compatibility adaptation of the existing data model corresponding to the target financial business scenario when the configuration data set of the business scenario changes, so that the changes take effect without interrupting business operations.

[0028] Furthermore, the financial rule engine has a built-in financial transaction characteristic verification capability. When generating accounting vouchers, it performs a mandatory debit-credit balance verification. If the verification fails, it prevents the generation of accounting vouchers and outputs the verification result.

[0029] Secondly, this disclosure provides a financial management method applied to the financial management system described in the first aspect, the method comprising:

[0030] By defining and storing metadata in the financial domain, the financial domain meta-model library is initialized. The metadata includes at least a subject system model, a voucher model, and an accounting dimension model.

[0031] The platform uses a graphical user interface to receive configuration operations from users for target financial business scenarios and generates a set of business scenario configuration data. The financial domain meta-model library provides financial semantic constraints and data mapping basis for the configuration operations.

[0032] The dynamic model-driven engine receives the set of configuration data for the business scenario and dynamically generates or updates the runtime components corresponding to the target financial business scenario based on the financial domain meta-model library.

[0033] The financial rules configured in the visualization configuration platform are parsed and executed by the financial rule engine. When a trigger point is detected during business operation, the corresponding rule is executed to generate accounting vouchers that comply with the double-entry bookkeeping method. The financial rules include the pre-configured trigger points.

[0034] The data persistence layer stores the set of configuration data for the business scenario, the business document data generated during business operation, and the accounting voucher data generated by the financial rule engine.

[0035] Furthermore, the receiving of user configuration operations for the target financial business scenario specifically includes at least one of the following:

[0036] The system receives a business document interface constructed by a user through a domain-specific form designer, wherein the domain-specific form designer provides financial semantic controls associated with the account system model and accounting dimension model stored in the financial domain meta-model library.

[0037] Receive approval processes for financial transactions defined by users through the process designer;

[0038] Receive the financial rules configured by the user through the financial rule designer;

[0039] The system receives the data retrieval criteria and display format of financial statements configured by the user through the report designer. The data retrieval criteria are based on the subject system model and the accounting dimension model, which bind the subject range and dimension fields.

[0040] Furthermore, the financial rules configured by the user through the financial rule designer specifically include:

[0041] The system receives the trigger points of the financial rules configured by the user. The trigger points include process node event trigger points and / or document event trigger points. The process node event trigger points include process node identifiers and node status change conditions. The document event trigger points include at least one event type among document saving, submission, and withdrawal.

[0042] The system receives the execution conditions and execution actions of the financial rules configured by the user, wherein the execution action is to generate accounting vouchers through a visual voucher template.

[0043] The visual voucher template reuses the structure defined by the voucher model, supports configuring debit and credit directions for each entry in the accounting voucher, selecting accounting subjects from the subject system model, binding amounts to business document fields, and attaching at least one accounting dimension from the accounting dimension model to at least one entry.

[0044] Furthermore, the method also includes:

[0045] When the configuration data set of the business scenario changes, the dynamic model-driven engine is used to perform online migration and compatibility adaptation of the existing data model corresponding to the target financial business scenario, so that the changes take effect without interrupting business operations.

[0046] Furthermore, the method also includes:

[0047] By utilizing the built-in financial transaction feature verification capability of the financial rule engine, a mandatory debit-credit balance verification is performed when generating accounting vouchers. If the verification fails, the generation of accounting vouchers is prevented, and the verification result is output.

[0048] Thirdly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the financial management method described in the second aspect above.

[0049] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the financial management method described in the second aspect above.

[0050] The financial management system, method, electronic device, and storage medium provided in this disclosure, through a technical solution combining a visual configuration platform, a financial domain meta-model library, a dynamic model-driven engine, a financial-specific rule engine, and a data persistence layer, can provide graphical configuration capabilities for target financial business scenarios. Relying on predefined financial domain metadata, it achieves financial semantic constraints and data mapping support in the configuration process, dynamically generating and driving runtime components for corresponding business scenarios. Simultaneously, based on the financial-specific rule engine, it automatically executes rules at preset trigger points during business operation and generates accounting vouchers compliant with double-entry bookkeeping, uniformly completing the persistent management of various business and configuration data. This enhances the flexibility and professionalism of financial business construction and operation, lowers the technical threshold for financial domain business configuration, and deeply adapts rule execution to financial professional logic. It allows for rapid construction and operation of financial business scenarios without relying on extensive low-level code development. This solves the problems of traditional packaged financial software's fixed functions and the need for secondary development, as well as the lack of domain models, high professional thresholds, and disconnect between rule engines and financial logic when general low-code platforms are applied to the financial domain. Attached Figure Description

[0051] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings:

[0052] Figure 1 A block diagram of a financial management system provided in an embodiment of this disclosure;

[0053] Figure 2 A block diagram of another financial management system provided as an embodiment of this disclosure;

[0054] Figure 3 A schematic diagram of the interface of the financial rule designer provided in this embodiment of the disclosure;

[0055] Figure 4 This is a schematic diagram of the structure of the subject system model provided in the embodiments of this disclosure;

[0056] Figure 5 A flowchart of a financial management method provided in this disclosure embodiment;

[0057] Figure 6 A flowchart of another financial management method provided in this disclosure embodiment;

[0058] Figure 7 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0059] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0060] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0061] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0062] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0063] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0064] Figure 1 This is a block diagram of a financial management system provided as an embodiment of the present disclosure. (Refer to...) Figure 1 The system includes a visual configuration platform 100, a financial domain meta-model library 200, a dynamic model-driven engine 300, a financial-specific rule engine 400, and a data persistence layer 500.

[0065] The visual configuration platform 100 is used to provide a graphical user interface to receive configuration operations from users for target financial business scenarios and generate a set of business scenario configuration data.

[0066] The financial domain meta-model library 200 is used to store predefined financial domain metadata and to provide financial semantic constraints and data mapping basis for configuration operations in the visualization configuration platform 100. The metadata includes at least the subject system model 210, the voucher model 220 and the accounting dimension model 230.

[0067] The dynamic model driving engine 300 is used to receive the business scenario configuration data set and dynamically generate or update the runtime components corresponding to the target financial business scenario based on the financial domain metamodel library 200.

[0068] The financial rule engine 400 is used to parse and execute the financial rules configured in the visualization configuration platform 100. The financial rules include pre-configured trigger points. When the financial rule engine 400 detects that the trigger points are met during business operation, it executes the corresponding rules to generate accounting vouchers that comply with the double-entry bookkeeping method.

[0069] The data persistence layer 500 is used to store the business scenario configuration data set, business document data generated during business operation, and accounting voucher data generated by the financial special rule engine 400.

[0070] Specifically, the visual configuration platform 100 serves as the entry point for user interaction with the system, providing a graphical user interface that supports user configuration operations for different financial business scenarios (such as employee expense reimbursement, purchase payments, and expense accruals). These configuration operations may include, but are not limited to, defining the format of business documents, arranging business processes, setting financial rules, and customizing financial reports. The visual configuration platform 100 generates corresponding business scenario configuration data sets by receiving user drag-and-drop, selection, and input operations. These data sets describe the various elements of the business scenario in a structured form.

[0071] Specifically, the financial domain metamodel library 200 pre-stores standardized metadata specific to the financial domain. This metadata covers the core basic elements of financial accounting. When users perform configuration operations, it automatically provides constraints and data mapping guidance at the financial semantic level, avoiding problems such as data definitions and field associations that do not conform to financial standards, and ensuring the professionalism and compliance of the configuration content.

[0072] Specifically, the dynamic model-driven engine 300, as the core driving component for business scenario operation, receives the business scenario configuration data set and, in conjunction with the metadata constraints in the financial domain meta-model library 200, automatically completes the creation and updating of runtime components. The runtime components generated by the dynamic model-driven engine 300 include at least: database table structure and migration scripts, business object APIs, front-end page interaction logic, process definitions and task table structure, and report query interfaces, ensuring that the configured financial business scenario can run directly and stably. For example, when a user configures a new expense report, the engine automatically creates the corresponding business table in the database, generates the corresponding data access interface, and updates the front-end page to display the new form.

[0073] Specifically, the financial rule engine 400 has the ability to parse, monitor and execute financial rules. It can accurately identify the preset financial rules and trigger points in the visual configuration platform 100, monitor the fulfillment of trigger points in real time throughout the entire financial business operation process, and immediately execute the corresponding rule logic once the trigger conditions are detected, automatically generating accounting vouchers that comply with the double-entry bookkeeping law without manual intervention.

[0074] Specifically, the data persistence layer 500 adopts a standardized storage mechanism to uniformly and securely store the business scenario configuration data set, various business document data generated during business operation (such as expense reports, payment slips, etc.), and accounting voucher data generated by the financial dedicated rule engine 400, while ensuring the integrity, consistency and traceability of the data, providing reliable data support for subsequent financial audits, data queries and business reviews.

[0075] In some embodiments, such as Figure 2 As shown, the visual configuration platform 100 includes a domain-specific form designer 110, a process designer 120, and a financial rule designer 130, wherein...

[0076] The domain-specific form designer 110 is used to provide financial semantic controls associated with the subject system model 210 and accounting dimension model 230 stored in the financial domain meta-model library 200, so as to construct a business document interface.

[0077] The process designer 120 is used to define the approval process for financial transactions;

[0078] The financial rule designer 130 is used to configure the financial rules.

[0079] Specifically, the visualization configuration platform 100 achieves full-process visualization configuration of "interface-process-rules" in financial business scenarios through the collaborative operation of three types of dedicated designers: a domain-specific form designer 110, a process designer 120, and a financial rule designer 130. These designers operate independently yet are interconnected, ensuring efficiency and professionalism in the configuration process. The domain-specific form designer 110, based on the subject system model 210 and accounting dimension model 230 in the financial domain meta-model library 200, pre-encapsulates various financial semantic controls, such as subject selectors, amount calculation formula boxes, and accounting dimension attachers. Users do not need to manually design basic controls; they can quickly construct business document interfaces that meet financial business needs and possess professional semantic constraints through simple operations such as dragging and selecting, adapting to the document requirements of different financial business scenarios. The process designer 120, based on the BPMN standard, allows users to flexibly define approval processes for various financial transactions by dragging and dropping process nodes, setting node attributes, and configuring flow conditions. For example, users can set the handler for each approval node, approval time limits, rejection conditions, and jump logic, adapting to the organizational structure and approval standards of different enterprises. The financial rule designer 130 provides users with a visual rule configuration interface, allowing them to flexibly configure various financial rules according to financial business logic, including rule triggering conditions, execution logic, and output results, providing a foundation for the automatic execution of subsequent financial rules and the automatic generation of accounting vouchers.

[0080] In some embodiments, the financial rule designer 130 is specifically used for:

[0081] Configure the trigger points of the financial rules. The trigger points include process node event trigger points and / or document event trigger points. The process node event trigger points include process node identifiers and node status change conditions. The document event trigger points include at least one event type among document saving, submission, and withdrawal.

[0082] Configure the execution conditions and execution actions of the financial rules, wherein the execution action is to generate accounting vouchers through a visual voucher template;

[0083] The visual voucher template reuses the structure defined by the voucher model 220, supports configuring debit and credit directions for each entry of the accounting voucher, selecting accounting subjects from the subject system model 210, binding amounts to business document fields, and attaching at least one accounting dimension from the accounting dimension model 230 to at least one entry.

[0084] Specifically, the financial rule designer 130 provides refined rule configuration functions, supporting users to configure each core element of financial rules step by step, ensuring that the rules can accurately match actual financial business needs. In the trigger point configuration stage, users can flexibly select one or a combination of process node event trigger points and document event trigger points according to business scenario requirements. For example, process node event trigger points can be set to node status change scenarios such as "approval node passed" and "approval node rejected," while document event trigger points can be set to specific document operation scenarios such as "document saved successfully," "document submitted for review," and "document withdrawn for modification." At the same time, detailed parameters such as process node identifiers and node status change conditions can be precisely configured to ensure the accuracy of trigger points. In the configuration of execution conditions and actions, various constraint rules can be set according to actual business needs, such as "reimbursement amount is greater than 1,000 yuan" and "payment method is bank transfer". Only when the execution conditions are met will subsequent execution actions be triggered. The execution actions focus on the automatic generation of accounting vouchers. The voucher template enables the rapid configuration and generation of vouchers. The voucher template reuses the voucher header and voucher line structure predefined by the voucher model 220. Users can configure the debit and credit directions for each entry of the accounting voucher in the template, select the corresponding accounting subject from the subject system model 210, and bind the entry amount to specific fields in the business document (such as reimbursement amount, payment amount, etc.) to achieve automatic filling of the amount. In addition, corresponding accounting dimensions can be attached to at least one entry, such as attaching accounting dimensions such as "department" and "project" to the management expense entry to ensure the accuracy of accounting voucher accounting.

[0085] For example, Figure 3 A schematic diagram of the interface of the financial rule designer 130 is shown, demonstrating how a user can configure a rule that "triggers at a specific trigger point and automatically generates accounting vouchers" without coding. The rule configuration includes: rule metadata, trigger point / condition expression, and voucher template mapping and validation options configuration based on voucher model 220. Detailed explanations are as follows:

[0086] 1) Rule Meta Information Area: Used to input basic information such as rule name, associated business document type, rule version / status.

[0087] 2) Trigger Condition Configuration Area: Used to configure the trigger points (TriggerPoints) and their condition expressions for rules. A trigger point must include at least:

[0088] (a) Process node event trigger point: consists of the node identifier (NodeID) generated by the process designer 120 and the node status change conditions, such as "NodeID=financial review, status=passed";

[0089] (b) Document event trigger points: such as save, submit, withdraw, etc. After selecting a trigger point, the user can further graphically combine the trigger conditions using drop-down selectors and logical operators (AND / OR), such as "when [Expense Form.Current Status] equals [Approved]".

[0090] 3) Execution Action Configuration Area (Generate Certificates):

[0091] This area reuses and presents the structure defined by voucher model 220 in a graphical way using a "voucher template", including voucher header fields (such as voucher date, summary, source document, etc.) and voucher line fields (such as direction, account, amount, accounting dimension, etc.).

[0092] The "multiple entries" configured by the user in this area correspond to the voucher line set in voucher model 220; each entry includes at least:

[0093] ① Journal entry direction (debit / credit);

[0094] ②Accounting Subjects: Selected via the “Subject Selector” control, which directly connects to the subject system model 210 and displays the nodes of the subject tree at all levels in the form of a tree drop-down menu / tree pop-up window (the allowed levels can be configured, for example, only the last level subject can be selected), and supports search filtering;

[0095] ③ Amount mapping: Bind the amount to a field in the business document (such as

Expense Report.Total Amount

[0096] ④ Attaching Accounting Dimensions: Attach one or more accounting dimensions to entries using the "Dimension Attacher" control. This control directly connects to the accounting dimension model 230 (such as department, employee, project, etc.).

[0097] 4) Advanced Options Area: Used to configure the verification / transaction strategy options for the actions to be performed. Figure 3 The "Automatic Loan-to-Debt Balance Validation" option shown indicates that this area offers an optional configuration item. When selected, the rules engine will force a checkmark check to ensure the total loan and borrow amounts are equal when generating vouchers; otherwise, generation will fail and the validation result will be returned. (Other implementations may also include options such as mandatory dimension validation and amount precision strategies.)

[0098] 5) Operation button: Used to save drafts or publish rules; after publication, the rule configuration data and trigger point information are written to the data persistence layer 500 for runtime triggering and execution.

[0099] In some embodiments, such as Figure 2As shown, the visualization configuration platform 100 also includes a report designer 140, which is used to configure the data retrieval scope and display format of financial statements. The data retrieval scope is based on the subject system model 210 and the accounting dimension model 230 to bind the subject range and dimension fields.

[0100] Specifically, the report designer 140 provides a visual report configuration interface. Users can configure financial reports through the following steps: First, select a data source, which may include voucher datasets, business document datasets, etc. in the data persistence layer 500; then bind the data retrieval scope, for example, limiting the subject range to "Management Expenses - Travel Expenses" (selected from the subject system model 210), and set the grouping dimension such as "Department" (selected from the accounting dimension model 230); next, configure indicators, such as summing the amount field; then set filtering conditions, such as limiting the period to "Expense Report.Period in which the expense date falls"; finally, configure the report layout, including row and column layout, total rows, drill-down details, etc. After configuration, the report definition is stored as configuration data, and the dynamic model driving engine 300 generates the report query interface and front-end presentation logic according to the definition, allowing users to view the report in real time and support drill-down to detailed data.

[0101] In some embodiments, the subject system model 210 is a tree structure, where each node corresponds to an accounting subject and each accounting subject includes a subject code, subject name, subject level, and balance direction attribute; the subject selector control in the visualization configuration platform 100 displays the subject hierarchy based on the tree structure in a tree drop-down or tree selection interface, and limits the selectable levels according to the subject level attribute;

[0102] The voucher model 220 defines the structure of the voucher header and voucher rows, and is reused by the visual voucher template in the financial rule designer 130;

[0103] The accounting dimension model 230 allows users to select or customize accounting dimensions, which include at least the dimensions of department, project, and employee.

[0104] Specifically, the subject system model 210 adopts a tree structure, which clearly presents the hierarchical relationship of accounting subjects. It subdivides subjects level by level from the first-level subject to the last-level subject, with each tree node uniquely corresponding to an accounting subject. Each accounting subject contains complete core attributes, such as a subject code for unique identification, a subject name for intuitively representing the subject's meaning, a subject level for distinguishing the subject's hierarchy (e.g., first-level subject, second-level subject, etc.), and a balance direction for clarifying the subject's debit / credit attribute (e.g., the balance direction for asset subjects is debit, and the balance direction for liability subjects is credit). The corresponding subject selector control, based on this tree structure, displays all accounting subjects and their hierarchical relationships to the user in the form of a tree-shaped drop-down menu or a tree-shaped selection interface. It also limits the selectable levels based on the subject level attributes; for example, it can be set to only allow selection of the last-level subject for operations such as voucher entry and report data retrieval, ensuring the standardization and accuracy of subject selection. Figure 4 The diagram illustrates the structure of the subject system model 210, revealing its internal data structure. This hierarchical, attribute-rich tree model is the cornerstone for achieving dynamic configuration and financial professionalism, as detailed below:

[0105] (1) The model is a clear tree-like hierarchical structure that reflects the subordinate relationship of accounting subjects.

[0106] (2) Each node represents an accounting subject and includes key attributes such as subject code (e.g., 1001), subject name (e.g., cash on hand), subject level, and balance direction (debit / credit).

[0107] (3) It shows the parent-child relationship between the subjects. For example, “Assets (1)” is a first-level subject, “Cash and Cash Equivalents (1001)” is a second-level subject, and “Bank Deposits (100102)” is a third-level subject.

[0108] (4) This structured storage method enables the subject selector to be presented to the user in the form of a tree drop-down menu, and ensures the consistency and accuracy of all subject references.

[0109] Specifically, voucher model 220 predefines standardized voucher header structures (such as voucher date, voucher number, summary, and number of attachments) and voucher line structures (such as entry number, debit / credit direction, account, and amount). Voucher lines can be associated with multiple accounting dimension instances. This structure can be directly reused by the visual voucher template in the financial rule designer 130, eliminating the need for users to repeatedly define voucher structures and improving the efficiency of voucher configuration and generation.

[0110] Specifically, the accounting dimension model 230 provides flexible accounting dimension configuration capabilities, allowing users to select from preset accounting dimensions, such as department, project, and employee dimensions, or to customize accounting dimensions (such as customer, supplier, and product) according to the actual financial accounting needs of the enterprise. Various accounting dimensions can be flexibly attached to accounting voucher entries, business documents, and other data to achieve refined accounting and analysis of financial data.

[0111] In some embodiments, the dynamic model-driven engine 300 is further configured to perform online migration and compatibility adaptation on the existing data model corresponding to the target financial business scenario when the business scenario configuration data set changes, so that the changes take effect without interrupting business operations.

[0112] Specifically, the dynamic model-driven engine 300 possesses flexible configuration change adaptation capabilities. When a user modifies, adds, or deletes configuration content for a target financial business scenario, resulting in changes to the business scenario configuration data set, the engine does not need to stop the current business operation and can receive the changed configuration data set in real time. Simultaneously, the dynamic model-driven engine 300 automatically identifies and analyzes the existing data model (including database table structure, business objects, process definitions, etc.) corresponding to the target financial business scenario, determines the impact of the changes on the existing data model, and then performs online migration and compatibility adaptation operations, such as incrementally modifying the database table structure, updating business object APIs, and synchronously adjusting process definitions. During the migration and adaptation process, the engine automatically handles data compatibility issues, ensuring that the original business data is not lost or damaged, and that the changed configuration content takes effect quickly, achieving "zero-downtime" updates for financial business scenarios. This not only ensures the continuity of business operations but also improves the efficiency of configuration changes, avoiding the drawbacks of traditional financial software changes requiring secondary development and interrupting business operations.

[0113] In some embodiments, the financial rule engine 400 has a built-in financial transaction feature verification capability. When generating accounting vouchers, it performs a mandatory debit-credit balance verification. If the verification fails, it prevents the generation of accounting vouchers and outputs the verification result.

[0114] Specifically, the financial rule engine 400, tailored to the specific characteristics of financial transactions, incorporates professional financial transaction feature verification capabilities, focusing on compliance verification during the accounting voucher generation process. Mandatory debit / credit balance verification is one of its core verification components. During the execution of rules and the generation of accounting vouchers, the financial rule engine 400 performs real-time debit / credit balance verification on the generated accounting vouchers. This involves automatically calculating the sum of all debit entries and the sum of all credit entries in the accounting voucher and determining if they are equal. If the verification result shows that the debit and credit amounts are equal (i.e., debit / credit balance), the accounting voucher is generated and stored normally. If the verification result shows that the debit and credit amounts are unequal (i.e., debit / credit imbalance), the engine immediately blocks the generation of the accounting voucher and outputs a clear verification result, such as a clear message like "Debit and credit amounts are unbalanced; total debit amount: XXX yuan; total credit amount: XXX yuan; please adjust the entry amounts," allowing users to quickly locate and correct the problem. In addition, this built-in verification capability can also assist in verifying other financial transaction characteristics (such as the compliance verification of accounting subjects in voucher entries) according to actual needs, further ensuring the accuracy and compliance of accounting vouchers and meeting the relevant requirements of accounting standards.

[0115] In one specific embodiment, the financial management system includes:

[0116] (1) Visual configuration platform 100: As a user interaction layer, it provides domain-specific form designer 110, process designer 120, financial rule designer 130 and report designer 140 to output configuration data such as forms / processes / rules / reports, and relies on the subject system model 210, voucher model 220 and accounting dimension model 230 provided by the financial domain meta-model library 200 to realize financial semantic binding.

[0117] (2) Financial domain meta-model library 200: used to store financial domain metadata including at least subject system model 210, voucher model 220 and accounting dimension model 230.

[0118] (3) Dynamic Model-Driven Engine 300: Receives configuration data set and activation instructions output from the visual configuration platform 100. The configuration data set includes at least one or more of form configuration, process configuration, rule configuration, and report configuration. In typical financial scenarios, the configuration data set can be "form + process + rule" or further extended to "form + process + rule + report," and allows incremental changes and releases only for a certain type of configuration. Finally, the configuration data set is generated / updated into runtime components executable in the same low-code runtime environment. The runtime components include at least database table structure and migration scripts, business object APIs, front-end page interaction logic, process definitions and task table structures, report query interfaces, etc., thereby forming a configurable business function module for this business scenario, and persisting the configuration data and business data to the data persistence layer 500.

[0119] (4) Financial dedicated rule engine 400: During runtime, it receives process node events (NodeID and status change) or document events (save / submit / retract, etc.) based on the trigger points in the rule configuration data, and completes rule matching and execution; it has built-in financial characteristics such as transaction atomicity (ACID) and mandatory verification of debit and credit balance, and persists the execution results (such as the generated voucher data) to the data persistence layer 500.

[0120] (5) Data persistence layer 500: used to store configuration data, business document data and voucher ledger data.

[0121] In another specific embodiment, the financial management system includes the following core modules:

[0122] 1. Visual Configuration Platform 100: Provides a graphical user interface, serving as the entry point for user interaction with the system. It includes multiple designers; some controls in each designer are directly linked to specific models in the financial domain meta-model library 200, while others do not directly depend on the meta-model library but interact with financial data through configuration logic. For example, it may include the following designers:

[0123] 1) Domain-Specific Form Designer 110: Provides controls rich in financial semantics, such as "Account Selector" and "Amount Calculation Formula Box," for building business document interfaces that conform to financial standards. Some controls are associated with the account system model 210 and accounting dimension model 230 in the financial domain meta-model library 200.

[0124] 2) Process Designer 120: Based on the BPMN standard, it allows users to drag and drop nodes to define financial approval workflows. The process engine outputs node events (including NodeID, status, instance ID, etc.) at runtime for the rule engine to subscribe to and match. In this designer, there are two types of nodes: predefined nodes and custom nodes.

[0125] (a) Predefined nodes: The system provides a set of commonly used predefined nodes (such as "Submit for approval", "Approval passed", "Financial review" etc.). These nodes represent standard process steps, and users can drag and drop them directly.

[0126] (b) Custom Nodes: Users can customize node names and execution logic to suit specific financial process requirements. This module generates the front-end interaction logic and database table structure related to the process.

[0127] 3) Financial Rule Designer 130: The core module, allowing users to configure automatic accounting voucher generation rules, data validation rules, etc., generating rules related to voucher model 220 and financial accounting dimensions. This designer triggers the generation of database table structures and business object APIs.

[0128] It should be noted that, when configuring rules, the financial rule designer 130, in addition to defining "condition-action", is also used to configure rule trigger points. The trigger points include at least process node event trigger points and document event trigger points. The process node event trigger points include node identifiers (NodeID) and node status change conditions, while the document event trigger points include event types such as save, submit, and withdraw. After the rule configuration is completed, the rule definition and its trigger points are stored together in the configuration database of the data persistence layer 500.

[0129] 4) Report Designer 140: Allows users to visually configure various financial reports such as balance sheets and income statements by dragging and dropping data fields and setting formulas. This designer affects the front-end interaction logic and the generation of related data tables.

[0130] 2. Financial Domain Metamodel Library 200: Stores fully defined financial domain metadata, serving as the "brain" of the system. It includes:

[0131] 1) Subject system model 210: Stores accounting subjects and their attributes in a tree structure and associates them with controls such as "subject selector".

[0132] 2) Voucher Model 220: Association defines the structure of the voucher header (date, voucher number, etc.) and voucher lines (account, debit / credit direction, amount, accounting dimension), and is associated with the "Voucher Rule Configuration" control in the Financial Rule Designer 130.

[0133] 3) Accounting Dimension Model 230: This control allows users to select or define accounting dimensions (such as departments, projects, etc.) and associate these dimensions with specific business documents or vouchers. It is related to the "Accounting Dimension Attacher" control in the domain-specific form designer 110.

[0134] 3. Dynamic Model-Driven Engine 300: Based on the user's definitions in the visual configuration platform 100, this engine dynamically generates or modifies the corresponding database table structure, business object APIs, and front-end interaction logic at runtime. When configuration changes, this engine is responsible for automatically migrating and adapting the data model.

[0135] 4. Financial Rule Engine 400: Responsible for parsing and executing rules configured in the Financial Rule Designer 130. This engine has built-in support for financial transaction characteristics, such as transaction atomicity (ACID), mandatory debit / credit balance verification, and can efficiently handle rule matching under multi-dimensional combinations.

[0136] It should be noted that the financial-specific rule engine 400 further includes trigger management and event adaptation capabilities: it completes rule registration based on the trigger point in the rule configuration data; during runtime, it receives process node lifecycle events and business document events generated by the process engine, and when the event meets the trigger conditions such as "NodeID + status change" or "document event type", it schedules the corresponding rule to perform condition calculation and action execution, thereby realizing the configurable binding of rules and process nodes.

[0137] 5. Data Persistence Layer 500: Used to store system configuration data, business data, and generated financial voucher data.

[0138] It should be noted that the financial management system provided in this public disclosure has the following beneficial effects:

[0139] a) Financial semantic-driven visual configuration capability: By constructing a financial domain meta-model library 200 that includes a subject system model 210, a voucher model 220, and an accounting dimension model 230, and providing a unified meta-model reuse mechanism for multiple designers such as forms, processes, rules, and reports, financial personnel can directly complete the configuration of business documents, accounting rules, and report scope using financial semantic controls such as "subject selector" and "dimensional attacher". This achieves consistency and constraint verification of subject reference, dimension attachment, and data retrieval scope, significantly reducing the configuration threshold and professional operation difficulty of financial scenarios.

[0140] b) Configurable binding mechanism for rules and processes: By introducing trigger point definitions that include process node events (node ​​identifier + status change) and document events (save / submit / retract), the execution of financial rules is no longer limited to fixed code logic, but can be dynamically bound to and scheduled at runtime with the lifecycle events of business processes, thereby improving the flexibility of rule configuration and business adaptability.

[0141] c) Declarative voucher generation and strong financial constraints: The visual voucher template based on voucher model 220 supports configuring debit and credit directions, selecting accounting subjects, binding business document amount fields for each entry of accounting vouchers, and attaching one or more accounting dimensions to the entries; at runtime, the financial dedicated rule engine 400 automatically executes financial-specific constraints such as mandatory debit and credit balance verification and mandatory dimension verification to ensure that the generated accounting vouchers comply with the double-entry bookkeeping law, realizing the automation and accuracy of voucher generation.

[0142] d) Online migration and adaptation capabilities and agile iteration capabilities: The Dynamic Model Driven Engine 300 can dynamically generate or update configuration data into runtime components such as database table structures, business object APIs, front-end page logic, process operation structures and report query interfaces. When configuration changes, it automatically performs online migration and compatibility adaptation of existing data models, enabling the system to make business adjustments without downtime or code deployment, which significantly improves the change response efficiency and maintainability of the financial system.

[0143] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0144] Figure 5 A flowchart of a financial management method provided in an embodiment of this disclosure.

[0145] Reference Figure 5 This disclosure provides a financial management method applied to the aforementioned financial management system, the method comprising:

[0146] Step S1: Initialize the financial domain meta-model library 200 by defining and storing financial domain metadata, wherein the metadata includes at least the subject system model 210, the voucher model 220 and the accounting dimension model 230.

[0147] Step S2: Through the graphical user interface provided by the visualization configuration platform 100, the configuration operation of the user for the target financial business scenario is received, and a business scenario configuration data set is generated. The financial domain meta-model library 200 provides financial semantic constraints and data mapping basis for the configuration operation.

[0148] Specifically, the financial domain metamodel library 200 stores financial domain metadata covering the core basic elements of financial accounting. When users perform configuration operations, it automatically provides constraints and data mapping guidance at the financial semantic level, avoiding problems such as data definitions and field associations that do not conform to financial standards, and ensuring the professionalism and compliance of the configuration content.

[0149] In some embodiments, receiving the user's configuration operation for a target financial business scenario specifically includes at least one of the following:

[0150] The system receives a business document interface constructed by the user through the domain-specific form designer 110, wherein the domain-specific form designer 110 provides financial semantic controls associated with the subject system model 210 and accounting dimension model 230 stored in the financial domain meta-model library 200.

[0151] Receive the approval process for financial transactions defined by the user through the process designer 120;

[0152] Receive the financial rules configured by the user through the financial rule designer 130;

[0153] The system receives the data retrieval criteria and display format of financial statements configured by the user through the report designer 140. The data retrieval criteria are based on the subject system model 210 and the accounting dimension model 230, which bind the subject range and dimension fields.

[0154] Specifically, users can choose to execute one or more of the above configuration operations according to the actual needs of the target financial business scenario. All configuration operations are completed through visual interaction, without the need to write underlying code. When receiving a user's construction of a business document interface through the domain-specific form designer 110, the user can use the financial semantic controls (such as account selection controls, accounting dimension selection controls, etc.) provided by the designer and associated with the account system model 210 and accounting dimension model 230 to quickly construct a business document interface that conforms to financial standards through simple operations such as drag and drop and selection, adapting to the document requirements of different financial business scenarios. When receiving a user's definition of an approval process through the process designer 120, the user can complete the definition of the financial business approval process through a graphical arrangement interface, dragging and dropping process nodes, setting node handlers, approval conditions, etc. When receiving a user's configuration of financial rules through the financial rule designer 130, the user can visually configure various parameters of the rules according to the financial business logic, laying the foundation for subsequent rule execution. When receiving configurations of financial statement-related content from users through the report designer 140, users can bind account scope and dimension fields through visual operations based on the account system model 210 and accounting dimension model 230, determine the data retrieval scope of the report, and flexibly set the report display format to quickly complete the configuration of financial statements.

[0155] In some embodiments, receiving the financial rules configured by the user through the financial rule designer 130 specifically includes:

[0156] The system receives the trigger points of the financial rules configured by the user. The trigger points include process node event trigger points and / or document event trigger points. The process node event trigger points include process node identifiers and node status change conditions. The document event trigger points include at least one event type among document saving, submission, and withdrawal.

[0157] The system receives the execution conditions and execution actions of the financial rules configured by the user, wherein the execution action is to generate accounting vouchers through a visual voucher template.

[0158] The visual voucher template reuses the structure defined by the voucher model 220, supports configuring debit and credit directions for each entry of the accounting voucher, selecting accounting subjects from the subject system model 210, binding amounts to business document fields, and attaching at least one accounting dimension from the accounting dimension model 230 to at least one entry.

[0159] Specifically, the process of receiving user-configured financial rules involves users completing the configuration of each core element of the rule in 130 steps using the financial rule designer. Each step of the configuration has visual guidance to ensure accuracy. When receiving trigger point configurations, users can choose one or a combination of process node event trigger points and document event trigger points according to business needs. For example, when configuring process node event trigger points, users need to enter the process node identifier and set the node status change conditions; when configuring document event trigger points, users can select event types such as document save, submit, and withdraw to clarify the triggering time of the rule. When receiving execution conditions and execution action configurations, users can set specific execution conditions. Only when these conditions are met will the execution action be triggered. The core of the execution action configuration is to generate accounting vouchers through visual voucher templates. Users can use the templates of the reusable voucher model 220 structure to configure debit and credit directions for each voucher entry, select the corresponding accounting subject from the subject system model 210, bind the entry amount with specific fields in the business document (such as reimbursement amount, payment amount) to achieve automatic filling, and attach accounting dimensions (such as department, project dimension) to at least one entry to ensure the professionalism and accuracy of voucher generation.

[0160] Step S3: Utilize the dynamic model-driven engine 300 to receive the business scenario configuration data set, and based on the financial domain meta-model library 200, dynamically generate or update the runtime components corresponding to the target financial business scenario.

[0161] Specifically, the dynamic model-driven engine 300 receives the business scenario configuration data set and, in conjunction with the metadata constraints in the financial domain meta-model library 200, automatically completes the creation and update operations of runtime components. The runtime components generated by the dynamic model-driven engine 300 include at least: database table structure and migration scripts, business object APIs, front-end page interaction logic, process definition and task table structure, and report query interface, ensuring that the configured financial business scenario can run directly and stably.

[0162] In some embodiments, the method further includes:

[0163] When the configuration data set of the business scenario changes, the dynamic model driving engine 300 is used to perform online migration and compatibility adaptation on the existing data model corresponding to the target financial business scenario, so that the changes take effect without interrupting business operations.

[0164] Specifically, when a user modifies, adds, or deletes configuration content for a target financial business scenario, resulting in changes to the business scenario configuration data set, the current financial business operation does not need to be stopped. The dynamic model-driven engine 300 receives the changed business scenario configuration data set in real time and automatically identifies and analyzes the existing data model corresponding to the scenario (including database table structure, business objects, process definitions, etc.) to determine the scope and extent of the impact of the changes on the existing data model. Then, the engine automatically performs online migration and compatibility adaptation operations on the existing data model, such as incrementally modifying the database table structure, updating business object APIs, and synchronously adjusting process definitions. Simultaneously, it automatically handles data compatibility issues, ensuring that the original business data is not lost or damaged, and that the changed configuration content takes effect quickly. This achieves "zero-downtime" updates for financial business scenarios, ensuring business continuity while improving the efficiency of configuration changes, avoiding the drawbacks of traditional methods that require interrupting business operations and manually modifying underlying code.

[0165] Step S4: The financial rules configured in the visualization configuration platform 100 are parsed and executed by the financial rule engine 400. When a trigger point is detected during business operation, the corresponding rule is executed to generate accounting vouchers that comply with the double-entry bookkeeping method. The financial rules include the pre-configured trigger points.

[0166] Specifically, the financial rule engine 400 has the ability to parse, monitor and execute financial rules. It can accurately identify the preset financial rules and trigger points in the visual configuration platform 100. Throughout the entire financial business operation, the financial rule engine 400 monitors the fulfillment of trigger points in real time. Once the trigger conditions are detected, the corresponding rule logic is executed immediately, and accounting vouchers that comply with the double-entry bookkeeping law are automatically generated without manual intervention.

[0167] In some embodiments, the method further includes:

[0168] By utilizing the built-in financial transaction feature verification capability of the financial rule engine 400, a mandatory debit-credit balance verification is performed when generating accounting vouchers. If the verification fails, the generation of accounting vouchers is prevented, and the verification result is output.

[0169] Specifically, during the execution of rules and generation of accounting vouchers by the financial rule engine 400, its built-in financial transaction characteristic verification capabilities are simultaneously invoked, with a focus on performing mandatory debit-credit balance verification. During verification, the engine automatically calculates the sum of all debit entries and the sum of all credit entries in the currently generated accounting voucher, comparing their amounts. If the amounts are equal, the debit-credit balance requirement is met, and the accounting voucher generation and subsequent storage operations are completed normally. If the amounts are not equal, indicating a debit-credit imbalance, the engine immediately terminates the accounting voucher generation process and outputs clear and specific verification results. This allows users to quickly locate problems, modify voucher entries, and ensure that the generated accounting vouchers comply with accounting standards, guaranteeing the accuracy and compliance of financial data. Furthermore, this built-in verification capability can also assist in completing other financial transaction verifications, such as accounting subject compliance, based on actual needs, further enhancing the professionalism of voucher generation.

[0170] Step S5: Store the business scenario configuration data set, business document data generated during business operation, and accounting voucher data generated by the financial rule engine 400 through the data persistence layer 500.

[0171] Specifically, through the standardized storage mechanism of the data persistence layer 500, the business scenario configuration data set, various business document data generated during business operation (such as expense reports, payment slips, etc.), and accounting voucher data generated by the financial dedicated rule engine 400 are uniformly and securely stored, while ensuring the integrity, consistency and traceability of the data, providing reliable data support for subsequent financial audits, data queries and business reviews.

[0172] In one specific embodiment, the financial management method includes the following steps:

[0173] (1) System initialization: The system administrator imports / selects templates / maintains the financial domain meta-model library 200 through the visual configuration platform 100, which includes at least the subject system model 210, voucher model 220 and accounting dimension model 230, in order to establish a financial professional foundation.

[0174] (2) Visual configuration of business scenarios. Configure forms, processes and rules on the low-code platform, and optionally configure report scope and layout to achieve "dynamic configurability".

[0175] (3) Model-driven generation and adaptation. The dynamic model-driven engine 300 generates or updates runtime components (table structure and migration, business object API, page logic, process running structure, report interface, etc.) based on the meta-model and configuration data, so that business scenarios are embedded in the same system in the form of configurable functional modules, realizing "model-driven".

[0176] (4) Execution and automatic accounting during operation. End users enter and submit business documents on the configured page. The process flow generates node events / document events. The rule engine performs verification and voucher generation according to the trigger points to achieve "automatic accounting".

[0177] (5) When business changes, the process can be quickly returned to (2) for adjustment, forming a closed loop of agile iteration.

[0178] Combination Figure 6 The following example uses the "employee travel expense reimbursement" business scenario to illustrate the financial management method in this embodiment:

[0179] Step S101: Domain Modeling. The system administrator initializes the financial domain metamodel library 200, importing or configuring the chart of accounts and accounting dimensions required by the enterprise.

[0180] Step S102: Business scenario configuration.

[0181] Form Configuration (S102a): Finance personnel use the domain-specific form designer 110 to drag and drop controls such as "Employee", "Department", "Expense Details", and "Total Amount" to create a "Travel Expense Reimbursement Form". Among them, the "Department" control will be bound to the "Department" dimension in the accounting dimension model 230.

[0182] Process Configuration (S102b): Using the process designer 120, configure the approval process of "employee submission → department manager approval → financial review".

[0183] Rule Configuration (S102c): This step is crucial. Using the Financial Rule Designer 130, when configuring rules, in addition to "Conditions and Actions," first configure the rule trigger points. Trigger points should include at least: process node events (NodeID + status change), document events (save / submit / retract), etc. Then configure "Conditions and Actions." Configure two core rules:

[0184] Rule 1 (Verification Rule): If the total amount of the expense report is greater than 10,000 yuan, then the attachment with special approval from the general manager must be uploaded; otherwise, the verification will fail.

[0185] Rule 2 (Voucher Rule): When the [Reimbursement Form.Status == Finance Approved], generate the following voucher: Debit: [Management Expenses - Travel Expenses] (Accounting Dimension: [Reimbursement Form.Department]), Credit: [Other Payables - Individual] (Accounting Dimension: [Reimbursement Form.Employee]), with the amount being [Reimbursement Form.Total Amount].

[0186] Report Configuration (S102d): Finance personnel use Report Designer 140 to configure the "Department Travel Expense Summary" (one of the sample reports). The configuration steps include:

[0187] a) Dataset selection: Select the data source as "Voucher Entries Dataset" and / or "Expense Reimbursement Business Dataset" in the data persistence layer 500;

[0188] b) Data retrieval scope binding: The scope of the subject is limited to [Management Expenses - Travel Expenses] (selected from the subject tree of subject system model 210210);

[0189] c) Dimension and indicator configuration: Set the grouping dimension = [Department] (from accounting dimension model 230230), and the indicator = [SUM(entry amount)].

[0190] d) Filtering criteria: Set the period = [Reimbursement form.Period in which the reimbursement date falls] or [Voucher date period], and you can configure the approval status = Completed;

[0191] e) Layout and display: Configure row and column layout, total row, drill-down to details (by employee / document number) and other interactive configurations.

[0192] After the report configuration is completed, the report definition is written as configuration data to the data persistence layer 500, and the dynamic model driving engine 300 generates the report query interface and front-end presentation logic.

[0193] Step S103: Dynamic Driving and Operation. The dynamic model driving engine 300 receives the above configuration, automatically creates or updates the "Travel Expense Reimbursement Form" business table structure and the instance / task table structure required for process operation in the database, and generates the corresponding data interface, page logic, and report query interface; when the configuration changes, it performs data model migration and adaptation.

[0194] Step S104: Business execution and automatic accounting.

[0195] Employee Zhang San filled out the expense reimbursement form (Department: Sales Department, Amount: 1200 yuan) and submitted it.

[0196] The documents are processed and approved according to the preset workflow.

[0197] When the process reaches the "Financial Review" node and the node status changes to "Passed", the financial special rule engine 400 is triggered, executes rule two, automatically creates accounting vouchers: Debit: Management Expenses - Travel Expenses (Sales Department) 1200 yuan; Credit: Other Payables - Individual (Zhang San) 1200 yuan; and forces a debit and credit balance check.

[0198] The generated vouchers are automatically recorded in the voucher data storage area (i.e., the "voucher library") in the data persistence layer 500, which includes voucher headers, entries, and tables for entry-dimension value association.

[0199] Step S104b: Report Query and Analysis. After the vouchers are entered into the database, the user opens the "Department Travel Expense Summary Table". The report engine performs a query according to the data retrieval criteria and dimension indicators configured in S102d, and summarizes and displays the travel expense amount of each department in real time. It also supports drill-down to employee or document details, realizing a closed loop of "business occurrence → automatic accounting → report presentation".

[0200] Step S105: Dynamic Adjustment. If company rules change, a "Project" accounting dimension needs to be added to the travel expenses of the "Sales Department". Finance personnel add a "Project" control to the expense report in the domain-specific form designer 110 and modify the voucher rules in the financial rule designer 130 to add the "Expense Report.Project" dimension to the debit entry. The dynamic model-driven engine 300 automatically completes the structural migration and interface adaptation of fields / associations based on the changes, allowing the system to adapt to changes without downtime or code deployment.

[0201] It should be noted that, apart from the employee travel expense reimbursement scenario mentioned above, the overall implementation steps for other financial business scenarios such as procurement payments, corporate reimbursements, expense accruals, fixed asset write-offs, and revenue recognition are consistent with the examples above and all follow the following:

[0202] Domain modeling (S101) → Scenario configuration (S102, including forms / processes / rules / reports, which can be selected as needed) → Dynamic generation and migration (S103) → Execution and automatic calculation (S104) → Dynamic adjustment (S105).

[0203] The differences between different scenarios are mainly reflected in the different sets of business document fields, process node sets, rule triggering conditions and voucher templates, as well as the different configurations of report indicators / dimensions. This application enables the above differences to be completed through low-code configuration through meta-model and dynamic driving mechanism, without the need for code deployment or downtime.

[0204] Figure 7 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0205] Reference Figure 7 This disclosure provides an electronic device, which includes: at least one processor 701; at least one memory 702; and one or more I / O interfaces 703 connected between the processor 701 and the memory 702; wherein the memory 702 stores one or more computer programs that can be executed by the at least one processor 701, and the one or more computer programs are executed by the at least one processor 701 to enable the at least one processor 701 to perform the above-described financial management method.

[0206] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the aforementioned financial management system. The computer-readable storage medium may be volatile or non-volatile.

[0207] In summary, the financial management system, method, electronic device, and storage medium provided in this disclosure, through a technical solution combining a visual configuration platform, a financial domain meta-model library, a dynamic model-driven engine, a financial-specific rule engine, and a data persistence layer, can provide graphical configuration capabilities for target financial business scenarios. Relying on predefined financial domain metadata, it achieves financial semantic constraints and data mapping support for the configuration process, dynamically generating and driving runtime components for corresponding business scenarios. Simultaneously, based on the financial-specific rule engine, it automatically executes rules at preset trigger points during business operation and generates accounting vouchers conforming to the double-entry bookkeeping method, uniformly completing the persistent management of various business and configuration data. This enhances the flexibility and professionalism of financial business construction and operation, lowers the technical threshold for financial domain business configuration, and deeply adapts rule execution to financial professional logic. It allows for rapid construction and operation of financial business scenarios without relying on extensive low-level code development. This solves the problems of fixed functions and the need for secondary development in traditional packaged financial software, as well as the lack of domain models, high professional thresholds, and disconnect between rule engines and financial logic when general low-code platforms are applied to the financial domain.

[0208] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0209] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0210] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0211] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0212] This disclosure has disclosed exemplary embodiments, and although specific terminology has been used, it is for general illustrative purposes only and should not be construed as limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A financial management system, characterized in that, This includes a visual configuration platform, a financial meta-model library, a dynamic model-driven engine, a financial-specific rule engine, and a data persistence layer. The visual configuration platform is used to provide a graphical user interface to receive configuration operations from users for target financial business scenarios and generate a set of business scenario configuration data. The financial domain meta-model library is used to store predefined financial domain metadata and to provide financial semantic constraints and data mapping basis for configuration operations in the visualization configuration platform. The metadata includes at least a subject system model, a voucher model and an accounting dimension model. The dynamic model driving engine is used to receive the business scenario configuration data set and dynamically generate or update the runtime components corresponding to the target financial business scenario based on the financial domain metamodel library. The dedicated financial rules engine is used to parse and execute the financial rules configured in the visualization configuration platform. The financial rules include pre-configured trigger points. When the dedicated financial rules engine detects that the trigger points are met during business operations, it executes the corresponding rules to generate accounting vouchers that comply with the double-entry bookkeeping method. The data persistence layer is used to store the business scenario configuration data set, business document data generated during business operation, and accounting voucher data generated by the financial rule engine.

2. The system according to claim 1, characterized in that, The visual configuration platform includes a domain-specific form designer, a process designer, and a financial rule designer, among which... The domain-specific form designer is used to provide financial semantic controls associated with the subject system model and accounting dimension model stored in the financial domain metamodel library, so as to construct the business document interface; The process designer is used to define the approval process for financial transactions; The financial rule designer is used to configure the financial rules.

3. The system according to claim 2, characterized in that, The financial rule designer is specifically used for: Configure the trigger points of the financial rules. The trigger points include process node event trigger points and / or document event trigger points. The process node event trigger points include process node identifiers and node status change conditions. The document event trigger points include at least one event type among document saving, submission, and withdrawal. Configure the execution conditions and execution actions of the financial rules, wherein the execution action is to generate accounting vouchers through a visual voucher template; The visual voucher template reuses the structure defined by the voucher model, supports configuring debit and credit directions for each entry in the accounting voucher, selecting accounting subjects from the subject system model, binding amounts to business document fields, and attaching at least one accounting dimension from the accounting dimension model to at least one entry.

4. The system according to claim 2, characterized in that, The visualization configuration platform also includes a report designer, which is used to configure the data retrieval scope and display format of financial statements. The data retrieval scope is based on the subject system model and the accounting dimension model to bind the subject range and dimension fields.

5. The system according to claim 2, characterized in that, The subject system model is a tree structure, with each node corresponding to an accounting subject and each accounting subject containing subject code, subject name, subject level, and balance direction attributes; the subject selector control in the visualization configuration platform displays the subject hierarchy based on the tree structure in a tree drop-down or tree selection interface, and limits the selectable levels according to the subject level attributes; The voucher model defines the structure of the voucher header and voucher rows, and is reused by the visual voucher template in the financial rule designer; The accounting dimension model allows users to select or customize accounting dimensions, which include at least department, project, and employee dimensions.

6. The system according to claim 1, characterized in that, The dynamic model-driven engine is also used to perform online migration and compatibility adaptation of the existing data model corresponding to the target financial business scenario when the configuration data set of the business scenario changes, so that the changes take effect without interrupting business operations.

7. The system according to claim 1, characterized in that, The dedicated financial rules engine has built-in financial transaction feature verification capabilities. When generating accounting vouchers, it performs mandatory debit and credit balance verification. If the verification fails, it prevents the generation of accounting vouchers and outputs the verification result.

8. A financial management method, characterized in that, The method, applied to the financial management system according to any one of claims 1 to 7, comprises: By defining and storing metadata in the financial domain, the financial domain meta-model library is initialized. The metadata includes at least a subject system model, a voucher model, and an accounting dimension model. The platform uses a graphical user interface to receive configuration operations from users for target financial business scenarios and generates a set of business scenario configuration data. The financial domain meta-model library provides financial semantic constraints and data mapping basis for the configuration operations. The dynamic model-driven engine receives the set of configuration data for the business scenario and dynamically generates or updates the runtime components corresponding to the target financial business scenario based on the financial domain meta-model library. The financial rules configured in the visualization configuration platform are parsed and executed by the financial rule engine. When a trigger point is detected during business operation, the corresponding rule is executed to generate accounting vouchers that comply with the double-entry bookkeeping method. The financial rules include the pre-configured trigger points. The data persistence layer stores the set of configuration data for the business scenario, the business document data generated during business operation, and the accounting voucher data generated by the financial rule engine.

9. The method according to claim 8, characterized in that, The receiving user's configuration operations for the target financial business scenario specifically includes at least one of the following: The system receives a business document interface constructed by a user through a domain-specific form designer, wherein the domain-specific form designer provides financial semantic controls associated with the account system model and accounting dimension model stored in the financial domain meta-model library. Receive approval processes for financial transactions defined by users through the process designer; Receive the financial rules configured by the user through the financial rule designer; The system receives the data retrieval criteria and display format of financial statements configured by the user through the report designer. The data retrieval criteria are based on the subject system model and the accounting dimension model, which bind the subject range and dimension fields.

10. The method according to claim 9, characterized in that, The financial rules configured by the user through the financial rule designer specifically include: The system receives the trigger points of the financial rules configured by the user. The trigger points include process node event trigger points and / or document event trigger points. The process node event trigger points include process node identifiers and node status change conditions. The document event trigger points include at least one event type among document saving, submission, and withdrawal. The system receives the execution conditions and execution actions of the financial rules configured by the user, wherein the execution action is to generate accounting vouchers through a visual voucher template. The visual voucher template reuses the structure defined by the voucher model, supports configuring debit and credit directions for each entry in the accounting voucher, selecting accounting subjects from the subject system model, binding amounts to business document fields, and attaching at least one accounting dimension from the accounting dimension model to at least one entry.

11. The method according to claim 8, characterized in that, The method further includes: When the configuration data set of the business scenario changes, the dynamic model-driven engine is used to perform online migration and compatibility adaptation of the existing data model corresponding to the target financial business scenario, so that the changes take effect without interrupting business operations.

12. The method according to claim 8, characterized in that, The method further includes: By utilizing the built-in financial transaction feature verification capability of the financial rule engine, a mandatory debit-credit balance verification is performed when generating accounting vouchers. If the verification fails, the generation of accounting vouchers is prevented, and the verification result is output.

13. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the financial management method as described in any one of claims 8-12.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the financial management method as described in any one of claims 8-12.

Images