Non-tax bill packaging method
By using dynamic segmentation and priority scheduling, the problems of lag and disordered sorting in the non-tax invoice packaging system have been solved, achieving efficient and accurate invoice processing and transmission, and adapting to the needs of fiscal business.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HEBEI YUNXING DATA COMM TECH CO LTD
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-14
AI Technical Summary
Existing methods for packaging non-tax invoices are prone to system lag and invoice sorting errors when processing large batches, affecting efficiency and accuracy.
A method combining dynamic block partitioning and priority scheduling is adopted. By obtaining the priority of the ticket data, the dynamic block partitioning parameters are determined based on the load data sequence. A dual-packet queue is used to distinguish between high and low priority ticket blocks, and a unique block identifier and sequence index are generated for each ticket block for accurate sorting and verification.
It effectively solves the problems of lag and sorting disorder when packaging large batches of invoices, improves processing efficiency and accuracy, and ensures timely processing of urgent business and accurate subsequent reconciliation.
Smart Images
Figure CN121858331A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of data processing technology, and more specifically, relates to a method for packaging non-tax invoices. Background Technology
[0002] Non-tax receipts are core vouchers for fiscal revenue management, covering various business scenarios such as administrative fees and medical payments. Electronic non-tax receipt packaging refers to the process of organizing and encapsulating scattered electronic receipt data according to unified standards for transmission, archiving, or reconciliation. Its efficiency and reliability directly impact the flow of fiscal business and the public service experience. With the deepening of "Internet + government services," the electronic rate of non-tax receipts has increased significantly, and large-scale receipt packaging scenarios are becoming increasingly common, placing higher demands on the performance, orderliness, and adaptability to urgent business needs of packaging technology.
[0003] The existing methods for packaging non-tax invoices have obvious flaws. On the one hand, when processing large batches of invoices, the large amount of data in a single block can easily lead to invoice congestion and system lag, resulting in low packaging efficiency. On the other hand, the sorting of invoices during the processing of large batches of invoices lacks an effective guarantee mechanism, and the order can easily be disordered during merging, affecting the accuracy of subsequent reconciliation and archiving.
[0004] In summary, there is an urgent need for a more efficient and accurate method for packaging non-tax invoices. Summary of the Invention
[0005] The purpose of this application is to provide a method for packaging non-tax invoices to improve the efficiency and accuracy of non-tax invoice packaging.
[0006] A first aspect of this application provides a method for packaging non-tax invoices, including: Acquire multiple invoice data and determine the invoice priority for each invoice data; Obtain the load data sequence and determine the dynamic block parameters based on the load data sequence; divide the multiple bill data into blocks based on the dynamic block parameters and the bill priority of each bill data to obtain multiple bill blocks marked with priority identifiers; For each ticket block, if the priority of the ticket block is marked as high priority, the ticket block is entered into the first packing queue; if the priority of the ticket block is marked as low priority, the ticket block is entered into the second packing queue. The ticket blocks in the first and second packing queues are sequentially scheduled; a unique block identifier is generated for each scheduled ticket block, and a sequential index is generated for each ticket data in the ticket block to obtain the target ticket block; The target ticket block is packaged and verified, and all packaged ticket blocks that pass verification are transmitted.
[0007] A second aspect of this application provides a non-tax invoice packaging device, comprising: The bill priority division module is used to obtain multiple bill data and determine the bill priority of each bill data. The bill segmentation module is used to obtain the load data sequence, determine the dynamic segmentation parameters based on the load data sequence, and segment multiple bill data into blocks based on the dynamic segmentation parameters and the bill priority of each bill data, resulting in multiple bill blocks marked with priority identifiers. The dual-queue module is used to input each ticket block into the first packing queue if the priority of the ticket block is marked as high priority, and into the second packing queue if the priority of the ticket block is marked as low priority. The ticket block scheduling module is used to sequentially schedule ticket blocks in the first and second packing queues; it generates a unique block identifier for each scheduled ticket block and generates a sequential index for each ticket data in the ticket block to obtain the target ticket block. The ticket block packaging module is used to package and verify the target ticket block, and transmit all packaged ticket blocks that pass verification.
[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described non-tax invoice packaging method.
[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described non-tax invoice packaging method.
[0010] The beneficial effects of the non-tax invoice packaging method provided in this application embodiment are as follows: The embodiments of this application can effectively solve the core problems of low efficiency and disordered sorting of large batches of invoices in the prior art, while taking into account both processing efficiency and data accuracy, and adapting to the actual needs of financial business and public services.
[0011] On the one hand, addressing the shortcomings of existing methods in handling large volumes of data, such as lag and low efficiency, this application's embodiments solve this problem through a combination of dynamic block partitioning and priority scheduling. This application's embodiments determine dynamic block partitioning parameters based on system load data, flexibly adjusting the number of tickets in a single ticket block according to system busyness, avoiding resource overload caused by fixed block partitioning, and reducing system lag at its source. Simultaneously, this application's embodiments distinguish between high and low priority ticket blocks through dual packaging queues, prioritizing the scheduling of urgent tickets, preventing urgent business from being congested by regular tickets, significantly improving overall packaging and processing efficiency, and ensuring timely processing of urgent business such as medical payments.
[0012] On the other hand, addressing the shortcomings of existing methods that result in disordered document sorting, this application's embodiment generates a unique block identifier for each scheduled document block and configures a sequential index for each document data. During merging and packaging, documents can be precisely sorted by number, completely avoiding disordered document order, ensuring the accuracy of subsequent reconciliation and archiving work, and reducing business rework caused by data errors. The post-packaging verification step further investigates data problems, ensuring the integrity and reliability of transmitted document data, and comprehensively improving the accuracy and stability of non-tax document packaging. Attached Figure Description
[0013] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0014] Figure 1 A flowchart illustrating a method for packaging non-tax invoices according to an embodiment of this application; Figure 2 A structural block diagram of a non-tax invoice packaging device provided in an embodiment of this application; Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0015] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0016] It is understood that in the embodiments of this application, data such as user information are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.
[0017] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in sequences other than those illustrated or described herein.
[0018] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a method for packaging non-tax invoices according to an embodiment of this application. The method can be executed by an electronic device, and specifically, the method may include steps S101 to S105.
[0019] S101: Obtain multiple bill data and determine the bill priority of each bill data.
[0020] In this embodiment, determining the ticket priority of each ticket data includes: For each invoice data, extract the business type field and payment deadline field from the invoice data, and determine the invoice priority based on the business type field and payment deadline field.
[0021] In this embodiment, the priority of the invoice data is determined based on the business type field and the payment deadline field, including: Perform keyword matching on the business type field to obtain the matching degree; Convert the payment deadline field to timestamp format to obtain the payment deadline timestamp; calculate the timestamp difference between the payment deadline timestamp and the current timestamp; If the matching degree is greater than the first matching degree threshold and / or the timestamp difference is less than the first time threshold, then the ticket priority of the ticket data is determined to be high priority; If the matching degree is not greater than the first matching degree threshold and the timestamp difference is not less than the first time threshold, then the ticket priority of the ticket data is determined to be low priority.
[0022] In this embodiment, invoice data refers to electronic data containing non-tax business-related information, used to record payment details. The business type field refers to the data field in the invoice representing the business category, used to distinguish different non-tax business scenarios. The payment deadline field refers to the data field in the invoice recording the payment deadline. Invoice priority refers to the hierarchical classification of invoice processing order, used to distinguish processing priorities. Matching degree refers to the degree of fit between the business type field and preset keywords. The first matching degree threshold refers to the critical value for determining high priority. Timestamp format refers to converting time into a unified digital format for easy calculation. The payment deadline timestamp refers to the timestamp corresponding to the payment deadline. The current timestamp refers to the timestamp corresponding to the system time at the time of determination. The timestamp difference refers to the difference between the payment deadline timestamp and the current timestamp. The first time threshold refers to the critical value for determining high priority based on the time difference. High priority refers to the invoice level that needs to be processed first. Low priority refers to the invoice level that is processed normally.
[0023] Considering that non-tax invoices cover various business scenarios and the urgency of different businesses varies, it is difficult to accurately determine priority based on a single dimension. The business type field is directly associated with the core attributes of the business, enabling rapid identification of urgent business categories; the payment deadline field intuitively reflects the time urgency, and the combination of the two can comprehensively cover the scenarios for determining urgent invoices. Therefore, this embodiment sets matching degree thresholds and time thresholds to flexibly adapt to the determination needs of different business scenarios, avoid delays or resource waste in urgent businesses caused by misjudgments based on a single dimension, ensure the accuracy and practicality of priority determination, and provide a reliable basis for subsequent differentiated processing.
[0024] For example, this embodiment can be applied to a hospital non-tax electronic invoice processing system, and the specific steps are as follows: (1) The system obtains multiple invoice data such as outpatient payment, inpatient payment, and administrative and institutional fee archives on the same day through the data interface, covering complete information such as invoice number, business description, and payment deadline.
[0025] (2) For each invoice data, the system extracts the business type field and payment deadline field through the XML parsing tool. For example, the business type field of a certain invoice is "outpatient medical payment" and the payment deadline field is "2025-09-10 18:00:00".
[0026] (3) Start the keyword matching process. The system has a preset emergency business keyword library such as "medical payment", "emergency payment" and "emergency payment". The matching degree between the business type field and the keyword library is calculated by the string comparison algorithm. If the business type field of the bill contains "medical payment", the matching degree is calculated to be 90%.
[0027] (4) Use a time format conversion tool to convert the payment deadline field into a timestamp format, and at the same time obtain the timestamp corresponding to the current system time, calculate the difference between the two timestamps, assuming it is 86400 seconds.
[0028] (5) The system presets the first matching degree threshold to 80% and the first time threshold to 86400 seconds (i.e. 24 hours), and retrieves the judgment rules to determine the priority.
[0029] (6) If a bill has a matching degree of 90% which is greater than the first matching degree threshold of 80%, it is directly judged as high priority; if the business type field of a bill is "administrative and institutional fee archive", the matching degree is 30% which is not greater than the first matching degree threshold, and the timestamp difference of 259,200 seconds (3 days) is not less than the first time threshold, it is judged as low priority; if a bill has a matching degree of 75% which is not greater than the first matching degree threshold, but the timestamp difference of 36,000 seconds (10 hours) is less than the first time threshold, it is also judged as high priority.
[0030] This embodiment determines invoice priority using both the business type field and the payment deadline field, effectively avoiding the limitations of a single-dimensional approach and improving the accuracy of priority determination. It accurately distinguishes between high- and low-priority invoices, providing a reliable basis for subsequent differentiated packaging and scheduling, ensuring that invoices for urgent services such as medical payments are processed first, and avoiding delays in these urgent cases. Threshold settings provide flexibility to the determination rules, adapting to different non-tax business scenarios, comprehensively improving the targeting and efficiency of non-tax invoice processing, and supporting the orderly flow of fiscal business.
[0031] S102: Obtain the load data sequence, determine the dynamic block parameters based on the load data sequence; divide the multiple bill data into blocks based on the dynamic block parameters and the bill priority of each bill data to obtain multiple bill blocks marked with priority identifiers.
[0032] In this embodiment, the load data sequence includes CPU utilization and memory usage; Dynamic block parameters are determined based on the load data sequence, including: If the CPU utilization rate is less than the first utilization rate threshold and the memory utilization rate is less than the second utilization rate threshold, then the dynamic block parameter is determined to be the number of first ticket data. If the CPU utilization rate is less than the first utilization rate threshold and the memory utilization rate is not less than the first utilization rate threshold, then the dynamic block parameter is determined to be the second ticket data quantity. If the CPU utilization rate is not less than the first utilization rate threshold and the memory utilization rate is less than the first utilization rate threshold, then the dynamic block parameter is determined to be the second ticket data quantity. If the CPU utilization rate is not less than the first utilization rate threshold and the memory utilization rate is not less than the first utilization rate threshold, then the dynamic block parameter is determined to be the third ticket data quantity. The number of first-issue data is greater than the number of second-issue data, and the number of second-issue data is greater than the number of third-issue data.
[0033] In this embodiment, the priority identifier includes a high priority identifier and a low priority identifier; Based on dynamic partitioning parameters and the priority of each data point, multiple data points are partitioned into blocks, resulting in multiple blocks labeled with priority identifiers, including: Get the generation timestamp of each invoice data; Arrange all high-priority bill data in descending order of generation timestamp to obtain the high-priority bill sequence. Arrange all the low-priority bill data in descending order of their generation timestamps to obtain the low-priority bill sequence. Based on the dynamic block division parameters, multiple bill blocks marked with high priority and multiple bill blocks marked with low priority are obtained for high priority bill sequences and low priority bill sequences, respectively.
[0034] In this embodiment, the load data sequence refers to a continuous set of data collected in real time reflecting the system resource occupancy status, used to dynamically adjust the block partitioning strategy. CPU utilization rate refers to the proportion of central processing unit resource usage, characterizing the busy level of computing resources. Memory utilization rate refers to the proportion of memory resource usage, characterizing the busy level of storage resources. Dynamic block partitioning parameters refer to the number of ticket data contained in a single ticket block, dynamically determined based on the system load. The first utilization rate threshold refers to the critical value for determining high CPU or memory load. The second utilization rate threshold refers to the critical value for determining low memory load.
[0035] The first number of bill data points refers to the number of bills in a single bill block under low load. The second number of bill data points refers to the number of bills in a single bill block under medium load. The third number of bill data points refers to the number of bills in a single bill block under high load. The priority identifier indicates the priority of the bill block. The high-priority identifier refers to the identifier of the corresponding high-priority bill block. The low-priority identifier refers to the identifier of the corresponding low-priority bill block. The generation timestamp refers to the timestamp when the bill data was generated, used for sorting. The high-priority bill sequence refers to the set of high-priority bills sorted by their generation timestamps. The low-priority bill sequence refers to the set of low-priority bills sorted by their generation timestamps.
[0036] Considering the need to balance system load and data order in large-volume invoice segmentation, CPU utilization and memory usage directly reflect the system's resource carrying capacity. Setting segmentation parameters according to different load combinations can avoid resource overload or waste caused by fixed segmentation. Sorting segments by generation timestamp ensures the temporal consistency of data within segments of the same priority, facilitating subsequent merging and reconciliation. Differentiating between high and low priority sequences for segmentation avoids mixing of invoices of different priorities, laying the foundation for subsequent differentiated scheduling. By setting a tiered segmentation number, a dynamic balance between load and segmentation efficiency is achieved, ensuring stable system operation while improving processing efficiency.
[0037] For example, this embodiment can be applied to the provincial-level electronic fiscal invoice management system, and the specific steps are as follows: (1) The system presets the parameter thresholds, the first occupancy rate threshold is set to 60%, the second occupancy rate threshold is set to 60%, the first ticket data quantity is set to 500, the second ticket data quantity is set to 200, and the third ticket data quantity is set to 100, to ensure that the first ticket data quantity is greater than the second ticket data quantity, and the second ticket data quantity is greater than the third ticket data quantity.
[0038] (2) The system collects CPU usage and memory usage in real time through the resource monitoring module to form a load data sequence. The collection frequency is once every 5 seconds, and 10 consecutive collections are used to form an effective load data sequence.
[0039] (3) Determine the dynamic block parameters based on the load data sequence: If the load data sequence shows that the CPU utilization rate is 55% less than the first utilization rate threshold and the memory utilization rate is 52% less than the second utilization rate threshold, then the dynamic block parameters are set to the first ticket data quantity of 500; if the CPU utilization rate is 58% less than the first utilization rate threshold and the memory utilization rate is 62% not less than the first utilization rate threshold, then the dynamic block parameters are set to the second ticket data quantity of 200; if the CPU utilization rate is 63% not less than the first utilization rate threshold and the memory utilization rate is 57% less than the first utilization rate threshold, then the dynamic block parameters are set to the second ticket data quantity of 200; if the CPU utilization rate is 65% not less than the first utilization rate threshold and the memory utilization rate is 64% not less than the first utilization rate threshold, then the dynamic block parameters are set to the third ticket data quantity of 100.
[0040] (4) Obtain all priority-determined ticket data, extract the generation timestamp of each ticket data, and ensure the uniqueness of the time sequence by making the generation timestamp accurate to the second.
[0041] (5) Sort by priority of bills: Arrange all high priority bill data in descending order of generation timestamp, that is, the latest generated bill is placed first, forming a high priority bill sequence; arrange all low priority bill data in descending order of generation timestamp, forming a low priority bill sequence.
[0042] (6) Perform block operation: Based on the determined dynamic block parameters, the high-priority ticket sequence is split. If the dynamic block parameter is 500, then every 500 ticket data forms a ticket block, and each block is marked with a high-priority identifier. The low-priority ticket sequence is split according to the same dynamic block parameters, and each block is marked with a low-priority identifier. Finally, multiple ticket blocks marked with high-priority or low-priority identifiers are obtained, and the block process is completed.
[0043] This embodiment dynamically adjusts the block segmentation parameters based on the load data sequence, adapting the block segmentation strategy to the system resource status. This avoids system lag caused by excessively large blocks under high load and maximizes block segmentation efficiency under low load, thereby improving overall processing capacity. Blocks are sorted by generation timestamp to ensure the temporal consistency of data within blocks of the same priority, preventing block misalignment. Priority sequences are differentiated for block segmentation and labeled, providing a clear basis for subsequent differentiated scheduling and ensuring that high-priority blocks are processed first, comprehensively balancing system stability, data orderliness, and business timeliness.
[0044] S103: For each ticket block, if the priority of the ticket block is marked as high priority, then the ticket block is entered into the first packing queue; if the priority of the ticket block is marked as low priority, then the ticket block is entered into the second packing queue.
[0045] In this embodiment, the first packaging queue refers to a task queue specifically for carrying high-priority marked ticket blocks, used for centralized management of the subsequent processing of high-priority ticket blocks. The second packaging queue refers to a task queue specifically for carrying low-priority marked ticket blocks, used for centralized management of the subsequent processing of low-priority ticket blocks. Both serve as buffers and scheduling carriers for ticket block processing, achieving physical isolation between ticket blocks of different priorities.
[0046] Considering that the priority of a ticket block is directly related to the urgency of the business, mixing and processing ticket blocks of different priorities can easily lead to low-priority ticket blocks consuming resources and blocking high-priority ticket blocks, causing delays in urgent business. By setting up two independent packaging queues to store high and low priority ticket blocks separately, physical isolation management can be achieved, avoiding priority confusion. At the same time, independent queues provide clear management boundaries for subsequent differentiated scheduling, making it easier for the system to accurately identify and prioritize high-priority queue tasks, ensuring the timeliness of urgent business while also ensuring the orderly processing of routine business.
[0047] For example, this embodiment can be applied to a municipal-level government non-tax revenue invoice processing platform, and the specific steps are as follows: After the system completes the ticket segmentation, it generates multiple ticket blocks marked with high or low priority identifiers. Each ticket block carries complete priority identifier information and segmentation attribute data. The system initiates a queue allocation detection program to read the priority identifier field of each ticket block one by one and classify the ticket blocks. If a ticket block is detected as having a high priority identifier, such as the ticket block corresponding to medical emergency payment, the system automatically calls the queue write interface to store the ticket block into the first packaging queue in the order of generation, while recording the storage time and ticket block number for subsequent traceability.
[0048] If a ticket block is detected as having a low priority, such as a ticket block corresponding to a routine administrative fee filing, the system stores it in a second packaging queue through the same interface, recording the storage information to ensure auditable queue data. After a ticket block is stored in its corresponding queue, the system updates the number of pending tasks in both queues in real time and displays it on the background monitoring interface, allowing maintenance personnel to easily monitor the queue status and ensure that high-priority queues are free from backlog and congestion, while low-priority queues are queued in an orderly manner.
[0049] S104: Perform sequential scheduling of the ticket blocks in the first and second packing queues; generate a unique block identifier for each scheduled ticket block, and generate a sequential index for each ticket data in the ticket block to obtain the target ticket block.
[0050] In this embodiment, sequential scheduling of ticket blocks in the first and second packing queues includes: If there are no ticket blocks in the first packing queue, the ticket blocks in the second packing queue will be scheduled sequentially using available resources; If there are ticket blocks in the first packaging queue and the number of ticket blocks in the second packaging queue is not greater than the target number of ticket blocks threshold, then the ticket blocks in the first packaging queue are scheduled sequentially using available resources. If there are ticket blocks in the first packaging queue and the number of ticket blocks in the second packaging queue is greater than the target ticket block quantity threshold, then the available resources are divided into the first resource and the second resource. The ticket blocks in the first packaging queue are scheduled sequentially through the first resource, and the ticket blocks in the first packaging queue are scheduled sequentially through the second resource until the first packaging queue is empty and / or the number of ticket blocks in the second packaging queue is not greater than the target ticket block quantity threshold.
[0051] In this embodiment, sequential scheduling refers to a scheduling method that processes ticket blocks in the queue sequentially according to preset rules, ensuring an orderly processing flow. Available resources refer to the total amount of CPU, network bandwidth, and other resources currently available for ticket block scheduling. The target ticket block quantity threshold refers to the critical number of ticket blocks required to determine whether the second packaging queue is backlogged. First resources refer to the portion of available resources used for scheduling the first packaging queue after partitioning. Second resources refer to the portion of available resources used for scheduling the second packaging queue after partitioning. A unique block identifier refers to a unique identifier assigned to each scheduled ticket block, used to distinguish different ticket blocks. A sequential index refers to an ordered identifier assigned to each piece of ticket data within a ticket block, used to determine the order of tickets within the block. The target ticket block refers to the ticket block after scheduling, generating a unique block identifier, and a sequential index.
[0052] Considering that scheduling needs to balance the timeliness of high-priority business with the fairness of low-priority business processing, the first packaging queue corresponds to urgent ticket blocks and must be given priority in scheduling to avoid delays in urgent business. However, if the second packaging queue is backlogged for a long time, it will affect the flow of regular business. Setting a target threshold for the number of ticket blocks can accurately determine the backlog status of the second queue. When the threshold is exceeded, available resources are split and scheduled in parallel, which does not affect the priority processing of the first queue and can alleviate the backlog of the second queue. Generating a unique block identifier and sequence index is to ensure the traceability and orderliness of the ticket blocks and their internal data after scheduling, laying the foundation for subsequent packaging and verification.
[0053] For example, this embodiment can be applied to a provincial-level electronic fiscal invoice dispatch system, and the specific steps are as follows: The system presets a target threshold of 1500 ticket blocks, and simultaneously monitors the number of ticket blocks in the first and second packing queues in real time, as well as the status of available system resources, including CPU availability and network bandwidth availability.
[0054] If the first packaging queue is empty and there are no high-priority ticket blocks to be processed, all available resources will be allocated to the second packaging queue and scheduled in the order in which the ticket blocks were enqueued, ensuring that low-priority routine business is processed in an orderly manner.
[0055] If there are ticket blocks in the first packaging queue, and the number of ticket blocks in the second packaging queue is 1200, which is not greater than the target ticket block number threshold, then all available resources will be allocated to the first packaging queue, and the ticket blocks will be scheduled one by one in the order they were enqueued, with priority given to urgent business, and the scheduling of the second packaging queue will be suspended.
[0056] If the first packaging queue contains ticket blocks, and the second packaging queue contains 1800 ticket blocks, exceeding the target ticket block count threshold, then the available resources are divided into the first resource and the second resource at a ratio of 85% and 15%, respectively. Ticket blocks in the first packaging queue are scheduled in enqueue order using the first resource, while ticket blocks in the second packaging queue are scheduled in enqueue order using the second resource, thus parallel processing to avoid excessive backlog in the second queue.
[0057] During the scheduling process, the queue status is monitored in real time. If the first packaging queue is empty or the number of ticket blocks in the second packaging queue drops below 1500, the parallel scheduling is terminated and the single queue scheduling logic is returned. At the same time, a unique block identifier is generated for each ticket block in the scheduling, and a sequential index is generated for each ticket data in the block in order, and finally the target ticket block is obtained.
[0058] This embodiment employs a hierarchical scheduling logic to ensure that high-priority ticket blocks in the first packaging queue are processed first, guaranteeing the timeliness of urgent business. Setting a target ticket block quantity threshold and a resource splitting mechanism effectively prevents long-term backlog in the second packaging queue while maintaining fairness in processing routine business. Generating unique block identifiers and sequential indexes ensures the orderliness and traceability of ticket blocks and their internal data, providing support for subsequent packaging and verification, and comprehensively improving the rationality, efficiency, and reliability of scheduling.
[0059] S105: Pack and verify the target ticket block, and transmit all the packaged ticket blocks that pass the verification.
[0060] In this embodiment, the target document block is packaged and verified, including: Extract the priority identifier, unique block identifier, and sequential index of all bill data of the target bill block, and associate the block identifier, sequential index, and corresponding extended nodes of the bill data for storage; The associated target bill block data is encapsulated, and the encapsulation content includes the bill block header, the bill data body, and the packaging tail. The bill block header includes a priority identifier, a block identifier, the total number of bills in the block, and a packaging timestamp. The bill data body includes bill data with a sequential index, and the packaging tail includes a reserved verification field. The packaged unit is signed, and the main body of the ticket data in the packaged target ticket block is encrypted using a digital envelope encryption method; Calculate the hash verification value of the encrypted target ticket block, write the hash verification value into the reserved verification field at the end of the package, and obtain the packaged ticket block; Perform sequential consistency verification, data integrity verification, and hash integrity verification on the packaged ticket blocks.
[0061] In this embodiment, the extended node refers to a reserved data node in the ticket data used to attach associated information, storing block identifiers and sequential indexes. The packaging unit refers to the entire encapsulated target ticket block, which is the basic unit of packaging processing. The ticket block header refers to the beginning of the packaging unit, carrying core identifiers and basic information. The ticket data body refers to the portion of the packaging unit containing the core ticket information. The packaging tail refers to the end of the packaging unit, carrying verification-related information. The reserved verification field refers to a pre-set field at the packaging tail used to store verification data. The packaging timestamp refers to the system timestamp when the packaging operation is completed, used to record the packaging sequence.
[0062] A signature refers to the operation of authenticating the packaged unit, ensuring the trustworthiness of the data source. Digital envelope encryption refers to a hybrid encryption method combining symmetric and asymmetric encryption to ensure secure data transmission. A hash checksum is a value calculated using a hash algorithm to verify data integrity. Sequence consistency verification refers to the verification method that confirms the order of the document data matches the index. Data integrity verification refers to the verification method that confirms the document data is free of missing or abnormal data. Hash integrity verification refers to the verification method that verifies the data has not been tampered with by comparing hash values.
[0063] Considering that packaging and verification are critical steps in the transmission of invoice data, standardization, security, and reliability must be balanced. Associating storage block identifiers and sequential indexes ensures a strong binding between invoice data and block information, providing a basis for subsequent traceability. A standardized packaging format adapts to the transmission specifications of the financial system, avoiding format incompatibility issues. The combination of signature and digital envelope encryption ensures both data traceability and prevents theft during transmission. The combination of hash checksums and multiple verification mechanisms comprehensively prevents risks of out-of-order transmission, missing data, and tampering, meeting the stringent requirements of financial invoices for data accuracy and security, ensuring that the packaged data can be transmitted and used securely and reliably.
[0064] For example, this embodiment can be applied to a provincial-level electronic fiscal invoice transmission system, and the specific steps are as follows: The system extracts the priority identifier (high priority), unique block identifier, and sequential index of all bill data from the target bill block. It then uses a data association tool to write the block identifier and sequential index into the extension node of the corresponding bill data, thereby achieving strong information binding.
[0065] Initiate a standardized encapsulation process to generate packaged units. The header of the ticket block includes a priority identifier (high priority), a block identifier, the total number of tickets within the block, and a packaging timestamp; the ticket data body contains 500 ticket data entries with sequential indexes; a hash verification field is reserved at the end of the package to complete the encapsulation.
[0066] The SM2 algorithm is used to sign the packaged units, ensuring data traceability. Simultaneously, a digital envelope encryption method is employed, encrypting the main body of the ticket data with a randomly generated symmetric key, and then encrypting the symmetric key with the recipient's public key to guarantee data transmission security. The hash checksum of the encrypted packaged unit is calculated based on the SM3 algorithm, and this value is written to a reserved checksum field at the end of the package, forming a complete packaged ticket block.
[0067] Perform multiple checks: Sequential consistency check compares whether the sequential index is consistent with the ticket generation time sequence; Data integrity check counts whether the actual number of tickets matches the total number of header annotations and verifies whether the core fields are complete; Hash integrity check recalculates the hash value and compares it with the reserved field value to ensure that the checks fully cover key risk points.
[0068] This embodiment ensures the traceability of invoice data and segmented information through associated storage and standardized encapsulation, adapting to the transmission specifications of the fiscal system. The combination of signature and digital envelope encryption comprehensively guarantees the security and source credibility of data transmission. Hash checksums and multiple verification mechanisms work together to effectively prevent issues such as disordered order, missing data, and tampering, ensuring the accuracy and integrity of packaged data. The overall process balances standardization, security, and reliability, meeting the stringent requirements for fiscal invoice transmission, improving data transmission quality, reducing rework, and providing strong support for the orderly flow of fiscal business.
[0069] As can be seen from the above, this embodiment can effectively solve the core problems of low efficiency and disordered sorting of large batches of invoices in the prior art, while taking into account both processing efficiency and data accuracy, and adapting to the actual needs of financial business and public services.
[0070] On the one hand, addressing the shortcomings of existing methods in handling large volumes of data, such as lag and low efficiency, this embodiment solves the problem through dynamic block partitioning and priority scheduling. This embodiment determines dynamic block partitioning parameters based on system load data, flexibly adjusting the number of tickets in a single ticket block according to system activity levels, avoiding resource overload caused by fixed block partitioning and reducing system lag at its source. Simultaneously, this embodiment distinguishes between high and low priority ticket blocks using dual packaging queues, prioritizing urgent tickets and preventing congestion of urgent transactions by regular tickets, significantly improving overall packaging and processing efficiency and ensuring timely processing of urgent transactions such as medical payments.
[0071] On the other hand, addressing the shortcomings of existing methods that suffer from disordered invoice sorting, this embodiment generates a unique block identifier for each scheduled invoice block and configures a sequential index for each invoice data. During merging and packaging, invoices can be precisely sorted by number, completely avoiding disordered invoice order, ensuring the accuracy of subsequent reconciliation and archiving work, and reducing business rework caused by data errors. The post-packaging verification step further investigates data problems, ensuring the integrity and reliability of transmitted invoice data, and comprehensively improving the accuracy and stability of non-tax invoice packaging.
[0072] Corresponding to the non-tax invoice packaging method in the above embodiment, Figure 2 This is a structural block diagram of a non-tax invoice packaging device provided according to an embodiment of this application. For ease of explanation, only the parts relevant to the embodiment of this application are shown. References Figure 2 The non-tax invoice packaging device 20 includes: an invoice priority division module 21, an invoice block division module 22, a dual queue module 23, an invoice block scheduling module 24, and an invoice block packaging module 25.
[0073] Among them, the bill priority division module 21 is used to acquire multiple bill data and determine the bill priority of each bill data; The bill segmentation module 22 is used to obtain the load data sequence, determine the dynamic segmentation parameters based on the load data sequence, and segment multiple bill data into blocks based on the dynamic segmentation parameters and the bill priority of each bill data to obtain multiple bill blocks marked with priority identifiers. The dual-queue module 23 is used to input each ticket block into the first packing queue if the priority of the ticket block is marked as high priority, and into the second packing queue if the priority of the ticket block is marked as low priority. The ticket block scheduling module 24 is used to sequentially schedule ticket blocks in the first packaging queue and the second packaging queue; it generates a unique block identifier for each scheduled ticket block and generates a sequential index for each ticket data in the ticket block to obtain the target ticket block; The ticket block packaging module 25 is used to package and verify the target ticket block, and to transmit all packaged ticket blocks that pass verification.
[0074] In one embodiment of this application, the bill priority division module 21 is specifically used to extract the business type field and the payment deadline field from each bill data, and determine the bill priority of the bill data based on the business type field and the payment deadline field.
[0075] In one embodiment of this application, the ticket priority allocation module 21 is further used for: Perform keyword matching on the business type field to obtain the matching degree; Convert the payment deadline field to timestamp format to obtain the payment deadline timestamp; calculate the timestamp difference between the payment deadline timestamp and the current timestamp; If the matching degree is greater than the first matching degree threshold and / or the timestamp difference is less than the first time threshold, then the ticket priority of the ticket data is determined to be high priority; If the matching degree is not greater than the first matching degree threshold and the timestamp difference is not less than the first time threshold, then the ticket priority of the ticket data is determined to be low priority.
[0076] In one embodiment of this application, the load data sequence includes CPU utilization and memory usage; the ticket segmentation module 22 is specifically used for: If the CPU utilization rate is less than the first utilization rate threshold and the memory utilization rate is less than the second utilization rate threshold, then the dynamic block parameter is determined to be the number of first ticket data. If the CPU utilization rate is less than the first utilization rate threshold and the memory utilization rate is not less than the first utilization rate threshold, then the dynamic block parameter is determined to be the second ticket data quantity. If the CPU utilization rate is not less than the first utilization rate threshold and the memory utilization rate is less than the first utilization rate threshold, then the dynamic block parameter is determined to be the second ticket data quantity. If the CPU utilization rate is not less than the first utilization rate threshold and the memory utilization rate is not less than the first utilization rate threshold, then the dynamic block parameter is determined to be the third ticket data quantity. The number of first-issue data is greater than the number of second-issue data, and the number of second-issue data is greater than the number of third-issue data.
[0077] In one embodiment of this application, the priority identifier includes a high-priority identifier and a low-priority identifier; the ticket segmentation module 22 is further used for: Get the generation timestamp of each invoice data; Arrange all high-priority bill data in descending order of generation timestamp to obtain the high-priority bill sequence. Arrange all the low-priority bill data in descending order of their generation timestamps to obtain the low-priority bill sequence. Based on the dynamic block division parameters, multiple bill blocks marked with high priority and multiple bill blocks marked with low priority are obtained for high priority bill sequences and low priority bill sequences, respectively.
[0078] In one embodiment of this application, the ticket block scheduling module 24 is specifically used for: If there are no ticket blocks in the first packing queue, the ticket blocks in the second packing queue will be scheduled sequentially using available resources; If there are ticket blocks in the first packaging queue and the number of ticket blocks in the second packaging queue is not greater than the target number of ticket blocks threshold, then the ticket blocks in the first packaging queue are scheduled sequentially using available resources. If there are ticket blocks in the first packaging queue and the number of ticket blocks in the second packaging queue is greater than the target ticket block quantity threshold, then the available resources are divided into the first resource and the second resource. The ticket blocks in the first packaging queue are scheduled sequentially through the first resource, and the ticket blocks in the first packaging queue are scheduled sequentially through the second resource until the first packaging queue is empty and / or the number of ticket blocks in the second packaging queue is not greater than the target ticket block quantity threshold.
[0079] In one embodiment of this application, the ticket block packaging module 25 is specifically used for: Extract the priority identifier, unique block identifier, and sequential index of all bill data of the target bill block, and associate the block identifier, sequential index, and corresponding extended nodes of the bill data for storage; The associated target bill block data is encapsulated, and the encapsulation content includes the bill block header, the bill data body, and the packaging tail. The bill block header includes a priority identifier, a block identifier, the total number of bills in the block, and a packaging timestamp. The bill data body includes bill data with a sequential index, and the packaging tail includes a reserved verification field. The packaged unit is signed, and the main body of the ticket data in the packaged target ticket block is encrypted using a digital envelope encryption method; Calculate the hash verification value of the encrypted target ticket block, write the hash verification value into the reserved verification field at the end of the package, and obtain the packaged ticket block; Perform sequential consistency verification, data integrity verification, and hash integrity verification on the packaged ticket blocks.
[0080] See Figure 3 , Figure 3 This is a schematic block diagram of an electronic device provided according to an embodiment of this application. Figure 3The electronic device 300 in this embodiment may include one or more processors 301, one or more input devices 302, one or more output devices 303, and one or more memories 304. The processors 301, input devices 302, output devices 303, and memories 304 communicate with each other via a communication bus 305. The memories 304 store computer programs, including program instructions. The processors 301 execute the program instructions stored in the memories 304. Specifically, the processors 301 are configured to invoke the program instructions to perform the functions of the modules in the aforementioned device embodiments, for example... Figure 2 The functions of the ticket priority division module 21, ticket block division module 22, dual queue module 23, ticket block scheduling module 24, and ticket block packaging module 25 are shown.
[0081] It should be understood that, in the embodiments of this application, the processor 301 may be a central processing unit (CPU), but it may also be 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 may be a microprocessor or any conventional processor.
[0082] Input device 302 may include a touchpad, a fingerprint sensor (for collecting the user's fingerprint information and fingerprint orientation information), a microphone, etc., and output device 303 may include a display (LCD, etc.), a speaker, etc.
[0083] The memory 304 may include read-only memory and random access memory, and provides instructions and data to the processor 301. A portion of the memory 304 may also include non-volatile random access memory. For example, the memory 304 may also store information about non-tax invoices.
[0084] In specific implementations, the processor 301, input device 302, and output device 303 described in the embodiments of this application can execute the implementation methods described in the embodiments of the non-tax invoice packaging method provided in the embodiments of this application, or they can execute the implementation methods of the electronic device 300 described in the embodiments of this application, which will not be repeated here.
[0085] In another embodiment of this application, a computer-readable storage medium is provided. This computer-readable storage medium stores a computer program, which includes program instructions. When executed by a processor, the program instructions implement all or part of the processes in the methods described above. Alternatively, the computer program can instruct related hardware to complete the process. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.
[0086] The computer-readable storage medium can be an internal storage unit of the electronic device in any of the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, etc., equipped on the electronic device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the electronic device. The computer-readable storage medium is used to store computer programs and other programs and data required by the electronic device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.
[0087] Those skilled in the art will recognize that the modules / units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.
[0088] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the electronic devices and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0089] In the several embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules, units, or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces or modules / units, or it may be an electrical, mechanical, or other form of connection.
[0090] The modules / units described as separate components may or may not be physically separate. Similarly, the components shown as modules / units may or may not be physical modules / units; they may be located in one place or distributed across multiple network modules / units. Some or all of the modules / units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.
[0091] Furthermore, the functional modules / units in the various embodiments of this application can be integrated into one processing module / unit, or each module / unit can exist physically separately, or two or more modules / units can be integrated into one module / unit. The integrated modules / units described above can be implemented in hardware or in the form of software functional modules / units.
[0092] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for packaging non-tax invoices, characterized in that, include: Acquire multiple invoice data and determine the invoice priority of each invoice data; Obtain the load data sequence, and determine the dynamic block parameters based on the load data sequence; Based on the dynamic block division parameters and the priority of each bill data, the multiple bill data are divided into blocks to obtain multiple bill blocks marked with priority identifiers; For each ticket block, if the priority of the ticket block is marked as high priority, the ticket block is entered into the first packing queue; if the priority of the ticket block is marked as low priority, the ticket block is entered into the second packing queue. The ticket blocks in the first packaging queue and the second packaging queue are sequentially scheduled; a unique block identifier is generated for each scheduled ticket block, and a sequential index is generated for each ticket data in the ticket block to obtain the target ticket block; The target ticket block is packaged and verified, and all packaged ticket blocks that pass verification are transmitted.
2. The method for packaging non-tax invoices as described in claim 1, characterized in that, Determining the ticket priority for each of the ticket data includes: For each of the bill data, the business type field and the payment deadline field are extracted from the bill data, and the bill priority of the bill data is determined based on the business type field and the payment deadline field.
3. The method for packaging non-tax invoices as described in claim 2, characterized in that, Determining the bill priority based on the business type field and the payment deadline field includes: Perform keyword matching on the business type field to obtain the matching degree; The payment deadline field is converted into a timestamp format to obtain the payment deadline timestamp; the timestamp difference between the payment deadline timestamp and the current timestamp is calculated. If the matching degree is greater than the first matching degree threshold and / or the timestamp difference is less than the first time threshold, then the ticket priority of the ticket data is determined to be high priority; If the matching degree is not greater than the first matching degree threshold and the timestamp difference is not less than the first time threshold, then the ticket priority of the ticket data is determined to be low priority.
4. The method for packaging non-tax invoices as described in claim 1, characterized in that, The load data sequence includes CPU utilization and memory usage. The determination of dynamic block parameters based on the load data sequence includes: If the CPU utilization rate is less than the first utilization rate threshold and the memory utilization rate is less than the second utilization rate threshold, then the dynamic block parameter is determined to be the number of first ticket data. If the CPU utilization rate is less than the first utilization rate threshold and the memory utilization rate is not less than the first utilization rate threshold, then the dynamic block parameter is determined to be the second ticket data quantity. If the CPU utilization rate is not less than the first utilization rate threshold and the memory utilization rate is less than the first utilization rate threshold, then the dynamic block parameter is determined to be the second ticket data quantity. If the CPU utilization rate is not less than the first utilization rate threshold and the memory utilization rate is not less than the first utilization rate threshold, then the dynamic block parameter is determined to be the number of third ticket data. The number of the first invoice data is greater than the number of the second invoice data, and the number of the second invoice data is greater than the number of the third invoice data.
5. The method for packaging non-tax invoices as described in claim 1, characterized in that, The priority identifier includes a high priority identifier and a low priority identifier; The process of dividing the multiple bill data into blocks based on the dynamic block division parameters and the bill priority of each bill data to obtain multiple bill blocks marked with priority identifiers includes: Get the generation timestamp of each invoice data; Arrange all high-priority bill data in descending order of generation timestamp to obtain the high-priority bill sequence. Arrange all the low-priority bill data in descending order of their generation timestamps to obtain the low-priority bill sequence. Based on the dynamic block division parameters, multiple bill blocks marked with high priority and multiple bill blocks marked with low priority are obtained from the high priority bill sequence and the low priority bill sequence, respectively.
6. The method for packaging non-tax invoices as described in claim 1, characterized in that, The sequential scheduling of ticket blocks in the first packaging queue and the second packaging queue includes: If the first packing queue does not have any ticket blocks, then the ticket blocks in the second packing queue are scheduled sequentially using available resources; If there are ticket blocks in the first packaging queue and the number of ticket blocks in the second packaging queue is not greater than the target number of ticket blocks threshold, then the ticket blocks in the first packaging queue are scheduled sequentially using available resources. If there are ticket blocks in the first packaging queue and the number of ticket blocks in the second packaging queue is greater than the target ticket block quantity threshold, then the available resources are divided into a first resource and a second resource; the ticket blocks in the first packaging queue are sequentially scheduled using the first resource, and the ticket blocks in the first packaging queue are sequentially scheduled using the second resource, until the first packaging queue is empty and / or the number of ticket blocks in the second packaging queue is not greater than the target ticket block quantity threshold.
7. The method for packaging non-tax invoices as described in claim 1, characterized in that, The process of packaging and verifying the target ticket block includes: Extract the priority identifier, unique block identifier, and sequential index of all bill data of the target bill block, and associate and store the block identifier, sequential index, and corresponding extended nodes of the bill data. The associated target bill block data is encapsulated, and the encapsulation content includes a bill block header, a bill data body, and a packaging tail. The bill block header includes a priority identifier, a block identifier, the total number of bills in the block, and a packaging timestamp. The bill data body includes bill data carrying a sequential index, and the packaging tail includes a reserved verification field. The packaged unit is signed, and the main body of the ticket data in the packaged target ticket block is encrypted using a digital envelope encryption method; Calculate the hash verification value of the encrypted target ticket block, and write the hash verification value into the reserved verification field at the end of the package to obtain the packaged ticket block; Perform sequential consistency verification, data integrity verification, and hash integrity verification on the packaged ticket blocks.
8. A non-tax invoice packaging device, characterized in that, include: The bill priority division module is used to acquire multiple bill data and determine the bill priority of each bill data. The bill segmentation module is used to acquire the load data sequence and determine the dynamic segmentation parameters based on the load data sequence. Based on the dynamic block division parameters and the priority of each bill data, the multiple bill data are divided into blocks to obtain multiple bill blocks marked with priority identifiers; The dual-queue module is used to input each ticket block into the first packing queue if the priority of the ticket block is marked as high priority, and into the second packing queue if the priority of the ticket block is marked as low priority. The ticket block scheduling module is used to sequentially schedule ticket blocks in the first packaging queue and the second packaging queue; generate a unique block identifier for each scheduled ticket block, and generate a sequential index for each ticket data in the ticket block to obtain the target ticket block; The ticket block packaging module is used to package and verify the target ticket block, and to transmit all packaged ticket blocks that pass verification.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.