A service transaction data processing method, device, equipment and storage medium

Abstract

The application provides a business transaction data processing method and device, equipment and a storage medium, relates to the technical field of financial accounting, and comprises the following steps: obtaining a bill generation request from a business end; generating a target financial scenario code corresponding to business transaction data according to a billing dimension in the business transaction data; generating a target transaction bill according to the business transaction data and the target financial scenario code; matching a corresponding target voucher template from a preset target voucher template library according to the target financial scenario code; and generating a financial voucher associated with the target transaction bill according to the target voucher template and the target transaction bill. The application can improve the efficiency of financial accounting.

Description

Technical Field

[0001] This application relates to the field of financial accounting technology, and more specifically, to a business transaction data processing method, apparatus, device, and storage medium. Background Technology

[0002] With the diversification of business models in the leasing industry, the frequency of transactions throughout the entire lifecycle of leasing—before, during, and after the lease—has increased significantly. Different business scenarios correspond to different rules for generating financial vouchers, and the same type of business may also require different voucher entries due to different accounting dimensions.

[0003] Existing financial accounting systems typically use a direct connection between business modules and financial modules, with each business line independently implementing its integration logic with the financial system. When new business types need to be added or financial accounting dimensions need to be adjusted, the integration code for each business module must be customized, resulting in high development costs, significant testing difficulties, and high deployment risks. Furthermore, finance personnel must anticipate all possible combinations of accounting dimensions and configure corresponding voucher templates for all scenarios, leading to an uncontrollable number of templates and tedious, error-prone configuration work. In addition, the disconnect between business transaction data and financial accounting data makes it difficult to quickly trace discrepancies in accounting records, severely complicating financial reconciliation.

[0004] This traditional direct-connect architecture can no longer meet the needs of leasing companies for rapid business expansion, and there is an urgent need for a technical solution that can achieve standardized connection between business transactions and financial accounting. Summary of the Invention

[0005] This application provides a business transaction data processing method, apparatus, device, and storage medium, which can improve financial accounting efficiency.

[0006] In a first aspect, embodiments of this application provide a business transaction data processing method applied to a billing intermediary layer, the method comprising: Obtain a bill generation request from the business side, the bill generation request including: business transaction data; Based on the accounting dimensions in the business transaction data, generate the target financial scenario code corresponding to the business transaction data; Based on the business transaction data and the target financial scenario code, generate the target transaction bill; Based on the target financial scenario code, match the corresponding target voucher template from the preset target voucher template library; Based on the target voucher template and the target transaction invoice, generate financial vouchers associated with the target transaction invoice.

[0007] Optionally, the bill generation request further includes: bill type; before generating the target financial scenario code corresponding to the business transaction data based on the accounting dimensions in the business transaction data, the method further includes: Based on the pre-selected accounting dimensions corresponding to the bill type, the business transaction data is validated according to the pre-selected accounting dimensions; If the verification of the pre-selected accounting dimension passes, the target financial scenario code is generated based on the accounting dimension in the business transaction data.

[0008] Optionally, generating the target transaction bill based on the business transaction data and the target financial scenario code includes: According to the amount detail configuration rules corresponding to the bill type, the amount detail items in the business transaction data are validated. If the amount details pass the verification, a target transaction bill corresponding to the business transaction data is generated based on the business transaction data and the target financial scenario code.

[0009] Optionally, before matching the corresponding target voucher template from the preset target voucher template library based on the target financial scenario code, the following steps are included: Obtain the financial scenario codes corresponding to multiple business scenarios; Configure a corresponding voucher template for each of the financial scenario codes to obtain the correspondence between multiple financial scenario codes and voucher templates.

[0010] Optionally, obtaining the financial scenario codes corresponding to multiple business scenarios includes: Obtain the bill type for each of the aforementioned business scenarios; The multiple accounting dimensions corresponding to the bill types of each business scenario are arranged and combined to obtain multiple accounting dimension combinations; Based on the combination of multiple accounting dimensions, multiple financial scenario codes corresponding to the business scenarios are generated respectively.

[0011] Optionally, generating a financial voucher associated with the target transaction invoice based on the target voucher template and the target transaction invoice includes: Based on the pre-defined mapping relationship between the bill amount details and debit / credit accounts in the target voucher template, and the amount details in the target transaction bill, voucher entries are generated. The voucher entries are verified, and if the verification is successful, a financial voucher associated with the target transaction invoice is generated.

[0012] Optionally, the step of verifying the voucher entry and generating a financial voucher associated with the target transaction invoice after successful verification includes: Based on the amount details in the voucher entry, the amount details range of the voucher entry is verified; If the range of the amount details passes the verification, a debit and credit balance verification is performed based on the total debit and credit amounts of the voucher entries. If the loan balance verification passes, a financial voucher associated with the target transaction invoice is generated.

[0013] Secondly, embodiments of this application also provide a business transaction data processing apparatus, the apparatus comprising: The acquisition module is used to acquire bill generation requests from the business side, and the bill generation requests include: business transaction data; The generation module is used to generate a target financial scenario code corresponding to the business transaction data based on the accounting dimension data in the business transaction data; and to generate a target transaction bill corresponding to the business transaction data based on the business transaction data and the target financial scenario code. The matching module is used to match the corresponding target voucher template from the preset target voucher template library based on the target financial scenario code; The generation module is further configured to generate financial vouchers associated with the target transaction invoice based on the target voucher template and the target transaction invoice.

[0014] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus, wherein the memory stores program instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the program instructions to perform the steps of the business transaction data processing method as described in any of the first aspects. Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the business transaction data processing method as described in any of the first aspects.

[0015] This application provides a business transaction data processing method, apparatus, device, and storage medium applied to an invoice middleware layer. This method introduces an independent invoice middleware layer as a unified connection between the business and financial ends, achieving automated and standardized processing of business transaction data into financial vouchers. First, an invoice generation request from the business end is obtained, carrying business transaction data. Then, based on the accounting dimension information in the business transaction data, a target financial scenario code uniquely corresponding to the transaction is generated. Next, combining the business transaction data and the target financial scenario code, a standardized target transaction invoice is generated, completing the standardized conversion of business data to invoice data. Furthermore, using the target financial scenario code as a match, a target voucher template corresponding to the scenario code is retrieved and matched from a preset target voucher template library. Finally, based on the matched target voucher template and the amount details in the target transaction invoice, a financial voucher associated with the target transaction invoice is automatically generated. By introducing an independent billing middleware layer between the business and financial systems using this approach, and establishing a standardized reconciliation relationship between business transactions and voucher templates through financial scenario codes, each business transaction can automatically match pre-configured voucher templates and generate financial vouchers. This not only significantly improves the automation level of financial accounting, but more importantly, through the unified collection and standardized processing of business data by the billing middleware layer, adding new business types or adjusting accounting dimensions only requires simple operations in the configuration interface, without the need for customized code development for each business module. This significantly reduces the development costs and launch risks of iterative upgrades, reduces the tedious work of financial personnel, and improves the response speed of financial personnel and the accuracy and consistency of financial data. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a business transaction data processing method provided in an embodiment of this application; Figure 2 A flowchart illustrating the process of obtaining the target financial scenario code in a business transaction data processing method provided in this application embodiment; Figure 3 A flowchart illustrating the process of obtaining a target transaction bill in a business transaction data processing method provided in this application embodiment; Figure 4 A flowchart illustrating the process of obtaining a target voucher template in a business transaction data processing method provided in this application embodiment; Figure 5 A flowchart illustrating the process of obtaining a financial scenario code in a business transaction data processing method provided in this application embodiment; Figure 6 A schematic diagram illustrating the process of generating financial vouchers in a business transaction data processing method provided in this application embodiment; Figure 7 A flowchart illustrating the generation of financial vouchers in another business transaction data processing method provided in this application embodiment; Figure 8 A schematic diagram of a business transaction data processing device provided in an embodiment of this application; Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0019] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] Before providing a detailed explanation of this application, let's first introduce its application scenarios.

[0022] Taking a comprehensive leasing company as an example, its business lines may cover multiple sectors such as commercial vehicle financial leasing, passenger vehicle operating leasing, and equipment leasing. Each business sector includes different business scenarios such as down payments, monthly payments, early repayments, and overdue processing. The financial accounting rules differ significantly under different scenarios. Even within the same scenario, different voucher entries may be required due to differences in accounting dimensions such as customer type, term structure, and invoice type. In the traditional business processing model, whenever a new business type is added or accounting rules are adjusted, developers need to modify the interface code between each business system and the financial system one by one. Financial personnel need to anticipate all dimension combinations and configure massive amounts of voucher templates. This is not only inefficient but also prone to errors, leading to frequent problems such as difficulties in reconciliation at the end of the month and delays in business launch. It is against this backdrop of increasingly prominent contradictions between business complexity and system adaptability that this application provides a business transaction data processing method based on a billing middleware layer.

[0023] Based on this, this application provides a business transaction data processing method, apparatus, device and storage medium, applied to the billing middleware layer. This method introduces an independent billing middleware layer as a unified connection carrier between the business end and the financial end, thereby realizing the automated and standardized processing of business transaction data into financial vouchers. First, a bill generation request is received from the business side, carrying business transaction data. Then, based on the accounting dimension information in the business transaction data, a target financial scenario code uniquely corresponding to the transaction is generated. Next, combining the business transaction data and the target financial scenario code, a standardized target transaction bill is generated, completing the standardization conversion of business data to bill data. Then, using the target financial scenario code as a match, a target voucher template corresponding to the scenario code is retrieved and matched from a pre-set target voucher template library. Finally, based on the matched target voucher template and the amount details in the target transaction bill, financial vouchers associated with the target transaction bill are automatically generated. This allows adding new business types or adjusting accounting dimensions to be done simply through the configuration interface, without requiring customized code development for each business module. This significantly reduces the development costs and deployment risks of iterative upgrades, reduces the tedious work of finance personnel, and improves the response speed of finance personnel and the accuracy and consistency of financial data.

[0024] The following explanation, in conjunction with the accompanying drawings, illustrates several embodiments. The business transaction data processing method provided in this application can be executed by a billing middleware layer. This middleware layer is a data processing platform independently deployed between the business and financial ends. It is used to uniformly collect, standardize, and connect financial accounting for business transaction data throughout the entire lifecycle of the leasing industry, including pre-leasing, during-leasing, and post-leasing stages. It is the processing layer for the flow of business transaction data to the generation of financial vouchers. All business transaction data requiring financial accounting must complete the subsequent processing through this billing middleware layer, thereby achieving standardized connection and automated processing of business transaction data and financial accounting data.

[0025] Figure 1 This is a flowchart illustrating a business transaction data processing method provided in an embodiment of this application, as shown below. Figure 1 As shown, this business transaction data processing method, applied to the billing middleware layer, includes: S101, Obtain the bill generation request from the business side. The bill generation request includes: business transaction data.

[0026] First, the billing middleware layer receives bill generation requests from the business side. Optionally, the business side can be various business systems of the leasing company, such as pre-lease management system, mid-lease business platform, post-lease asset management system, etc.

[0027] The bill generation request triggers the billing middleware layer to initiate the processing flow of business transaction data. This request contains business transaction data. Business transaction data refers to core data generated by the business side during specific business operations that requires financial accounting. This data includes, but is not limited to: business type identifiers (such as financial leasing and operating leasing), transaction amount information (such as principal, interest, and handling fees), transaction participant information (such as customer name and customer type), transaction time information (such as lease start date and repayment date), and accounting dimension information required for financial accounting (such as business line, product type, and customer attributes).

[0028] In one possible implementation, the business side pushes the bill generation request, encapsulated in JSON or XML format, to the billing middleware layer via a predefined Application Programming Interface (API). The billing middleware layer performs basic format validation on the received request to ensure that the request message structure is complete and that core fields are not empty. Requests with abnormal formats or missing key information are intercepted and error messages are returned.

[0029] S102, based on the accounting dimensions in the business transaction data, generate the target financial scenario code corresponding to the business transaction data.

[0030] After acquiring business transaction data, the billing middleware layer extracts accounting dimension information from the business transaction data. Accounting dimensions are business attributes used to distinguish different accounting standards during financial accounting, such as business line (commercial vehicle business, passenger vehicle business), customer type (individual customer, corporate customer), transaction status (normal repayment, overdue repayment), and invoice type (special invoice, general invoice), etc.

[0031] After extracting and parsing the complete business transaction data from the bill generation request, the billing middleware layer identifies the accounting dimension corresponding to the business transaction from the fields of the business transaction data through preset dimension recognition rules. The accounting dimension can be a single dimension or a combination of multiple dimensions.

[0032] The billing middleware layer has built-in preset financial scenario code generation rules. These rules are pre-configured according to the enterprise's financial accounting needs, corresponding one-to-one with accounting dimensions, enabling unique coding for different accounting dimensions or combinations of dimensions. The billing middleware layer identifies the accounting dimension of the business transaction data, substitutes it into the preset financial scenario code generation rules, and performs standardized coding processing on the accounting dimension according to the rules to generate a target financial scenario code that uniquely corresponds to the accounting dimension of the business transaction data. The target financial scenario code serves as a unique matching identifier connecting business transaction data and financial voucher templates, realizing the association between business transaction scenarios and financial accounting scenarios, and ensuring the accuracy of subsequent voucher template matching.

[0033] S103, generate the target transaction bill based on business transaction data and the target financial scenario code.

[0034] The target transaction invoice is a standardized, structured invoice generated by the intermediate invoice layer based on business transaction data. It is used to uniformly collect and store all financial accounting information related to this transaction. The target transaction invoice must include at least the following data fields: basic invoice information (such as invoice number, invoice type, and generation time), original business transaction data (such as transaction amount and counterparty), target financial scenario code, and detailed amount items required for the generation of subsequent financial vouchers (such as principal amount, interest amount, and handling fee amount).

[0035] In one possible implementation, the billing middleware layer maps each field in the business transaction data to the corresponding position in the bill according to a predefined billing data structure template, and writes the target financial scenario code into the financial scenario identifier field of the bill to form a structured target transaction bill, which is stored in the database of the billing middleware layer as the data source for the generation of subsequent financial vouchers.

[0036] S104. Based on the target financial scenario code, match the corresponding target voucher template from the preset target voucher template library.

[0037] It should be noted that the billing middleware layer is pre-configured with a target voucher template library, which stores the correspondence between multiple financial scenario codes and voucher templates. The voucher templates are preset voucher generation rules that define complete accounting processing rules for specific financial accounting scenarios, covering financial accounting information such as debit and credit accounting subjects, subject value rules, and accounting processing methods.

[0038] The preset target voucher template library adopts a storage structure indexed by financial scenario codes, supporting fast retrieval and matching based on these codes. After a target transaction invoice is generated, the invoice intermediate layer uses the target financial scenario code as the index key to search and match within the target voucher template library, finding the target voucher template that uniquely corresponds to that target financial scenario code.

[0039] The template matching process is fully automated by the billing middleware layer, requiring no manual intervention. This achieves accurate and rapid matching from business transaction scenarios to financial accounting templates, effectively avoiding mismatches and omissions caused by manual matching, and improving the efficiency and accuracy of financial voucher template matching. After obtaining the target voucher template, the billing middleware layer associates and stores it with the target transaction bill, preparing rules for the subsequent automatic generation of financial vouchers.

[0040] S105, Based on the target voucher template and the target transaction invoice, generate financial vouchers associated with the target transaction invoice.

[0041] After obtaining the target voucher template and the target transaction invoice, the invoice intermediate layer takes both as input, performs an automatic voucher generation operation, and finally outputs a financial voucher that is uniquely associated with the target transaction invoice.

[0042] Among them, financial vouchers are standardized accounting vouchers that comply with financial accounting standards and accounting systems, and at least include voucher header information (such as voucher date and voucher number), debit entry details (accounting subject and amount), credit entry details (accounting subject and amount), and related business document information.

[0043] In one possible implementation, the billing middleware parses the voucher structure definition in the target voucher template, obtaining the pre-defined list of debit and credit accounts, as well as the mapping relationship between the amounts of each account and the detailed amount items in the target transaction invoice. Simultaneously, it extracts the actual values ​​of each detailed amount item from the target transaction invoice and, according to the mapping rules defined in the template, fills the actual amounts into the corresponding account entries. Finally, it combines these to generate a complete financial voucher and stores it in association with the target transaction invoice. The financial voucher not only contains complete accounting information but also carries the corresponding target transaction invoice number and target financial scenario code, realizing the association between the financial voucher, the target transaction invoice, and business transaction data. The financial voucher and business transaction data can be traced through the invoice number or financial scenario code.

[0044] In this embodiment, an independent billing middleware layer is introduced between the business system and the financial system. A standardized reconciliation relationship between business transactions and voucher templates is established through financial scenario codes. This enables each business transaction to automatically match the pre-configured voucher template and generate financial vouchers. This not only significantly improves the automation level of financial accounting, but more importantly, through the unified collection and standardized processing of business data by the billing middleware layer, adding new business types or adjusting accounting dimensions only requires simple operations in the configuration interface. There is no need to develop customized code for each business module, which significantly reduces the development cost and launch risk of iterative upgrades, reduces the tedious work of financial personnel, and improves the response speed of financial personnel and the accuracy and consistency of financial data.

[0045] In the above Figure 1 Based on the corresponding embodiments, in order to more clearly demonstrate the process of obtaining the target financial scenario code, this application also provides a possible implementation method for obtaining the target financial scenario code in a business transaction data processing method. Figure 2 This is a flowchart illustrating the process of obtaining the target financial scenario code in a business transaction data processing method provided in an embodiment of this application. Figure 2 As shown, before generating the target financial scenario code corresponding to the business transaction data based on the accounting dimension in the business transaction data in S102 above, the method further includes: The bill generation request also includes: bill type.

[0046] Bill types are used to identify the specific scenario category to which a business belongs. In actual business operations, different scenarios correspond to different financial accounting requirements, which need to be distinguished by bill types. For example, the "Finance Lease - Direct Lease - Principal and Interest Bill" type is applicable to the regular repayment scenario of finance lease direct lease business, and principal and interest need to be accounted for separately; the "Finance Lease - Sale and Leaseback - Service Fee Bill" type is applicable to the scenario of service fees being charged separately in finance lease sale and leaseback business, and only service fee income needs to be accounted for; the "Operating Lease - Rent Bill" type is applicable to the scenario of periodic rent collection in operating lease business, and rent income and related taxes need to be accounted for. S210 verifies the pre-selected accounting dimensions of business transaction data based on the pre-selected accounting dimensions corresponding to the bill type.

[0047] Each bill type is pre-bound with corresponding pre-selected accounting dimensions during the configuration phase. These pre-selected accounting dimensions are the set of dimensions that must be provided when performing financial accounting for this type of bill, clarifying from which angles the transaction should be recorded financially. For example, the "Finance Lease - Direct Lease - Principal and Interest Bill" type must provide four dimensions: business line (commercial vehicle / passenger vehicle), customer type (individual / legal entity), term type (short-term / medium-to-long-term), and repayment status (on track / overdue); the "Finance Lease - Sale-Leaseback - Service Fee Bill" type must provide three dimensions: business line, customer type, and invoice type (special invoice / general invoice); and the "Operating Lease - Rent Bill" type must provide three dimensions: asset type, customer type, and lease nature (operating / financing).

[0048] Before generating the target financial scenario code, the billing middleware layer first obtains the pre-selected accounting dimensions corresponding to the current bill type, and then iterates through the accounting dimension fields in the business transaction data to verify one by one whether the business side has provided all the dimension values ​​required by the pre-selected accounting dimensions.

[0049] Specifically, if the current bill type is "Financial Leasing - Direct Lease - Principal and Interest Bill", its pre-selected accounting dimensions require four dimensions: "Business Line", "Customer Type", "Term Type", and "Repayment Status". The system then verifies whether the business transaction data simultaneously contains values ​​for all four dimensions. For example, if the accounting dimensions passed from the business end are: Business Line "Commercial Vehicle", Customer Type "Individual", Term Type "Medium-to-Long Term", and Repayment Status "Normal", the verification will pass. If "Term Type" is missing or any dimension is empty, the verification will fail, the process will terminate, and an error message will be returned.

[0050] In this way, each bill type is configured with a differentiated set of pre-selected accounting dimensions according to its actual financial accounting needs, and the integrity of the dimensions is verified before the scenario code is generated.

[0051] S220: If the verification of the pre-selected accounting dimension passes, generate the target financial scenario code based on the accounting dimension in the business transaction data.

[0052] Once the pre-selected accounting dimension passes the verification, the billing middle layer confirms that the current business transaction data meets the basic dimension requirements for financial accounting of this bill type. At this time, the target financial scenario code generation operation is initiated, that is, the scenario code generation step described in S102 is executed, and the verified accounting dimension is substituted into the preset financial scenario code generation rule to generate a unique target financial scenario code.

[0053] In this embodiment, by matching the bill type to pre-select the accounting dimensions and performing pre-verification, the completeness and compliance of the dimensions of business transaction data can be screened in advance. This avoids the failure of subsequent financial scenario code generation due to missing or incorrect core accounting dimensions, ensuring the accuracy of financial scenario code generation, reducing the subsequent processing of invalid data, and improving the data processing efficiency of the bill intermediate layer.

[0054] In the above Figure 2 Based on the corresponding embodiments, in order to more clearly demonstrate the process of obtaining the target transaction bill, this application also provides a possible implementation of obtaining the target transaction bill in a business transaction data processing method. Figure 3 This is a schematic diagram illustrating the process of obtaining a target transaction invoice in a business transaction data processing method provided in an embodiment of this application. Figure 3 As shown, in step S103 above, based on business transaction data and the target financial scenario code, a target transaction bill is generated, including: S310 performs amount detail verification on the amount detail items in the business transaction data according to the amount detail configuration rules corresponding to the bill type.

[0055] Each bill type has corresponding amount detail configuration rules pre-bound during the configuration phase. These rules define the range of amount detail items included in that type of bill. For example, the "Finance Lease - Direct Lease - Principal and Interest Bill" type includes the following amount detail items: principal, interest, and handling fee; the "Finance Lease - Sale and Purchase - Service Fee Bill" type includes the handling fee; and the "Operating Lease - Rent Bill" type includes the following amount detail items: rent, deposit, and management fee.

[0056] Before generating the target transaction bill, the billing middleware first obtains the amount detail configuration rules corresponding to the current bill type, and then iterates through the amount detail fields in the business transaction data to verify whether the amount detail items passed in by the business end are all within the range allowed by the rules.

[0057] Specifically, if the current bill type is "Financial Leasing - Direct Lease - Principal and Interest Bill", and its amount detail configuration rules allow for principal, interest, and handling fees as the amount detail items, then the system verifies whether all the amount detail items passed in the business transaction data belong to one of these three categories. For example, if the amount detail items passed in from the business end are: Principal = 10,000 yuan, Interest = 500 yuan, and Handling Fee = 200 yuan, then the verification passes; if the passed amount detail items include fines, then the verification fails, the process terminates, and an error message is returned.

[0058] In this way, the amount details passed in by the business side are allowed to be less than the range allowed by the configuration rules (for example, only the principal and interest are passed in, but the handling fee is not passed in), but the amount details that exceed the range are prohibited, ensuring that the billing data entering the subsequent process meets the standardized accounting requirements of this type of bill.

[0059] S320: If the amount details verification passes, generate the target transaction bill corresponding to the business transaction data based on the business transaction data and the target financial scenario code.

[0060] Once the amount details are verified, the billing middleware layer confirms that the amount details in the current business transaction data meet the standardization requirements of the bill type, and then initiates the generation of the target transaction bill.

[0061] Specifically, the billing middleware layer fills the basic information fields (such as transaction amount and counterparty), the verified amount details (such as principal = 10,000 yuan and interest = 500 yuan) and the target financial scenario code in the business transaction data into the corresponding positions of the bill according to the template format, forming a structured target transaction bill, which is stored in the database of the billing middleware layer as the data source for the subsequent generation of financial vouchers.

[0062] By incorporating amount detail verification before generating the invoice, we can ensure that all invoice data entering subsequent processes meets the amount range requirements for that invoice type, thus avoiding voucher generation failures or accounting errors caused by the input of invalid amount items.

[0063] In this embodiment, a pre-verification mechanism for amount details is used to verify the range of amount details in the business transaction data before generating the target transaction bill. This ensures that the input amount items all meet the standardized accounting requirements of this type of bill, intercepting illegal amount item data from the source. This effectively avoids abnormal voucher generation caused by amount details exceeding the range, and improves the standardization of bill data and the reliability of subsequent financial accounting.

[0064] In the above Figure 1 Based on the corresponding embodiments, in order to more clearly demonstrate the process of obtaining the target voucher template, this application also provides a possible implementation of obtaining the target voucher template in a business transaction data processing method. Figure 4 This is a flowchart illustrating the process of obtaining a target voucher template in a business transaction data processing method provided in an embodiment of this application. Figure 4 As shown, in S104 above, based on the target financial scenario code, the corresponding target voucher template is matched from the preset target voucher template library, including: S410 retrieves the financial scenario codes corresponding to multiple business scenarios.

[0065] During the initial configuration phase, the billing middleware layer first obtains the set of financial scenario codes corresponding to all business scenarios of the enterprise.

[0066] Specifically, for each business scenario (such as the principal and interest scenario of direct lease in finance leasing, the service fee scenario of leaseback in finance leasing, and the rental scenario of operating lease), based on the differentiated needs of enterprise financial accounting, the accounting dimensions used to distinguish the financial accounting standards under each business scenario are determined. Based on preset financial scenario code generation rules, which are pre-configured coding logics that uniquely correspond to the accounting dimensions of each business scenario, standardized and unique coding processing of accounting dimensions under different business scenarios can be achieved. Based on these preset financial scenario code generation rules, the billing middleware layer sequentially encodes and converts the accounting dimensions corresponding to each business scenario, generating a unique financial scenario code for each business scenario. Finally, these codes are integrated to form a set of financial scenario codes covering all financial accounting business scenarios of the enterprise, completing the acquisition of financial scenario codes corresponding to all business scenarios and forming a complete set of financial scenario codes.

[0067] S420 configures a corresponding voucher template for each financial scenario code, thus obtaining the correspondence between multiple financial scenario codes and voucher templates.

[0068] After obtaining all financial scenario codes, the corresponding voucher template is configured for each financial scenario code through the configuration interface provided by the billing middleware layer. The voucher template is a preset voucher generation rule that defines the complete accounting rules under a specific financial accounting scenario, including: debit accounting subjects, credit accounting subjects, the value mapping relationship between the amount of each subject and the detailed items of the bill amount, accounting processing methods, etc.

[0069] In one possible implementation, for financial scenario codes with similar accounting rules, finance personnel can first configure a baseline template, and then quickly generate templates for other scenario codes by copying and fine-tuning them, significantly reducing the configuration workload. For example, multiple financial scenario codes under the "financial leasing - direct leasing - principal and interest bill" scenario have basically the same voucher template structure, and only need to be fine-tuned according to specific dimensions to combine and adjust some auxiliary accounting items.

[0070] After configuration, the billing middleware layer establishes a relationship between each financial scenario code and its corresponding voucher template, and uses the financial scenario code as the index key to store the template data in the preset target voucher template library, forming a one-to-one correspondence between financial scenario codes and voucher templates, providing a data foundation for template matching in the subsequent operation phase.

[0071] In this way, a voucher template only needs to be configured once for each financial scenario code to cover all possible business transactions in that scenario, without the need to configure it separately for each transaction, which greatly improves the configuration efficiency and management convenience of voucher templates.

[0072] In this embodiment, through the financial scenario code acquisition and template configuration mechanism, the accounting dimensions of all business scenarios are combined into standardized financial scenario codes, and a corresponding voucher template is configured for each scenario code. This realizes the binding of voucher templates with business scenarios. A single configuration can cover all possible transactions in that scenario, greatly reducing the workload and complexity of template configuration and laying a solid foundation for subsequent automated voucher matching.

[0073] In the above Figure 4 Based on the corresponding embodiments, in order to more clearly demonstrate the process of obtaining the financial scenario code, this application also provides a possible implementation of obtaining the financial scenario code in a business transaction data processing method. Figure 5 This is a flowchart illustrating the process of obtaining a financial scenario code in a business transaction data processing method provided in an embodiment of this application. Figure 5 As shown, S410 above obtains financial scenario codes corresponding to multiple business scenarios, including: S510 retrieves the billing types for various business scenarios.

[0074] In this context, bill types are used to differentiate the financial accounting attributes of different business scenarios. During the process of obtaining the financial scenario code, the billing middleware layer first retrieves the bill types corresponding to all of the enterprise's business scenarios.

[0075] Specifically, for each business scenario (such as the principal and interest scenario of direct lease in finance lease, the service fee scenario of leaseback in finance lease, and the rental scenario of operating lease), the billing middleware layer obtains the bill type identifier corresponding to that scenario. For example, the bill type corresponding to the principal and interest scenario of direct lease in finance lease is "Finance Lease - Direct Lease - Principal and Interest Bill", the bill type corresponding to the service fee scenario of leaseback in finance lease is "Finance Lease - Leaseback - Service Fee Bill", and the bill type corresponding to the rental scenario of operating lease is "Operating Lease - Rental Bill".

[0076] S520 arranges and combines multiple accounting dimensions corresponding to the bill types of various business scenarios to obtain multiple accounting dimension combinations.

[0077] After obtaining the bill types for each business scenario, the billing middleware layer further obtains the set of accounting dimensions bound to each bill type during the configuration phase, and arranges and combines multiple accounting dimensions in the set to generate all possible combinations of accounting dimensions for that bill type.

[0078] For example, for the "Financial Leasing - Direct Lease - Principal and Interest Bill" type, its accounting dimensions include four dimensions: business line (commercial vehicle / passenger vehicle), customer type (individual / legal entity), term type (short-term / medium-to-long-term), and repayment status (on track / overdue). The billing middle layer permutes and combines all possible values ​​of these four dimensions, generating 2×2×2×2=16 accounting dimension combinations, such as: business line = commercial vehicle, customer type = individual, term type = short-term, repayment status = on track; business line = commercial vehicle, customer type = individual, term type = short-term, repayment status = overdue; ... until all dimension value combinations are covered.

[0079] Based on this, the billing middleware layer automatically completes the full permutation and combination of accounting dimensions under all bill types, generating a set of accounting dimension combinations covering all accounting standards, eliminating the need for manual enumeration and significantly reducing the complexity and error risk of configuration work.

[0080] S530 generates multiple financial scenario codes corresponding to different business scenarios based on a combination of multiple accounting dimensions.

[0081] After obtaining all the accounting dimension combinations under each bill type, the bill intermediate layer generates a unique corresponding financial scenario code for each accounting dimension combination according to the preset financial scenario code generation rules.

[0082] For example, for the 16 accounting dimension combinations under the "financial leasing-direct leasing-principal and interest bill" type, the bill intermediate layer sequentially substitutes them into the preset coding generation logic to generate a unique financial scenario code for each combination, generating a total of 16 financial scenario codes.

[0083] Ultimately, all possible combinations of accounting dimensions under all business scenarios are converted into standardized, uniquely identifiable financial scenario codes, forming a complete set of financial scenario codes.

[0084] In this embodiment, a standardized conversion from business scenarios to financial accounting standards is achieved through the acquisition of bill types, the arrangement and combination of accounting dimensions, and the generation of scenario codes. The system automatically completes the arrangement and combination of all accounting dimensions and generates corresponding financial scenario codes without the need for manual enumeration, which greatly reduces the complexity and error risk of configuration work and lays the foundation for the subsequent configuration and automated matching of voucher templates.

[0085] In the above Figure 1 Based on the corresponding embodiments, in order to more clearly demonstrate the process of generating financial vouchers, this application also provides a possible implementation method for generating financial vouchers in a business transaction data processing method. Figure 6 This is a schematic diagram illustrating the process of generating financial vouchers in a business transaction data processing method provided in an embodiment of this application. Figure 6As shown, in step S105 above, the financial documents generated based on the target voucher template and the target transaction invoice include: S610, Generate voucher entries based on the pre-defined mapping relationship between bill amount details and debit / credit accounts in the target voucher template, and the amount details in the target transaction bill.

[0086] After obtaining the target voucher template and the target transaction statement, the middleware layer of the statement parses the preset mapping relationship in the target voucher template. This mapping relationship clarifies which amount detail item in the target transaction statement each debit and credit account should take its value from.

[0087] Specifically, the target voucher template defines complete mapping rules. For example, the debit account "Accounts Receivable for Leases" corresponds to "Principal" in the bill amount details; the debit account "Accounts Receivable for Interest" corresponds to "Interest" in the bill amount details; and the credit account "Lease Income" corresponds to "Rental Income" in the bill amount details. The intermediate layer of the bill traverses the mapping relationships in the template, extracts the actual values ​​of each amount detail from the target transaction bill (e.g., Principal = 10,000 yuan, Interest = 500 yuan), and fills the actual amounts into the corresponding account entries according to the mapping rules, generating preliminary voucher entries.

[0088] In one possible implementation, if the amount detail item pointed to by the mapping relationship of a certain account in the target voucher template does not exist in the target transaction bill, it is determined that no entry needs to be generated for that account and the processing is skipped; if the amount detail item corresponding to the required account in the template is missing, the exception handling process is triggered.

[0089] Based on this, the billing middle layer automatically fills in the voucher entries based on the preset mapping relationship, eliminating the need for manual entry of each item, which significantly improves the efficiency and accuracy of voucher generation.

[0090] S620 verifies the voucher entries, and generates financial vouchers associated with the target transaction invoice after the verification is successful.

[0091] Specifically, the billing middle layer performs several basic verification operations: amount non-empty verification to ensure that the amount of key accounts is not empty or zero; mapping integrity verification to confirm that all mapping relationships defined in the template have been correctly parsed and filled into the entries; and entry structure integrity verification to check whether the voucher contains at least one debit entry and one credit entry.

[0092] Once all validation items pass, the billing middleware layer combines the validated voucher entries with the voucher header information to generate a complete standardized financial voucher. The voucher header information includes, but is not limited to: voucher date, voucher number, associated target transaction invoice number, and target financial scenario code. The generated financial voucher is then linked to the target transaction invoice for storage, forming a traceable link between business transactions and financial vouchers.

[0093] If any validation item fails, the process terminates and returns an error message, requiring manual intervention or triggering an exception handling process.

[0094] In this embodiment, voucher entries are automatically filled based on the pre-defined mapping relationship between amount details and accounts in the template, and multiple automated checks are performed after generation to ensure the accuracy and compliance of the voucher data. The entire process requires no manual intervention, significantly improving the efficiency of financial voucher generation and effectively reducing the financial accounting risks caused by manual entry errors.

[0095] In the above Figure 6 Based on the corresponding embodiments, in order to more clearly demonstrate the process of generating financial vouchers, this application also provides a possible implementation method for generating financial vouchers in a business transaction data processing method. Figure 7 This is a schematic diagram illustrating the process of generating financial vouchers in another business transaction data processing method provided in this application embodiment. For example... Figure 7 As shown, S620 above verifies the voucher entries. After successful verification, the generated financial voucher associated with the target transaction invoice includes: S710, perform a range check on the amount details in the voucher entry based on the amount details in the voucher entry.

[0096] Each bill type is pre-bound with a corresponding amount detail range rule during the configuration phase. This rule defines the allowed value range or format requirements for each amount detail item under this type of bill.

[0097] Specifically, the intermediate layer of the invoice iterates through each detailed item in the voucher entries, checking whether each value is within the preset allowable range. For example, for the "Finance Lease - Direct Lease - Principal and Interest Invoice" type, the principal amount must be positive and not exceed the total contract amount, and the interest amount must comply with the interest rate calculation rules; for the "Expenses - Travel Reimbursement Invoice" type, the transportation and accommodation expenses must not exceed the upper limit of the reimbursement standard stipulated by the company.

[0098] If all amount details are within the allowed range, the amount detail range verification is considered successful, and the process proceeds to step S720 for the next verification step; if any amount detail exceeds the range, the verification is considered unsuccessful, the process terminates, and an error message is returned.

[0099] S720: If the range of amount details passes the verification, perform a debit and credit balance verification based on the total debit and credit amounts in the voucher entries.

[0100] Once the range of amounts is verified, the intermediate layer of the invoice further verifies the debit-credit balance of the voucher entries. Debit-credit balance is a fundamental principle that financial vouchers must meet, meaning that the total debit amount must equal the total credit amount.

[0101] Specifically, the intermediate layer of the invoice summarizes the amounts of all debit accounts in the voucher entries to obtain the total debit amount, and summarizes the amounts of all credit accounts to obtain the total credit amount, and then calculates the difference between the two. If the total debit amount is equal to the total credit amount (or within a preset tolerance range, such as cent error), the debit-credit balance check is considered to have passed; if the two are not equal, the check is considered to have failed, the process terminates and an error message is returned.

[0102] S730, if the debit-credit balance check passes, generate financial vouchers associated with the target transaction invoice.

[0103] Once the debit and credit balance verification passes, the intermediate layer of the billing system confirms that the current voucher entry has passed all verification steps and meets the requirements of financial accounting standards. At this point, the voucher generation operation is executed.

[0104] Specifically, the middleware layer combines validated voucher entries with voucher header information to generate complete standardized financial vouchers. Voucher header information includes, but is not limited to: voucher date, voucher number, associated target transaction invoice number, and target financial scenario code. The generated financial vouchers are then linked to the target transaction invoice for storage, thus linking business transactions with financial vouchers.

[0105] In this embodiment, the range of amounts and the balance of debits and credits are double-verified during the voucher generation process to ensure that each generated financial voucher complies with accounting standards and internal accounting requirements. This effectively avoids financial accounting risks caused by abnormal amounts or debit / credit imbalances, improves the accuracy and compliance of voucher data, and provides a reliable guarantee for subsequent financial processing.

[0106] The following describes a business transaction data processing apparatus and electronic device provided in this application for execution. The specific implementation process and technical effects are described above and will not be repeated below.

[0107] Figure 8 This is a schematic diagram of a business transaction data processing device provided in an embodiment of this application, as shown below. Figure 8 As shown, the business transaction data processing device includes: The acquisition module 1000 is used to acquire bill generation requests from the business side. The bill generation requests include business transaction data.

[0108] The generation module 2000 is used to generate the target financial scenario code corresponding to the business transaction data based on the accounting dimensions in the business transaction data; and to generate the target transaction bill based on the business transaction data and the target financial scenario code.

[0109] The matching module 3000 is used to match the corresponding target voucher template from the preset target voucher template library based on the target financial scenario code.

[0110] The generation module 2000 is also used to generate financial vouchers associated with the target transaction invoice based on the target voucher template and the target transaction invoice.

[0111] Optionally, the business transaction data processing device further includes a verification module 4000, which is used for bill generation requests to include: bill type; and to verify the business transaction data according to the pre-selected accounting dimension corresponding to the bill type.

[0112] Optionally, the generation module 2000 is specifically used to generate a target financial scenario code based on the accounting dimensions in the business transaction data if the verification of the pre-selected accounting dimensions passes.

[0113] Optionally, the verification module 4000 is also used to perform amount detail verification on the amount detail items in the business transaction data according to the amount detail configuration rules corresponding to the bill type.

[0114] Optionally, the generation module 2000 is specifically used to generate the target transaction bill corresponding to the business transaction data based on the business transaction data and the target financial scenario code, if the amount details verification passes.

[0115] Optionally, module 1000 can also be used to obtain financial scenario codes corresponding to multiple business scenarios.

[0116] Optionally, the generation module 2000 is also used to configure a corresponding voucher template for each financial scenario code, thereby obtaining the correspondence between multiple financial scenario codes and voucher templates.

[0117] Optionally, module 1000 is used to obtain the billing type for each business scenario.

[0118] Optionally, the generation module 2000 is also used to arrange and combine multiple accounting dimensions corresponding to the bill types of each business scenario to obtain multiple accounting dimension combinations; and to generate multiple financial scenario codes corresponding to the business scenario based on the multiple accounting dimension combinations.

[0119] Optionally, the generation module 2000 is specifically used to generate voucher entries based on the pre-defined mapping relationship between the bill amount details and debit / credit accounts in the target voucher template, as well as the amount details in the target transaction bill.

[0120] Optionally, the verification module 4000 is also used to verify the voucher entries.

[0121] Optionally, the generation module 2000 is also used to generate financial vouchers associated with the target transaction invoice after the verification is passed.

[0122] Optionally, the verification module 4000 is specifically used to verify the range of amount details in the voucher entry based on the amount details in the voucher entry; if the range of amount details is verified, a debit and credit balance verification is performed based on the total debit amount and total credit amount of the voucher entry.

[0123] Optionally, the generation module 2000 is specifically used to generate financial vouchers associated with the target transaction invoice if the loan balance verification passes.

[0124] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more digital signal processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0125] Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of this application. The device may be a computing device or a server with computing processing capabilities.

[0126] The electronic device 10 includes a processor 11, a storage medium 12, and a bus 13. The storage medium 12 stores program instructions executable by the processor 11. When the electronic device 10 is executed, the processor 11 communicates with the storage medium 12 via the bus 13, and the processor 11 executes the program instructions to perform the above-described method embodiment. The specific implementation and technical effects are similar and will not be described in detail here.

[0127] Optionally, this application also provides a program product, such as a computer-readable storage medium, including a program that, when executed by a processor, performs the above-described method embodiments.

[0128] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0129] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0130] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0131] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0132] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing business transaction data, characterized in that, Applied to the billing middleware layer, the method includes: Obtain a bill generation request from the business side, the bill generation request including: business transaction data; Based on the accounting dimensions in the business transaction data, generate the target financial scenario code corresponding to the business transaction data; Based on the business transaction data and the target financial scenario code, generate the target transaction bill; Based on the target financial scenario code, match the corresponding target voucher template from the preset target voucher template library; Based on the target voucher template and the target transaction invoice, generate financial vouchers associated with the target transaction invoice.

2. The method according to claim 1, characterized in that, The bill generation request further includes: bill type; before generating the target financial scenario code corresponding to the business transaction data based on the accounting dimensions in the business transaction data, the method further includes: Based on the pre-selected accounting dimensions corresponding to the bill type, the business transaction data is validated according to the pre-selected accounting dimensions; If the verification of the pre-selected accounting dimension passes, the target financial scenario code is generated based on the accounting dimension in the business transaction data.

3. The method according to claim 2, characterized in that, The step of generating a target transaction bill based on the business transaction data and the target financial scenario code includes: According to the amount detail configuration rules corresponding to the bill type, the amount detail items in the business transaction data are validated. If the amount details pass the verification, a target transaction bill corresponding to the business transaction data is generated based on the business transaction data and the target financial scenario code.

4. The method according to claim 1, characterized in that, Before matching the corresponding target voucher template from the preset target voucher template library based on the target financial scenario code, the process includes: Obtain the financial scenario codes corresponding to multiple business scenarios; Configure a corresponding voucher template for each of the financial scenario codes to obtain the correspondence between multiple financial scenario codes and voucher templates.

5. The method according to claim 4, characterized in that, The process of obtaining financial scenario codes corresponding to multiple business scenarios includes: Obtain the bill type for each of the aforementioned business scenarios; The multiple accounting dimensions corresponding to the bill types of each business scenario are arranged and combined to obtain multiple accounting dimension combinations; Based on the combination of multiple accounting dimensions, multiple financial scenario codes corresponding to the business scenarios are generated respectively.

6. The method according to claim 1, characterized in that, The step of generating financial vouchers associated with the target transaction invoice based on the target voucher template and the target transaction invoice includes: Based on the pre-defined mapping relationship between the bill amount details and debit / credit accounts in the target voucher template, and the amount details in the target transaction bill, voucher entries are generated. The voucher entries are verified, and if the verification is successful, a financial voucher associated with the target transaction invoice is generated.

7. The method according to claim 6, characterized in that, The process of verifying the voucher entries, and generating financial vouchers associated with the target transaction invoice upon successful verification, includes: Based on the amount details in the voucher entry, the amount details range of the voucher entry is verified; If the range of the amount details passes the verification, a debit and credit balance verification is performed based on the total debit and credit amounts of the voucher entries. If the loan balance verification passes, a financial voucher associated with the target transaction invoice is generated.

8. A business transaction data processing device, characterized in that, Applied to a billing intermediary layer, the device includes: The acquisition module is used to acquire bill generation requests from the business side, and the bill generation requests include: business transaction data; The generation module is used to generate a target financial scenario code corresponding to the business transaction data based on the accounting dimension data in the business transaction data; and to generate a target transaction bill corresponding to the business transaction data based on the business transaction data and the target financial scenario code. The matching module is used to match the corresponding target voucher template from the preset target voucher template library based on the target financial scenario code; The generation module is further configured to generate financial vouchers associated with the target transaction invoice based on the target voucher template and the target transaction invoice.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores program instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the program instructions to perform the steps of the business transaction data processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which is executed by a processor to perform the business transaction data processing method as described in any one of claims 1-7.

Images