Accounting method, device, equipment and storage medium
By breaking down payment information and using a pre-defined accounting rule base for recording, the system addresses the lack of automation and intelligence in the payment information recording process, reducing system load and improving processing efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- PEOPLE'S INSURANCE COMPANY OF CHINA
- Filing Date
- 2023-05-29
- Publication Date
- 2026-06-09
AI Technical Summary
The existing enterprise information systems lack sufficient automation and intelligence in the recording of payment information, resulting in high labor costs, high system resource consumption, and low processing efficiency.
By generating pending tasks, splitting them according to product details and relational database performance configuration, generating multiple batches of pending sub-tasks, and using a preset accounting rule base to record payment information, the overall view of accounting vouchers is consistent with the vouchers generated at once.
It reduced system pressure, improved the automation and intelligence of the payment registration process, reduced manpower costs, and increased system response speed.
Smart Images

Figure CN116823505B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of financial accounting technology, and in particular to an accounting bookkeeping method, apparatus, equipment and storage medium. Background Technology
[0002] Most existing enterprise information systems, such as Enterprise Resource Planning (ERP) systems, have automated the accounting of product sales details and sales flow records. However, for the recording of payment information, they generally provide functions for manual post-entry. Since post-entry requires financial personnel to screen and cancel each item through the system page or to compile a reconciliation table of payment registration in a specified format offline and upload it to the system for processing, the establishment of reconciliation between product sales details and sales flow records is usually completed by financial personnel using their business and financial expertise, which is cumbersome. Summary of the Invention
[0003] This invention provides an accounting method, apparatus, device, and storage medium to address the cumbersome operation of the payment registration process in the prior art, improve the automation and intelligence of the accounting process in the payment registration process, and simultaneously realize the splitting of large-scale transactions in this process to reduce system pressure.
[0004] In a first aspect, the present invention provides an accounting bookkeeping method, comprising:
[0005] In response to user input, generate tasks to be processed;
[0006] Based on the product details and relational database performance configuration corresponding to the task to be processed, the task to be processed is split into multiple batches of sub-tasks to be processed; and the overall view of the accounting vouchers generated based on each batch of the sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed.
[0007] For each batch of sub-tasks to be processed, the accounting rules corresponding to the sub-tasks to be processed are obtained based on the product details corresponding to the sub-tasks to be processed, the type of the sub-tasks to be processed, and the preset accounting rule library.
[0008] According to the accounting rules, the payment information for the pending sub-tasks is recorded.
[0009] Optionally, the overall view of the accounting vouchers is obtained by summarizing the accounting vouchers corresponding to the pending sub-tasks in each batch, and the accounting vouchers corresponding to the pending sub-tasks in each batch are generated based on the payment information records of the pending sub-tasks; the accounting vouchers generated at one time are obtained by reconciling each item based on the product details corresponding to the pending task.
[0010] Optionally, the step of splitting the task to be processed into multiple batches of sub-tasks based on the product details and relational database performance configuration corresponding to the task to be processed includes:
[0011] The product details corresponding to the tasks to be processed are summarized and calculated to obtain summary data;
[0012] Based on the performance configuration of the relational database, a threshold is set for the resources consumed by the relational database when the subtasks to be processed in a single batch are executed; the threshold includes at least one of the following: a threshold for time resources and a threshold for space resources;
[0013] Based on the aggregated data and the threshold, calculate the number of batches that the task to be processed needs to be split into;
[0014] Based on the number of batches to be split, the task to be processed is split into multiple batches of sub-tasks to be processed.
[0015] Optionally, the preset accounting rule library includes at least one of the following: accounting rules for accounts receivable and payable, accounting rules for cash payments, accounting rules for non-cash payments, accounting rules for offsetting payment methods, accounting rules for bank statement payment methods, and accounting rules for transferring excess bank statement payments to temporary receipts.
[0016] Optionally, after recording the payment information of the sub-task to be processed according to the accounting rules, the method further includes:
[0017] Compare the overall view of the accounting voucher with the accounting voucher generated in one go for consistency.
[0018] If the overall view of the accounting voucher is inconsistent with the accounting voucher generated in one go, the number of batches that the pending task needs to be split into should be recalculated.
[0019] Based on the recalculated number of batches to be split, the task to be processed is re-splitted to obtain multiple batches of sub-tasks to be processed.
[0020] Optionally, the user's input includes at least the identification information of the product data to be processed; the product data to be processed is obtained based on at least one of the following: product sales details and product sales records;
[0021] The process of generating a task to be processed in response to user input includes:
[0022] The product data in the database is identified based on the identification information of the product data to be processed;
[0023] The data set consisting of the identified product data in the database is determined as the product details corresponding to the task to be processed.
[0024] Optionally, before obtaining the accounting rules corresponding to the sub-task to be processed based on the product details, the type of the sub-task to be processed, and the preset accounting rule base, the method further includes:
[0025] Determine the type of the subtask to be processed; the type includes at least one of the following: payment tasks and fee payment tasks.
[0026] Optionally, when the type is a payment task, before obtaining the accounting rules corresponding to the sub-task based on the product details, the type of the sub-task, and the preset accounting rule library, the method further includes:
[0027] Based on the product details corresponding to the sub-task to be processed, obtain the information of the payment object corresponding to the sub-task to be processed;
[0028] The step of obtaining the accounting rules corresponding to the sub-task to be processed based on the product details, the type of the sub-task to be processed, and the preset accounting rule library includes:
[0029] Based on the information of the payment object corresponding to the sub-task to be processed and the product details corresponding to the sub-task to be processed, the accounting rules corresponding to the sub-task to be processed are selected from the preset accounting rule library.
[0030] Optionally, when the type is a payment-related task, before obtaining the accounting rules corresponding to the sub-task based on the product details, the type of the sub-task, and the preset accounting rule library, the method further includes:
[0031] Based on the product details corresponding to the sub-task to be processed, determine the payment information of the payment object corresponding to the sub-task to be processed;
[0032] The step of obtaining the accounting rules corresponding to the sub-task to be processed based on the product details, the type of the sub-task to be processed, and the preset accounting rule library includes:
[0033] Based on the payment information of the payee corresponding to the sub-task to be processed and the product details corresponding to the sub-task to be processed, the accounting rules corresponding to the sub-task to be processed are selected from the preset accounting rule library.
[0034] In a second aspect, the present invention also provides an accounting and bookkeeping device, comprising:
[0035] The task generation module is used to generate tasks to be processed in response to user input;
[0036] The task splitting module is used to split the task to be processed into multiple batches of sub-tasks based on the product details and relational database performance configuration corresponding to the task to be processed; and the overall view of the accounting vouchers generated based on each batch of the sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed.
[0037] The task processing module is used to obtain the accounting rules corresponding to each batch of sub-tasks to be processed based on the product details, the type of the sub-task, and a preset accounting rule library; and to record the payment information of the sub-tasks to be processed according to the accounting rules.
[0038] Thirdly, the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the accounting method described above.
[0039] Fourthly, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the accounting method as described above.
[0040] Fifthly, the present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the accounting method described above.
[0041] This invention provides an accounting bookkeeping method, apparatus, device, and storage medium. In response to user input, a task to be processed is generated. Then, based on the product details corresponding to the task and the performance configuration of the relational database, the task is split into multiple batches of sub-tasks. Furthermore, the overall view of the accounting vouchers generated from each batch of sub-tasks is consistent with the accounting vouchers generated all at once from the task. Next, for each batch of sub-tasks, accounting rules corresponding to the sub-task are obtained based on the product details, the type of the sub-task, and a preset accounting rule library. Finally, payment information for the sub-task is recorded according to the accounting rules. This method targets pending tasks involving large volumes of big data transactions. First, it breaks down the pending tasks into multiple batches of sub-tasks based on the product details and the performance configuration of the relational database. This minimizes the resource consumption of transactions generated during the processing of a single batch, thereby reducing the overall system pressure and improving system response speed. Furthermore, for each batch of sub-tasks, a matching process is performed against a pre-defined accounting rule base to obtain the corresponding accounting rules. This enhances the automation and intelligence of the accounting process during payment registration. Attached Figure Description
[0042] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0043] Figure 1 This is one of the flowcharts illustrating the accounting bookkeeping method provided by this invention;
[0044] Figure 2 This is the second flowchart illustrating the accounting bookkeeping method provided by this invention;
[0045] Figure 3 This is a schematic diagram of the structure of the accounting and bookkeeping device provided by the present invention;
[0046] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation
[0047] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.
[0048] First, the terminology used in the embodiments of this invention will be explained:
[0049] Product sales transaction record registration: A company's information system can persistently record the sales revenue details generated during the product sales process. This action is automatically completed when sales personnel use the information system to complete transactions. Product sales transaction details generally include unrecorded bank transfers, recorded advance receipts, prepayments and balances, temporary payments, and real-time interactive internet and mobile payment transactions.
[0050] Product sales details registration: The company's information system can persistently record product outbound and return details generated during the product sales process. This action is automatically completed when sales personnel use the information system to complete transactions.
[0051] Payment information recording: The company's information system persistently records the relationship between product sales details and product sales flow. This action is generally performed by finance personnel in the information system to supplement the large number of details involved in the transaction after the transaction is completed.
[0052] Secondly, the application scenarios of the accounting bookkeeping method provided in the embodiments of the present invention will be introduced.
[0053] The products involved in this solution are mainly services promised under insurance contracts.
[0054] Most existing enterprise information systems, such as Enterprise Resource Planning (ERP) systems, have automated the accounting of product sales details and sales flow records. However, for the recording of payment information, the system typically provides a function for manual post-entry. During this post-entry process, finance personnel need to filter and cancel each item through the system page or compile a reconciliation table of payment registrations in a specified format offline and upload it to the system for processing. In other words, the establishment of reconciliation between product sales details and sales flow records is usually left to finance personnel to complete based on their business and financial expertise.
[0055] The existing technology has the following shortcomings:
[0056] (1) The lack of automation and intelligence in the recording of payment information leads to high labor costs. The above-mentioned process of retroactively recording payment information, such as when a transaction generates a large number of product sales, return details or uses a large amount of cash flow, will inevitably incur huge labor costs.
[0057] (2) The recording of payment information leads to high consumption of system application host memory and database resources, resulting in low system response efficiency. Because the existing technology does not take into account the background knowledge of accounting rules involved in manual operations, it is impossible to split the reconciliation relationship table submitted by manual operations without affecting the financial accounting results during the system processing. When encountering a large set of relationship data, the system consumes a lot of resources and the processing efficiency is low.
[0058] To address the aforementioned shortcomings, this invention provides an accounting solution that enhances the intelligence of the payment information recording process, significantly reduces the manpower required for manual breakdown, fully utilizes the application host's central processing unit (CPU) to improve system processing efficiency, and substantially reduces the overall system load.
[0059] The following is combined Figures 1-4 This invention describes the accounting and bookkeeping solution provided by the present invention.
[0060] Figure 1 This is one of the flowcharts illustrating the accounting bookkeeping method provided by this invention, such as... Figure 1 As shown, the method includes:
[0061] Step 101: In response to user input, generate a task to be processed;
[0062] Step 102: Based on the product details and relational database performance configuration corresponding to the task to be processed, the task to be processed is split into multiple batches of sub-tasks to be processed; and the overall view of the accounting vouchers generated based on each batch of sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed.
[0063] Step 103: For each batch of pending subtasks, obtain the accounting rules corresponding to the pending subtasks based on the product details, the type of the pending subtasks, and the preset accounting rule library.
[0064] Step 104: Record the payment information for the sub-tasks to be processed in accordance with accounting rules.
[0065] Specifically, user input can be understood as filtering conditions for product data. These conditions are usually related to the characteristics of the business the user is operating. For example, for businesses with fixed settlement rules, specific identifiers may be stored when registering product sales details and product sales records. User input can be filtering conditions for product sales details or product sales records, such as the product sales detail number or the product sales record detail number. Furthermore, in response to the above user input, a task to be processed can be generated. Specifically, the database can be filtered according to the user input, for example, by querying the database by the product sales detail number, and the retrieved product data can be identified. This identification process can also be seen as the process of generating a task to be processed. Optionally, based on this, basic statistical and validation operations can be performed on the product data in the task to be processed, so that the user can verify whether the data submission is correct and confirm the start of processing.
[0066] Furthermore, after generating the task to be processed, it can be split into multiple batches of sub-tasks based on the product details corresponding to the task, such as the total quantity and total amount of the product details, and the hardware resources used in the system deployment, such as the performance configuration of the relational database. The overall view of the accounting vouchers generated from each batch of sub-tasks is consistent with the accounting vouchers generated all at once from the task. Here, a relational database refers to a database built on a relational model, using mathematical concepts and methods such as set algebra to process the data. In this method, the relational model at least includes the relationship between product sales details and product sales flow.
[0067] Furthermore, for each batch of pending subtasks, the product details corresponding to the pending subtask can be obtained first. Then, based on the obtained product details, the type of the pending subtask (e.g., payment task, billing task), and a preset accounting rule library, the corresponding accounting rule for the pending subtask can be obtained. The preset accounting rule library pre-configures the accounting rules needed for registering payment information with fixed settlement rules. This pre-configuration process can be customized by professional financial or business personnel and can be adjusted in real time according to the actual settlement scenario.
[0068] Furthermore, based on the accounting rules matched in the preset accounting rule library for the sub-task to be processed, the payment information of the sub-task to be processed can be recorded to complete the accounting entries. Specifically, the matched accounting rules are the agreements on the specific data format for the required accounting type, which in turn include the requirements for the relevant database table structure and field assignments. Recording the payment information of the sub-task to be processed involves using the matched accounting rules and the user-specified product detail data to perform calculations and reorganization, and finally persistently recording the generated data.
[0069] In the method provided in this embodiment, a task to be processed is generated in response to user input. Then, based on the product details corresponding to the task to be processed and the performance configuration of the relational database, the task to be processed is split into multiple batches of sub-tasks to be processed. Furthermore, the overall view of the accounting vouchers generated based on each batch of sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed. Subsequently, for each batch of sub-tasks to be processed, the accounting rules corresponding to the sub-tasks to be processed are obtained based on the product details corresponding to the sub-tasks to be processed, the type of the sub-tasks to be processed, and the preset accounting rule library. Then, the payment information of the sub-tasks to be processed is recorded according to the accounting rules. This method targets pending tasks involving large volumes of big data transactions. First, it breaks down the pending tasks into multiple batches of sub-tasks based on the product details and the performance configuration of the relational database. This minimizes the resource consumption of transactions generated during the processing of a single batch, thereby reducing the overall system pressure and improving system response speed. Furthermore, for each batch of sub-tasks, a matching process is performed against a pre-defined accounting rule base to obtain the corresponding accounting rules. This enhances the automation and intelligence of the accounting process during payment registration.
[0070] Optionally, the overall view of accounting vouchers is obtained by summarizing the accounting vouchers corresponding to each batch of pending sub-tasks. The accounting vouchers corresponding to each batch of pending sub-tasks are generated based on the payment information records of the pending sub-tasks. The accounting vouchers generated at one time are obtained by reconciling each item based on the product details corresponding to the pending task.
[0071] Specifically, in the method of this embodiment, after each batch of sub-tasks to be processed is completed, a record of payment information for the sub-tasks to be processed will be obtained. Based on the record of payment information for the sub-tasks to be processed, corresponding accounting vouchers can be generated. Then, the accounting vouchers corresponding to each batch of sub-tasks to be processed can be summarized to obtain a general view of the accounting vouchers.
[0072] In existing technologies, tasks are not broken down into product details. Instead, accounting vouchers can be generated in one go by verifying each product detail based on the task to be processed.
[0073] In the method provided by this invention, the overall view of accounting vouchers generated by each batch of tasks to be processed after splitting is consistent with the accounting vouchers generated all at once without pre-splitting, and the accounting based on this method is more accurate.
[0074] Optionally, based on the product details corresponding to the task to be processed and the performance configuration of the relational database, the task to be processed can be split into multiple batches of sub-tasks to be processed, which may include:
[0075] The product details corresponding to the tasks to be processed are summarized and calculated to obtain summary data;
[0076] Based on the performance configuration of the relational database, a threshold is set for the relational database resources consumed when a single batch of pending subtasks is executed; the threshold includes at least one of the following: a threshold for time resources and a threshold for space resources;
[0077] Based on the aggregated data and thresholds, calculate the number of batches that the task to be processed needs to be split into;
[0078] The task to be processed is split into multiple batches of sub-tasks based on the number of batches to be split.
[0079] Specifically, after generating the task to be processed in step 101, it can be further determined whether the task needs to be split based on the product details corresponding to the task, and the number of batches to be split for the task can be obtained. An example of this implementation process is as follows:
[0080] First, based on the product details corresponding to the tasks to be processed, summary data of the product details corresponding to the tasks to be processed can be obtained, such as the summary quantity and summary amount.
[0081] Furthermore, based on the summarized data of the product details corresponding to the tasks to be processed, such as the summarized quantity and total amount, and in conjunction with the hardware resources used in the system deployment, especially the performance configuration of the relational database, a judgment is made. The performance of the relational database is generally measured by two indicators: response time and throughput. Relational database performance configuration includes, for example, the maximum number of users the database can support, the database access speed, the input / output wait time, and the maximum number of blocks read in a single input / output operation. Further, based on the relational database performance configuration, thresholds can be set for the relational database resources consumed when executing a single batch of subtasks to be processed. These thresholds may include time resource thresholds and space resource thresholds. The specific judgment process is as follows: Based on the performance configuration of the system's relational database, a judgment is made in conjunction with the product details corresponding to the task to be processed, such as the database access speed, combined with the summary data of the product details corresponding to the task to be processed, such as the summary amount of the product details corresponding to the task to be processed, the summary quantity of the product details corresponding to the task to be processed, and a pre-set threshold related to the resources of the relational database. Adjustments are made according to database tuning experience and actual experiments. The goal of the adjustment can be to adapt the main Structured Query Language (SQL) that occurs in a single batch processing to a better time and space consumption, that is, not exceeding the pre-set threshold, thereby obtaining the number of batches that the task to be processed needs to be split into.
[0082] Furthermore, after obtaining the number of batches that the task to be processed needs to be split into, the task to be processed is split into multiple batches of sub-tasks to be processed based on the number of batches that the task to be processed needs to be split into.
[0083] The method provided in this embodiment summarizes and calculates the product details corresponding to the task to be processed, obtaining summarized data such as summarized quantity and summarized amount. Then, based on the summarized quantity and summarized amount, as well as the performance configuration of the relational database, the number of batches that the task to be processed needs to be split is calculated, and the task to be processed is then split. The splitting process also takes into account accounting rules. By splitting and batching the product detail data corresponding to the task to be processed, this method controls the consumption of system resources by the transactions formed in a single batch processing process to be relatively small. Therefore, when processing combined table queries in the relational database, the resource consumption of the relational database decreases from a geometric increase to a near linear increase as the amount of data processed increases, thereby reducing the overall system pressure and improving the system response speed.
[0084] Optionally, the preset accounting rule library includes at least one of the following: accounting rules for accounts receivable and payable, accounting rules for cash payments, accounting rules for non-cash payments, accounting rules for offsetting payment methods, accounting rules for bank statement payment methods, and accounting rules for transferring excess bank statement receipts to temporary receipts.
[0085] Specifically, the pre-configured accounting rule library used in the aforementioned accounting methods contains a variety of pre-configured accounting rules applicable to payment scenarios where settlement rules are fixed. These pre-configured accounting rules include, for example, accounting rules for accounts receivable / payable, accounting rules for cash payments, accounting rules for non-cash payments, accounting rules for offsetting payment methods, accounting rules for bank statement payment methods, and accounting rules for transferring excess bank statement payments to temporary receipts.
[0086] For example, the accounting rules for offsetting receipts apply when the task type of the sub-task to be processed is a payment task and the total amount of the product details corresponding to the sub-task to be processed is negative. The accounting rules for offsetting receipts refer to using the payment information of the payee to offset the payment information corresponding to the sub-task to be processed. The accounting rules for accounts receivable and payable apply when the task type of the sub-task to be processed is a payment task and the total amount of the product details corresponding to the sub-task to be processed is negative. The accounting rules for accounts receivable and payable refer to using the payment information of the payee to offset the payment information corresponding to the sub-task to be processed.
[0087] Furthermore, the pre-configured accounting rules can correspond to the back-end accounting and financial system. The determined accounting rules are transmitted to the back-end accounting and financial system. When the accounting and financial system receives the determined accounting rules, it can automatically generate the corresponding accounting vouchers according to the determined accounting rules and complete the accounting.
[0088] In the method provided in this embodiment, the preset accounting rule library contains a variety of pre-configured accounting rules. This method matches the accounting rules of the task to be processed in the preset accounting rule library and completes the recording of payment information according to the determined accounting rules, that is, automatically completes accounting, improves the intelligence level of the payment information recording process, and saves manpower.
[0089] Optionally, after recording the payment information for the sub-tasks to be processed according to accounting rules, the method also includes:
[0090] Compare the overall view of the accounting vouchers with the accounting vouchers generated in one go for consistency.
[0091] If the overall view of the accounting voucher is inconsistent with the accounting voucher generated in one go, the number of batches that the pending task needs to be split into should be recalculated.
[0092] Based on the recalculated number of batches that need to be split, the task to be processed is re-split into multiple batches of sub-tasks to be processed.
[0093] Specifically, in the method provided in this embodiment of the invention, after splitting the task to be processed and obtaining the payment information for each batch of tasks to be processed, the overall view of the accounting voucher can be compared with the accounting voucher generated at one time. If the two are inconsistent, the number of batches that the task to be processed needs to be split into can be recalculated, and the task to be processed can be re-split.
[0094] In the method provided by the embodiments of the present invention, the final overall view of the accounting voucher is consistent with the accounting voucher generated at one time, and the final result obtained by the accounting bookkeeping method is more accurate.
[0095] Optionally, the user's input may include at least the identification information of the product data to be processed; the product data to be processed may be obtained based on at least one of the following: product sales details and product sales records;
[0096] In response to user input, generate tasks to be processed, including:
[0097] Identify the product data in the database based on the identification information of the product data to be processed;
[0098] The data set consisting of the identified product data in the database is determined as the product details corresponding to the task to be processed.
[0099] Specifically, in step 101, the user's input can be understood as a filtering condition for product data in the database. Therefore, the user's input at least includes identification information of the product data to be processed. This identification information is obtained based on either the product sales details or the product sales flow chart. The product sales details or the product sales flow chart contain identification information of the product data to be processed, such as product number and product model, used to mark the product data to be processed. In the above process, the identification information of the product data to be processed can first be obtained based on the user's input.
[0100] Furthermore, the database can be queried based on the identification information of the product data to be processed. The identification information of the product data to be processed can be used to identify multiple product data in the database. The set of multiple product data is determined as the product details corresponding to the task to be processed, that is, the generation operation of the task to be processed is completed.
[0101] In the method provided in this embodiment, the user's input includes at least the identification information of the product data to be processed. The product data to be processed is obtained based on at least one of product sales details and product sales flow. Then, the product data in the database is identified according to the identification information of the product data to be processed. The data set composed of the identified product data in the database is determined as the product details corresponding to the task to be processed, thus completing the generation of the task. This method uses the product sales details or product sales flow input by the user as the filtering condition for product data. Based on the filtering condition, a query and matching is performed in the database to generate the task to be processed. The operation process is simple and easy to operate, and can be completed without professional financial personnel, making it applicable to a wider range of scenarios.
[0102] Optionally, before obtaining the accounting rules corresponding to the sub-task based on the product details, the type of the sub-task, and the preset accounting rule library, the method further includes:
[0103] Determine the type of the subtask to be processed; the type includes at least one of the following: payment task and fee payment task.
[0104] Specifically, before processing the sub-tasks in step 102, the type of each batch of sub-tasks to be processed can be determined first. That is, it can be determined whether the sub-tasks to be processed as a whole are payment tasks or payment tasks. Payment tasks can be understood as the sub-tasks to be processed that require expenditure, and correspondingly, payment tasks can be understood as the sub-tasks to be processed that require income. Thus, the corresponding accounting rules can be matched according to the different types of sub-tasks to be processed.
[0105] The method provided in this embodiment first determines the type of the subtask to be processed, and then matches the corresponding accounting rules according to the type of the subtask. This method has low system load and fast system response speed during processing.
[0106] Optionally, when the task type is payment-related, before obtaining the accounting rules corresponding to the sub-task based on the product details, the type of the sub-task, and the preset accounting rule library, the method further includes:
[0107] Based on the product details of the subtask to be processed, obtain the information of the payment object corresponding to the subtask to be processed;
[0108] Based on the product details, sub-task type, and pre-defined accounting rule base, the accounting rules for the sub-task are obtained, including:
[0109] Based on the information of the payment recipient and the product details of the sub-task to be processed, the accounting rules corresponding to the sub-task to be processed are selected from the preset accounting rule library.
[0110] Specifically, after determining the type of the subtask to be processed, the corresponding task processing operation can be performed according to different task types. When the type is a payment task, that is, this task requires payment, the information of the payment recipient needs to be obtained first. The basis for obtaining the payment recipient information can be the product details corresponding to the subtask to be processed. The payment recipient information generally includes information such as the payment recipient's account number, payment recipient's name, payment currency, payment amount, and payment reason.
[0111] Optionally, after obtaining the information of the payment recipient, the payment can be merged according to the actual situation. For example, if the same payment recipient has multiple product transactions with the enterprise, or if multiple payments occur for the same product, they can be merged into one payment if they occur in a single settlement.
[0112] Furthermore, after obtaining the payment recipient's information, the system can filter accounting rules corresponding to the sub-task from a pre-defined accounting rule base based on the payment recipient's information and the product details corresponding to the sub-task to be processed. An example of the process for filtering to obtain the accounting rules corresponding to the sub-task is as follows:
[0113] Step a. Determine whether the product details summary corresponding to the subtask to be processed is a payment (the amount after the summary is a negative amount, i.e., a negative payment);
[0114] If it is a payment, then retrieve the accounting rules for accounts receivable and payable;
[0115] If it is not a payment, proceed to step b below.
[0116] Step b. Further determine whether to choose a payment method;
[0117] If it is a cash payment method, then retrieve the accounting rules for cash payments;
[0118] If payment is not made in cash, proceed to step c below;
[0119] Step c. Retrieve the accounting rules for non-cash payments.
[0120] The retrieved accounting rules can be understood as the specific data format conventions for the required accounting type, which in turn include the requirements for the relevant database table structure and field values. Furthermore, completing the payment registration involves using the retrieved accounting rules and the product data to be processed to perform calculations and reorganization, ultimately persisting the generated data as a record.
[0121] In the method provided in this embodiment, when the task type is payment-related, the information of the payment object corresponding to the sub-task to be processed is first obtained based on the product details corresponding to the sub-task to be processed. Then, based on the information of the payment object corresponding to the sub-task to be processed and the product details corresponding to the sub-task to be processed, accounting rules corresponding to the sub-task to be processed are selected from a preset accounting rule library. By matching the product details corresponding to the sub-task to be processed with the corresponding accounting rules based on the preset accounting rule library, the payment information of the sub-task to be processed can be recorded according to the corresponding accounting rules, completing the accounting record. This achieves the reuse of accounting rules, eliminating the need to compile a reconciliation table for each payment information record, significantly saving manpower.
[0122] Optionally, when the task type is a payment-related task, before obtaining the accounting rules corresponding to the sub-task based on the product details, the type of the sub-task, and the preset accounting rule library, the method further includes:
[0123] Based on the product details corresponding to the sub-task to be processed, determine the payment information of the payment recipient corresponding to the sub-task to be processed;
[0124] Based on the product details, sub-task type, and pre-defined accounting rule base, the accounting rules for the sub-task are obtained, including:
[0125] Based on the payment information of the payee corresponding to the sub-task to be processed and the product details corresponding to the sub-task to be processed, the accounting rules corresponding to the sub-task to be processed are selected from the preset accounting rule library.
[0126] Specifically, after determining the type of the sub-task to be processed, the corresponding task processing operation can be executed according to different task types. When the type is a payment task, that is, this task requires payment, the payment information of the payee needs to be obtained first. The basis for obtaining the payment information of the payee can be the product details corresponding to the sub-task to be processed, since the payment information of the payee is also a type of product sales revenue flow. To obtain the payment information of the payee, for example, bank statements can be selected. The process of selecting bank statements is as follows: For each payment transferred from the customer (payee) to the company account, the bank will generate a bank statement; the specific method for selecting bank statements in this step is to select the minimum number of bank statements submitted by the system user based on the total amount of the product details corresponding to the sub-task to be processed, so that the amount of the bank statements is greater than or equal to the total amount of the product details corresponding to the sub-task to be processed. Optionally, the bank statement matched after selecting the bank statement may fall into two categories: equal to or exceeding the total amount after summarizing the product details. These correspond to equal payment method and excess payment method, and these two methods have different requirements for generating accounting vouchers.
[0127] Furthermore, after obtaining the payment information of the payee, such as the selected bank statement, the system can filter the accounting rules corresponding to the sub-task from a pre-defined accounting rule library based on the payee's payment information and the product details corresponding to the sub-task to be processed. An example of the process of filtering the accounting rules corresponding to the sub-task to be processed is as follows:
[0128] Step a. Determine whether the product details summary corresponding to the subtask to be processed is a payment (if the summation amount is negative, i.e., a negative amount is received);
[0129] If it is a payment, first retrieve the accounting rules for offset payment methods, and then retrieve the accounting rules for bank statement payment methods.
[0130] If it is not a payment, proceed to step b below.
[0131] Step b. Further determine whether the summaries of the product details corresponding to the sub-task to be processed constitute overpayment;
[0132] If it is an overpayment method, first retrieve the accounting rules for overpayment to temporary receipts from the bank statement, and then retrieve the accounting rules for overpayment methods from the bank statement.
[0133] If it is not an overpayment method, then proceed to step c below;
[0134] Step c. Retrieve the accounting rules for bank statements and payment methods.
[0135] In the method provided in this embodiment, when the task type is a payment-related task, the payment information of the payment recipient corresponding to the sub-task is first determined based on the product details corresponding to the sub-task. Then, based on the payment information of the payment recipient and the product details corresponding to the sub-task, accounting rules corresponding to the sub-task are selected from a preset accounting rule library. By matching the product details of the sub-task with the corresponding accounting rules based on the preset accounting rule library, the payment information of the sub-task can be recorded according to the corresponding accounting rules, completing the accounting entries. This achieves the reuse of accounting rules, eliminating the need to compile a reconciliation table for each payment record, significantly saving manpower.
[0136] Figure 2 This is the second flowchart illustrating the accounting bookkeeping method provided by this invention, as shown below. Figure 2 As shown, the method includes:
[0137] Step 201: Filter the product details corresponding to the tasks to be processed based on the user's input, and generate the tasks to be processed based on the product details;
[0138] Step 202: Based on the product details and relational database performance configuration of the task to be processed, calculate the number of batches that the task to be processed needs to be split into, and obtain multiple batches of sub-tasks to be processed.
[0139] Step 203: For each batch of pending subtasks, extract the product details corresponding to the pending subtasks from the database;
[0140] Step 204: Determine the task type of the subtask to be processed;
[0141] Step 205: Obtain the payment object information based on the product details corresponding to the sub-task to be processed, and complete the necessary merging process at the same time;
[0142] Step 206: Based on the information of the payment recipient and the product details corresponding to the sub-task to be processed, filter the accounting rules corresponding to the sub-task to be processed from the preset accounting rule library to obtain the matching accounting rules.
[0143] Step 207: Based on the product details corresponding to the sub-task to be processed, determine the payment information of the payment recipient corresponding to the sub-task to be processed;
[0144] Step 208: Based on the payment information of the payment recipients corresponding to the sub-tasks to be processed and the product details corresponding to the sub-tasks to be processed, filter the accounting rules corresponding to the sub-tasks to be processed from the preset accounting rule library to obtain the matching accounting rules.
[0145] Step 209: Record the payment information for the pending sub-tasks according to the matching accounting rules.
[0146] Specifically, the system filters the product details corresponding to the tasks to be processed based on the user's input, and generates the tasks to be processed based on the product details; it calculates the number of batches that the tasks to be processed need to be split into based on the product details corresponding to the tasks to be processed and the performance configuration of the relational database, and obtains multiple batches of sub-tasks to be processed; for each batch of sub-tasks to be processed, it extracts the product details corresponding to the sub-tasks to be processed from the database.
[0147] Then, determine the task type of the subtask to be processed;
[0148] When the task type of the subtask to be processed is a payment task, the following steps are performed: Obtain the payment recipient information based on the product details corresponding to the subtask to be processed, and complete the necessary merging processing; Based on the payment recipient information and the product details corresponding to the subtask to be processed, filter the accounting rules corresponding to the subtask from the preset accounting rule library to obtain the matching accounting rules; Based on the matching accounting rules, record the payment information of the subtask to be processed, and complete the accounting of the payment information.
[0149] When the task type of the subtask to be processed is a payment task, the following steps are performed: Based on the product details corresponding to the subtask to be processed, determine the payment information of the payment recipient corresponding to the subtask to be processed; Based on the payment information of the payment recipient corresponding to the subtask to be processed and the product details corresponding to the subtask to be processed, filter the accounting rules corresponding to the subtask to be processed from the preset accounting rule library to obtain the matching accounting rules; Record the payment information of the subtask to be processed according to the matching accounting rules.
[0150] The method provided in this invention pre-configures an accounting rule base in the system, enabling the system functions related to the product payment information recording process to have the same capabilities as manual operations using accounting knowledge. Simultaneously, a data splitting algorithm is designed to split large-volume transaction tasks into multiple batches of sub-tasks based on the product details and relational database performance configuration. This minimizes the system resource consumption of transactions generated during a single batch processing, fully utilizes the application host CPU, achieves near-linear database resource utilization, improves processing efficiency, and balances the overall system load.
[0151] The accounting and bookkeeping device provided by the present invention is described below. The accounting and bookkeeping device described below can be referred to in correspondence with the accounting and bookkeeping method described above.
[0152] Figure 3This is a schematic diagram of the structure of the accounting and bookkeeping device 300 provided by the present invention, as shown below. Figure 3 As shown, the accounting and bookkeeping device 300 includes:
[0153] The task generation module 310 is used to generate tasks to be processed in response to user input;
[0154] The task splitting module 320 is used to split the task to be processed into multiple batches of sub-tasks based on the product details and performance configuration of the relational database corresponding to the task to be processed; and the overall view of the accounting vouchers generated based on each batch of the sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed.
[0155] The task processing module 330 is used to obtain the accounting rules corresponding to each batch of sub-tasks to be processed based on the product details, the type of the sub-task, and a preset accounting rule library; and to record the payment information of the sub-tasks to be processed according to the accounting rules.
[0156] In the device provided in this embodiment, the task generation module 310 generates a task to be processed in response to user input. Then, the task splitting module 320 splits the task to be processed according to the product details and relational database performance configuration corresponding to the task to be processed, resulting in multiple batches of sub-tasks to be processed. Furthermore, the overall view of the accounting vouchers generated based on each batch of sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed. Subsequently, the task processing module 330, for each batch of sub-tasks to be processed, obtains the accounting rules corresponding to the sub-tasks to be processed based on the product details, the type of the sub-tasks, and the preset accounting rule library. Then, according to the accounting rules, the payment information of the sub-tasks to be processed is recorded. This method targets pending tasks involving large volumes of big data transactions. First, it breaks down the pending tasks into multiple batches of sub-tasks based on the product details and the performance configuration of the relational database. This minimizes the resource consumption of transactions generated during the processing of a single batch, thereby reducing the overall system pressure and improving system response speed. Furthermore, for each batch of sub-tasks, a matching process is performed against a pre-defined accounting rule base to obtain the corresponding accounting rules. This enhances the automation and intelligence of the accounting process during payment registration.
[0157] Optionally, the overall view of the accounting vouchers is obtained by summarizing the accounting vouchers corresponding to the pending sub-tasks in each batch, and the accounting vouchers corresponding to the pending sub-tasks in each batch are generated based on the payment information records of the pending sub-tasks; the accounting vouchers generated at one time are obtained by reconciling each item based on the product details corresponding to the pending task.
[0158] Optionally, the task splitting module 320 is specifically used for:
[0159] The product details corresponding to the tasks to be processed are summarized and calculated to obtain summary data;
[0160] Based on the performance configuration of the relational database, a threshold is set for the resources consumed by the relational database when the subtasks to be processed in a single batch are executed; the threshold includes at least one of the following: a threshold for time resources and a threshold for space resources;
[0161] Based on the aggregated data and the threshold, calculate the number of batches that the task to be processed needs to be split into;
[0162] Based on the number of batches to be split, the task to be processed is split into multiple batches of sub-tasks to be processed.
[0163] Optionally, the preset accounting rule library includes at least one of the following: accounting rules for accounts receivable and payable, accounting rules for cash payments, accounting rules for non-cash payments, accounting rules for offsetting payment methods, accounting rules for bank statement payment methods, and accounting rules for transferring excess bank statement receipts to temporary receipts.
[0164] Optionally, the accounting and bookkeeping device 300 further includes a consistency comparison module;
[0165] The consistency comparison module is specifically used for:
[0166] After recording the payment information for the pending sub-tasks according to the accounting rules, the process further includes:
[0167] Compare the overall view of the accounting voucher with the accounting voucher generated in one go for consistency.
[0168] If the overall view of the accounting voucher is inconsistent with the accounting voucher generated in one go, the number of batches that the pending task needs to be split into should be recalculated.
[0169] Based on the recalculated number of batches to be split, the task to be processed is re-splitted to obtain multiple batches of sub-tasks to be processed.
[0170] Optionally, the user's input may include at least the identification information of the product data to be processed; the product data to be processed may be obtained based on at least one of the following: product sales details and product sales records;
[0171] Task generation module 310 is specifically used for:
[0172] Identify the product data in the database based on the identification information of the product data to be processed;
[0173] The data set consisting of the identified product data in the database is determined as the product details corresponding to the task to be processed.
[0174] Optionally, the accounting and bookkeeping device 300 also includes a task type determination module;
[0175] The task type determination module is specifically used for:
[0176] Determine the type of the subtask to be processed; the type includes at least one of the following: payment task and fee payment task.
[0177] Optionally, when the task type is payment-related, the accounting and bookkeeping device 300 further includes a payment recipient information acquisition module; the payment recipient information acquisition module is specifically used for:
[0178] Based on the product details of the subtask to be processed, obtain the payment information of the payment object corresponding to the subtask to be processed;
[0179] The task processing module 330 is specifically used for:
[0180] Based on the payment information of the payment recipient corresponding to the sub-task to be processed and the product details corresponding to the sub-task to be processed, the accounting rules corresponding to the sub-task to be processed are selected from the preset accounting rule library.
[0181] Optionally, when the task type is a payment-related task, the accounting and bookkeeping device 300 further includes a payment information determination module; the payment information determination module is specifically used for:
[0182] Based on the product details corresponding to the sub-task to be processed, determine the payment information of the payment recipient corresponding to the sub-task to be processed;
[0183] The task processing module 330 is specifically used for:
[0184] Based on the payment information of the payee corresponding to the sub-task to be processed and the product details corresponding to the sub-task to be processed, the accounting rules corresponding to the sub-task to be processed are selected from the preset accounting rule library.
[0185] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include: a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute an accounting method, which includes:
[0186] In response to user input, generate tasks to be processed;
[0187] Based on the product details and relational database performance configuration corresponding to the task to be processed, the task to be processed is split into multiple batches of sub-tasks to be processed; and the overall view of the accounting vouchers generated based on each batch of the sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed.
[0188] For each batch of pending subtasks, the accounting rules corresponding to the pending subtasks are obtained based on the product details, the type of the pending subtasks, and the preset accounting rule library; and the payment information of the pending subtasks is recorded according to the accounting rules.
[0189] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. 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.
[0190] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the accounting methods provided by the above methods, the method including:
[0191] In response to user input, generate tasks to be processed;
[0192] Based on the product details and relational database performance configuration corresponding to the task to be processed, the task to be processed is split into multiple batches of sub-tasks to be processed; and the overall view of the accounting vouchers generated based on each batch of the sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed.
[0193] For each batch of pending subtasks, accounting rules corresponding to the pending subtasks are obtained based on the product details, the type of the pending subtasks, and a preset accounting rule base; payment information for the pending subtasks is recorded according to the accounting rules. Furthermore, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the accounting methods provided by the above methods, the method comprising:
[0194] In response to user input, generate tasks to be processed;
[0195] Based on the product details and relational database performance configuration corresponding to the task to be processed, the task to be processed is split into multiple batches of sub-tasks to be processed; and the overall view of the accounting vouchers generated based on each batch of the sub-tasks to be processed is consistent with the accounting vouchers generated all at once based on the task to be processed.
[0196] For each batch of pending subtasks, the accounting rules corresponding to the pending subtasks are obtained based on the product details, the type of the pending subtasks, and the preset accounting rule library; and the payment information of the pending subtasks is recorded according to the accounting rules.
[0197] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0198] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.
[0199] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. An accounting bookkeeping method, characterized in that, include: In response to user input, generate tasks to be processed; Based on the product details and relational database performance configuration corresponding to the task to be processed, the task to be processed is split into multiple batches of sub-tasks to be processed. Furthermore, the overall view of the accounting vouchers generated from each batch of the pending subtasks is consistent with the accounting vouchers generated all at once from the pending task; the step of splitting the pending task into multiple batches of pending subtasks based on the product details corresponding to the pending task and the performance configuration of the relational database includes: summarizing and calculating the product details corresponding to the pending task to obtain summary data; setting a threshold for the relational database resources consumed by a single batch of the pending subtasks when executing, based on the performance configuration of the relational database; the performance configuration of the relational database includes at least one of the following: the maximum number of users the database can support, the database access speed, the input / output waiting time, and the maximum number of blocks read in a single input / output operation; the threshold includes at least one of the following: a threshold for time resources and a threshold for space resources; calculating the number of batches to be split for the pending task based on the summary data and the threshold; and splitting the pending task into multiple batches of the pending subtasks based on the number of batches to be split. For each batch of pending sub-tasks, the accounting rules corresponding to the pending sub-tasks are obtained based on the product details, the type of the pending sub-tasks, and a preset accounting rule library. The preset accounting rule library includes at least one of the following: accounting rules for accounts receivable and payable, accounting rules for cash payments, accounting rules for non-cash payments, accounting rules for offsetting payment methods, accounting rules for bank statement payment methods, and accounting rules for transferring excess bank statement payments to temporary receipts. According to the accounting rules, the payment information for the pending sub-tasks is recorded.
2. The accounting method according to claim 1, characterized in that, The overall view of the accounting vouchers is obtained by summarizing the accounting vouchers corresponding to the pending sub-tasks in each batch. The accounting vouchers corresponding to the pending sub-tasks in each batch are generated based on the payment information records of the pending sub-tasks. The accounting vouchers generated at one time are obtained by reconciling each item according to the product details corresponding to the pending task.
3. The accounting method according to claim 1, characterized in that, After recording the payment information for the pending sub-tasks according to the accounting rules, the process further includes: Compare the overall view of the accounting voucher with the accounting voucher generated in one go for consistency. If the overall view of the accounting voucher is inconsistent with the accounting voucher generated in one go, the number of batches that the pending task needs to be split into should be recalculated. Based on the recalculated number of batches to be split, the task to be processed is re-splitted to obtain multiple batches of sub-tasks to be processed.
4. The accounting method according to claim 1, characterized in that, include: The user's input includes at least the identification information of the product data to be processed; the product data to be processed is obtained based on at least one of the following: product sales details and product sales flow; The process of generating a task to be processed in response to user input includes: The product data in the database is identified based on the identification information of the product data to be processed; The data set consisting of the identified product data in the database is determined as the product details corresponding to the task to be processed.
5. The accounting method according to claim 1, characterized in that, Before obtaining the accounting rules corresponding to the sub-task based on the product details, the type of the sub-task, and the preset accounting rule library, the process further includes: Determine the type of the subtask to be processed; the type includes at least one of the following: payment tasks and fee payment tasks.
6. The accounting method according to claim 5, characterized in that, When the type is a payment-related task, before obtaining the accounting rules corresponding to the sub-task based on the product details, the type of the sub-task, and the preset accounting rule library, the process further includes: Based on the product details corresponding to the sub-task to be processed, obtain the payment information of the payment object corresponding to the sub-task to be processed; The step of obtaining the accounting rules corresponding to the sub-task to be processed based on the product details, the type of the sub-task to be processed, and the preset accounting rule library includes: Based on the payment information of the payment object corresponding to the sub-task to be processed and the product details corresponding to the sub-task to be processed, the accounting rules corresponding to the sub-task to be processed are selected from the preset accounting rule library.
7. The accounting method according to claim 5, characterized in that, When the type is a payment-related task, before obtaining the accounting rules corresponding to the sub-task based on the product details, the type of the sub-task, and the preset accounting rule library, the process includes: Based on the product details corresponding to the sub-task to be processed, determine the payment information of the payment object corresponding to the sub-task to be processed; The step of obtaining the accounting rules corresponding to the sub-task to be processed based on the product details, the type of the sub-task to be processed, and the preset accounting rule library includes: Based on the payment information of the payee corresponding to the sub-task to be processed and the product details corresponding to the sub-task to be processed, the accounting rules corresponding to the sub-task to be processed are selected from the preset accounting rule library.
8. An accounting and bookkeeping device, characterized in that, include: The task generation module is used to generate tasks to be processed in response to user input; The task splitting module is used to split the task to be processed into multiple batches of sub-tasks based on the product details and relational database performance configuration corresponding to the task to be processed. Furthermore, the overall view of the accounting vouchers generated from each batch of the pending subtasks is consistent with the accounting vouchers generated all at once from the pending task; the step of splitting the pending task into multiple batches of pending subtasks based on the product details corresponding to the pending task and the performance configuration of the relational database includes: summarizing and calculating the product details corresponding to the pending task to obtain summary data; setting a threshold for the relational database resources consumed by a single batch of the pending subtasks when executing, based on the performance configuration of the relational database; the performance configuration of the relational database includes at least one of the following: the maximum number of users the database can support, the database access speed, the input / output waiting time, and the maximum number of blocks read in a single input / output operation; the threshold includes at least one of the following: a threshold for time resources and a threshold for space resources; calculating the number of batches to be split for the pending task based on the summary data and the threshold; and splitting the pending task into multiple batches of the pending subtasks based on the number of batches to be split. The task processing module is used to obtain the accounting rules corresponding to each batch of pending subtasks based on the product details, the type of the pending subtask, and a preset accounting rule library. The preset accounting rule library includes at least one of the following: accounting rules for accounts receivable / payable, accounting rules for cash payments, accounting rules for non-cash payments, accounting rules for offsetting payment methods, accounting rules for bank statement payment methods, and accounting rules for transferring excess bank statement payments to temporary receipts. The module records the payment information of the pending subtasks according to the accounting rules.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the accounting method as described in any one of claims 1 to 7.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the accounting method as described in any one of claims 1 to 7.