Automatic billing method, device and electronic equipment

Abstract

The application provides an automatic billing method, which comprises the following steps: periodically responding to order data aggregation tasks, synchronously aggregating a plurality of order data corresponding to a plurality of preset types according to a preset number in batches, determining that the synchronous aggregation of the plurality of order data is completed, responding to a bill preview data generation instruction, processing the plurality of order data according to customer needs through a differential processing mechanism, generating a bill temporary storage table, auditing the bill temporary storage table, and the differential processing mechanism is a synchronous mode or an asynchronous mode through a message queue. After the audit is passed, a bill target storage table generation instruction is responded to, the bill temporary storage table is subjected to data verification, and after the verification is passed, the bill target storage table is generated from the bill temporary storage table through the differential processing mechanism, and the bill target storage table is subjected to auditing. After the audit is passed, a billing instruction is responded to, the bill target storage table and customer needs are subjected to billing processing, and a target invoice is obtained.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an automatic invoicing method, apparatus, and electronic device. Background Technology

[0002] In enterprise-level financial management systems, invoicing is a core link connecting business transactions and financial settlement, mainly comprising three steps: order data synchronization, invoice generation, and invoice issuance. Specifically, the system retrieves order data from various business systems through a full query and loads it into memory to complete order data synchronization. Subsequently, after operations personnel select an order in the system, the system loads all order data at once to summarize the invoice and generate it. Finally, the system generates an invoice preview based on the generated invoice, and after approval, calls a third-party invoicing interface to execute the invoicing operation. Furthermore, during the invoice issuance process, mutual exclusion access to shared resources is implemented using database row-level locks or table-level locks to achieve concurrency control. For cases of abnormal order data, the issue is handled by directly modifying the database record or deleting and re-entering it.

[0003] However, the aforementioned invoicing method suffers from slow database response and excessively long network transmission times, failing to effectively utilize system resources and thus reducing the timeliness of subsequent invoice processing and invoice retrieval. Furthermore, multiple operations personnel may simultaneously perform operations such as adding orders, reviewing invoices, and generating invoices for the same customer, leading to confusion in the originally synchronized order data and making it impossible to accurately obtain the corresponding invoices. Summary of the Invention

[0004] Embodiments of the present invention provide an automatic invoicing method, apparatus, and electronic device. This method solves the problems of slow database response and excessive network transmission time when loading all order data in a single query when the order data volume reaches hundreds of thousands or even millions. It also avoids the situation where system resources cannot be effectively utilized when dealing with multiple preset types of order data, thus improving the timeliness of subsequent billing processing and invoice acquisition. Furthermore, by generating a temporary billing storage table through a differentiated processing mechanism, it can solve the problem in the prior art where multiple operators may simultaneously perform operations such as adding orders, reviewing bills, and generating invoices for the same customer, leading to the confusion of the originally synchronized order data. This ensures accurate acquisition of the corresponding target invoice and improves the user experience.

[0005] To achieve the above objectives, in a first aspect, embodiments of the present invention provide an automatic invoicing method, the method comprising: Periodically respond to order data aggregation tasks, and synchronously aggregate multiple order data corresponding to multiple preset types in batches according to preset quantities; After confirming that the data from multiple orders has been synchronously aggregated, the system responds to the instruction to generate bill preview data. Through a differentiated processing mechanism, the system processes the data from multiple orders according to customer needs, generates a temporary bill storage table, and then reviews the temporary bill storage table. The differentiated processing mechanism is determined based on the number of orders in the order data. The differentiated processing mechanism can generate the temporary bill storage table synchronously or asynchronously through a message queue. After the temporary bill storage table is approved, the system responds to the instruction to generate the target bill storage table, performs data verification on the temporary bill storage table, and after the verification is passed, generates the target bill storage table based on the temporary bill storage table through a differentiated processing mechanism, and then reviews the target bill storage table. After the billing target storage table is approved, respond to the invoicing instruction, process the invoicing according to the billing target storage table and the customer's requirements, and obtain the target invoice.

[0006] In one embodiment, each order data is assigned a preset identifier, which is either a summarized identifier or a non-summarized identifier. The periodic response to the order data summarization task synchronously summarizes multiple order data corresponding to multiple preset types in batches according to a preset quantity, including: The task of summarizing order data is triggered according to a preset time. For multiple order data of various preset types, the preset identifier bits of each order data are obtained. Based on the preset identifier, the preset number of order data corresponding to each preset type is synchronously acquired and summarized, and the preset identifier is updated. The process then returns to acquire the preset identifier of the order data until the synchronous summary of multiple order data is completed.

[0007] In one embodiment, the step of synchronously acquiring and summarizing the preset quantity of order data corresponding to each preset type according to the preset identifier, updating the preset identifier, and returning to retrieve the preset identifier of the order data until the synchronous summarization of multiple order data is completed includes: When the preset flag is determined to be an unsummarized flag, the preset quantity of order data corresponding to each preset type is synchronously acquired, summarized, and the unsummarized flag corresponding to the current preset quantity of order data is updated to a summarized flag. Before the next batch of order data is aggregated, it is determined whether the preset quantity is greater than the number of order data with the preset identifier as the unaggregated identifier. If not, it returns to the previous step to synchronously obtain the preset quantity of order data corresponding to each preset type and aggregate it until the preset quantity is greater than the number of order data with the preset identifier as the unaggregated identifier, and then it is determined that the synchronous aggregation of multiple order data is completed.

[0008] In one embodiment, after determining that the synchronous aggregation of multiple order data is complete, responding to the bill preview data generation instruction, and processing the multiple order data according to customer needs through a differentiated processing mechanism to generate a temporary bill storage table, includes: Responding to the bill preview data generation instruction, multiple pending order data are identified from multiple order data based on customer needs; Determine whether the number of orders in multiple pending order data is less than a first preset threshold. If so, generate a temporary billing storage table directly through synchronization. If not, a temporary bill storage table is generated asynchronously via a message queue; The temporary billing storage table stores billing information for multiple pending order data, invoice information for each pending order data, and customer information. Each pending order data is set with an unbilled status flag, and a unique index is established between each pending order data and the customer through the order number and customer identifier.

[0009] In one embodiment, generating the temporary bill storage table asynchronously via a message queue includes: Based on multiple pending order data and customer needs, send MQ messages to the message queue; Upon receiving an MQ message and acquiring a distributed lock for multiple pending order data, but without acquiring an idempotency flag, the system writes the billing information, invoice information, and customer information for each pending order data to the temporary billing storage table in batches according to the preset processing data volume. It also updates the processing progress for the multiple pending order data until all pending order data is written to the temporary billing storage table, at which point the distributed lock for the multiple pending order data is released.

[0010] In one embodiment, responding to the instruction to generate the bill target storage table, performing data verification on the bill temporary storage table, and generating the bill target storage table based on the bill temporary storage table through a differential processing mechanism after the verification passes, includes: Responding to the bill preview data generation command, the system validates the data in the temporary bill storage table based on the bill amount; After the verification is passed, it is determined whether the number of orders in the multiple pending order data stored in the bill temporary storage table is less than the second preset threshold. If so, the bill target storage table is generated directly through synchronization, and the consolidated status flag is set for the multiple pending order data. The corresponding multiple pending order data stored in the bill temporary storage table is deleted. If not, the billing target storage table is generated asynchronously via message queue.

[0011] In one embodiment, generating the bill target storage table asynchronously via a message queue includes: Update the unbilled status flag of multiple pending order data stored in the temporary billing storage table to the processing status flag, and send the MQ message to the message queue; When a distributed lock for multiple pending order data is acquired via a message queue, and an idempotency flag is not acquired, the billing information, invoice information, and customer information for each pending order data stored in the temporary billing storage table are written to the target billing storage table in batches according to the preset processing data volume. The processing status flag for the current multiple pending order data is updated to the processing success status flag. The corresponding multiple pending order data stored in the temporary billing storage table are deleted, and the processing progress for the multiple pending order data is updated until all the multiple pending order data are written to the target billing storage table. After writing multiple pending order data into the billing target storage table, release the distributed lock on the multiple pending order data.

[0012] In one embodiment, the method further includes: When abnormal order data is identified among multiple order data, respond to the abnormal adjustment processing request, generate adjustment data for the abnormal order data, and summarize and synchronize it; The adjustment data includes: reversal order adjustment data that is consistent with the abnormal order data but has a negative amount, and correction order adjustment data.

[0013] Secondly, embodiments of the present invention provide an automatic invoicing device, comprising: The multiple order data aggregation module is used to periodically respond to order data aggregation tasks, and synchronously aggregate multiple order data corresponding to multiple preset types in batches according to preset quantities; The temporary bill storage table generation module is used to respond to the bill preview data generation instruction after the synchronous aggregation of multiple order data is completed. Through a differentiated processing mechanism, it processes the multiple order data according to customer needs, generates a temporary bill storage table, and reviews the temporary bill storage table. The differentiated processing mechanism is determined based on the number of orders in the order data. The differentiated processing mechanism can generate the temporary bill storage table synchronously or asynchronously through a message queue. The bill target storage table generation module is used to respond to the bill target storage table generation instruction after the temporary bill storage table has been approved, to perform data verification on the temporary bill storage table, and after the verification is passed, to generate the bill target storage table based on the temporary bill storage table through a differential processing mechanism, and to review the bill target storage table. The invoicing module is used to respond to invoicing instructions after the target storage table of the statement has been approved, and to process the invoicing according to the target storage table of the statement and the customer's requirements, and obtain the target invoice.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the automatic invoicing method described in the first aspect.

[0015] The above technical solution has the following technical effects: Thus, the automatic invoicing method provided in this embodiment periodically responds to order data aggregation tasks, synchronously aggregating multiple order data corresponding to multiple preset types in batches according to preset quantities. This solves the problems of slow database response and excessive network transmission time when loading all order data in a single query when the order data volume reaches hundreds of thousands or even millions in the prior art. It also avoids the situation where system resources cannot be effectively utilized when dealing with multiple preset types of order data, thereby improving the timeliness of subsequent billing processing and invoice acquisition. After confirming that the synchronous aggregation of multiple order data is completed, it responds to the bill preview data generation instruction, and processes the multiple order data according to customer needs through a differentiated processing mechanism, generating a temporary bill storage table, and then reviewing the temporary bill storage table. The differentiated processing mechanism is determined based on the number of orders in the order data, and the differentiated processing mechanism can generate the temporary bill storage table synchronously or asynchronously through a message queue. After the temporary billing storage table is approved, the system responds to the instruction to generate the target billing storage table, verifies the data in the temporary billing storage table, and, upon successful verification, generates the target billing storage table based on the temporary billing storage table using a differentiated processing mechanism. The target billing storage table is then approved. After the target billing storage table is approved, the system responds to the invoicing instruction, processes the invoicing based on the target billing storage table and customer requirements, and obtains the target invoice. This differentiated processing mechanism generates both the temporary billing storage table and the target billing storage table, resolving the issue in existing technologies where multiple operations personnel might simultaneously perform operations such as adding orders, approving invoices, and generating invoices for the same customer, leading to confusion in the originally synchronized order data. This ensures accurate acquisition of the corresponding target invoice and improves the user experience. Attached Figure Description

[0016] Figure 1This is a flowchart illustrating an automatic invoicing method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of an automatic invoicing device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0017] To further illustrate the various embodiments, the present invention provides accompanying drawings. These drawings are part of the disclosure of the present invention, primarily used to illustrate the embodiments and to explain the operating principles of the embodiments in conjunction with the relevant descriptions in the specification. With reference to these drawings, those skilled in the art should be able to understand other possible implementations and the advantages of the present invention. Components in the drawings are not drawn to scale, and similar component symbols are generally used to represent similar components.

[0018] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0019] Example 1: Figure 1 This is a flowchart illustrating an embodiment of an automatic invoicing method according to the present invention. In this embodiment, the method specifically includes the following steps: S10: Periodically responds to order data aggregation tasks, and synchronously aggregates multiple order data corresponding to multiple preset types in batches according to preset quantities.

[0020] Periodicity refers to the timing of the task, such as triggering an order data aggregation task at 7 a.m. every day. That is, at 7 a.m. every day, multiple order data corresponding to multiple preset types are aggregated in batches according to a preset quantity.

[0021] The preset quantity refers to the number of order data entries acquired in each batch for multiple order data entries corresponding to multiple preset types. This preset quantity could be, for example, 1000 entries. By setting this preset quantity to synchronize multiple order data entries in batches, the problem of slow database response, excessively long network transmission times, and extremely low synchronization efficiency caused by loading all data in a single query when the order data volume reaches hundreds of thousands or even millions is solved. Especially when processing various types of order data such as coupon orders, direct top-up orders, and e-commerce orders, the full synchronization strategy cannot effectively utilize system resources, resulting in an excessively long synchronization time window, which in turn affects the timeliness of subsequent billing processing. However, this is not a limitation; this embodiment is not specifically restrictive, and those skilled in the art can set it according to actual conditions.

[0022] The preset type refers to the different business systems corresponding to the order data acquisition, such as: coupon system, direct top-up system, and e-commerce system. Each business system corresponds to a different type of order data; that is, the coupon system corresponds to coupon type order data, the direct top-up system corresponds to direct top-up type order data, and the e-commerce system corresponds to e-commerce type order data. However, this is not a limitation, and this embodiment is not specifically limited. Those skilled in the art can set it according to the actual situation.

[0023] Specifically, the system periodically triggers and responds to order data aggregation tasks, performs order data aggregation operations, and synchronously aggregates multiple order data corresponding to multiple preset types in batches according to preset quantities.

[0024] Optionally, based on the above embodiments, each order data is set with a preset identifier bit, which is either a summarized identifier bit or a non-summarized identifier bit. For example, for multiple order data of various preset types, the preset identifier bit is initialized to the non-summarized identifier bit 0, indicating that the current order data has not been summarized. On the other hand, after the synchronization and summarization operation of the order data is completed, the non-summarized identifier bit 0 is updated to the summarized identifier bit 1, but this is not limited to this. This embodiment is not specifically limited, and those skilled in the art can set it according to the actual situation. Based on this, in some embodiments of the present invention, one implementation of S10 can be: S101: Trigger the response order data aggregation task according to the preset time interval, and obtain the preset identifier bit of each order data for multiple order data of each preset type.

[0025] Specifically, when the order data aggregation task is triggered at a preset time, the preset identifier of the corresponding order data is obtained for each preset type of multiple order data. Based on the preset identifier, it is determined whether the current order data is unaggregated or aggregated.

[0026] S102: Based on the preset identifier, synchronously acquire the preset quantity of order data corresponding to each preset type, summarize them synchronously, update the preset identifier, return to the preset identifier of acquiring the order data, until the synchronous summary of multiple order data is completed.

[0027] Optionally, based on the above embodiments, in some embodiments of the present invention, one implementation of S102 may be: S1021: When it is determined that the preset flag is an unsummarized flag, the preset quantity of order data corresponding to each preset type is obtained synchronously and summarized, and the unsummarized flag corresponding to the current preset quantity of order data is updated to a summarized flag.

[0028] Specifically, after obtaining the preset identifiers corresponding to multiple order data of each preset type, and determining that the preset identifiers corresponding to multiple order data are all unsummarized identifiers, the preset number of order data corresponding to each preset type is obtained synchronously for summarization processing. After the summarization processing of the preset number of order data is completed, the unsummarized identifiers corresponding to the summarized preset number of order data are updated to the summarized identifiers.

[0029] S1022: Before the next batch of order data is aggregated, determine whether the preset quantity is greater than the number of order data with the preset identifier as the unaggregated identifier. If not, return to execute the synchronous acquisition of the preset quantity of order data corresponding to each preset type for aggregation, until the preset quantity is greater than the number of order data with the preset identifier as the unaggregated identifier, and determine that the synchronous aggregation of multiple order data is completed.

[0030] Specifically, after the current batch of order data aggregation processing is completed, before proceeding to the next batch of order data aggregation, the number of remaining order data with the preset flag as the unaggregated flag is obtained. The preset number is compared with this number. If the preset number is less than this number, the process returns to synchronously obtain the preset number of order data corresponding to each preset type for aggregation, until the preset number is greater than the number of order data with the preset flag as the unaggregated flag, thus confirming that the synchronous aggregation of multiple order data is complete.

[0031] It should be noted that each order data item undergoing summary processing is marked with the transaction type "order placed" to facilitate subsequent billing summary and invoicing processing, as well as historical query processing of order data by operations personnel.

[0032] S11: After confirming that the data of multiple orders has been synchronized and summarized, respond to the instruction to generate bill preview data, process the data of multiple orders according to customer needs through a differentiated processing mechanism, generate a temporary bill storage table, and review the temporary bill storage table.

[0033] The differentiated processing mechanism is determined based on the number of orders in the order data. The differentiated processing mechanism can be either to generate a temporary billing table synchronously or asynchronously via a message queue.

[0034] The bill preview data generation instruction is generated by the operations personnel based on customer needs and order conditions. These customer needs may include, for example, customer number, customer requirements for invoices, and order data that the customer needs to process, but are not limited to these. This embodiment does not impose specific limitations, and those skilled in the art can set them according to actual circumstances.

[0035] Specifically, after the data from multiple orders of various preset types is synchronized and aggregated, the system responds to the instruction to generate bill preview data. Through a differentiated processing mechanism determined by the number of orders in the order data, the system processes the multiple order data synchronously or asynchronously via message queues according to customer needs, generating a temporary bill storage table. After generating the temporary bill storage table, the system performs an audit process on the temporary bill storage table.

[0036] Optionally, based on the above embodiments, in some embodiments of the present invention, one implementation of S11 may be: S111: Respond to the bill preview data generation instruction and determine multiple pending order data from multiple order data based on customer needs.

[0037] Specifically, it receives and responds to the instruction to generate bill preview data, and determines the multiple pending order data that need to be processed from the multiple order data corresponding to various preset types, based on the customer needs entered by the operations personnel.

[0038] S112: Determine whether the number of orders in multiple pending order data is less than the first preset threshold. If so, generate a temporary bill storage table directly through synchronization.

[0039] The first preset threshold is used to determine whether the bill temporary storage table is generated synchronously or asynchronously via a message queue. For example, the first preset threshold may be 20,000, but it is not limited to this. This embodiment does not impose specific limitations, and those skilled in the art can set it according to the actual situation.

[0040] Specifically, the system retrieves data on the number of orders awaiting processing. If the number of orders is less than a first preset threshold, a temporary billing table is generated synchronously within the current thread. The data for the multiple pending orders is then written to this temporary billing table.

[0041] It should be noted that the temporary billing storage table stores billing information for multiple pending order data, invoice information for each pending order data, and customer information. Each pending order data is set with an unbilled status flag, and a unique index is established between each pending order data and the customer through the order number and customer identifier.

[0042] S113: If not, generate a temporary bill storage table asynchronously via message queue.

[0043] Specifically, if the number of orders for multiple pending order data is determined to be no less than a first preset threshold, a temporary billing storage table is generated asynchronously via a message queue.

[0044] Optionally, based on the above embodiments, in some embodiments of the present invention, one implementation of S113 may be: S1131: Based on multiple pending order data and customer requirements, send MQ messages to the message queue.

[0045] The MQ message is sent to the message queue only after the database transaction is successfully committed, ensuring the consistency between message sending and data updates, and avoiding data inconsistency caused by messages already being sent after the transaction is rolled back.

[0046] It can encapsulate and process multiple pending order data and customer requirements, and then send MQ messages to the message queue so that a temporary billing storage table can be generated through the message queue.

[0047] S1132: After receiving the MQ message through the message queue and acquiring the distributed lock for multiple pending order data, and without acquiring the idempotency flag, the billing information of multiple pending order data, the invoice information corresponding to each pending order data, and the customer information are written to the temporary billing storage table in batches according to the preset processing data volume, and the processing progress of multiple pending order data is updated until all multiple pending order data are written to the temporary billing storage table, and the distributed lock for multiple pending order data is released.

[0048] The distributed lock refers to a distributed lock based on the customer ID. Specifically, the Redisson distributed lock framework is used. The lock key name is formed by concatenating a fixed prefix with the customer ID, thereby achieving mutual exclusion of customer-level operations. This solves the problem that when multiple operations personnel operate on the same customer's bill at the same time, only the bill preview data generation instruction that obtains the lock can execute the relevant operations for generating bill preview data. Other bill preview data generation waits within the lock timeout period (5 seconds), and if the timeout occurs, an operation failure message is returned.

[0049] The idempotency flag is used to check whether an operation has been processed after acquiring a distributed lock by checking the Redis key flag. If it has been processed, success is returned directly to avoid duplicate processing. If a database persistence exception occurs during processing (such as a unique index conflict), the Redis flag is cleared to allow retry.

[0050] Specifically, upon receiving an MQ message and acquiring a distributed lock for the operation of generating a temporary billing storage table for multiple pending order data, and without acquiring an idempotency flag, it indicates that the operation of generating the temporary billing storage table is not currently being executed. Based on the preset processing data volume, the billing information of multiple pending order data, the invoice information corresponding to each pending order data, and customer information are written to the temporary billing storage table in batches, and the processing progress for multiple pending order data is updated until all pending order data is written to the temporary billing storage table, at which point the distributed lock for multiple pending order data is released.

[0051] Optionally, based on the above embodiments, in some embodiments of the present invention, one way to update the processing progress for multiple pending order data may be: During the generation of the temporary billing storage table via message queue, processing progress values ​​can be stored in Redis, for example, with the key format FMS_BILL_ORDER_PROGRESS_{pageId}. Specifically, after each batch of processing is completed, the progress percentage is updated, and the progress query interface is called every 2 seconds to retrieve the progress value in Redis. A progress bar is then displayed in a front-end pop-up window, allowing operations personnel to easily monitor the real-time generation progress of the temporary billing storage table. Furthermore, when the progress reaches 100%, the pop-up window will automatically close, allowing operations personnel to continue with subsequent operations.

[0052] S12: After the temporary bill storage table is approved, respond to the bill target storage table generation instruction, perform data verification on the temporary bill storage table, and after the verification is passed, generate the bill target storage table based on the temporary bill storage table through a differential processing mechanism, and then review the bill target storage table.

[0053] Optionally, based on the above embodiments, in some embodiments of the present invention, S12 may be implemented as follows: S121: Respond to the bill preview data generation command and perform data verification on the temporary bill storage table based on the bill amount.

[0054] Specifically, upon receiving the instruction to generate bill preview data, the system responds by performing data verification on the temporary bill storage table based on the bill amount. Specifically, it calculates the sum of the amounts of the multiple pending order data stored in the temporary bill storage table, determines whether the sum of the amounts is correct, and thus performs data verification on the temporary bill storage table.

[0055] S122: After the verification is passed, determine whether the number of orders in the multiple pending order data stored in the bill temporary storage table is less than the second preset threshold. If so, generate the bill target storage table directly through synchronization, set the consolidated status flag for the multiple pending order data, and delete the corresponding multiple pending order data stored in the bill temporary storage table.

[0056] The second preset threshold is used to determine whether the bill target storage table is generated synchronously or asynchronously via a message queue. The second preset threshold can be, for example, 100,000, but is not limited thereto. This embodiment does not impose specific limitations, and those skilled in the art can set it according to actual conditions.

[0057] Specifically, after the verification is passed, the number of orders for multiple pending order data stored in the bill temporary storage table is obtained, and it is determined whether the number of orders is less than the second preset threshold. If the number of orders is less than the second preset threshold, the bill target storage table is generated directly through synchronization, and the consolidated status flag is set for multiple pending order data. The corresponding multiple pending order data stored in the bill temporary storage table are also deleted.

[0058] S123: If not, generate the bill target storage table asynchronously via message queue.

[0059] Optionally, based on the above embodiments, in some embodiments of the present invention, one implementation of S123 may be: S1231: Update the unbilled status flag of the multiple pending order data stored in the temporary bill storage table to the processing status flag, and send the MQ message to the message queue.

[0060] Specifically, after determining that the bill target storage table will be generated asynchronously via message queue, the unbilled status flag of multiple pending order data stored in the bill temporary storage table needs to be updated to the processing status flag, and an MQ message is sent to the message queue, thereby completing the generation of the bill target storage table through the message queue.

[0061] S1232: When a distributed lock for multiple pending order data is acquired via a message queue, and an idempotency flag is not acquired, the billing information, invoice information, and customer information for each pending order data stored in the temporary billing storage table are written to the target billing storage table in batches according to the preset processing data volume. The processing status flag for the current multiple pending order data is updated to the processing success status flag. The corresponding multiple pending order data stored in the temporary billing storage table are deleted, and the processing progress for the multiple pending order data is updated until all the multiple pending order data are written to the target billing storage table.

[0062] S1233: After writing multiple pending order data into the bill target storage table, release the distributed lock on the multiple pending order data.

[0063] Specifically, the system acquires a distributed lock for multiple pending order data of various preset types via a message queue. If the idempotency flag is not acquired, the system will, according to the preset processing data volume, write the billing information, invoice information, and customer information of the multiple pending order data stored in the temporary billing storage table to the target billing storage table in batches. Simultaneously, the "processing" status flag of the currently written multiple pending order data in the target billing storage table is updated to the "processing successful" status flag. After multiple pending order data are written to the target billing storage table, the system deletes the corresponding multiple pending order data from the temporary billing storage table and updates the processing progress of these pending order data until all pending order data in the temporary billing storage table has been written. Finally, after all pending order data has been written to the target billing storage table, the distributed lock for these pending order data is released.

[0064] S13: After the billing target storage table is approved, respond to the invoicing instruction, process the invoicing according to the billing target storage table and the customer's requirements, and obtain the target invoice.

[0065] Optionally, based on the above embodiments, in some embodiments of the present invention, one implementation of S13 may be: after the bill target storage table is reviewed, an invoicing instruction is responded to: including responding to the customer's instruction to add preview invoice data subscription entered by the operations personnel, or automatically generating invoice data to be reviewed based on the bill target storage table and customer needs through the "one-click invoicing" function. Further, after the invoice data to be reviewed is approved, it is split according to the invoice type (such as VAT general invoice, VAT special invoice) and subject (such as prepaid card recharge sales, service fees, etc.) included in the customer's needs, generating multiple invoicing data records, each record containing only a single invoice type and corresponding subject. Finally, the invoicing interface is called to execute the invoicing operation, at which time the invoicing status is updated to "invoicing"; after filtering the multiple invoicing data in the "invoicing" status, the invoicing is completed, the target invoice is obtained, and the invoicing status is updated to "invoicing completed".

[0066] It should be noted that for invoices that fail to be issued, the invoice status will be updated to "Invoice Failed" and the reason for the failure will be recorded for the convenience of operations personnel to review later.

[0067] Thus, the automatic invoicing method provided in this embodiment, by periodically responding to order data aggregation tasks, synchronously aggregates multiple order data corresponding to multiple preset types in batches according to preset quantities. This solves the problem in the prior art where, when the order data volume reaches hundreds of thousands or even millions, a single query to load all order data results in slow database response and excessive network transmission time. It also avoids situations where system resources cannot be effectively utilized when dealing with multiple preset types of order data, improving the timeliness of subsequent billing processing and invoice retrieval. After confirming that the synchronous aggregation of multiple order data is complete, it responds to the bill preview data generation instruction and processes the multiple order data according to customer needs through a differentiated processing mechanism, generating a temporary bill storage table, and then reviewing the temporary bill storage table. The differentiated processing mechanism is determined based on the number of orders in the order data, and can generate the temporary bill storage table synchronously or asynchronously through a message queue. After the temporary billing storage table is approved, the system responds to the instruction to generate the target billing storage table, verifies the data in the temporary billing storage table, and, upon successful verification, generates the target billing storage table based on the temporary billing storage table using a differentiated processing mechanism. The target billing storage table is then approved. After the target billing storage table is approved, the system responds to the invoicing instruction, processes the invoicing based on the target billing storage table and customer requirements, and obtains the target invoice. This differentiated processing mechanism generates both the temporary billing storage table and the target billing storage table, resolving the issue in existing technologies where multiple operations personnel might simultaneously perform operations such as adding orders, approving invoices, and generating invoices for the same customer, leading to confusion in the originally synchronized order data. This ensures accurate acquisition of the corresponding target invoice and improves the user experience.

[0068] Optionally, based on the above embodiments, some embodiments of the present invention further include, for obtaining the customer invoice type corresponding to the target invoice, it can be a customer monthly invoice type (type value 0) and a customer-defined invoice type (type value 1). For customers with the customer monthly invoice type, S10-S13 are automatically executed at the beginning of each month. The specific implementation process can be referred to the above description, and will not be elaborated further here.

[0069] It should be noted that for customers with monthly invoicing, during the generation of the target invoice, a corresponding review message and invoicing message will be automatically sent to the customer to inform them to reconcile accounts and obtain the target invoice.

[0070] Optionally, based on the above embodiments, in some embodiments of the present invention, when it is determined that there is abnormal order data in multiple order data, an abnormal adjustment processing request is responded to, adjustment data for the abnormal order data is generated, and the data is summarized and synchronized.

[0071] The adjustment data includes: reversal order adjustment data that is consistent with the abnormal order data but has a negative amount, and corrected order adjustment data, which refers to order data with the correct amount.

[0072] In this way, by verifying the data through the sum of the billing amounts, abnormal order data has been identified in multiple order records. At this point, the abnormal order data can be reversed (i.e., the abnormal data is offset by a negative amount corresponding to the abnormal order data), and then the correct corrected order data can be added. This differs from existing technologies that directly modify database records when handling abnormal order data (such as incorrect price configuration, incorrect invoice account configuration, incorrect invoice type configuration, etc.). This method results in the inability to retain modification traces, lacks audit trail capabilities, and directly modifying processed order data can easily cause discrepancies between the billing amount and the invoice amount, making it impossible to obtain the accurate target invoice.

[0073] Example 2: Figure 2 This is a schematic diagram of an automatic invoicing device provided in an embodiment of the present invention, as shown below. Figure 2 As shown, it includes: a multiple order data aggregation module 10, a bill temporary storage table generation module 11, a bill target storage table generation module 12, and an invoicing module 13.

[0074] Among them, the multiple order data aggregation module 10 is used to periodically respond to the order data aggregation task and synchronously aggregate multiple order data corresponding to multiple preset types in batches according to the preset quantity.

[0075] The temporary bill storage table generation module 11 is used to respond to the bill preview data generation instruction after determining that the data of multiple orders has been synchronously summarized. Through a differentiated processing mechanism, it processes the data of multiple orders according to customer needs, generates a temporary bill storage table, and reviews the temporary bill storage table. The differentiated processing mechanism is determined according to the number of orders in the order data. The differentiated processing mechanism can generate the temporary bill storage table synchronously or asynchronously through a message queue.

[0076] The bill target storage table generation module 12 is used to respond to the bill target storage table generation instruction after the temporary bill storage table has been approved, to perform data verification on the temporary bill storage table, and after the verification is passed, to generate the bill target storage table based on the temporary bill storage table through a differential processing mechanism, and to review the bill target storage table.

[0077] The invoicing module 13 is used to respond to the invoicing instruction after the invoice target storage table is approved, and to process the invoicing according to the invoice target storage table and the customer's requirements to obtain the target invoice.

[0078] Thus, in this embodiment, multiple order data aggregation modules periodically respond to order data aggregation tasks, synchronously aggregating multiple order data corresponding to multiple preset types in batches according to preset quantities. This solves the problem in the prior art where, when the order data volume reaches hundreds of thousands or even millions, a single query to load all order data results in slow database response and excessive network transmission time. It also avoids situations where system resources cannot be effectively utilized when dealing with multiple preset types of order data, improving the timeliness of subsequent billing processing and invoice retrieval. After determining that the synchronous aggregation of multiple order data is complete, the bill temporary storage table generation module responds to the bill preview data generation instruction. Through a differentiated processing mechanism, it processes the multiple order data according to customer needs, generates a bill temporary storage table, and reviews the bill temporary storage table. The differentiated processing mechanism is determined based on the number of orders in the order data. The differentiated processing mechanism can generate the bill temporary storage table synchronously or asynchronously through a message queue. After approving the temporary bill storage table, the bill target storage table generation module responds to the bill target storage table generation instruction, performs data verification on the temporary bill storage table, and generates the bill target storage table based on the temporary bill storage table through a differentiated processing mechanism, and then approves the bill target storage table. After approving the bill target storage table, the invoicing module responds to the invoicing instruction, processes the invoicing based on the bill target storage table and the customer's requirements, and obtains the target invoice. In this way, by generating the temporary bill storage table and the bill target storage table through a differentiated processing mechanism, the problem of multiple operations personnel simultaneously performing operations such as adding orders, approving invoices, and generating invoices for the same customer, leading to the corruption of the originally synchronized order data, is solved. This ensures accurate acquisition of the corresponding target invoice and improves the user experience.

[0079] Example 3: The present invention also provides an electronic device, Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the electronic device includes a processor 1101, a memory 1102, a bus 1103, and a computer program stored in the memory 1102 and executable on the processor 1101. The processor 1101 includes one or more processing cores. The memory 1102 is connected to the processor 1101 via the bus 1103. The memory 1102 is used to store program instructions. When the processor executes the computer program, it implements the steps in the above-described method embodiment of Embodiment 1 of the present invention.

[0080] Furthermore, as an executable solution, the electronic device can be a computer unit, which can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. The computer unit may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above-described structure of the computer unit is merely an example and does not constitute a limitation on the computer unit. It may include more or fewer components, or combine certain components, or use different components. For example, the computer unit may also include input / output devices, network access devices, buses, etc., and this embodiment of the invention does not limit this.

[0081] Furthermore, as an executable solution, the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. The processor is the control center of the computer unit, connecting various parts of the entire computer unit via various interfaces and lines.

[0082] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the computer unit by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital card (SD card), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0083] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.

Claims

1. An automatic invoicing method, characterized in that, The method includes: Periodically respond to order data aggregation tasks, and synchronously aggregate multiple order data corresponding to multiple preset types in batches according to preset quantities; After confirming that the data from multiple orders has been synchronously aggregated, the system responds to the instruction to generate bill preview data. Through a differentiated processing mechanism, the system processes the data from multiple orders according to customer needs, generates a temporary bill storage table, and then reviews the temporary bill storage table. The differentiated processing mechanism is determined based on the number of orders in the order data. The differentiated processing mechanism can generate the temporary bill storage table synchronously or asynchronously through a message queue. After the temporary bill storage table is approved, the system responds to the instruction to generate the target bill storage table, performs data verification on the temporary bill storage table, and after the verification is passed, generates the target bill storage table based on the temporary bill storage table through a differentiated processing mechanism, and then reviews the target bill storage table. After the billing target storage table is approved, respond to the invoicing instruction, process the invoicing according to the billing target storage table and the customer's requirements, and obtain the target invoice.

2. The method according to claim 1, characterized in that, Each order data is assigned a preset identifier, which can be either a summarized identifier or a non-summarized identifier. The periodic order data summarization task synchronously summarizes multiple order data corresponding to multiple preset types in batches according to a preset quantity, including: The task of summarizing order data is triggered according to a preset time. For multiple order data of various preset types, the preset identifier bits of each order data are obtained. Based on the preset identifier, the preset number of order data corresponding to each preset type is synchronously acquired and summarized, and the preset identifier is updated. The process then returns to acquire the preset identifier of the order data until the synchronous summary of multiple order data is completed.

3. The method according to claim 2, characterized in that, The process of synchronously acquiring and summarizing the preset quantity of order data corresponding to each preset type according to the preset identifier, updating the preset identifier, and returning to retrieve the preset identifier of the order data, until the synchronous summarization of multiple order data is completed, includes: When the preset flag is determined to be an unsummarized flag, the preset quantity of order data corresponding to each preset type is synchronously acquired, summarized, and the unsummarized flag corresponding to the current preset quantity of order data is updated to a summarized flag. Before the next batch of order data is aggregated, it is determined whether the preset quantity is greater than the number of order data with the preset identifier as the unaggregated identifier. If not, it returns to the previous step to synchronously obtain the preset quantity of order data corresponding to each preset type and aggregate it until the preset quantity is greater than the number of order data with the preset identifier as the unaggregated identifier, and then it is determined that the synchronous aggregation of multiple order data is completed.

4. The method according to claim 3, characterized in that, After confirming that the data from multiple orders has been synchronously aggregated, the system responds to the invoice preview data generation instruction and, through a differentiated processing mechanism, processes the multiple order data according to customer needs to generate a temporary invoice storage table, including: Responding to the bill preview data generation instruction, multiple pending order data are identified from multiple order data based on customer needs; Determine whether the number of orders in multiple pending order data is less than a first preset threshold. If so, generate a temporary billing storage table directly through synchronization. If not, a temporary bill storage table is generated asynchronously via a message queue; The temporary billing storage table stores billing information for multiple pending order data, invoice information for each pending order data, and customer information. Each pending order data is set with an unbilled status flag, and a unique index is established between each pending order data and the customer through the order number and customer identifier.

5. The method according to claim 4, characterized in that, The method of generating a temporary bill storage table asynchronously via message queue includes: Based on multiple pending order data and customer needs, send MQ messages to the message queue; Upon receiving an MQ message and acquiring a distributed lock for multiple pending order data, but without acquiring an idempotency flag, the system writes the billing information, invoice information, and customer information for each pending order data to the temporary billing storage table in batches according to the preset processing data volume. It also updates the processing progress for the multiple pending order data until all pending order data is written to the temporary billing storage table, at which point the distributed lock for the multiple pending order data is released.

6. The method according to claim 5, characterized in that, The process of responding to the instruction to generate the target bill storage table involves verifying the data in the temporary bill storage table, and, after successful verification, generating the target bill storage table based on the temporary bill storage table using a differential processing mechanism. This includes: Responding to the bill preview data generation command, the system validates the data in the temporary bill storage table based on the bill amount; After the verification is passed, it is determined whether the number of orders in the multiple pending order data stored in the bill temporary storage table is less than the second preset threshold. If so, the bill target storage table is generated directly through synchronization, and the consolidated status flag is set for the multiple pending order data. The corresponding multiple pending order data stored in the bill temporary storage table is deleted. If not, the billing target storage table is generated asynchronously via message queue.

7. The method according to claim 6, characterized in that, The method of asynchronously generating the bill target storage table via message queue includes: Update the unbilled status flag of multiple pending order data stored in the temporary billing storage table to the processing status flag, and send the MQ message to the message queue; When a distributed lock for multiple pending order data is acquired via a message queue, and an idempotency flag is not acquired, the billing information, invoice information, and customer information for each pending order data stored in the temporary billing storage table are written to the target billing storage table in batches according to the preset processing data volume. The processing status flag for the current multiple pending order data is updated to the processing success status flag. The corresponding multiple pending order data stored in the temporary billing storage table are deleted, and the processing progress for the multiple pending order data is updated until all the multiple pending order data are written to the target billing storage table. After writing multiple pending order data into the billing target storage table, release the distributed lock on the multiple pending order data.

8. The method according to claim 7, characterized in that, The method further includes: When abnormal order data is identified among multiple order data, respond to the abnormal adjustment processing request, generate adjustment data for the abnormal order data, and summarize and synchronize it; The adjustment data includes: reversal order adjustment data that is consistent with the abnormal order data but has a negative amount, and correction order adjustment data.

9. An automatic invoicing device, characterized in that, include: The multiple order data aggregation module is used to periodically respond to order data aggregation tasks, and synchronously aggregate multiple order data corresponding to multiple preset types in batches according to preset quantities; The temporary bill storage table generation module is used to respond to the bill preview data generation instruction after the synchronous aggregation of multiple order data is completed. Through a differentiated processing mechanism, it processes the multiple order data according to customer needs, generates a temporary bill storage table, and reviews the temporary bill storage table. The differentiated processing mechanism is determined based on the number of orders in the order data. The differentiated processing mechanism can generate the temporary bill storage table synchronously or asynchronously through a message queue. The bill target storage table generation module is used to respond to the bill target storage table generation instruction after the temporary bill storage table has been approved, to perform data verification on the temporary bill storage table, and after the verification is passed, to generate the bill target storage table based on the temporary bill storage table through a differential processing mechanism, and to review the bill target storage table. The invoicing module is used to respond to invoicing instructions after the target storage table of the statement has been approved, and to process the invoicing according to the target storage table of the statement and the customer's requirements, and obtain the target invoice.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the automatic invoicing method according to any one of claims 1 to 8.

Images