Bill batch processing method, device and equipment and storage medium

Abstract

This application discloses a method, apparatus, device, and storage medium for batch bill processing, belonging to the field of financial technology. This application obtains bills to be processed, which include multiple sets of bills, each set containing multiple individual bills; it sequentially performs bill verification processing on the individual bills within each set, obtaining a first processing result after processing each bill. If the first processing result is abnormal, the abnormal bill is re-verified; when a preset first condition is met, the next bill is re-verified, repeating the step of re-verifying the abnormal bill if the first processing result is abnormal, until the bill verification processing of the multiple bills in each set is completed, thereby quickly completing batch bill processing.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a method, apparatus, device and storage medium for batch bill processing. Background Technology

[0002] Currently, during the batch reconciliation of statements, the large amount of data involved and the numerous reconciliation items often lead to processing failures.

[0003] When this happens, the current reconciliation process is usually terminated and then manually resumed. However, manual processing is less efficient, which reduces the efficiency of batch bill processing.

[0004] Therefore, there is a technical problem of low efficiency in batch bill processing in related technologies. Summary of the Invention

[0005] The main objective of this application is to provide a bill batch processing method, apparatus, device, and storage medium, which aims to solve the technical problem of low efficiency in bill batch processing.

[0006] To achieve the above objectives, this application provides a batch billing method, which includes the following steps:

[0007] Obtain pending invoices, which include multiple sets of invoices, and each set of invoices includes multiple invoices;

[0008] Multiple bills in each group of bills are checked sequentially. After each bill is processed, a first processing result is obtained. If there is an anomaly in the first processing result, the bill with the anomaly is checked again.

[0009] When the preset first condition is met, the bill verification process continues for the next bill. The steps of re-verifying the abnormal bill if the first processing result is abnormal are repeated until the bill verification process for multiple bills in each group of bills is completed.

[0010] Optionally, the first processing result includes the second processing result, and the step of re-verifying the abnormal bill if the first processing result is abnormal includes:

[0011] Determine the anomaly type of the first processing result;

[0012] If the anomaly type is not a data anomaly, the anomaly bill is re-verified. If the second processing result obtained after re-processing is an anomaly, the step of determining the anomaly type of the first processing result is repeated. If the anomaly type is not a data anomaly, the anomaly bill is re-verified.

[0013] Optionally, the preset first condition includes a threshold for the number of repeated processing times, and the step of continuing to process the bill reconciliation for the next bill when the preset first condition is met includes:

[0014] If the abnormal bill is re-verified and the second processing result corresponding to the abnormal bill is still abnormal, then it is determined whether the number of re-processing times is greater than the repeated processing number threshold, and the repeated processing number threshold is related to the abnormality type.

[0015] If the value is greater than the specified value, skip the abnormal bill and continue with the bill reconciliation process for the next bill.

[0016] Optionally, the step of determining the anomaly type of the first processing result includes:

[0017] Based on a preset verification model, the first processing result is type-verified to obtain a verification result. If the verification result is a data error, the anomaly type of the first processing result is determined to be a data anomaly. The preset verification model is obtained by iteratively training a preset training model based on the processing result sample and preset bill labels.

[0018] Optionally, before the step of performing type verification on the first processing result based on a preset verification model to obtain the verification result, the method further includes:

[0019] Obtain a sample of processing results and its result labels, wherein the sample of processing results is obtained by performing bill verification on historical bills, and the bill labels include the probability of each type of anomaly.

[0020] The processed result sample is input into a preset training model to obtain the verification result;

[0021] The difference between the verification result and the bill label is calculated to obtain the error result;

[0022] Determine whether the error result meets the error standard indicated by the preset error threshold range;

[0023] If the error result does not meet the error standard indicated by the preset error threshold range, the process returns to the step of inputting the processing result sample into the preset training model to obtain the verification result. Training stops when the error result meets the error standard indicated by the preset error threshold range, and a verification model that meets the accuracy conditions is obtained.

[0024] Optionally, before the step of obtaining the bill to be processed, the method further includes:

[0025] Acquire account data from multiple customer groups, each group including multiple customers to be pushed to;

[0026] Based on the account data of each customer group and the preset bill template, multiple sets of bills are generated to obtain bills to be processed.

[0027] In the process of generating multiple sets of bills based on the account data of each group of customers, a third processing result is obtained for each bill corresponding to a customer to be pushed to.

[0028] If the third processing result is abnormal, the process returns to the step of obtaining account data of multiple groups of customers, each group of customers including multiple customers to be pushed. When the preset second condition is met, the process continues to generate bills based on the account data of the next customer, repeating the step of re-verifying the bills of abnormal customers if the third processing result is abnormal, until the bills for all customers to be pushed in each group of customers are generated.

[0029] Optionally, after completing the step of generating bills for all customers to be pushed to in each group of customers, the method further includes:

[0030] Based on the third processing results corresponding to each group of customers, the first success rate of the bill generation process is determined. If the first success rate is greater than the first proportion threshold, the step of obtaining the bill to be processed is executed.

[0031] After completing the bill reconciliation process for multiple bills in each group of bills, the method further includes:

[0032] Based on the first processing result corresponding to multiple bills in each group of bills, a second success rate of the bill verification process is determined. If the second success rate is greater than a second proportion threshold, bill push processing is performed on the multiple bills in each group of bills that have completed the bill verification process.

[0033] Furthermore, to achieve the above objectives, this application also provides a bill batch processing apparatus, the bill batch processing apparatus comprising:

[0034] The bill retrieval module is used to retrieve bills to be processed, which include multiple sets of bills, and each set of bills includes multiple individual bills.

[0035] The anomaly detection module is used to perform bill verification processing on multiple bills in each group of bills in sequence. After each bill is processed, a first processing result is obtained. If there is an anomaly in the first processing result, the bill with the anomaly is re-verified.

[0036] The bill reconciliation module is used to continue the bill reconciliation process for the next bill when a preset first condition is met. It repeats the step of reconciling the abnormal bill if the first processing result is abnormal, until the bill reconciliation process for multiple bills in each group of bills is completed.

[0037] In addition, to achieve the above objectives, this application also provides an apparatus comprising: a memory, a processor, and a billing batch processing program stored in the memory and executable on the processor, the billing batch processing program being configured to implement the steps of the billing batch processing method as described above.

[0038] In addition, to achieve the above objectives, this application also provides a computer-readable storage medium storing a bill batch processing program, which, when executed by a processor, implements the steps of the bill batch processing method described above.

[0039] This application obtains pending invoices, which include multiple sets of invoices, each set containing multiple individual invoices. It then sequentially verifies the individual invoices within each set, obtaining a first processing result after processing each invoice. If the first processing result is abnormal, the abnormal invoice is re-verified. When a preset first condition is met, the verification process continues for the next invoice, repeating the steps of re-verifying the abnormal invoice if the first processing result is abnormal, until all individual invoices in each set are verified. This approach avoids directly ending the reconciliation process when processing failures occur; instead, it re-verifies abnormal invoices and continues with the next invoice when the preset first condition is met, thus quickly completing batch invoice processing. Attached Figure Description

[0040] Figure 1 This is a first flowchart illustrating the first embodiment of the bill batch processing method of this application;

[0041] Figure 2 This is a schematic diagram of a first scenario of the first embodiment of the bill batch processing method of this application;

[0042] Figure 3 This is a schematic diagram of a second scenario of the first embodiment of the bill batch processing method of this application;

[0043] Figure 4 This is a schematic diagram of a third scenario in the first embodiment of the bill batch processing method of this application;

[0044] Figure 5 This is a second flowchart illustrating the second embodiment of the bill batch processing method of this application;

[0045] Figure 6 This is a structural block diagram of an embodiment of the bill batch processing device of this application;

[0046] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application.

[0047] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0048] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0049] Reference Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the bill batch processing method of this application.

[0050] In the first embodiment, the bill batch processing method includes the following steps:

[0051] S10: Obtain pending bills, which include multiple sets of bills, and each set of bills includes multiple bills;

[0052] It should be noted that the execution subject of the bill batch processing method in this embodiment is the bill batch processing device, which is subordinate to the bill batch processing equipment.

[0053] Generally, when banks issue monthly analysis reports to customers, they perform batch processing of bills (batch billing), such as... Figure 2 As shown, the batch billing process mainly includes three parts: bill generation, bill verification, and bill delivery. The final bill delivered to the customer must be accurate and may include information such as transaction time, transaction partner, transaction amount, and account balance.

[0054] This embodiment aims to treat the above three parts as a single process, such as Figure 3 As shown, after the bill is generated, the status transitions to bill verification processing. After the bill verification processing is completed, the status transitions to bill push. Admission criteria and termination rules are set for each part to improve the robustness of the overall bill batch processing workflow and increase the success rate of bill batch processing.

[0055] Therefore, before the step of obtaining the bills to be processed, the bill generation process can be to obtain account data of multiple groups of customers, each group of customers including multiple customers to be pushed, and generate multiple bills based on the account data of each group of customers and a preset bill template to obtain the bills to be processed. In the process of generating multiple bills based on the account data of each group of customers, a third processing result is obtained for each bill corresponding to a customer to be pushed. If the third processing result is abnormal, the step of obtaining account data of multiple groups of customers, each group of customers including multiple customers to be pushed, is returned. When the preset second condition is met, the bill is generated based on the account data of the next customer. The step of re-verifying the bills for abnormal customers if the third processing result is abnormal is repeated until the bills for all customers to be pushed in each group of customers are generated.

[0056] Specifically, it can be to identify customers who meet the bill query criteria (if a customer has cancelled their account, there is no need to push the bill again). To improve processing efficiency, customers who meet the bill query criteria are first divided into multiple groups. For example, 10 million customers are divided into 5 groups of 2 million customers each. The account data of the 2 million customers in each group are obtained and processed simultaneously (i.e., multi-threaded calculation), instead of directly obtaining and processing the account data of 10 million customers through a single thread.

[0057] The account data may be obtained from a database, and may include the customer's historical transaction records or historical loan records, etc.

[0058] To facilitate subsequent processing and improve processing efficiency, this embodiment can generate multiple sets of bills based on the account data of each group of customers and a preset bill template, resulting in bills to be processed. Specifically, the preset bill template includes the aforementioned transaction time, transaction object, transaction amount, account balance, etc. Since there is a lot of account data involved in the customer, but some data is useless (data that has no impact on the bill), when generating multiple sets of bills, the account data of each group of customers can be filtered based on the preset bill template, retaining the account data related to the preset bill template, thereby reducing the amount of data to be processed and improving processing efficiency.

[0059] Meanwhile, to ensure stability, multiple threads retrieve account data for 2 million customers within the corresponding group. Based on the account data of each group of customers and the preset bill template, multiple sets of bills are generated to obtain bills to be processed. That is, each of the 5 sets of bills includes 2 million bills for 2 million customers. Each time a bill corresponding to a customer to be pushed is generated, a third processing result is obtained.

[0060] like Figure 4As shown, in thread one, the account data of the first customer is obtained, the bill of the first customer is generated, and a third processing result is obtained. If the third processing result is normal, the account data of the second customer is obtained, the bill of the second customer is generated, and a third processing result is obtained. If the third processing result is abnormal, the account data of the second customer is obtained again, the bill of the second customer is generated, and the first and third processing results are obtained.

[0061] When the preset second condition is met, continue to generate bills based on the account data of the next customer, and repeat the steps of re-verifying the bills for abnormal customers if the third processing result is abnormal, until the bills for all customers to be pushed in each group of customers are generated.

[0062] In the above process, after each thread completes the bill generation process for a customer, it obtains 2 million third processing results. If the first success rate of the bill generation process is low, the current exception is considered to be a general exception. If the next process, bill verification processing, is continued at this time, the failure rate of bill verification processing will likely increase due to the problems that have already occurred in the bill generation process.

[0063] Therefore, in order to stop the loss in time, it is necessary to determine the first success rate of the bill generation process based on the third processing result corresponding to each group of customers. If the first success rate is greater than the first proportion threshold, then the step of obtaining the bill to be processed is executed.

[0064] like Figure 4 As shown, when the initial success rate of the bill generation process is low (less than 90% or 95%), all threads return to the starting point and re-execute the bill generation process. If the initial success rate is greater than 90% or 95%, the bill verification process can proceed.

[0065] Similarly, during the bill reconciliation process, multiple threads are needed to process each group of bills simultaneously. Therefore, the bills to be processed include multiple groups of bills, each group of bills includes multiple bills, and the customers corresponding to these multiple groups of bills correspond to the aforementioned multiple groups of customers.

[0066] S20: Perform bill verification processing on multiple bills in each group of bills in sequence. After each bill is processed, a first processing result is obtained. If there is an anomaly in the first processing result, the bill with the anomaly is re-verified.

[0067] It should be noted that the bill reconciliation process is not only to verify whether the contents of the final bill are the same as the corresponding customer account data obtained above, but also to verify whether there are obvious data logic errors or calculation errors that do not conform to the relevant financial fields during the calculation process.

[0068] Bill reconciliation process: During the process of reconciling multiple bills in each group of bills, a first processing result is obtained after each bill is processed. If there is an anomaly in the first processing result, the bill with the anomaly is re-reconciled without returning to the bill generation process, which reduces data processing time and improves bill processing efficiency.

[0069] S30: When the preset first condition is met, continue to process the bill reconciliation for the next bill, repeating the step of reconciling the abnormal bill if the first processing result is abnormal, until the bill reconciliation of multiple bills in each group of bills is completed.

[0070] When the preset first condition is met, if the first processing result is still abnormal, there is no need to continue to re-verify the abnormal bill. Instead, the current abnormal bill is skipped and a prompt is issued (for staff to handle manually), and the bill verification process continues for the next bill, reducing manual intervention and improving overall processing efficiency.

[0071] Similarly, in the above process, after each thread completes the bill verification process for a bill, it obtains 2 million first processing results. If the second success rate of the bill verification process is low, it is considered that the current exception is a general exception. If the next process, bill push, is continued at this time, the failure rate of bill push will likely increase due to the problems that have already occurred in the bill verification process.

[0072] Therefore, in order to stop losses in time, after completing the bill reconciliation process for multiple bills in each group of bills, it is also necessary to determine the second success rate of the bill reconciliation process based on the first processing result corresponding to the multiple bills in each group of bills. If the second success rate is greater than the second proportion threshold, then bill push processing is performed on the multiple bills in each group of bills that have completed the bill reconciliation process.

[0073] like Figure 4 As shown, when the second success rate of the bill reconciliation process is low (less than 90% or 95%), all threads return to the starting point and re-execute the bill reconciliation process. If the second success rate is greater than 90% or 95%, the bill push process can proceed.

[0074] During the bill push process, multiple bills from each group of customers are pushed sequentially (invoices that are abnormal during the bill reconciliation process will be manually corrected and pushed separately). After each bill is pushed, a fourth processing result is obtained. If the fourth processing result is abnormal, the abnormal bill is pushed again (bill push process), without having to return to the bill reconciliation process, thus reducing data processing time and improving bill processing efficiency.

[0075] To ensure that each bill is pushed to the corresponding user, a third success rate of the bill push process needs to be verified after multiple threads have completed the bill push. Figure 4 As shown, when the success rate of the third step in the bill push process is low (less than 90% or 95%), all threads return to the starting point and re-execute the bill push process. If the success rate of the third step is greater than 90% or 95%, then the three parts of the bill batch processing are completed.

[0076] This embodiment starts from the three parts (three processes) of the overall bill batch processing and the single step and single point (each bill processed). When there is an anomaly, it re-executes and skips the strategy, and performs state transitions when some processes meet certain conditions. It can automatically resolve most abnormal situations without manual intervention, reduce operational risks, and improve stability.

[0077] like Figure 5 As shown, based on the first embodiment, a second embodiment of the bill batch processing of this application is proposed. In this embodiment, the first processing result includes the second processing result. The step of re-verifying the bills if the first processing result is abnormal includes:

[0078] A1: Determine the type of exception in the first processing result;

[0079] It is understandable that if there is a problem with the acquired account data, when an anomaly occurs (including anomalies that occur during bill generation and bill reconciliation), even if the current part of the process is re-executed, the anomaly cannot be resolved. Therefore, when an anomaly occurs, the anomaly type of the processing result should be determined first. For example, if the first processing result is anomaly, the anomaly type of the first processing result should be determined.

[0080] Specifically, the exception types include data types (data source record errors) and non-data types, where non-data types include network failures and server failures, etc.

[0081] If the exception type of the first processing result is a data type, a prompt or alarm will be issued directly, the bill with the exception will be skipped, and the bill with the exception will be stored in the database for special processing by subsequent programs or manual intervention.

[0082] Similarly, in order to improve processing efficiency, when the third and fourth processing results are obtained, if the third or fourth processing result is determined to be abnormal, the abnormality type of the third or fourth processing result can also be determined first. That is, when abnormal processing results occur during bill generation and bill push, the abnormality type of the processing result can also be determined first, thereby reducing the processing time of each process in the bill batch processing and improving the overall processing efficiency.

[0083] Specifically, the specific implementation of determining the anomaly type of the first processing result may be:

[0084] Based on a preset verification model, the first processing result is subjected to type verification to obtain a verification result. If the verification result is a data error, the exception type of the first processing result is determined to be a data exception.

[0085] Specifically, if the first processing result is abnormal, the abnormality type of the first processing result is determined based on the content of the feedback first processing result. Specifically, since the feedback content of processing results for different abnormality types is different, it can be quickly identified based on a preset verification model. For example, the feedback first processing result may be a string of characters or a pop-up window.

[0086] It should be noted that the preset verification model is obtained by iteratively training the preset training model based on the processing result samples and preset bill labels.

[0087] The specific training process is as follows: obtain processing result samples and their result labels, wherein the bill labels include the probability of each anomaly type; input the processing result samples into a preset training model to obtain a verification result; calculate the difference between the verification result and the bill labels to obtain an error result; determine whether the error result meets the error standard indicated by the preset error threshold range; if the error result does not meet the error standard indicated by the preset error threshold range, return to the step of inputting the processing result samples into the preset training model to obtain a verification result; stop training until the error result meets the error standard indicated by the preset error threshold range, and obtain a verification model that meets the accuracy conditions.

[0088] It should be noted that the aforementioned pre-set training model can be a neural network model capable of semantic analysis by recognizing text or symbols in strings or images. The processing result samples can be obtained through bill verification of historical bills. That is, it can be understood that various anomalies may occur during the bill verification process, resulting in diverse historical results and a wide variety of anomaly types in the historical result samples, which can cover the anomaly types that may occur during the current bill batch processing.

[0089] Therefore, the verification model obtained through the above training process can quickly perform type verification on the first processing result and obtain the verification result. The verification result includes the probability of each anomaly type. Specifically, the anomaly types include data anomalies, network anomalies, and service anomalies. The anomaly type with the highest probability is taken as the verification result, and the anomaly type of the first processing result can be determined.

[0090] A2: If the anomaly type is not a data anomaly, then the anomaly bill is re-verified. If the second processing result obtained after re-processing is an anomaly, then the step of determining the anomaly type of the first processing result is repeated. If the anomaly type is not a data anomaly, then the anomaly bill is re-verified.

[0091] In this embodiment, if the anomaly type is not a data anomaly, that is, if the anomaly type is a network anomaly or a service anomaly, the current process can be re-executed to try to resolve these unexpected problems, improve the efficiency of data processing, and minimize human intervention. However, if the second processing result obtained after multiple reprocessing is still an anomaly, the current anomaly bill can be skipped and the next bill can be processed.

[0092] In this embodiment, the first processing result is quickly validated by a validation model to obtain the validation result, thereby determining the anomaly type of the first processing result. This enables a quick determination of whether the current processing flow should be re-executed when an anomaly occurs, thus improving the overall efficiency of bill batch processing.

[0093] Furthermore, embodiments of this application also propose a bill batch processing apparatus, referring to... Figure 6 The bill batch processing device includes:

[0094] The bill acquisition module 10 is used to acquire bills to be processed, which include multiple sets of bills, and each set of bills includes multiple bills.

[0095] The anomaly detection module 20 is used to perform bill verification processing on multiple bills in each group of bills in sequence. After each bill is processed, a first processing result is obtained. If there is an anomaly in the first processing result, the bill with the anomaly is re-verified.

[0096] The bill verification module 30 is used to continue the bill verification process for the next bill when a preset first condition is met, repeating the step of re-verifying the abnormal bill if the first processing result is abnormal, until the bill verification process for multiple bills in each group of bills is completed.

[0097] This embodiment acquires bills to be processed, which include multiple sets of bills, each set containing multiple individual bills. The individual bills in each set are sequentially reconciled. After processing each bill, a first processing result is obtained. If the first processing result is abnormal, the abnormal bill is reconciled. When a preset first condition is met, the next bill is reconciled, and the process of reconciling abnormal bills with the first processing result is repeated until all individual bills in each set are reconciled. This avoids directly ending the reconciliation process when processing failures occur; instead, abnormal bills are reconciled, and the process continues until the preset first condition is met, thus quickly completing batch bill processing.

[0098] It should be noted that each module in the above-mentioned device can be used to implement each step in the above-mentioned method and achieve the corresponding technical effect. This embodiment will not elaborate further here.

[0099] Reference Figure 7 , Figure 7 This is a schematic diagram of the hardware operating environment of the device involved in the embodiments of this application.

[0100] like Figure 7As shown, the device may include: a processor 1001, such as a CPU; a communication bus 1002; a user interface 1003; a network interface 1004; and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0101] Those skilled in the art will understand that Figure 7 The structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0102] like Figure 7 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a billing batch processing program.

[0103] exist Figure 7 In the device shown, network interface 1004 is mainly used for data communication with external networks; user interface 1003 is mainly used for receiving user input commands; the device calls the bill batch processing program stored in memory 1005 through processor 1001 and performs the following operations:

[0104] Obtain pending invoices, which include multiple sets of invoices, and each set of invoices includes multiple invoices;

[0105] Multiple bills in each group of bills are checked sequentially. After each bill is processed, a first processing result is obtained. If there is an anomaly in the first processing result, the bill with the anomaly is checked again.

[0106] When the preset first condition is met, the bill verification process continues for the next bill. The steps of re-verifying the abnormal bill if the first processing result is abnormal are repeated until the bill verification process for multiple bills in each group of bills is completed.

[0107] Furthermore, the processor 1001 can call the bill batch processing program stored in the memory 1005 and also perform the following operations:

[0108] Determine the anomaly type of the first processing result;

[0109] If the anomaly type is not a data anomaly, the anomaly bill is re-verified. If the second processing result obtained after re-processing is an anomaly, the step of determining the anomaly type of the first processing result is repeated. If the anomaly type is not a data anomaly, the anomaly bill is re-verified.

[0110] Furthermore, the processor 1001 can call the bill batch processing program stored in the memory 1005 and also perform the following operations:

[0111] If the abnormal bill is re-verified and the second processing result corresponding to the abnormal bill is still abnormal, then it is determined whether the number of re-processing times is greater than the repeated processing number threshold, and the repeated processing number threshold is related to the abnormality type.

[0112] If the value is greater than the specified value, skip the abnormal bill and continue with the bill reconciliation process for the next bill.

[0113] Furthermore, the processor 1001 can call the bill batch processing program stored in the memory 1005 and also perform the following operations:

[0114] Based on a preset verification model, the first processing result is type-verified to obtain a verification result. If the verification result is a data error, the anomaly type of the first processing result is determined to be a data anomaly. The preset verification model is obtained by iteratively training a preset training model based on the processing result sample and preset bill labels.

[0115] Furthermore, the processor 1001 can call the bill batch processing program stored in the memory 1005 and also perform the following operations:

[0116] Obtain a sample of processing results and its result labels, wherein the sample of processing results is obtained by performing bill verification on historical bills, and the bill labels include the probability of each type of anomaly.

[0117] The processed result sample is input into a preset training model to obtain the verification result;

[0118] The difference between the verification result and the bill label is calculated to obtain the error result;

[0119] Determine whether the error result meets the error standard indicated by the preset error threshold range;

[0120] If the error result does not meet the error standard indicated by the preset error threshold range, the process returns to the step of inputting the processing result sample into the preset training model to obtain the verification result. Training stops when the error result meets the error standard indicated by the preset error threshold range, and a verification model that meets the accuracy conditions is obtained.

[0121] Furthermore, the processor 1001 can call the bill batch processing program stored in the memory 1005 and also perform the following operations:

[0122] Acquire account data from multiple customer groups, each group including multiple customers to be pushed to;

[0123] Based on the account data of each customer group and the preset bill template, multiple sets of bills are generated to obtain bills to be processed.

[0124] In the process of generating multiple sets of bills based on the account data of each group of customers, a third processing result is obtained for each bill corresponding to a customer to be pushed to.

[0125] If the third processing result is abnormal, the process returns to the step of obtaining account data of multiple groups of customers, each group of customers including multiple customers to be pushed. When the preset second condition is met, the process continues to generate bills based on the account data of the next customer, repeating the step of re-verifying the bills of abnormal customers if the third processing result is abnormal, until the bills for all customers to be pushed in each group of customers are generated.

[0126] Furthermore, the processor 1001 can call the bill batch processing program stored in the memory 1005 and also perform the following operations:

[0127] Based on the third processing results corresponding to each group of customers, the first success rate of the bill generation process is determined. If the first success rate is greater than the first proportion threshold, the step of obtaining the bill to be processed is executed.

[0128] After completing the bill reconciliation process for multiple bills in each group of bills, the method further includes:

[0129] Based on the first processing result corresponding to multiple bills in each group of bills, a second success rate of the bill verification process is determined. If the second success rate is greater than a second proportion threshold, bill push processing is performed on the multiple bills in each group of bills that have completed the bill verification process.

[0130] This embodiment acquires bills to be processed, which include multiple sets of bills, each set containing multiple individual bills. The individual bills in each set are sequentially reconciled. After processing each bill, a first processing result is obtained. If the first processing result is abnormal, the abnormal bill is reconciled. When a preset first condition is met, the next bill is reconciled, and the process of reconciling abnormal bills with the first processing result is repeated until all individual bills in each set are reconciled. This avoids directly ending the reconciliation process when processing failures occur; instead, abnormal bills are reconciled, and the process continues until the preset first condition is met, thus quickly completing batch bill processing.

[0131] Furthermore, embodiments of this application also propose a computer-readable storage medium storing a bill batch processing program, which, when executed by a processor, performs the following operations:

[0132] Obtain pending invoices, which include multiple sets of invoices, and each set of invoices includes multiple invoices;

[0133] Multiple bills in each group of bills are checked sequentially. After each bill is processed, a first processing result is obtained. If there is an anomaly in the first processing result, the bill with the anomaly is checked again.

[0134] When the preset first condition is met, the bill verification process continues for the next bill. The steps of re-verifying the abnormal bill if the first processing result is abnormal are repeated until the bill verification process for multiple bills in each group of bills is completed.

[0135] This embodiment acquires bills to be processed, which include multiple sets of bills, each set containing multiple individual bills. The individual bills in each set are sequentially reconciled. After processing each bill, a first processing result is obtained. If the first processing result is abnormal, the abnormal bill is reconciled. When a preset first condition is met, the next bill is reconciled, and the process of reconciling abnormal bills with the first processing result is repeated until all individual bills in each set are reconciled. This avoids directly ending the reconciliation process when processing failures occur; instead, abnormal bills are reconciled, and the process continues until the preset first condition is met, thus quickly completing batch bill processing.

[0136] It should be noted that when the above-mentioned computer-readable storage medium is executed by the processor, it can also implement the various steps in the above method and achieve the corresponding technical effects. This embodiment will not be described in detail here.

[0137] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0138] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0139] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, 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 is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0140] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method of billing batch processing, characterized by, The bill batch processing method includes the following steps: Obtain pending invoices, which include multiple sets of invoices, and each set of invoices includes multiple invoices; Multiple bills in each group of bills are checked sequentially. After each bill is processed, a first processing result is obtained. If there is an anomaly in the first processing result, the bill with the anomaly is checked again. When the preset first condition is met, continue to process the bill verification for the next bill, repeat the step of re-processing the bill verification for the abnormal bill if the first processing result is abnormal, until the bill verification for multiple bills in each group of bills is completed. The first processing result includes the second processing result. The step of re-verifying the abnormal bill if the first processing result is abnormal includes: Determine the anomaly type of the first processing result. The anomaly type includes data type and non-data type, wherein non-data type includes network failure and server failure. If the anomaly type is not a data anomaly, the anomaly bill is re-verified. If the second processing result obtained after re-processing is an anomaly, the steps of determining the anomaly type of the first processing result are repeated. If the anomaly type is not a data anomaly, the anomaly bill is re-verified. Prior to the step of obtaining the pending invoice, the method further includes: Acquire account data from multiple customer groups, each group including multiple customers to be pushed to; Based on the account data of each customer group and the preset bill template, multiple sets of bills are generated to obtain bills to be processed. In the process of generating multiple sets of bills based on the account data of each group of customers, a third processing result is obtained for each bill corresponding to a customer to be pushed to. If the third processing result is abnormal, the process returns to the step of obtaining account data of multiple groups of customers, each group of customers including multiple customers to be pushed. When the preset second condition is met, the process continues to generate bills based on the account data of the next customer, repeating the step of obtaining account data of multiple groups of customers if the third processing result is abnormal, until the bills for all customers to be pushed in each group of customers are generated. After completing the step of generating bills for all customers to be pushed to in each customer group, the method further includes: Based on the third processing results corresponding to each group of customers, the first success rate of the bill generation process is determined. If the first success rate is greater than the first proportion threshold, the step of obtaining the bill to be processed is executed. After completing the bill reconciliation process for multiple bills in each group of bills, the method further includes: Based on the first processing result corresponding to multiple bills in each group of bills, a second success rate of the bill verification process is determined. If the second success rate is greater than a second proportion threshold, bill push processing is performed on the multiple bills in each group of bills that have completed the bill verification process.

2. The bill batch processing method as described in claim 1, characterized in that, The preset first condition includes a threshold for the number of repeated processing times. The step of continuing to process the bill reconciliation for the next bill when the preset first condition is met includes: If the abnormal bill is re-verified and the second processing result corresponding to the abnormal bill is still abnormal, then it is determined whether the number of re-processing times is greater than the repeated processing number threshold, and the repeated processing number threshold is related to the abnormality type. If the value is greater than the specified value, skip the abnormal bill and continue with the bill reconciliation process for the next bill.

3. The bill batch processing method as described in claim 1, characterized in that, The step of determining the anomaly type of the first processing result includes: Based on a preset verification model, the first processing result is type-verified to obtain a verification result. If the verification result is a data error, the anomaly type of the first processing result is determined to be a data anomaly. The preset verification model is obtained by iteratively training a preset training model based on the processing result sample and preset bill labels.

4. The bill batch processing method as described in claim 3, characterized in that, Before the step of performing type verification on the first processing result based on a preset verification model to obtain the verification result, the method further includes: Obtain a sample of processing results and its result labels, wherein the sample of processing results is obtained by performing bill verification on historical bills, and the bill labels include the probability of each type of anomaly. The processed result sample is input into a preset training model to obtain the verification result; The difference between the verification result and the bill label is calculated to obtain the error result; Determine whether the error result meets the error standard indicated by the preset error threshold range; If the error result does not meet the error standard indicated by the preset error threshold range, the process returns to the step of inputting the processing result sample into the preset training model to obtain the verification result. Training stops when the error result meets the error standard indicated by the preset error threshold range, and a verification model that meets the accuracy conditions is obtained.

5. A batch bill processing device, characterized in that, The bill batch processing device includes: The bill retrieval module is used to retrieve bills to be processed. These bills include multiple sets of bills, each set containing multiple individual bills. Before retrieving the bills to be processed, the module also retrieves account data from multiple customer groups, each group containing multiple customers to be pushed to. Based on the account data of each customer group and a preset bill template, multiple sets of bills are generated, resulting in bills to be processed. During the generation of multiple sets of bills based on the account data of each customer group, a third processing result is obtained for each bill corresponding to a customer to be pushed to. If the third processing result is abnormal, the module returns to the step of retrieving account data from multiple customer groups, each group containing multiple customers to be pushed to. When a preset second condition is met, the module continues to generate bills based on the account data of the next customer, repeating the process of returning to the step of retrieving account data from multiple customer groups if the third processing result is abnormal, until bills for all customers to be pushed to in each customer group are generated. The anomaly detection module is used to sequentially verify multiple bills in each group of bills. After each bill is processed, a first processing result is obtained. If the first processing result is abnormal, the abnormal bill is re-verified. The first processing result includes a second processing result. The anomaly detection module is also used to determine the anomaly type of the first processing result. The anomaly type includes data type and non-data type, where non-data type includes network failure and server failure. If the anomaly type is not data anomaly, the abnormal bill is re-verified. If the second processing result obtained after re-processing is abnormal, the step of determining the anomaly type of the first processing result and re-verifying the abnormal bill if the anomaly type is not data anomaly is repeated. The bill verification module is used to continue the bill verification process for the next bill when a preset first condition is met, repeating the step of re-verifying the abnormal bill if the first processing result is abnormal, until the bill verification process for multiple bills in each group of bills is completed. After the step of generating bills for all customers to be pushed to in each group of customers is completed, the bill verification module is also used to determine the first success rate of the bill generation process based on the third processing result corresponding to each group of customers. If the first success rate is greater than the first proportion threshold, the step of obtaining the bill to be processed is executed. After the step of completing the bill verification process for multiple bills in each group of bills, the module further includes: determining the second success rate of the bill verification process based on the first processing result corresponding to multiple bills in each group of bills. If the second success rate is greater than the second proportion threshold, the multiple bills in each group of bills that have completed the bill verification process are pushed to the bills respectively.

6. A device, characterized in that, The device includes: a memory, a processor, and a billing batch processing program stored on the memory and executable on the processor, the billing batch processing program being configured to implement the steps of the billing batch processing method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a billing batch processing program, which, when executed by a processor, implements the steps of the billing batch processing method as described in any one of claims 1 to 4.

Images