Data processing method and related equipment

Abstract

The embodiment of the invention discloses a data processing method and related equipment, which are used for processing data under the condition of improving an effect of preventing repeated payment. The method provided by the embodiment of the invention comprises the steps of generating a target machine account initial list and a target machine account transaction detail list based on a fund flow condition of receipt circulation corresponding to each service, and generating a target machine account balance list based on the target machine account transaction detail list; on the basis of the target machine account balance table, determining whether the amount of money of a current downstream intermediate document corresponding to the target service is greater than the target amount of the corresponding upstream document or not; and determining whether the amount of the current final document corresponding to the target business is greater than the target amount of the initial document corresponding to the target machine account initial document table based on the target machine account balance table to obtain a determination result, and determining whether to intercept the generation of the current downstream intermediate document and the current final document based on the determination result.

Description

Technical Field

[0001] The embodiments of this application relate to the field of data processing, and more specifically, to data processing methods, data processing apparatus, data processing devices, computer-readable storage media, and computer program products containing instructions. Background Technology

[0002] As business grows, payment scenarios become increasingly complex, and the number and types of payment requests continue to increase, thus requiring a more effective mechanism to prevent duplicate payments.

[0003] Existing technologies primarily rely on single-point control mechanisms to prevent duplicate payments, by generating a unique order number for each payment request. The system only checks the status of each document to ensure that each payment request is processed only once.

[0004] However, existing technologies only focus on individual payment requests or order statuses, making it difficult to handle complex document flows and multi-level approval scenarios in complex business control situations, such as multi-level document flows in ERP systems. In such complex business processes, existing technologies struggle to control overpayments and duplicate payments as a whole, thus their effectiveness in preventing duplicate payments is poor. Summary of the Invention

[0005] This application provides a data processing method, a data processing apparatus, a data processing device, a computer-readable storage medium, and a computer program product containing instructions, which can perform data processing while improving the effectiveness of preventing double payment.

[0006] In a first aspect, embodiments of this application provide a data processing method, including:

[0007] Based on at least one initial document, at least one intermediate document, and a final document corresponding to each business, generate the target ledger initial document table and the target ledger transaction detail table, and generate the target ledger balance table based on the target ledger transaction detail table.

[0008] When the target business generates an intermediate document, the amount of the current downstream intermediate document corresponding to the target business is determined based on the target ledger balance table to determine whether it is greater than the target amount of the corresponding upstream document. When the target business submits the final document, the amount of the current final document corresponding to the target business is determined based on the target ledger balance table to determine whether it is greater than the target amount of the corresponding initial document in the target ledger initial document table, and the determination result is obtained.

[0009] Based on the determination result, determine whether to intercept the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business.

[0010] Secondly, embodiments of this application provide a data processing apparatus, including:

[0011] The generation unit is used to generate the target ledger initial form table and the target ledger transaction detail table based on the fund flow of the corresponding documents of each business, and to generate the target ledger balance table based on the target ledger transaction detail table. The corresponding document flow of the business represents the flow between at least one initial document, at least one intermediate document and final document corresponding to the business.

[0012] The determining unit is used to determine, based on the target ledger balance table, whether the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document when the target business generates an intermediate document, and to determine, based on the target ledger balance table, whether the amount of the current final document corresponding to the target business is greater than the target amount of the corresponding initial document in the target ledger initial document table when the target business submits the final document, and to obtain a determining result.

[0013] The determining unit is further configured to determine, based on the determining result, whether to intercept the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business.

[0014] Thirdly, embodiments of this application provide a data processing apparatus, including:

[0015] Central processing unit, memory, input / output interfaces, wired or wireless network interfaces, and power supply;

[0016] The memory is either a short-term storage memory or a persistent storage memory;

[0017] The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the aforementioned data processing method.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the aforementioned data processing method.

[0019] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to execute the aforementioned data processing method.

[0020] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: By generating initial target ledger forms, transaction detail forms, and balance sheets, the flow of funds in the business process is comprehensively recorded and monitored. When generating intermediate and final documents, the target ledger balance sheet is used to dynamically verify whether the amount exceeds the limit, and abnormal document generation is blocked accordingly, thereby achieving overall control over overpayment and duplicate payment. This global perspective and dynamic verification mechanism enable it to effectively cope with document flow and multi-level approval in complex business processes (such as multi-level document flow in ERP systems), significantly improving the effect of preventing duplicate payments.

[0021] Accordingly, the data processing apparatus, data processing equipment, computer-readable storage medium, and computer program product containing instructions provided in this application also have the aforementioned technical effects. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the architecture of a data processing system disclosed in an embodiment of this application;

[0023] Figure 2-1 This is a flowchart illustrating a data processing method disclosed in an embodiment of this application;

[0024] Figure 2-2 This is a schematic diagram of the overall architecture of a fund ledger in an ERP system, as disclosed in an embodiment of this application.

[0025] Figure 2-3 This is a schematic diagram illustrating the changes in the balance sheet corresponding to a one-to-one mode disclosed in an embodiment of this application;

[0026] Figure 2-4 This is a schematic diagram illustrating the changes in the balance sheet corresponding to a one-to-many mode disclosed in an embodiment of this application;

[0027] Figure 2-5 This is a schematic diagram illustrating the changes in a many-to-one balance sheet as disclosed in an embodiment of this application;

[0028] Figure 3-1 This is a schematic diagram of a procurement payment process disclosed in an embodiment of this application;

[0029] Figure 3-2 This is a schematic diagram illustrating a purchase order posting process disclosed in an embodiment of this application;

[0030] Figure 3-3 This is a schematic diagram of a purchase receipt posting process disclosed in an embodiment of this application;

[0031] Figure 3-4 This is a schematic diagram illustrating the process of posting a provisional accounts payable invoice according to an embodiment of this application;

[0032] Figure 3-5 This is a schematic diagram illustrating the process of recording a purchase acceptance form according to an embodiment of this application;

[0033] Figure 3-6 This is a schematic diagram of a receipt posting process disclosed in an embodiment of this application;

[0034] Figure 3-7 This is a schematic diagram illustrating the process of posting a financial accounts payable invoice according to an embodiment of this application;

[0035] Figure 3-8 This is a schematic diagram illustrating the process of recording a payment application and payment order, as disclosed in an embodiment of this application.

[0036] Figure 3-9 This is a schematic diagram illustrating a final bank payment submission process disclosed in an embodiment of this application;

[0037] Figure 4 This is a schematic diagram of the structure of a data processing device disclosed in an embodiment of this application;

[0038] Figure 5 This is a schematic diagram of the structure of a data processing device disclosed in an embodiment of this application. Detailed Implementation

[0039] This application provides a data processing method, a data processing apparatus, a data processing device, a computer-readable storage medium, and a computer program product containing instructions for performing data processing while improving the effectiveness of preventing double payment.

[0040] The relevant technical features in this field are described as follows:

[0041] BOTP stands for "Business Object Transform Platform". It is a data transformation platform based on business object technology, used to handle data transformation transactions between different documents.

[0042] Entry into the ledger: The process of writing into the relevant ledger table, which can be understood as an action of a product.

[0043] ERP stands for Enterprise Resource Planning. It is a management information system that integrates all core business processes within an enterprise (such as procurement, production, sales, finance, and human resources).

[0044] Existing technologies primarily rely on single-point control mechanisms to prevent duplicate payments, generating a unique order number for each payment request. The system only checks the status of each document, ensuring that each payment request is processed only once. However, this mechanism has significant shortcomings in complex scenarios, especially in ERP systems, primarily in the following two aspects: First, the process is complex and lengthy: In the procurement payment process of existing ERP systems, taking a certain procurement process as an example, multiple documents are involved from procurement to payment. These documents are intertwined and complex, with multiple branches, ultimately flowing to the payment order. This complex process makes it difficult for existing technologies to effectively monitor and manage the flow of funds throughout the entire process. Second, there are customization development issues: In the customization solutions of existing ERP systems, customization development (secondary development) intrudes into the key business elements of standard products, involving complex heterogeneous system integration. This intrusive development affects the uniqueness of document numbers and concurrency control, leading to the failure of concurrency idempotency. This approach has the following shortcomings: First, existing technologies only focus on a single payment request or order status, making it difficult to cope with complex document flow and multi-level approval scenarios in complex business control scenarios. In such complex business processes, existing technologies struggle to control overpayments and duplicate payments holistically, resulting in poor effectiveness in preventing duplicate payments. Secondly, customized code intrusion occurs: customized code intrudes into standard products, modifying key elements, affecting document number uniqueness and concurrency control, leading to the failure of idempotency. Thirdly, the business control logic itself is too flexible: allowing overpayments, prepayments followed by payments, multiple step-by-step payment pushbacks, merging and splitting payments, payment refunds, etc. Fourthly, non-standard human operation: duplicate payments result from untimely bank status updates and non-standard human operation. Other existing technologies only prevent duplicate payments at the system design level, mainly including but limited to the following: 1. Front-end and back-end verification: unifying front-end and back-end verification logic to prevent customers from bypassing inherent logic to make duplicate payments. 2. Intermediate payment status: introducing a "paying in progress" status to check payment records for the same order, ensuring atomicity of payment through locking mechanisms. 3. Order status update mechanism: optimizing the order status update mechanism to ensure timely and accurate updates to the order status after successful payment, avoiding duplicate payments due to untimely status updates. 4. System Concurrency Control: Allocate system resources appropriately to avoid system processing anomalies due to high concurrency, thus preventing duplicate payments. 5. System Version Compatibility: Ensure good compatibility between different system versions to avoid payment process anomalies caused by version differences and reduce the risk of duplicate payments. 6. Data Synchronization Mechanism: Establish an efficient data synchronization mechanism to ensure real-time data consistency between systems and prevent duplicate payments caused by data asynchrony. 7. Interface Idempotent Anti-Duplicate Mechanism: Through unique request identifiers, status verification, and transaction control, ensure that the same payment request is processed only once, effectively preventing duplicate payments.However, these existing technologies are all single-point controls. If there is a vulnerability in any link, the corresponding vulnerability is fixed. It is difficult to cover various complex scenarios. If an incorrect payment or overpayment occurs, compensation can only be provided afterward. Therefore, the effectiveness of existing technologies in preventing duplicate payments is not ideal.

[0045] Based on this, this application provides a data processing method that comprehensively records the flow of funds in business document circulation by generating an initial target ledger table, transaction details table, and balance table. When generating intermediate and final documents, the target ledger balance table is used to verify whether the amount exceeds the limit, and abnormal document generation is blocked based on the verification result, thereby effectively controlling overpayment and duplicate payment. This method is suitable for complex business processes and multi-level approval scenarios. It is evident that this application can achieve the following effects: First, it can achieve overall control overpayment and duplicate payment. This global perspective and dynamic verification mechanism enable it to effectively handle document circulation and multi-level approval in complex business processes (such as multi-level document circulation in ERP systems). This pairwise control and beginning-end control method can significantly improve the effectiveness of preventing duplicate payments. Second, verification through the target ledger balance table avoids the impact of customized development on the uniqueness of document numbers and concurrency control, ensuring the idempotency of concurrent operations and solving the problem of concurrency idempotency failure in existing technologies. Third, the ledger mechanism strictly controls the payment logic, avoiding overpayment and duplicate payments caused by overly flexible business control logic, thus improving the standardization and controllability of the payment process. Fourth, the automated verification and interception mechanism reduces the risk of duplicate payments caused by untimely bank status updates or improper human operation, thereby improving the reliability and security of the payment system.

[0046] Please see Figure 1 The architecture of the data processing system in this application embodiment includes:

[0047] Data processing device 101 and client 102. When performing data processing, data processing device 101 can connect to client 102. Data processing device 101 can obtain at least one initial document, at least one intermediate document, and a final document corresponding to each business. Based on these documents, it generates a target ledger initial document table and a target ledger transaction detail table, and generates a target ledger balance table based on the target ledger transaction detail table. When an intermediate document is generated for a target business, the device determines whether the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document based on the target ledger balance table. Similarly, when a final document is submitted for a target business, the device determines whether the amount of the current final document corresponding to the target business is greater than the target amount of the corresponding initial document in the target ledger initial document table. Based on these results, the device determines whether to intercept the generation of the current downstream intermediate document and the current final document corresponding to the target business.

[0048] based on Figure 1 Please refer to the data processing system shown. Figure 2-1 , Figure 2-1 This is a flowchart illustrating a data processing method disclosed in an embodiment of this application. The method includes:

[0049] 201. Based on at least one initial document, at least one intermediate document, and a final document corresponding to each business, generate the target ledger initial document table and the target ledger transaction detail table, and generate the target ledger balance table based on the target ledger transaction detail table.

[0050] In one optional implementation, the ledger refers to a funds ledger, which represents the flow of funds in the business process, specifically including the transfer between initial documents, intermediate documents, and final documents. Initial documents represent the starting point of the business, such as sales orders. Intermediate documents represent intermediate stages in the business process, such as accounts receivable. Final documents represent the end point of the business process, such as payment slips. Specifically, because actual business involves a reverse refund process, its algorithm is exactly the opposite of the forward process, with deductions becoming increases; this will not be elaborated upon further.

[0051] It is important to understand that this application aims to manage funds through a unified fund ledger system, mitigating payment risks in complex processes. The original design is based on the fact that payment is essentially a transfer of monetary claims from the payer to the payee. This leads to three aspects: first, the total amount of the payer's claims transferred between documents remains constant; second, so-called double payments and erroneous payments refer to abnormal "overdrafts" in the transfer of claims between documents; and third, claims can be carried out at the accounting level, controlling duplicate payments through accounting controls. Therefore, the core idea of ​​this application is to comprehensively control each document transfer process through the overall framework of a fund ledger. Traditional defenses are limited to local control points, while this application starts from the overall business process, comprehensively monitoring fund flows. Please refer to the diagram for details. Figure 2-2 , Figure 2-2 This is a schematic diagram of the overall architecture of a fund ledger in an ERP system disclosed in an embodiment of this application. Figure 2-2 It is known that traditional defenses are limited to local control points, such as: first layer of protection, second layer of protection, etc. However, the anti-duplication of the fund ledger in this application starts from the overall business process and conducts overall control over each process of document transfer (debt transfer), specifically including the following four aspects: (1) Debt transfer is maintained throughout the entire chain; (2) Document number conversion is continuous in each link; (3) Redundancy and mutual backup of transaction link ledger accounts; (4) The scheme is jointly managed with other payment special projects. Through this comprehensive protection strategy, the fund ledger can be managed and controlled more effectively to ensure the security and accuracy of fund transfer. For example: a document in the business system is generated into a document in the fund system, i.e., document A -> document B. In the system, document A generates document B, which is actually a debt transfer. This fund transfer process will be recorded in the fund ledger. The core of the fund ledger is the balance model. The balance model is the core of the fund ledger. Excess control is achieved by controlling the balance. Usually, when the balance is 0, funds cannot be further transferred downstream unless excess or debt is allowed. The balance model is mainly divided into three parts. The first part is the ledger balance sheet, which records the available balance of all documents that can be transferred. The second part is the ledger initial document sheet, which records the initial amount of multiple documents merged and pushed down to generate the downstream. The third part is the ledger transaction flow sheet, which records the upstream and downstream relationships and the transaction amount of this transaction.

[0052] The Ledger Balance (T_BD_LedgerBalance) is used to control the flow of funds between documents. If the available balance (FBalanceAmt) is exceeded, the transaction will be blocked. For example: Document A -> Document B, Document B -> Document C, the amount exceeding the limit between each pair of documents is controlled. Document A can be pushed down to generate Document B, and the available balance must generally be sufficient to allow it. Exceeding the limit is allowed in special cases, implemented by configuring limits. The Ledger Balance is the control table for the flow of funds between pairs of documents, ensuring the compliance of fund transfers. The relevant table structure design fields of the Ledger Balance are shown in Table 1 below:

[0053]

[0054] Table 1

[0055] Note: The default values ​​for the table structure of the ledger balance sheet and whether it is allowed to be empty are not explained in detail here. In actual implementation, you can adjust it according to the specifications.

[0056] The initial ledger table (T_BD_LedgerBeginBill) is used to record scenarios where multiple first orders are combined and pushed down during the first circulation of documents, i.e., scenarios where multiple first orders are merged and pushed down. For example, if the initial order is A+B->C, and orders A and B are merged and pushed down to generate order C, A, B, and C are respectively posted in the previous ledger balance table, while the initial ledger table records two records for the source orders of C: A and B. The foreign key field FID corresponds to the internal key of C in the ledger balance table, realizing a one-to-many relationship. The relevant table structure design fields of the initial ledger table are shown in Table 2 below:

[0057]

[0058] Table 2

[0059] The Ledger Transaction Flow Sheet (T_BD_LedgerDetail) records the transaction details of each document transfer. For example, document A generates downstream document B, which is equivalent to a bank transaction used to deduct from the balance. This table also records the upstream and downstream relationships, facilitating control between pairs of documents. The relevant table structure design fields of the Ledger Transaction Flow Sheet are shown in Table 3 below:

[0060]

[0061] Table 3

[0062] For example: Purchase order CG001 purchases materials worth 5000 yuan. Assume that an inbound notification order RK001 is generated. According to the balance model design, the data flow in the table is as follows: Step 1: Purchase order CG001 is the initial source order because it has no upstream. The records in the ledger balance table (T_BD_LedgerBalance) are shown in Table 4 below:

[0063]

[0064] Table 4

[0065] The available balance of the FBalanceAmt field in the ledger balance table for purchase order CG001 is 0 because a receivables transfer has occurred. If it is a partial rollover, then 5000 - rollover amount = available balance. In this case, the receiving notification RK001 should also be recorded in the ledger balance table (T_BD_LedgerBalance), as shown in Table 5 below:

[0066]

[0067] Table 5

[0068] Since the receiving notification RK001 is not an initial order, this relationship needs to be recorded in the initial order table of the ledger (T_BD_LedgerBeginBill), as shown in Table 6 below:

[0069]

[0070] Table 6

[0071] Simultaneously, record one transaction, and the transaction details in the ledger (T_BD_LedgerDetail) are shown in Table 7 below:

[0072]

[0073] Table 7

[0074] This concludes one accounting process.

[0075] Understandably, in actual business operations, business models can include, but are not limited to, the following three: First, a one-to-one model: one initial document corresponds to one intermediate document and one final document. Second, a one-to-many model: one initial document corresponds to multiple intermediate documents and one final document. Third, a many-to-one model: multiple initial documents correspond to one intermediate document and one final document. These models are recorded and managed through initial document ledgers and transaction logs to ensure the compliance of fund flows. Please refer to [link / reference] for details. Figure 2-3 , Figure 2-4 and Figure 2-5 , Figure 2-3This is a schematic diagram illustrating the changes in the balance sheet corresponding to a one-to-one mode disclosed in an embodiment of this application. Figure 2-4 This is a schematic diagram illustrating the changes in the balance sheet corresponding to a one-to-many model disclosed in an embodiment of this application. Figure 2-5 This is a schematic diagram illustrating the changes in a many-to-one balance sheet as disclosed in an embodiment of this application. Figure 2-3 , Figure 2-4 and Figure 2-5 The table on the right is a partial field of the Ledger Balance Sheet (T_BD_LedgerBalance). More specifically, it is... Figure 2-3 As can be seen, in the one-to-one model, taking a sales order as an example to derive an accounts receivable order, and the accounts receivable order to derive a payment order. Furthermore, both the accounts receivable order and the payment order need to be entered into the initial ledger form (e.g., the corresponding initial orders are all sales orders) and the ledger transaction log. Figure 2-4 As can be seen, in a one-to-many model, taking the example of a sales order repeatedly pushing down to accounts receivable, and then the accounts receivable further pushing down to payment orders. Furthermore, accounts receivable 1, accounts receivable 2, and payment orders all need to be entered into the initial order form (e.g., the corresponding initial orders are all sales orders) and the transaction log form. Figure 2-5 As can be seen, in the many-to-one model, taking the merging of multiple sales orders to push down accounts receivable, and the accounts receivable to push down payment orders as an example, in addition, the sales orders 1 and 2 and the payment orders corresponding to the accounts receivable need to be entered into the initial order form of the ledger (for example, the corresponding initial orders are sales orders 1 and 2) and the transaction flow form of the ledger.

[0076] 202. When generating intermediate documents for the target business, determine whether the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document based on the target ledger balance sheet. When submitting the final document for the target business, determine whether the amount of the current final document corresponding to the target business is greater than the target amount of the corresponding initial document in the target ledger initial document table, and obtain the determination result.

[0077] In one optional implementation, the amount of the current downstream intermediate document represents the actual amount of the current intermediate document. The target amount of the corresponding upstream document represents the target amount set by the upstream document. The amount of the current final document represents the actual amount of the current final document. The target amount of the initial document represents the target amount set by the initial document. These amounts are dynamically verified through the ledger balance sheet to ensure the compliance of fund flows.

[0078] It's important to understand that the overall design of the funds ledger balance model is the key and innovative aspect of this application. It breaks with traditional design thinking, achieving ultimate anti-duplicate measures from the perspective of debt transfer. Two control points are involved: 1. Control of the flow of documents between each other: ensuring the compliance of the amount in each flow. 2. Control of the final documents (such as payment slips) and initial slips submitted to the bank: ensuring the compliance of the final payment amount. This method of pairwise control and initial / final slip control can significantly improve the effectiveness of preventing duplicate payments.

[0079] 203. Based on the determined results, determine whether to intercept the generation of the current downstream intermediate documents corresponding to the target business and the current final documents corresponding to the target business.

[0080] In one optional implementation, global dynamic verification of the amount exceeds the limit is achieved through pairwise control and first / last order control, blocking the generation of documents that do not comply with business rules, thereby preventing overpayment and duplicate payments. This ensures the compliance of fund flows in the business process and improves the reliability and security of the payment system. It is important to understand that duplicate payments inevitably lead to overpayments; therefore, determining whether a duplicate payment has occurred is crucial. Overpayment detection can effectively block duplicate payments and enhance the security of the payment system.

[0081] To facilitate understanding of the embodiments of this application, a specific example is given below to illustrate the entire process of posting entries to the ledger and balance sheet, using the procurement process as an example: Please refer to... Figure 3-1 , Figure 3-2 , Figure 3-3 , Figure 3-4 , Figure 3-5 , Figure 3-6 , Figure 3-7 , Figure 3-8 , Figure 3-9 . Figure 3-1 This is a schematic diagram of a procurement payment process disclosed in an embodiment of this application. Figure 3-1 As can be seen, taking a certain procurement process as an example, from procurement to payment, multiple documents are involved. These documents are intertwined and complex, with multiple branches, and eventually flow to the payment order. Figure 3-2 This is a schematic diagram of a purchase order posting process disclosed in an embodiment of this application. Figure 3-2 It can be seen that the purchase order has been recorded, and the available balance corresponding to the purchase order in the ledger balance table is 5000. Figure 3-3 This is a schematic diagram illustrating the process of posting a purchase receipt as disclosed in an embodiment of this application. Figure 3-3It can be seen that the purchase receipt is a downstream document of the purchase order. The purchase receipt amount of 1500 is less than the purchase order amount of 5000. The generation of the purchase receipt is not intercepted and the purchase receipt is not posted in the ledger. The available balance of the purchase receipt is recorded as 1500 in the ledger balance table, and the available balance of the purchase order is updated to 5000-1500=3500. Figure 3-4 This is a schematic diagram illustrating the process of posting provisional accounts payable in an embodiment of this application. Figure 3-4 It can be seen that the provisional accounts payable is a downstream document of the purchase order. The provisional accounts payable of 2000 is less than the purchase order of 3500. The generation of the provisional accounts payable is not intercepted and the provisional accounts payable is not posted. The available balance of the provisional accounts payable is recorded as 2000 in the ledger balance table, and the available balance of the purchase order is updated to 3500-2000=1500. Figure 3-5 This is a schematic diagram of a purchase acceptance form posting process disclosed in an embodiment of this application. Figure 3-5 It can be seen that the purchase acceptance form is a downstream document of the purchase order. The purchase acceptance form's value of 1000 is less than the purchase order's value of 1500. The generation of the purchase acceptance form is not intercepted and the purchase acceptance form is not recorded in the ledger balance table. The available balance of the purchase acceptance form is recorded as 1000, and the available balance of the purchase order is updated to 1500-1000=500. Figure 3-6 This is a schematic diagram of a receipt posting process disclosed in an embodiment of this application. Figure 3-6 It can be seen that the receipt is a downstream document of the provisional payable. The receipt 2000 is equal to the provisional payable 2000. The generation of the receipt is not intercepted and the receipt is not posted in the ledger. The available balance of the receipt is recorded as 2000 in the ledger balance table, and the available balance of the provisional payable is updated to 2000-2000=0. Figure 3-6 This is a schematic diagram illustrating a process for posting financial accounts payable invoices according to an embodiment of this application. Figure 3-7 It can be seen that the financial payables are downstream documents of the receipt note, purchase receipt note, and purchase acceptance note. The financial payables of 4500 are equal to the sum of the receipt note of 2000, the purchase receipt note of 1500, and the purchase acceptance note of 1000. The generation of financial payables is not intercepted and the financial payables are not posted in the ledger. The available balance of financial payables is recorded as 4500 in the ledger balance table, and the receipt note, purchase receipt note, and purchase acceptance note are updated to 0 respectively. Figure 3-8 This is a schematic diagram illustrating the process of posting a payment application form and a payment order, as disclosed in an embodiment of this application. Figure 3-8It can be seen that the payment application form is a downstream document of the accounts payable document. The payment application form's value of 4500 equals the accounts payable document's value of 4500. The generation of the payment application form is not intercepted, and the payment application form is not posted. The ledger balance shows the available balance of the payment application form as 4500, and the accounts payable document is updated to 4500-4500=0. The payment note is a downstream document of the payment application form. The payment note's value of 4000 is less than the payment application form's value of 4500. The generation of the payment note is not intercepted, and the payment note is not posted. The ledger balance shows the available balance of the payment note as 4000, and the payment application form is updated to 4500-4000=500. Figure 3-9 This is a schematic diagram illustrating a final bank payment submission process disclosed in an embodiment of this application. Figure 3-9 As can be seen, during the final bank payment process, payment order 4000 is disbursed, generating a bank receivable order of 4000. At this point, the available balance of the payment order in the ledger balance sheet is updated to 4000 - 4000 = 0. If the final bank payment process needs to be completed again, the disbursement of 4000 must be greater than the available balance of the payment order (0), thus blocking the disbursement of the subsequent bank receivable order.

[0082] Understandable, Figures 3-2 to 3-9 The fields in the database differ slightly from the actual design of the ledger balance sheet. Figures 3-2 to 3-9 For ease of reading and understanding, the actual development process will follow the field design of the ledger balance table.

[0083] In this way, by generating initial target ledger forms, transaction detail forms, and balance sheets, the flow of funds in the business process is comprehensively recorded and monitored. When generating intermediate and final documents, the target ledger balance sheet is used to dynamically verify whether the amount exceeds the limit, and abnormal document generation is blocked accordingly, thereby achieving overall control over overpayment and duplicate payment. This global perspective and dynamic verification mechanism enable it to effectively handle document flow and multi-level approval in complex business processes (such as multi-level document flow in ERP systems), significantly improving the effectiveness of preventing duplicate payments. Secondly, the system performance and functions remain stable when facing changes in internal structure and external environment, ensuring the reliability and security of the payment process.

[0084] In one optional implementation, when the target business generates an intermediate document, the method further includes determining whether the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document based on the target ledger balance table; and when the target business submits a final document, the method further includes determining whether the amount of the current final document corresponding to the target business is greater than the target amount of the corresponding initial document in the target ledger initial document table.

[0085] Specifically, the available balance in the target ledger balance table represents the amount available for payment in the current business process, reflecting the actual availability of funds. The excess amount corresponding to each target document configured in the target ledger balance table represents the amount exceeding the available balance allowed by the system under specific circumstances, typically used to handle special situations (such as emergency payments or temporary credit limit adjustments). The target amount can be obtained by adding the available balance and the excess amount, representing the maximum amount that can be used for the document in the current business process. This design allows for flexible handling of excess payments when necessary, while ensuring compliance with overall fund control.

[0086] By introducing the concepts of available balance and excess amount, this application enables flexible handling of special circumstances (such as emergency payments or temporary credit limit adjustments) while ensuring overall compliance with fund control regulations. This design not only enhances the flexibility of fund management but also strengthens the system's adaptability and robustness in complex business scenarios.

[0087] In one optional implementation, based on the determined result, determining whether to intercept the generation of the current downstream intermediate document and the current final document includes: if the amount of the current downstream intermediate document corresponding to the target business is less than or equal to the target amount of the corresponding upstream document, and the amount of the current final document corresponding to the target business is less than or equal to the target amount of the corresponding initial document in the target ledger initial document table, then determining not to intercept the generation of the current downstream intermediate document and the current final document corresponding to the target business; if the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document, and the amount of the current final document corresponding to the target business is greater than the target amount of the corresponding initial document in the target ledger initial document table, then determining whether to intercept the generation of the current downstream intermediate document and the current final document corresponding to the target business based on preset interception control rules, wherein the preset interception control rules are configured in the target ledger configuration table.

[0088] Specifically, the preset interception control rules characterize the system's processing strategy when it detects excessive payments, i.e., under what circumstances the generation of documents is blocked. These rules are preset in the target ledger configuration table (ledger configuration master table and ledger configuration entry table) to determine whether to block the generation of excessive intermediate or final documents, ensuring the compliance of fund flows.

[0089] The Ledger Configuration Master Table (T_BD_LedgerConfig) is used to globally control the enabling status of the fund ledger function and set the number of days to retain historical data to optimize system performance. Through this table, system administrators can flexibly enable or disable the fund ledger function and manage historical data cleanup strategies. The relevant table structure design fields of the Ledger Configuration Master Table are shown in Table 8 below:

[0090]

[0091] Table 8

[0092] The Ledger Configuration Entry table (T_BD_LedgerConfigEntry) is used in conjunction with the product. It allows you to configure which documents require control and map them to specific fields on those documents, rather than hardcoding them. It also supports secondary document configuration and enabling or disabling mandatory interception controls. This is useful because some processes can exceed limits, but even if limits are exceeded, the business may not want mandatory control, only a notification. The relevant table structure and fields of the Ledger Configuration Entry table are shown in Table 9 below:

[0093]

[0094] Table 9

[0095] In this way, by introducing preset interception control rules and a flexible target ledger configuration table, the fund control strategy can be flexibly adjusted according to business needs. This design not only ensures the compliance of fund flows but also enhances the system's flexibility and adaptability, meeting the diverse needs of different business scenarios.

[0096] In one optional implementation, based on a preset interception control rule, determining whether to intercept the generation of the current downstream intermediate document and the current final document corresponding to the target business includes: if the preset interception control rule is a strong interception control rule, then determining to intercept the generation of the current downstream intermediate document and the current final document corresponding to the target business, and executing the interception; if the preset interception control rule is a weak interception control rule, then after obtaining the user's interception trigger signal, determining to intercept the generation of the current downstream intermediate document and the current final document corresponding to the target business, and executing the interception.

[0097] Specifically, strong interception control rules mean that when overpayment is detected, the system will automatically intercept the generation of related documents to ensure the absolute compliance of fund flows. Weak interception control rules mean that when overpayment is detected, the system will not automatically intercept document generation, but will wait for user confirmation (such as an interception trigger signal) before executing the interception, suitable for business scenarios requiring flexible handling. A user interception trigger signal represents a signal that the user actively triggers the interception operation after the system prompts an overpayment, used to determine whether to intercept document generation under weak interception rules. A weakly controlled document is one where, when overpayment is detected, the system only issues a prompt and does not automatically prevent document generation, suitable for business scenarios requiring flexible handling. A strongly controlled document is one where, when overpayment is detected, the system automatically prevents document generation to ensure the absolute compliance of fund flows. Customizable interception strength means that users can define which documents require strong control and which require weak control according to business needs. For example, in the procurement process, the conversion from purchase orders to accounts payable involves various complex operations, such as merging, splitting, reversing operations, and modifying amounts. In this situation, implementing strict controls could lead to a high false positive rate. Therefore, the design opts not to implement strict controls, but only to perform record-keeping to avoid unnecessary interception.

[0098] It is understandable that documents requiring strict control include, but are not limited to, expense reimbursement forms, accounts payable forms, payment application forms, and payment forms, the specifics of which are defined by the business operations. The processing method for strictly controlled documents involves checking the current balance on the validator; if the amount exceeds the target amount, it is automatically blocked. Documents not subject to strict control do not require balance checks, and the system will not automatically block their generation.

[0099] In this way, by distinguishing between strong and weak interception control rules and strong and weak control documents, this application can flexibly adjust the fund control strategy according to business needs. This design not only ensures the compliance of fund flows but also reduces the false judgment rate, improves the system's flexibility and adaptability, and meets the diverse needs of different business scenarios.

[0100] In an optional implementation, the method further includes: obtaining update information of the target ledger configuration table, generating a target plugin based on the update information, the update information including newly added and / or updated target interception control logic, dynamically loading and executing the target plugin at runtime, so as to intercept the generation of current downstream intermediate documents and current final documents corresponding to other businesses based on the target interception control logic.

[0101] Specifically, the update information in the target ledger configuration table represents the target interception control logic for adding and / or updating the fund ledger configuration table. This includes, but is not limited to, the addition interception rules for each document (the specific processing logic when overpayment is detected, including strong interception, weak interception, interception conditions, etc., used to determine whether to intercept document generation), adjusting the overpayment amount of each document, and updating the control relationship between each document. It is understandable that ERP systems typically require continuous updates due to product iterations, while private deployment versions are fixed and upgrades are complex. This application utilizes the platform's injectable features to achieve versionless upgrades through a dynamic registration function of the plugin model. The specific technical implementation involves injecting the BOS platform table T_META_OPERATESERVICEPLUGIN, binding it to operations such as save, audit, and unaudit, and implementing ledger entry and control through plugin code, corresponding to the ledger configuration table. This approach solves the problem of version updates in private deployments, avoiding system instability and secondary development costs caused by version differences.

[0102] Specifically, in an example of the overall process and architecture for fund ledger management in an ERP system disclosed in this application, the process begins with a salesperson creating a purchase order. The purchase order undergoes a series of operations and transfers, including filling out forms and reviewing them, ultimately generating an accounts payable invoice. The finance department creates a payment application based on the accounts payable invoice, then generates a payment order, and finally reviews the documents. During the document transfer process, various operations (including saving, submitting, reviewing, unreviewing, and deleting) are performed through the BOS platform domain model, ensuring the correct processing and transfer of documents. When processing documents, the system executes interception control logic to ensure the compliance and security of transactions. The refund sharing limit scheme allows the system to set a total refund limit. As long as the total refund does not exceed this limit, the specific refund amount can be flexibly processed. For example, if A needs a refund of 50 and B needs a refund of 100, the system sets the refund sharing limit for A and B to 150, as long as the total refund does not exceed 150. Functionality can also be dynamically extended and modified through plugins without requiring system upgrades. The ledger records detailed accounts of all financial transactions, including ledger balances, transaction logs, and refund sharing quota tables. Ultimately, all transaction data is stored in backend tables, including ledger configuration tables, ledger balance tables, transaction logs, and refund sharing quota tables. This design allows the system to dynamically expand and modify its functionality through plugins without upgrades, thus solving the version update problem in private deployments and avoiding system instability and secondary development costs caused by version differences. This solution avoids precise allocation of specific refund amounts, improving flexibility.

[0103] It's worth noting that secondary development documents are not within the scope of standard products, and without proper control, anomalies may occur at the initial stage of the business process. This application supports configurability, ensuring that secondary development documents can also be included in the fund control system. Secondly, once rules are established, universal control can be implemented regardless of the system, as long as it is connected as required. This is difficult to achieve with existing technical solutions, and this application solves this problem through a plug-in model. Next, the system supports dynamic loading of plug-ins, eliminating concerns about version issues and allowing flexible configuration of any document (including secondary development documents), improving the system's adaptability and flexibility. Furthermore, the system design ensures compatibility with historical versions, avoiding functional failures or data inconsistencies caused by version updates.

[0104] Understandably, for documents in transit, the actual initial document may not have been posted after a patch (plugin) update. This application standardizes the initial document scheduling criterion to "no upstream." Specifically, before the patch (plugin) upgrade, A / B operations had been completed. After the sudden upgrade, the system determines A as the initial document and posts it, thus finding that the initial document for C is A, for subsequent control. This design ensures that intermediate states after going live (incomplete intermediate document states) will not cause control anomalies due to patch updates, improving system stability and reliability.

[0105] In an optional implementation, after determining the generation of the current downstream intermediate document and the current final document corresponding to the target service, the method further includes: generating interception logs corresponding to the current downstream intermediate document and the current final document corresponding to the target service. Further, intercepting the generation of the current downstream intermediate document and the current final document corresponding to other services based on the target interception control logic includes at least one of the following: if the number of interception logs for the first tenant within the most recent preset time period is less than or equal to a preset maximum threshold, then the generation of the current downstream intermediate document and the current final document corresponding to other services of the first tenant is intercepted based on the target interception control logic; if the number of interception logs for the second tenant within the most recent preset time period is less than a preset minimum threshold, then the generation of the current downstream intermediate document and the current final document corresponding to other services of the second tenant is intercepted based on the target interception control logic.

[0106] Specifically, after determining the generation of the current downstream intermediate document and the current final document corresponding to the target business, interception logs for these documents can be generated to create a ledger interception log table. It's understandable that while the ledger configuration table can be configured not to intercept, the interception logs in the ledger interception log table (T_BD_LedgerInterceptLog) will still be recorded for future reference. The relevant table structure design fields for the ledger interception log table are shown in Table 10 below:

[0107]

[0108] Table 10

[0109] It is understandable that the six tables in this application—the target ledger initial table, the target ledger transaction details table, the target ledger balance table, the ledger configuration master table, the ledger configuration entry table, and the ledger interception log table—are the core design of this application. Because the actual business involves a reverse refund process, the algorithm is exactly the opposite of the forward one, with deductions becoming increases. This will not be elaborated in detail.

[0110] It's important to understand that after a patch (plugin) update, the system will not enable the new interception control function (i.e., target interception control logic) by default, unless the user is a trial customer. The system will automatically enable this function after a certain rectification period. To achieve this, the system will add automatic activation logic to the periodic cleanup execution plan and set it to run daily. The recent preset period can be the most recent month or before the deadline (e.g., December 31, 2025). The specific method is as follows:

[0111] 1. Automatic Activation Based on Log Record Count: If the number of automatically blocked log records exceeds a certain absolute value (e.g., 30) within the past month, the system automatically activates a new interception control function (target interception control logic). This method is applicable to tenants during trial or rectification periods, where the system determines whether a new interception control function (target interception control logic) needs to be activated based on the number of log records. Specifically, it determines whether to execute the steps of intercepting the generation of current downstream intermediate documents and current final documents corresponding to other businesses based on the target interception control logic.

[0112] 2. Automatic Activation Based on Deadline: The system sets a deadline (e.g., 2025-12-31). If the number of records intercepted before the deadline does not exceed a preset value, the new interception control function (target interception control logic) will be automatically activated after the deadline. This method is suitable for tenants during the rectification period. The system uses the deadline to determine whether to activate the new interception control function (target interception control logic), that is, to determine whether to execute the steps of intercepting the generation of current downstream intermediate documents and current final documents corresponding to other businesses based on the target interception control logic.

[0113] It's worth noting that the automatic blocking control function is designed with the possibility of false blocking in mind. The system determines whether to enable the blocking function (target blocking control logic) based on the number of log entries or the deadline, thus avoiding unnecessary activation of the blocking function and reducing the risk of false blocking.

[0114] In this way, by generating interception logs and dynamically adjusting the interception control function according to the number of interception logs of tenants, this application can flexibly adapt to the actual business needs of different tenants.

[0115] In one optional implementation, generating a target ledger balance sheet based on the target ledger transaction details table includes: determining the transaction amount and value corresponding to each business in the target ledger transaction details table, taking the difference between the available balance corresponding to each business in the initial ledger balance table and the transaction amount and value corresponding to each business as the available balance corresponding to each business, and obtaining the target ledger balance sheet based on the available balance corresponding to each business.

[0116] Specifically, when generating the target ledger balance sheet, the system does not directly modify the balance values. Instead, it updates the balance by calculating the transaction amounts and values ​​in the transaction log. In other words, the latest available balance is calculated by subtracting the transaction amounts in the transaction log from the current available balance. This improves the efficiency and accuracy of data updates.

[0117] In one optional implementation, each document in the target ledger transaction details table includes a corresponding execution status. Generating a target ledger balance table based on the target ledger transaction details table includes: determining the execution status of the balance processing corresponding to each document in the target ledger transaction details table; if the execution status of the target document is not executed, then executing the balance processing of the target document to generate the target ledger balance table; and if the execution is successful, then updating the execution status of the target document in the target ledger transaction details table to executed; if the execution fails, then keeping the execution status of the target document in the target ledger transaction details table as not executed.

[0118] Specifically, the execution status indicates whether the balance processing for each document recorded in the target ledger transaction details table has been completed. Executing the balance processing of a target document refers to performing actual fund operations on the target document, such as deductions or repayments. These operations ensure that the document's amount is deducted or added from the available balance, thereby updating the ledger balance table. To prevent deduction operations from failing to be recorded due to network issues or other reasons, a "Successful Execution?" field has been added to the transaction log table. If a deduction fails, this field remains in the "Not Executed" state so that it can be retried in subsequent operations until it is successfully deducted, at which point it is updated to "Executed".

[0119] By introducing the execution status of the document and the "execution success" field, this application can ensure the accuracy and completeness of fund operations.

[0120] In an optional implementation, the method further includes: identifying and deleting ledger data records in the target ledger balance sheet and target ledger transaction details sheet prior to a preset time, obtaining the deleted target ledger balance sheet and target ledger transaction details sheet, wherein the preset time is set in the target ledger configuration table, and saving the deleted ledger data records in the target ledger balance sheet and target ledger transaction details sheet in a backup table.

[0121] Specifically, ledger data records prior to a preset time represent all ledger data records preceding a time threshold set in the target ledger configuration table. These records typically represent completed transactions; for example, if the preset time is 90 days, then all ledger data records older than 90 days will be considered "ledger data records prior to the preset time." Saving deleted ledger data records in a backup table ensures that this data can still be accessed and recovered even after historical data is cleaned up. This preserves historical data for auditing or recovery when needed. Secondly, cleaning up old data reduces the size of the ledger table, improving system query and operational performance. To prevent excessive ledger table data from impacting system performance, the system periodically cleans up historical data. Specifically, the system periodically cleans up ledger records exceeding a time threshold (e.g., 90 days) set in the ledger configuration table. The cleanup task dynamically generates corresponding backup tables. For example, the backup table for the ledger balance table T_BD_LedgerBalance is T_BD_LedgerBalance_2025_bak, and the backup table for the ledger transaction record table is T_BD_LedgerDetail_2025_bak. If the dynamically created table name already exists, the month will be added after the year, such as T_BD_LedgerBalance_202506_bak.

[0122] This ensures the preservation of historical data while optimizing system performance through regular cleanup.

[0123] It is worth mentioning that this application may also involve the following technical implementations:

[0124] 1. Database Pessimistic Locking: Database pessimistic locking is a common concurrency control mechanism used to ensure that multiple threads do not interfere with each other when operating on the same resource (such as a balance). In balance deduction scenarios, pessimistic locking prevents multiple threads from operating on the same balance simultaneously, thus avoiding data corruption. Therefore, in a multi-threaded environment (application scenario), when multiple threads may deduct the same balance at the same time, pessimistic locking ensures that only one thread can operate on the balance at a time, guaranteeing data consistency.

[0125] 2. Batch Execution Over-Amount Prevention Design: A large number of documents are placed in a temporary table, and the calculation process is completed all at once. During the calculation, row locks are applied to the documents in the temporary table to ensure that each document is not interfered with by other threads during calculation. A WHERE filter condition is added to the SQL query to perform balance increment / decrement operations only on documents that meet the condition. To avoid anomalies during the approval process (such as increments not being deducted), an "Executed?" field is added to the transaction log table. If the execution of a document fails, this field is marked as "Not Executed," facilitating the recalculation of all unexecuted transactions on subsequent runs. This prevents concurrent over-payments during batch operation posting.

[0126] 3. Field Uniqueness Constraints: If all business processes reside in the same database, the problem can be solved by designing unique field constraints in the tables. Unique fields in the master ledger table typically include document number, document identifier, and organization (the organization field may not require configuration). Through the combination of these fields, each document is ensured to be unique in the master ledger table, thus avoiding duplicate records. Specifically, in a distributed system (distributed system environment), it is necessary to ensure the global uniqueness of document number, document identifier, and organization. Although the specific implementation varies from system to system, there are relevant industry solutions, such as using distributed ID generators to ensure uniqueness, which will not be elaborated upon here.

[0127] It is worth mentioning that by using pessimistic locking, batch execution to prevent overpayment, and field uniqueness constraints, the system can effectively handle concurrent operations, prevent overpayment and data duplication, thereby improving the system's reliability and stability.

[0128] For further details, please refer to Figure 4 One embodiment of the data processing apparatus in this application includes:

[0129] The generation unit is used to generate the target ledger initial form table and the target ledger transaction detail table based on the fund flow of the corresponding documents of each business, and to generate the target ledger balance table based on the target ledger transaction detail table. The corresponding document flow of the business represents the flow between at least one initial document, at least one intermediate document and final document corresponding to the business.

[0130] The determining unit is used to determine, based on the target ledger balance table, whether the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document when the target business generates an intermediate document, and to determine, based on the target ledger balance table, whether the amount of the current final document corresponding to the target business is greater than the target amount of the corresponding initial document in the target ledger initial document table when the target business submits the final document, and to obtain a determining result.

[0131] The determining unit is further configured to determine, based on the determining result, whether to intercept the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business.

[0132] In one alternative implementation, the determining unit may be used for:

[0133] Determine the available balance in the target ledger balance sheet and the excess amount corresponding to each configured target document, and determine the target amount corresponding to each target document based on the available balance and excess amount corresponding to each target document.

[0134] In one alternative implementation, the determining unit may be used for:

[0135] If the amount of the current downstream intermediate document corresponding to the target business is less than or equal to the target amount of the corresponding upstream document, and the amount of the current final document corresponding to the target business is less than or equal to the target amount of the initial document corresponding to the target ledger initial document table, then it is determined not to intercept the generation of the current downstream intermediate document and the current final document corresponding to the target business; if the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document, and the amount of the current final document corresponding to the target business is greater than the target amount of the initial document corresponding to the target ledger initial document table, then based on the preset interception control rules, it is determined whether to intercept the generation of the current downstream intermediate document and the current final document corresponding to the target business, where the preset interception control rules are configured in the target ledger configuration table.

[0136] In one alternative implementation, the determining unit may be used for:

[0137] If the preset interception control rule is a strong interception control rule, then the generation of the current downstream intermediate document and the current final document corresponding to the target business will be intercepted, and the interception will be executed; if the preset interception control rule is a weak interception control rule, then after obtaining the user interception trigger signal, the generation of the current downstream intermediate document and the current final document corresponding to the target business will be intercepted, and the interception will be executed.

[0138] In one optional implementation, the data processing apparatus further includes an execution unit:

[0139] The generation unit can be used for:

[0140] Obtain updated information from the target ledger configuration table and generate a target plugin based on the updated information, wherein the updated information includes newly added and / or updated target interception control logic;

[0141] Execution units can be used for:

[0142] The target plugin is dynamically loaded and executed at runtime to intercept the generation of current downstream intermediate documents and current final documents corresponding to other businesses based on the target interception control logic.

[0143] In one alternative implementation, the generating unit may be used for:

[0144] Generate the current downstream intermediate document corresponding to the target business and the interception log corresponding to the current final document corresponding to the target business;

[0145] The execution unit can be used to: if the number of logs intercepted by the first tenant within the most recent preset time period is less than or equal to a preset maximum threshold, then based on the target interception control logic, intercept the generation of the current downstream intermediate documents and the current final documents corresponding to other businesses of the first tenant; if the number of logs intercepted by the second tenant within the most recent preset time period is less than a preset minimum threshold, then based on the target interception control logic, intercept the generation of the current downstream intermediate documents and the current final documents corresponding to other businesses of the second tenant.

[0146] In one alternative implementation, the generating unit may be used for:

[0147] The transaction amount and value corresponding to each business in the target ledger transaction details table are determined. The difference between the available balance corresponding to each business in the initial ledger balance table and the transaction amount and value corresponding to each business is taken as the available balance corresponding to each business. The target ledger balance table is obtained based on the available balance corresponding to each business.

[0148] In one alternative implementation, the generating unit may be used for:

[0149] The execution status of the balance processing for each document in the target ledger transaction details table is determined. If the execution status of the target document is not executed, the balance processing of the target document is executed to generate the target ledger balance table. If the execution is successful, the execution status of the target document in the target ledger transaction details table is updated to executed. If the execution fails, the execution status of the target document in the target ledger transaction details table is kept as not executed. Each document in the target ledger transaction details table includes a corresponding execution status.

[0150] In one alternative implementation, the data processing apparatus further includes a storage unit;

[0151] The determining unit can be used to: determine and delete the ledger data records in the target ledger balance table and the target ledger transaction details table before a preset time, so as to obtain the deleted target ledger balance table and target ledger transaction details table, wherein the preset time is set in the target ledger configuration table;

[0152] The storage unit can be used to save the ledger data records of the deleted target ledger balance sheet and target ledger transaction details sheet in the backup table.

[0153] For further details, please refer to Figure 5 One embodiment of the electronic device in this application includes:

[0154] Central processing unit 501, memory 505, input / output interface 504, wired or wireless network interface 503, and power supply 502;

[0155] Memory 505 is either a short-term storage memory or a persistent storage memory;

[0156] The central processing unit 501 is configured to communicate with the memory 505 and execute instructions stored in the memory 505 to perform the aforementioned operations. Figure 2-1 The method in the illustrated embodiment.

[0157] Furthermore, embodiments of this application also provide a computer-readable storage medium, which includes instructions that, when executed on a computer, cause the computer to perform the aforementioned... Figure 2-1 The method in the illustrated embodiment.

[0158] Furthermore, embodiments of this application also provide a computer program product containing instructions, which, when run on a computer, causes the computer to perform the aforementioned... Figure 2-1 The method in the illustrated embodiment.

[0159] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0160] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0161] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, 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 an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0162] 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.

[0163] 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 as a software functional unit.

[0164] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 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.

Claims

1. A data processing method, characterized in that, include: Based on at least one initial document, at least one intermediate document, and a final document corresponding to each business, generate the target ledger initial document table and the target ledger transaction detail table, and generate the target ledger balance table based on the target ledger transaction detail table. When the target business generates an intermediate document, the amount of the current downstream intermediate document corresponding to the target business is determined based on the target ledger balance table to determine whether it is greater than the target amount of the corresponding upstream document. When the target business submits the final document, the amount of the current final document corresponding to the target business is determined based on the target ledger balance table to determine whether it is greater than the target amount of the corresponding initial document in the target ledger initial document table, and the determination result is obtained. Based on the determination result, determine whether to intercept the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business.

2. The method according to claim 1, characterized in that, The step of determining whether to intercept the generation of the current downstream intermediate document and the current final document based on the determination result includes: If the amount of the current downstream intermediate document corresponding to the target business is less than or equal to the target amount of the corresponding upstream document, and the amount of the current final document corresponding to the target business is less than or equal to the target amount of the initial document corresponding to the target ledger initial document, then it is determined that the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business will not be blocked. If the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document, and the amount of the current final document corresponding to the target business is greater than the target amount of the initial document corresponding to the target ledger initial document table, then based on the preset interception control rules, it is determined whether to intercept the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business. The preset interception control rules are configured in the target ledger configuration table.

3. The method according to claim 2, characterized in that, The step of determining whether to intercept the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business based on preset interception control rules includes: If the preset interception control rule is a strong interception control rule, then the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business will be intercepted, and the interception will be executed. If the preset interception control rule is a weak interception control rule, then after obtaining the user interception trigger signal, it is determined to intercept the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business, and the interception is executed.

4. The method according to claim 1, characterized in that, The method further includes: Obtain updated information from the target ledger configuration table and generate a target plugin based on the updated information, wherein the updated information includes newly added and / or updated target interception control logic; The target plugin is dynamically loaded and executed at runtime to intercept the generation of current downstream intermediate documents and current final documents corresponding to other businesses based on the target interception control logic.

5. The method according to claim 4, characterized in that, After determining the generation of the current downstream intermediate document corresponding to the intercepted target service and the current final document corresponding to the target service, the method further includes: Generate the current downstream intermediate document corresponding to the target business and the interception log corresponding to the current final document corresponding to the target business; The interception of the generation of current downstream intermediate documents and current final documents corresponding to other services based on the target interception control logic includes at least one of the following situations: If the number of logs intercepted by the first tenant within the most recent preset time period is less than or equal to the preset maximum threshold, then the generation of the current downstream intermediate documents and the current final documents corresponding to other businesses of the first tenant will be intercepted based on the target interception control logic. If the number of logs intercepted by the second tenant within the most recent preset time period is less than the preset minimum threshold, then the generation of the current downstream intermediate documents and the current final documents corresponding to other services of the second tenant will be intercepted based on the target interception control logic.

6. The method according to claim 1, characterized in that, Each document in the target ledger transaction details table includes a corresponding execution status. Generating the target ledger balance table based on the target ledger transaction details table includes: Determine the execution status of the balance processing for each document in the target ledger transaction details table; If the execution status of the target document is not executed, then the balance processing of the target document is performed to generate the target ledger balance table. If the execution is successful, the execution status of the target document in the target ledger transaction details table is updated to executed. If the execution fails, the execution status of the target document in the target ledger transaction details table remains not executed.

7. The method according to claim 1, characterized in that, The method further includes: Identify and delete the ledger data records in the target ledger balance table and target ledger transaction details table before a preset time, to obtain the deleted target ledger balance table and target ledger transaction details table. The preset time is set in the target ledger configuration table. Save the deleted target ledger balance sheet and target ledger transaction details in a backup table.

8. A data processing apparatus, characterized in that, include: The generation unit is used to generate the target ledger initial form table and the target ledger transaction detail table based on the fund flow of the corresponding documents of each business, and to generate the target ledger balance table based on the target ledger transaction detail table. The corresponding document flow of the business represents the flow between at least one initial document, at least one intermediate document and final document corresponding to the business. The determining unit is used to determine, based on the target ledger balance table, whether the amount of the current downstream intermediate document corresponding to the target business is greater than the target amount of the corresponding upstream document when the target business generates an intermediate document, and to determine, based on the target ledger balance table, whether the amount of the current final document corresponding to the target business is greater than the target amount of the corresponding initial document in the target ledger initial document table when the target business submits the final document, and to obtain a determining result. The determining unit is further configured to determine, based on the determining result, whether to intercept the generation of the current downstream intermediate document corresponding to the target business and the current final document corresponding to the target business.

9. A data processing device, characterized in that, include: Central processing unit and memory; The memory is either a short-term storage memory or a persistent storage memory; The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

11. A computer program product containing instructions, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 7.

Images