Data processing methods, electronic devices and computer program products
By generating configuration files and dynamically binding executable programs with hot-loading indexes, the problems of high development costs and poor scalability of financial systems in multiple business scenarios are solved, enabling flexible and efficient financial data processing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KE COM (BEIJING) TECHNOLOGY CO LTD
- Filing Date
- 2026-02-06
- Publication Date
- 2026-06-02
AI Technical Summary
Existing financial systems suffer from high development costs, poor scalability, and insufficient flexibility when faced with various business services, especially when adding or iterating new business services, making it difficult to respond quickly.
By generating configuration files to define the business service characteristics of financial data, and using hot-loading indexes to dynamically bind execution programs, business logic and code are decoupled, supporting flexible processing of multiple business scenarios.
Significantly reduce development costs, increase iteration speed, enhance system flexibility, stability and industry applicability, and ensure the accuracy and consistency of financial data processing.
Smart Images

Figure CN122132403A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the technical fields of data processing, and in particular to a data processing method, electronic device, and computer program product. Background Technology
[0002] The financial system needs to provide accounting support for various business services, but the financial data of these services often differ significantly in terms of field definitions and types. For example, supply chain operations focus on purchase amounts and supplier settlements, while rental operations emphasize rental periods and deposit processing. Developing and hard-coding separate processing logic for each business service would drastically increase development and maintenance costs. Furthermore, the system suffers from poor scalability and flexibility when introducing new business services or iterating on existing ones. Summary of the Invention
[0003] This disclosure provides a data processing method, an electronic device, and a computer program product.
[0004] According to one aspect of this disclosure, a data processing method is provided, comprising: generating a configuration file capable of processing financial data in a business service, the business service including the business department to which the financial data belongs, business type, and transaction type, the configuration file recording data processing logic adapted to the business service; forming a hot-loading index recording the association between the business service corresponding to the financial data and an executable program capable of calling the configuration file; in response to a processing request for target data, determining a target executable program capable of calling the target configuration file in the hot-loading index, the target configuration file being a configuration file applicable to the target business service to which the target data belongs; and triggering the target executable program to execute the target configuration file on the target data to obtain a processing result for the target data.
[0005] Based on one technical solution, through configurable and modular design, the financial system achieves efficient compatibility with multiple business operations, significantly reduces development costs, increases iteration speed, and combines flexibility, stability, and industry universality.
[0006] In some implementations, generating a configuration file capable of processing financial data in business services includes: generating a first configuration file containing validation logic, wherein the financial data includes financial parameters and parameter values, and the validation logic is logic for determining whether the parameter values meet the numerical requirements of the corresponding financial parameters; generating a second configuration file containing conversion logic, wherein the conversion logic converts some financial parameters in the financial data into field names that meet naming rules; and generating a third configuration file containing file marking logic, wherein the file marking logic is at least used to determine that the financial data requires reconciliation operations.
[0007] According to one technical solution, the decoupling of verification, conversion and reconciliation marking is achieved through layered configuration, which improves the flexibility, maintainability and business adaptability of financial data processing.
[0008] In some implementations, a third configuration file containing file marking logic is generated, including: when the transaction type of the business service is transaction void, determining inversion marking logic, wherein the inversion marking logic is a sub-logic of the file marking logic, and the inversion marking logic is used to determine that the financial data needs to be inverted, wherein the inversion operation means recording the amount value in the financial data in negative form.
[0009] According to one technical solution, the logic for automatically identifying and reversing flags in the scenario of transaction cancellation is automatically identified through configuration, which realizes flexible triggering and accurate recording of amount reversal processing, and improves the consistency of financial data reconciliation and business adaptability.
[0010] In some implementations, a third configuration file containing file tagging logic is generated, which includes: determining tax splitting logic based on the transaction type of the business service, wherein the tax splitting logic is a sub-logic of the file tagging logic, and the tax splitting logic is used to determine that the financial data needs to undergo a tax splitting operation, wherein the tax splitting operation means splitting the transaction amount of the financial data into a tax amount and a tax-exclusive amount.
[0011] According to one technical solution, by dynamically configuring the tax splitting logic based on the transaction type, flexible identification and accurate processing of tax separation operations under different business scenarios are achieved, thereby improving the standardization of financial data and the accuracy of accounting.
[0012] In some implementations, before forming a hot-load index that records the association between the business service corresponding to the financial data and the executable program capable of processing the business service, the process includes: determining whether there is an existing executable program capable of calling the configuration file; when there is no existing executable program capable of calling the configuration file, generating an executable program capable of calling the configuration file, and configuring a tag for the executable program, the tag recording the business service that the executable program can process and the program identifier of the executable program.
[0013] According to one technical solution, by pre-generating the executor and configuring tags containing business service scope and program identifier, flexible binding of processing logic and business scenarios is achieved, laying the foundation for subsequent dynamic construction of hot-loading indexes and improving the scalability of the system and the accuracy of runtime routing.
[0014] In some implementations, before determining a target executor capable of invoking a target configuration file in the hot-load index in response to a processing request for target data, the method includes: in response to a processing request for target data, reading a target business department, a target business type, and a target transaction type from the target data, and determining a target business service.
[0015] According to one technical solution, by dynamically parsing the target business department, target business type, and target transaction type in the target data when processing requests, the corresponding target business service can be accurately identified. This provides a reliable basis for subsequent accurate matching of configuration files and execution programs, and enhances the system's adaptability and processing accuracy to multiple business scenarios.
[0016] In some implementations, in response to a request to process target data, determining a target executor capable of calling the target configuration file in the hot-load index includes: determining a program identifier corresponding to the target business service in the hot-load index, and using the executor having the program identifier as the target executor.
[0017] According to one technical solution, by finding the corresponding program identifier based on the target business service in the hot-loading index and locating the target execution program, the dynamic binding of business rules and processing logic is realized, which improves the accuracy and maintainability of system routing and supports flexible expansion and efficient invocation.
[0018] In some implementations, obtaining the processing result of the target data includes: verifying the target data according to the verification logic in the first configuration file to obtain a verification result; and issuing a failure prompt when the verification result is a failure.
[0019] According to one technical solution, by verifying the target data according to the verification logic in the first configuration file and issuing a failure prompt in a timely manner when the verification fails, the pre-control of data quality is realized, which effectively ensures the accuracy and reliability of financial processing and avoids invalid or erroneous data from entering subsequent processes.
[0020] In some implementations, after obtaining the verification result, the method further includes: if the verification result is successful, converting at least some of the financial parameters of the target data into field names that satisfy the naming rules according to the conversion logic of the second configuration file.
[0021] According to one technical solution, after verification, the financial parameters are mapped to field names that conform to the naming conventions of the financial system based on the conversion logic of the second configuration file. This realizes the automatic conversion of business data to the financial standard format, improving the uniformity, readability and efficiency of data processing and inter-system collaboration.
[0022] In some implementations, after obtaining the verification result, the method further includes: analyzing the target data according to a third configuration file; marking the target data with a reconciliation identifier when a reconciliation operation is required; and calling the reconciliation system to reconcile the target data with the reconciliation identifier to obtain the reconciliation result.
[0023] According to one technical solution, the system dynamically analyzes whether the target data needs to be reconciled through a third configuration file, and automatically marks the reconciliation flag and triggers the reconciliation process when the conditions are met. This achieves flexible configuration and automated execution of reconciliation processing, improving the accuracy and timeliness of reconciliation and the system's adaptability to multiple business scenarios.
[0024] In some implementations, after obtaining the reconciliation results, the method includes: in response to the reconciliation cancellation data in the reconciliation results, performing an inversion operation on the amount value in the reconciliation cancellation data.
[0025] According to one technical solution, by identifying reconciliation cancellation data in the reconciliation results and performing a reverse operation on its amount, the financial impact of reversal or cancellation transactions can be accurately reflected, ensuring the integrity and consistency of ledgers and subsequent accounting data, and improving the accuracy of financial accounting.
[0026] In some implementations, after obtaining the verification result, the method further includes: marking the target data with a negation flag when the third configuration file contains negation flag logic; and representing the monetary value of the target data with the negation flag in negative form.
[0027] According to one technical solution, by configuring the negation marking logic in the third configuration file, business scenarios that need to be reversed or processed are dynamically identified, and the target data is automatically marked with a negation mark, thereby representing its amount in negative form. This achieves flexible configuration and automated processing of financial reversal operations, ensuring data accuracy and consistency of business semantics.
[0028] In some implementations, after obtaining the verification result, the method further includes: marking the target data with a tax splitting identifier when the third configuration file contains tax splitting logic; and splitting the transaction amount of the target data with the tax splitting identifier into a tax amount and a tax-exclusive amount.
[0029] Based on one technical solution, flexible configuration and automated processing of price and tax separation were achieved, improving the standardization of financial data and the accuracy of bookkeeping.
[0030] In some implementations, after converting at least some financial parameters of the target data into field names that satisfy naming rules according to the conversion logic of the second configuration file, the method includes: when the field name contains an accounting entity, determining the tax rate of the target data based on the role of the accounting entity.
[0031] Based on one technical solution, the process of obtaining tax rates was automated and adapted to business needs, thereby improving the accuracy and flexibility of tax processing.
[0032] In some implementations, after triggering the target execution program to execute the target configuration file on the target data and obtain the processing result of the target data, the method further includes: calling the accounting system to record the processing result and forming a target bill.
[0033] According to one technical solution, by calling the accounting system to persist the processing results as standard financial statements, closed-loop management from business data to accounting records is achieved, ensuring the traceability, consistency and compliance of financial information.
[0034] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform a data processing method according to any embodiment of this disclosure.
[0035] According to another aspect of this disclosure, a readable storage medium is provided, wherein executable instructions are stored therein, which, when executed by a processor, are used to implement a data processing method according to any embodiment of this disclosure.
[0036] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a data processing method according to any embodiment of this disclosure. Attached Figure Description
[0037] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.
[0038] Figure 1 This is a schematic diagram illustrating an application scenario of the data processing method according to the embodiments of this disclosure.
[0039] Figure 2 This is a flowchart of a data processing method according to an embodiment of the present disclosure.
[0040] Figure 3This is a schematic diagram of the inter-system interaction process according to an embodiment of the present disclosure.
[0041] Figure 4 This is a schematic diagram of the accounting process according to an embodiment of the present disclosure.
[0042] Figure 5 This is a schematic block diagram of the structure of a data processing apparatus according to an embodiment of the present disclosure.
[0043] Figure 6 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation
[0044] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.
[0045] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.
[0046] As a core system for enterprises, the financial system needs to uniformly support diverse business scenarios. For example, in real estate operations, the financial system needs to interface with numerous businesses such as integrated decoration supply chains, apartment rentals, and property sales. These businesses differ significantly in the field definitions, types, validation rules, and processing logic of financial data: for instance, the supply chain focuses on purchase orders, supplier settlement cycles, and input tax, while the rental business emphasizes rental cycles, deposit rules, and lease termination settlements. Writing hard-coded logic for each business is not only costly to develop, but also requires code modification, retesting, and re-deployment whenever a new business is added (e.g., adding home decoration installment payments) or existing logic is adjusted (e.g., changing the deposit calculation method), making business expansion difficult and response slow. Furthermore, business personnel cannot participate in rule configuration; all changes rely on technical personnel, resulting in poor flexibility. This model easily becomes a bottleneck when facing high-frequency iterations or rapid integration of new businesses, failing to meet the core requirements of modern financial systems: "rapid response and flexible expansion."
[0047] Therefore, this disclosure proposes a data processing method.
[0048] Figure 1 This is a schematic diagram illustrating an application scenario of the data processing method according to embodiments of this disclosure. For example... Figure 1As shown, in this application scenario, a server 100 and a terminal device 200 may be included. The server 100 and the terminal device 200 can connect via a network or Bluetooth to exchange data. The server 100 can be a cloud server or a physical server, and the terminal device 200 can be a smart device such as a computer, mobile phone, or tablet. The server 100 provides the basic data required to run the data processing method, and the terminal device 200 executes the data processing method of this disclosure based on the basic data provided by the server 100.
[0049] Figure 2 This is a flowchart of a data processing method according to an embodiment of the present disclosure. The following is in conjunction with… Figure 2 For data processing method M200, steps S210 to S230 are proposed to decouple the processing logic of financial data from the code through configuration management, thereby improving the flexibility and maintainability of the financial system.
[0050] Step S210: Generate a configuration file that can process financial data in business services.
[0051] Business services define the data characteristics of financial data across three dimensions: the business department, business type, and transaction type. Typically, financial data describing different business services possess different characteristics. For example, in the apartment rental department's room rental business, the transaction type might include fields such as "rent" and "deposit"; in the whole-house furnishing supply chain department's procurement business, the transaction type might include fields such as "purchase amount." Field values under different field definitions can have different types, such as strings, numbers, and dates, leading to differences in the corresponding validation and conversion rules and other processing logic. It's important to note that financial data belonging to the same business service, with the same field definitions and types, are subject to the same processing logic.
[0052] Financial data consists of structured business records generated by various business departments when cash flows or financial changes occur. It covers various economic matters such as income, expenses, receivables, payables, and asset changes. To achieve unified management and automated processing of the financial system, each piece of financial data is clearly labeled with its respective business department, business type, and transaction type. These three dimensions together constitute its complete business context identifier, which is the core basis for the financial system to perform data identification, logical matching, and accounting processing.
[0053] Among them, the business department refers to the organization to which the data originates, such as "apartment leasing department", "whole-house furnishing supply chain department", "financial services department", etc., used to distinguish different business lines or responsible entities; business type refers to the major business category associated with the financial data, reflecting its core business attributes, such as "property acquisition business", "property rental business", "sales business", "insurance compensation", "internal transfer", etc.; while transaction type further refines the specific operational scenarios and behavioral nature, such as "rent collection", "deposit refund", "purchase payment", "contract cancellation", "service fee settlement", etc., used to accurately describe the specific driving force and business meaning of each financial change.
[0054] By combining these three dimensions, the financial system can uniquely identify the business identity of a single piece of financial data. For example, "Apartment Leasing Department - Room Rental Business - Rent Collection" and "Supply Chain Department - Procurement Business - Procurement Payment" belong to completely different business services, with different data structures, field definitions, validation rules, and conversion logics. Conversely, all data belonging to "Apartment Leasing Department - Leasing Business - Deposit Refund" share highly consistent data characteristics and processing logic, facilitating standardized and configurable processing by the financial system. Therefore, multi-dimensional business service positioning of financial data is not only the foundation for flexible business access and efficient processing but also a crucial prerequisite for supporting automated processing of subsequent validation, conversion, tax breakdown, and other full-process procedures.
[0055] The configuration files provide standardized and scalable data processing logic for different business services. Each configuration file should correspond to a specific business service it can handle. A configuration file may consist of multiple parts, such as a first configuration file, a second configuration file, and a third configuration file. The first configuration file records the validation logic, the second configuration file records the conversion logic, and the third configuration file records the logic for determining whether a reconciliation operation is needed. Additionally, depending on the business service, the third configuration file may also include inversion flag logic and / or tax splitting logic. If a new business service is added, the corresponding processing logic is configured based on the data characteristics of that business service to form a new configuration file. Of course, if an existing configuration file is applicable to a new business service, the existing configuration file can simply be associated with the new business service.
[0056] Step S220: A hot-load index is formed, which records the association between the business services corresponding to the financial data and the executable programs that can call the configuration file.
[0057] The executor is the program code used to call and execute the processing logic defined in the configuration file. It is typically implemented in the Java programming language and is considered hard-coded. However, the program itself does not contain specific business rules; instead, it dynamically executes corresponding verification, conversion, and tax splitting operations based on the configuration file loaded at runtime. This decouples business logic from the code, significantly reducing redundant coding and maintenance costs. Furthermore, when the processing logic of multiple business services shares commonalities, their configuration files can be parsed and executed by the same executor, enabling the sharing and reuse of executors. This further enhances the flexibility and scalability of the financial system and minimizes system coding costs.
[0058] Business services can be associated with executable programs by adding tags to them. In other words, the tags of an executable program specify which business services it belongs to. This allows the executable program to call the configuration files of the corresponding business services, process the financial data belonging to those services, and obtain the results. The tags of an executable program should also include its identifier (e.g., program name).
[0059] The hot-load index is used to record the mapping relationship between business services and executors, that is, to clarify "which business service should be handled by which executor". Furthermore, the hot-load index has dynamic update capabilities, allowing it to flexibly adapt to new business services: after determining the appropriate executor for a new business service, the mapping relationship between the two can be added immediately, ensuring that subsequent calls to the business service can be accurately routed to the corresponding executor.
[0060] Specifically, when creating an executor, tags containing the identifiers of the business services and the executor are added to its code annotations based on the business services it supports. Simultaneously, during deployment, these annotations are scanned to automatically register each business service and its corresponding program identifier (such as a Bean name or classpath) in the hot-loading index. For scenarios where multiple business services share the same executor, they can point to the same program identifier, achieving program reuse. During subsequent runtime, when the system receives a request to process financial data, it first parses the business service identifier, then quickly searches and locates the matching executor identifier in the hot-loading index, and then loads and triggers the corresponding executor to call the configuration file, completing configuration-based dynamic routing and processing. This approach decouples the processing logic from the execution code, improving the system's flexibility and maintainability.
[0061] Step S230: In response to the request to process the target data, determine the target executor that can call the target configuration file in the hot-load index.
[0062] Target data refers to the financial data to be processed, which includes the relevant business department, business type, and transaction type to fully identify its corresponding "target business service." Based on this target business service, a matching search is performed in the hot-loaded index to locate the "target execution program" that can process this business service. The "target configuration file" refers to a pre-configured set of processing rules specifically applicable to this target business service, containing specific logic such as validation, transformation, and tax splitting. Through this key identifier of business service, precise binding and dynamic invocation from data to execution program and configuration file are achieved, ensuring the accuracy and flexibility of financial processing.
[0063] Step S240: Trigger the target executable program to execute the target configuration file on the target data and obtain the processing result of the target data.
[0064] The target configuration file can include validation logic, transformation logic, and judgment logic for whether to perform reconciliation operations on the target data. Of course, it can also have inverted marking logic or tax splitting logic, depending on the data characteristics of the target data.
[0065] The processing result is the output generated after the target data has undergone the execution program's invocation of the various logics in the corresponding configuration file. This result includes not only standardized financial information processed through logic such as field validation, field conversion, tax splitting, reconciliation marking, and inversion, but may also include auxiliary information such as processing status, validation pass indicators, error codes (e.g., validation failure), and log context. The processing result strictly adheres to the processing logic defined by the target business service, ensuring data accuracy, consistency, and business compliance. Ultimately, it can be used for subsequent accounting and reconciliation processes, serving as a crucial link between the business system, reconciliation system, and accounting system.
[0066] Figure 3 This is a schematic diagram of the inter-system interaction process according to embodiments of the present disclosure. (Reference) Figure 3 The data processing involves interaction between multiple systems, including business systems, ledger systems, reconciliation systems, and accounting systems. The following is a detailed explanation of the multi-terminal interaction process.
[0067] The financial system comprises three components: the ledger system, the reconciliation system, and the accounting system. The ledger system processes raw financial data, transforming it into structured and semantically clear intermediate financial data. The reconciliation system compares data from different sources, such as internal transaction records and external payment flows, determining the reconciliation status (e.g., reconciled, unreconciled, anomaly), ensuring data consistency and fund security. The accounting system then records the data processed by the ledger system into invoices, completing the final transformation from business to finance, supporting financial statements and compliant disclosures.
[0068] Depending on the types of services a company provides, it may have multiple business systems, such as business system A, business system B through business system N, where the value of N is determined based on the company's actual operational scenarios and is not limited here. All these business systems are connected to the ledger system. When financial changes occur in these business systems, step 301 is executed to synchronize the resulting target data to the ledger system.
[0069] The ledger system receives target data from various business systems. It should be noted that each business system typically corresponds to one or more business services. However, since all this financial data is processed through the same ledger system, the aforementioned data processing methods are required to personalize the financial data based on the business services provided.
[0070] For financial data that requires reconciliation, the ledger system will execute step 302, sending the financial data to be reconciled to the reconciliation system to invoke the reconciliation system to reconcile the financial data, and then execute step 303, whereby the reconciliation system will feed back the reconciliation results to the ledger system.
[0071] Furthermore, the ledger system can process the reconciliation results. For example, in response to reconciliation cancellation data in the reconciliation results, the amount value in the reconciliation cancellation data can be inverted.
[0072] Furthermore, in step 304, the ledger system synchronizes the processing results to the accounting system. The processing results here include the processing results of the reconciliation results returned by the reconciliation system and the processing results of the target data.
[0073] Further, the accounting system executes step 305, which parses and records the processing results to form the target bill.
[0074] Figure 4 This is a schematic diagram of the accounting process according to an embodiment of this disclosure. The following is in conjunction with… Figure 4 Explain the complete bookkeeping process.
[0075] In step 401, a configuration file is generated based on the introduced business services.
[0076] Configuration files can include a first configuration file, a second configuration file, and a third configuration file. When introducing a new business service, a configuration file should be created based on the data characteristics of the business service to provide a processing basis for subsequent execution programs. Configuration logic is usually recorded in the form of corresponding field names and field values, which is convenient for non-technical personnel such as business personnel to configure and reduces the difficulty of configuration. The field name is the definition of the field, and the field value is the requirement that the field should meet.
[0077] The first configuration file includes validation logic to verify the compliance and validity of financial data. For example, it checks if the value of the "Amount" field is between its maximum and minimum values; it checks if the length of the field value is less than a length threshold; if the payment method is "01," indicating online payment, then the payment transaction number field cannot be empty; if the payment method is "04," indicating bank card payment, then the payee / payer account field cannot be empty, etc. The validation logic is determined based on the data characteristics of the business services and is not restricted here. Furthermore, the first configuration file should correspondingly have the business services it can process, including the business department to which the financial data belongs, the business type, and the transaction type.
[0078] If field validation fails, a corresponding failure message will be automatically returned to the business system, and subsequent parameter input processes will not proceed. If validation passes, the processing in the second configuration file will be executed.
[0079] The second configuration file contains conversion logic to transform raw field parameters in financial data into unified field names that conform to the naming conventions of the financial system, achieving data standardization and consistency management between systems. For example, in the business system, "mdmcode" represents the accounting entity, while in the financial system, "subject" is used to represent the same meaning. To facilitate subsequent accounting processing, reconciliation analysis, and ledger management, business-side fields such as "mdmcode" need to be mapped to the standard field name "subject identifier" in the financial system through configuration rules. This type of conversion not only covers renaming field names but also includes unifying data formats, units, and coding systems, thereby eliminating semantic differences between systems and improving the readability, maintainability, and automation efficiency of financial data.
[0080] Additionally, the second configuration file also includes tax rate configuration logic. When the conversion logic includes conversion of the accounting entity, it identifies the role of the accounting entity and determines the appropriate tax rate for that entity. If the field conversion does not include conversion of the accounting entity, then the default tax rate is used as the tax rate for that entity.
[0081] The third configuration file contains file marking logic, which is used at least to determine whether financial data requires reconciliation. This file marking logic can be at least one of the following sub-logic: reconciliation operation judgment logic, negation marking logic, tax splitting logic, etc.
[0082] Regarding the reconciliation operation judgment logic, if a business service needs to perform a reconciliation operation, then the first configuration file should record "enablereconcile (reconciliation switch): true", meaning that all financial data belonging to this business service needs to undergo reconciliation. This logic should also configure some labeling requirements for financial data, such as determining its business type, business code, and business name, to facilitate subsequent reconciliation operations; no restrictions are imposed here.
[0083] The negation flag logic is used to determine whether a value in the financial data needs to be negated. Data marked with the negation flag will be negated, meaning the monetary value will be represented as a negative number, such as recording "1000 yuan" as "-1000 yuan". For example, in the "transaction voided" type, the transaction process will be recorded in a negated manner instead of being directly deleted, making the transaction process traceable.
[0084] The tax splitting logic is used to determine whether financial data needs to undergo tax splitting. Transaction data marked with the tax splitting flag will have its transaction amount split into a tax amount and a tax-exclusive amount. In other words, transaction data marked with the tax splitting flag will undergo tax splitting, for example, splitting "1000 yuan" into a tax-exclusive amount of 950 yuan and a tax amount of 50 yuan.
[0085] In step 402, the executor is determined for the configuration file.
[0086] An executable program is a runnable unit of code responsible for executing a configuration file, typically existing as a class or service (such as a Service class in Java). It serves as the entry point for processing various logics within the configuration file, capable of validating, transforming, and marking input financial data according to the configuration file. The processing behavior of an executable program often relies on an external configuration file to drive it, thus achieving "one program handling multiple business processes." For example, in a financial system, an accounting executable program can universally handle entry requests in different scenarios, with specific behaviors defined by the configuration file and dynamically invoked through business services, enabling flexible and scalable business support.
[0087] The comments section of the executable program contains tags that record the business services the executable program can handle and the program identifier. Each executable program can be used for one or more business services, and the number of business services it corresponds to indicates the processing capacity of the executable program.
[0088] In some implementations, when a new business service is added, it is necessary to determine whether an existing executable program capable of calling the configuration file exists. If an existing executable program capable of calling the configuration file exists, a new tag can be added to the annotation of the corresponding executable program without modifying the core scheduling code, thus enabling flexible expansion. If no existing executable program capable of calling the configuration file exists, a new executable program can be generated based on the new business service and its corresponding configuration file; this executable program also drives its processing behavior through the corresponding configuration file and is annotated with the corresponding tags after generation.
[0089] Furthermore, the tag registration of the executable program generates a hot-loading index. The program identifier and the corresponding business services that can be supported are stored in the hot-loading index. When this method runs, it can dynamically call the corresponding executable program and configuration file through the business services of financial data, so as to realize a configuration-driven and highly scalable scheduling mechanism.
[0090] In step 403, the business services for the target data are determined.
[0091] The target data is the financial data to be processed. Each piece of financial data is labeled with a corresponding business service when it is generated, including the business department, business type and transaction type.
[0092] Further, in step 404, the executable program corresponding to the business service is located in the hot-load index. Referring to the foregoing, the hot-load index records the program identifier and the supported business services. By finding the program identifier corresponding to the target business service, the target executable program can be located. Then, step 405 is executed, triggering the executable program to process the target data.
[0093] Specifically, the execution program is triggered to execute the verification logic of the first configuration file to verify the target data. If the verification is successful, the conversion logic in the second configuration file is executed to convert the financial parameters that need field conversion into field names that meet the naming rules. If the converted financial parameters contain an accounting entity, the tax rate of that accounting entity is determined based on its role. If the converted field names do not contain an accounting entity, the default tax rate can be used, without restriction. Simultaneously, the reconciliation operation judgment logic of the third configuration file can be executed to determine whether the financial data under the current business service needs to undergo reconciliation. If reconciliation is required, a reconciliation flag is marked for the financial data. Additionally, if the third configuration file also contains negation flag logic, a negation flag is marked for the financial data; if the third configuration file also contains tax splitting logic, a tax splitting flag is marked for the financial data.
[0094] Furthermore, perform a reverse operation on financial data with a reverse flag; and perform a split operation on tax amount and non-tax amount on financial data with a tax split flag.
[0095] Of course, if the verification fails, a failure message will be returned directly so that the business system can optimize and adjust the financial data.
[0096] Further, step 406 is executed to determine if there is a reconciliation flag. That is, to determine whether the financial data requires a reconciliation operation. If there is a reconciliation flag, step 407 is executed to call the reconciliation system to reconcile the target data; and the reconciliation result is synchronized to the ledger system. If no reconciliation operation is required, step 410 is executed to trigger the accounting system to record the processing result of the ledger system, forming the target invoice.
[0097] Furthermore, in step 408, when a cancellation operation is triggered due to reconciliation errors or business reversals, corresponding cancellation data is generated to indicate the invalidation or rollback of the reconciliation action. Subsequently, in step 409, key fields (such as amount and quantity) in these cancellation data are inverted, that is, the original values are converted into their opposites to accurately reflect the semantics of reversal or reverse adjustment in financial processing, ensuring the accuracy and consistency of subsequent ledger records and accounting results.
[0098] Furthermore, the reconciliation results are synchronized to the ledger system, which then executes step 410, triggering the accounting system to record the processing results and form the target invoice. Of course, if it is found in step 408 that the target data does not contain reconciliation cancellation data, then step 410 is executed directly.
[0099] By constructing a multi-dimensional dynamic configuration mechanism, high cohesion, low coupling, and comprehensive configurability of the financial accounting logic are achieved. This effectively supports rapid access for various business scenarios, significantly reduces the development cost of business access, and improves the response speed for configuration changes. While ensuring the stability of the financial system, it greatly enhances the flexibility, maintainability, reusability, and scalability of the financial system.
[0100] Figure 5 This is a schematic block diagram of the structure of a data processing apparatus according to embodiments of the present disclosure. For example... Figure 5As shown, the data processing device 500 includes: a configuration module 510, used to generate a configuration file capable of processing financial data in business services, wherein the business services include the business department to which the financial data belongs, the business type, and the transaction type, and the configuration file records the data processing logic adapted to the business services; a program configuration module 520, used to associate the business services corresponding to the financial data with the executable programs that can call the configuration file to form a hot-loading index; a program calling module, used to respond to a processing request for target data, and determine the target executable program that can call the target configuration file in the hot-loading index, wherein the target configuration file is a configuration file applicable to the target business service to which the target data belongs; and a processing module 530, used to trigger the target executable program to execute the target configuration file on the target data to obtain the processing result of the target data.
[0101] The data processing apparatus 500 disclosed herein may be in the form of computer software, and each module of the data processing apparatus 500 may be in the form of computer software modules.
[0102] The various modules of the data processing apparatus 500 disclosed herein are set up to implement the various steps of the data processing method. Their execution principles and steps can be referred to the preceding text and will not be repeated here.
[0103] Figure 6 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure. Figure 6 As shown, this disclosure also provides an electronic device 1000, including: a processor 1200 and a memory 1300, the memory 1300 storing execution instructions; the processor 1200 executes the execution instructions stored in the memory 1300, causing the processor 1200 to execute a data processing method.
[0104] The hardware architecture of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application of the hardware and overall design constraints. Bus 1100 connects various circuits, including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400, such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.
[0105] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one connection line is used in this diagram, but this does not imply that there is only one bus or only one type of bus.
[0106] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.
[0107] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.
[0108] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.
[0109] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, electronic devices, readable storage media, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0110] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0112] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0113] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.
[0114] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0115] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.
Claims
1. A data processing method, characterized in that, include: Generate a configuration file capable of processing financial data in business services, wherein the business services include the business department to which the financial data belongs, the business type, and the transaction type, and the configuration file records the data processing logic adapted to the business services; A hot-load index is created that records the association between the business services corresponding to the financial data and the executable programs that can call the configuration file; In response to a request to process target data, a target executable program that can invoke the target configuration file is determined in the hot-load index. The target configuration file is a configuration file applicable to the target business service to which the target data belongs. as well as The target executable program is triggered to execute the target configuration file on the target data to obtain the processing result of the target data.
2. The data processing method according to claim 1, characterized in that, Generate configuration files capable of processing financial data in business services, including: Generate a first configuration file containing verification logic. The financial data includes financial parameters and parameter values. The verification logic is the logic to determine whether the parameter values meet the numerical requirements of the corresponding financial parameters. Generate a second configuration file containing conversion logic, wherein the conversion logic converts some financial parameters in the financial data into field names that meet the naming rules; A third configuration file containing file tagging logic is generated, which is at least used to determine that the financial data requires reconciliation.
3. The data processing method according to claim 2, characterized in that, Generate a third configuration file containing file tagging logic, including: When the transaction type of the business service is transaction void, the negation mark logic is determined. The negation mark logic is a sub-logic of the file mark logic. The negation mark logic is used to determine that the financial data needs to be negated. The negation operation means recording the amount value in the financial data in negative form.
4. The data processing method according to claim 2, characterized in that, Generate a third configuration file containing file tagging logic, including: Based on the transaction type of the business service, a tax splitting logic is determined. The tax splitting logic is a sub-logic of the file marking logic. The tax splitting logic is used to determine that the financial data needs to undergo a tax splitting operation. The tax splitting operation means splitting the transaction amount of the financial data into a tax amount and a tax-exclusive amount.
5. The data processing method according to claim 1, characterized in that, Before forming a hot-loaded index that records the association between the business service corresponding to the financial data and the executor capable of processing the business service, the process includes: Determine if an existing executable program exists that can call the configuration file; When no existing executable program exists that can call the configuration file, an executable program that can call the configuration file is generated, and a tag is configured for the executable program. The tag records the business services that the executable program can handle and the program identifier of the executable program.
6. The data processing method according to claim 1, characterized in that, Before determining the target executor capable of invoking the target configuration file in the hot-load index in response to a request to process the target data, the process includes: In response to a request to process the target data, the target business department, target business type, and target transaction type are read from the target data to determine the target business service.
7. The data processing method according to claim 6, characterized in that, In response to a request to process target data, the target executor that can invoke the target configuration file is determined from the hot-load index, including: The program identifier corresponding to the target service is determined in the hot-load index, and the executor with the program identifier is used as the target executor.
8. The data processing method according to claim 1, characterized in that, Obtaining the processing result of the target data includes: The target data is validated according to the validation logic in the first configuration file to obtain the validation result; and, When the verification result is a failure, a failure message is issued.
9. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the data processing method according to any one of claims 1 to 8.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the data processing method according to any one of claims 1 to 8.