A method and system for quickly sorting different specifications of instant tickets

Abstract

The application relates to the technical field of data processing, and discloses a quick sorting method and system for instant invoice of different specifications, which comprises the following steps: determining an order type based on order information, locking target inventory based on the order type, and triggering a three-way locking mechanism; horizontally and vertically counting the target inventory and performing inventory lending processing; screening the ticket state of the target inventory, and filtering out the to-be-sorted tickets with the ticket state of 'locked' and 'problem ticket' from the target inventory; detecting the allocation specification of the order information, and triggering the box opening logic if the allocation specification is the same; and sorting the target inventory based on the order information. Through specification level association and dynamic lending, the application solves the problems of insufficient sorting specification accuracy, low efficiency caused by separate database and table, large artificial checking workload, and delayed real-time data statistics in instant invoice sorting.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a method and system for rapid sorting of instant invoices of different specifications. Background Technology

[0002] Instant ticketing involves complex scenarios and massive amounts of data, with cumbersome allocation processes and varying business needs across different provinces. Currently, the allocation function in the business system covers 55 business scenarios, primarily categorized into hierarchical allocation and direct allocation, supporting a mixed allocation model for boxes and books. Related technologies have implemented functions such as order placement, sorting, allocation, warehousing, station entry, and integration with courier companies. It also provides branch owners with management functions including channels, funds, reconciliation, account adjustments, and reports. A centralized database combined with a sharded database and read / write separation approach is used to handle massive amounts of data, supporting allocation by "box" and "book" specifications. Allocation by "book" allows for precise allocation of specific book numbers, while allocation by "box" or mixed specifications requires calculating the number of boxes based on the issuance base data. Sorting data statistics utilize near real-time queries, and business data is synchronized to a read-only database using technical components, with customized indexes optimizing query speed.

[0003] However, the relevant solutions have significant shortcomings. On the one hand, sorting can only be accurately allocated according to the "book" specification; when allocated by "box" or mixed specifications, it cannot pinpoint the specific box number. Furthermore, the separate database and table design requires additional location of the invoice table during sorting, reducing efficiency. Additionally, the workload of manually verifying box numbers and transferring ownership at the provincial center is substantial. On the other hand, real-time data statistics suffer from time delays, failing to simultaneously meet the needs of online transaction processing and online analytical processing, resulting in inconsistent business operations and a less user-friendly interface. In summary, the relevant technologies for instant invoice sorting suffer from insufficient sorting specification accuracy, low efficiency due to separate database and table design, a large workload for manual verification, and delays in real-time data statistics. Summary of the Invention

[0004] In view of this, the present invention provides a method and system for rapid sorting of instant invoices of different specifications, in order to solve the problems of insufficient sorting specification accuracy, low efficiency caused by separate databases and tables, large workload of manual verification, and delay in real-time data statistics in related technologies for instant invoice sorting.

[0005] Firstly, this invention provides a method for rapid sorting of instant invoices of different specifications. The method includes: receiving order information through a distributed database; determining the order type based on the order information; locking the target inventory based on the order type and triggering a triple-lock mechanism; performing horizontal and vertical statistics on the target inventory based on the order information to obtain statistical results; performing inventory borrowing processing based on the statistical results to update the target inventory; filtering the invoice status of the target inventory, removing invoices with statuses of "locked" and "problem invoices" from the target inventory; detecting the transfer specifications in the order information; if the transfer specifications are the same, triggering unpacking logic to unpack the target inventory; and sorting the target inventory based on the order information to generate inbound / outbound records and an inventory snapshot.

[0006] This embodiment provides a rapid sorting method for instant invoices of different specifications. It receives order information from a distributed database and locks target inventory based on order type. Simultaneously, it triggers a triple-locking mechanism of distributed locks, optimistic locks, and database locks. Real-time read / write separation replaces the original quasi-real-time synchronization, solving the problem of low cross-database query efficiency caused by database sharding and ensuring the atomicity and consistency of inventory locking in high-concurrency scenarios. Target inventory is statistically analyzed horizontally by specification and vertically by game, batch, and status. When a smaller specification is insufficient, it borrows from a higher specification and records it independently. Through specification hierarchy association and dynamic borrowing, it achieves linked statistics for box-by-box specifications, solving the error problem of calculating the number of boxes required for allocation in the original solution, ensuring consistency between system inventory and physical quantity. The method filters the ticket status of the target inventory, removing "locked" and "problem tickets" from the data to be sorted. A composite index quickly locates valid status tickets, reducing invalid data traversal and lowering the workload of manual verification of non-allocation tickets at the provincial center, thus improving sorting efficiency. Finally, it detects the order allocation specification; if it is "book,"... The system automatically determines the status of the box and triggers unpacking, breaking the entire box into individual, unrecoverable records. The unpacking log records the specification conversion process, solving the problem of the original solution's inaccuracy to the last item and achieving refined management of ownership transfer. Based on order information, the system sorts target inventory, generating real-time inbound and outbound records containing warehouse number, specifications, and quantity. A snapshot module generates daily inventory snapshots containing the quantity and hash value of each specification. Through multi-dimensional data recording and snapshot queries, it supports phased traceability of inventory counts, solving the problem of data real-time latency and ensuring the continuity of business operations and data traceability. In summary, the rapid sorting method for different specifications of instant invoices provided in this embodiment comprehensively solves the problems of insufficient sorting specification accuracy, low efficiency due to database and table partitioning, large workload of manual verification, and delays in real-time data statistics in related technologies for instant invoice sorting.

[0007] In one optional implementation, the order types include orders placed by game and orders placed by batch. If an order is placed by game, the target inventory corresponding to the batch quantity of the game is randomly locked; if an order is placed by batch, the target inventory is locked according to the batch specified by the user.

[0008] In one alternative implementation, the triple locking mechanism includes a distributed lock, an optimistic lock, and a database lock, wherein: the distributed lock is used to lock the target inventory in cross-server concurrent scenarios; the optimistic lock is used to perform a version number verification mechanism; and the database lock is used to maintain data atomicity during unboxing operations.

[0009] In one optional implementation, the above-mentioned horizontal and vertical statistics of the target inventory based on order information are used to obtain statistical results. Based on the statistical results, inventory borrowing is performed to update the target inventory. This includes: performing layer-by-layer statistics on the target inventory according to the specifications of prize groups, sets, boxes, notebooks, and sheets to obtain horizontal statistical results; establishing an index on the target inventory according to the dimensions of game, batch, status, and quantity to obtain vertical statistical results; and determining whether the inventory of each specification level is sufficient based on order information. When the inventory of the current specification level is insufficient, it is borrowed from the next higher specification level and the borrowed quantity is recorded in an independent field.

[0010] In one optional implementation, the above-mentioned filtering of the ticket status of the target inventory to remove the tickets to be sorted with the status of "locked" and "problem ticket" from the target inventory includes: performing a composite index on the ticket status of the target inventory, filtering the tickets to be sorted with the status of "locked" and "problem ticket", and retaining the tickets to be sorted with the status of "normal", "in transit" and "sold".

[0011] In one optional implementation, the above-mentioned detection of the transfer specification of the order information, if the transfer specification is "book", triggers the unpacking logic to unpack the target inventory, including: detecting the transfer specification of the order information, if the transfer specification is "book", determining the box status of the book to be transferred, if the box status is a full box, then automatically unpacking, splitting the full box record into individual book records; updating the specification association relationship in the inventory table, and generating an unpacking log, recording the original box number, the split book number range, and the splitting time.

[0012] In one alternative implementation, after a full box of records is split into individual records, the individual records cannot be restored to a full box.

[0013] In one optional implementation, the above-mentioned sorting of target inventory based on order information to generate inbound / outbound records and inventory snapshots includes: sorting target inventory based on order information, recording warehouse number, ticket specifications, quantity and operation time, and generating inbound / outbound records; generating an inventory snapshot at a preset time, wherein the content of the inventory snapshot includes the generation time, warehouse number, game batch, inventory quantity of each specification and hash check value.

[0014] In an optional implementation, after sorting the target inventory based on order information, the method further includes: marking tickets that are actually unallocated as abnormal tickets and updating the ticket status index synchronously.

[0015] Secondly, this invention provides a rapid sorting system for instant invoices of different specifications. The system includes: a locking module, used to receive order information through a distributed database, determine the order type based on the order information, lock the target inventory based on the order type, and trigger a triple-locking mechanism; a statistics module, used to perform horizontal and vertical statistics on the target inventory based on the order information, obtain statistical results, perform inventory borrowing processing based on the statistical results, and update the target inventory; a filtering module, used to filter the ticket status of the target inventory, removing tickets with statuses of "locked" and "problem tickets" from the target inventory; an unpacking module, used to detect the transfer specifications in the order information, and if the transfer specifications are the same, trigger the unpacking logic to unpack the target inventory; and a sorting module, used to sort the target inventory based on the order information, generating inbound / outbound records and an inventory snapshot. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a rapid sorting method for instant invoices of different specifications according to an embodiment of the present invention.

[0018] Figure 2 This is a structural block diagram of a rapid sorting system for instant tickets of different specifications according to an embodiment of the present invention. Detailed Implementation

[0019] Instant ticketing involves complex scenarios and massive amounts of data, with cumbersome allocation processes and varying business needs across different provinces. Currently, the allocation function in the business system covers 55 business scenarios, primarily categorized into hierarchical allocation and direct allocation, supporting a mixed allocation model for boxes and books. Related technologies have implemented functions such as order placement, sorting, allocation, warehousing, station entry, and integration with courier companies. It also provides branch owners with management functions including channels, funds, reconciliation, account adjustments, and reports. A centralized database combined with a sharded database and read / write separation approach is used to handle massive amounts of data, supporting allocation by "box" and "book" specifications. Allocation by "book" allows for precise allocation of specific book numbers, while allocation by "box" or mixed specifications requires calculating the number of boxes based on the issuance base data. Sorting data statistics utilize near real-time queries, and business data is synchronized to a read-only database using technical components, with customized indexes optimizing query speed.

[0020] However, the relevant solutions have significant shortcomings. On the one hand, sorting can only be accurately allocated according to the "book" specification; when allocated by "box" or mixed specifications, it cannot pinpoint the specific box number. Furthermore, the separate database and table design requires additional location of the invoice table during sorting, reducing efficiency. Additionally, the workload of manually verifying box numbers and transferring ownership at the provincial center is substantial. On the other hand, real-time data statistics suffer from time delays, failing to simultaneously meet the needs of online transaction processing and online analytical processing, resulting in inconsistent business operations and a less user-friendly interface. In summary, the relevant technologies for instant invoice sorting suffer from insufficient sorting specification accuracy, low efficiency due to separate database and table design, a large workload for manual verification, and delays in real-time data statistics.

[0021] This embodiment provides a rapid sorting method for instant invoices of different specifications. It receives order information from a distributed database and locks target inventory based on order type. Simultaneously, it triggers a triple-locking mechanism of distributed locks, optimistic locks, and database locks. Real-time read / write separation replaces the original quasi-real-time synchronization, solving the problem of low cross-database query efficiency caused by database sharding and ensuring the atomicity and consistency of inventory locking in high-concurrency scenarios. Target inventory is statistically analyzed horizontally by specification and vertically by game, batch, and status. When a smaller specification is insufficient, it borrows from a higher specification and records it independently. Through specification hierarchy association and dynamic borrowing, it achieves linked statistics for box-by-box specifications, solving the error problem of calculating the number of boxes required for allocation in the original solution, ensuring consistency between system inventory and physical quantity. The method filters the ticket status of the target inventory, removing "locked" and "problem tickets" from the data to be sorted. A composite index quickly locates valid status tickets, reducing invalid data traversal and lowering the workload of manual verification of non-allocation tickets at the provincial center, thus improving sorting efficiency. Finally, it detects the order allocation specification; if it is "book,"... The system automatically determines the status of the box and triggers unpacking, breaking the entire box into individual, unrecoverable records. The unpacking log records the specification conversion process, solving the problem of the original solution's inaccuracy to the last item and achieving refined management of ownership transfer. Based on order information, the system sorts target inventory, generating real-time inbound and outbound records containing warehouse number, specifications, and quantity. A snapshot module generates daily inventory snapshots containing the quantity and hash value of each specification. Through multi-dimensional data recording and snapshot queries, it supports phased traceability of inventory counts, solving the problem of data real-time latency and ensuring the continuity of business operations and data traceability. In summary, the rapid sorting method for different specifications of instant invoices provided in this embodiment comprehensively solves the problems of insufficient sorting specification accuracy, low efficiency due to database and table partitioning, large workload of manual verification, and delays in real-time data statistics in related technologies for instant invoice sorting.

[0022] According to an embodiment of the present invention, a method for rapid sorting of instant invoices of different specifications is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0023] This embodiment provides a method for rapid sorting of instant invoices of different specifications. Figure 1 This is a flowchart of a rapid sorting method for instant invoices of different specifications according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps:

[0024] Step S1: Receive order information through a distributed database, determine the order type based on the order information, lock the target inventory based on the order type, and trigger a triple lock mechanism.

[0025] Specifically, the order types mentioned above include orders placed by game and orders placed by batch. If an order is placed by game, the target inventory for the corresponding game batch quantity is randomly locked; if an order is placed by batch, the target inventory is locked according to the batch specified by the user. The above triple-locking mechanism includes distributed locks, optimistic locks, and database locks, where: distributed locks are used to lock the target inventory in cross-server concurrent scenarios; optimistic locks are used to execute version number verification mechanisms; and database locks are used to maintain data atomicity during unboxing operations.

[0026] Furthermore, order information is received through a distributed database, and key data in the orders, including game identifiers, batch numbers, allocation specifications, and quantities, is parsed in real time. Based on this, the order type is automatically identified as either a game-based order or a batch-based order. The distributed database adopts a real-time read-write separation architecture, abandoning the traditional database sharding scheme. It can simultaneously support online transaction processing and online analytical processing, ensuring the efficiency of order information reception and parsing, and avoiding the additional overhead of cross-database queries caused by database sharding in the original solution. After determining the order type, the target inventory is locked based on the order type. If the order type is a game-based order, the corresponding quantity of inventory is randomly locked from the available batches of the corresponding game according to the game identifier in the order. This method is suitable for business scenarios that require batch allocation by game type, and can meet the need to quickly lock inventory from different batches of the same game. If the order type is a batch-based order, the target inventory quantity under that batch is accurately locked according to the batch number specified by the user, realizing priority allocation of inventory for specific batches and meeting the needs of refined batch management. During the process of locking the target inventory, a triple-locking mechanism is triggered to ensure data security and operational consistency. Among them, distributed locks are used to solve inventory conflict problems in cross-server concurrent scenarios. By locking shared resources in a distributed environment, they prevent the same inventory from being locked repeatedly due to simultaneous orders from multiple locations. Optimistic locks improve the efficiency of inventory updates in high-concurrency environments through a version number verification mechanism. When performing an inventory locking operation, the system verifies the data version number and only performs the update if the version number matches, avoiding frequent locking that affects system performance. Database locks are used to maintain data atomicity during unpacking operations, ensuring that the inventory data update operations of the box specification and the specification during unpacking either all succeed or all fail, preventing data inconsistency caused by operation interruption.

[0027] Step S2: Perform horizontal and vertical statistics on the target inventory based on order information to obtain statistical results. Based on the statistical results, perform inventory borrowing and updating of the target inventory.

[0028] Specifically, step S2 above includes:

[0029] Step a1: Perform layer-by-layer statistics on the target inventory according to the specifications of prize groups, sets, boxes, notebooks, and sheets to obtain horizontal statistical results.

[0030] Furthermore, when performing horizontal statistics on target inventory based on order information, a layer-by-layer penetrating statistical approach is implemented according to the specification dimensions of "prize group, set, box, notebook, sheet". This progressive statistical method from large to small specifications can accurately locate the actual available quantity of inventory at each level. For example, when allocating 150 instant invoices, the inventory quantity of the "notebook" specification is checked first. If the inventory of this specification is insufficient, the statistics are extended to the higher-level "box" or "carton" specification, ensuring that the inventory data of each specification level can be accurately captured. This provides accurate basic data support for subsequent inventory transfers and avoids errors in the allocation quantity caused by missing specification-level statistics.

[0031] Step a2: Index the target inventory by game, batch, status, and quantity to obtain vertical statistical results.

[0032] Furthermore, after completing the horizontal specification-level statistics, a composite index is built for the target inventory according to the dimensions of game, batch, status, and quantity, forming vertical statistical results. Through this multi-dimensional indexing mechanism, the system can quickly locate the inventory quantity of a specific game, batch, and status. For example, when the provincial center needs to query the available inventory of a certain game batch, it can directly and quickly filter out the inventory data that meets the conditions through the vertical index, without having to traverse the entire inventory information, which greatly improves the efficiency of inventory query and lays an efficient data retrieval foundation for subsequent inventory status filtering and precise allocation.

[0033] Step a3: Based on order information, determine whether the inventory of each specification level is sufficient. When the inventory of the current specification level is insufficient, borrow from the next higher specification level and record the borrowed quantity in an independent field.

[0034] Furthermore, based on order information and horizontal and vertical statistical results, the system further determines whether the inventory of each specification level is sufficient. When the inventory quantity of a specification level cannot meet the allocation needs, a borrowing mechanism to the next higher specification level is automatically triggered. For example, when the inventory of the "book" specification is insufficient, the corresponding quantity is borrowed from the "box" or "carton" specification, and the borrowed quantity is recorded in real time through an independent field to ensure the traceability of the borrowing process. When calculating inventory, the original specification quantity is still used for calculation before the borrowing. For example, after borrowing 50 books from the carton specification, the statistical quantity of the carton specification is still displayed according to the original carton number. At the same time, the actual number of books separated is associated through the borrowing record field. This processing method not only ensures the consistency between inventory data and physical inventory, but also avoids inventory statistics chaos caused by specification conversion, and achieves accurate inventory quantity management.

[0035] Step S3: Filter the ticket status of the target inventory and remove the tickets to be sorted that are "locked" or "problem tickets" from the target inventory.

[0036] Specifically, a composite index is used to index the status of tickets in the target inventory, filtering out tickets with statuses of "locked" or "problem tickets" to be sorted, and retaining tickets with statuses of "normal", "in transit", or "sold".

[0037] Furthermore, a composite index is pre-established in the ticket status module for the target inventory data, encompassing dimensions such as specification, status, and game. This composite index mechanism can quickly locate the corresponding ticket status data based on the game identifier and transfer specification in the order information. For example, when an order involves the transfer of a specific specification for a particular game, the composite index can directly lock all ticket status records for that specification under that game, avoiding a full data traversal and improving filtering efficiency from the underlying data structure. Relying on the established composite index, the status filtering logic is automatically executed, removing tickets marked as "locked" and "problem tickets" from the target inventory. Tickets in the "locked" state have already been occupied by other orders or are being processed, while "problem tickets" may be unable to participate in the transfer due to physical damage, data anomalies, or other reasons. The index quickly matches and excludes such invalid data, ensuring that the inventory to be sorted only contains tickets that can be transferred normally. After status filtering, only tickets with statuses of "normal," "in transit," and "on sale" are retained. The "Normal" status indicates that the ticket is in a usable state that can be directly allocated; the "In Transit" status reflects the intermediate state where the ticket has been dispatched but the transfer of ownership has not yet been completed; and the "Sold" status corresponds to inventory tickets that can be circulated normally. Tickets in this valid state will be prioritized for inclusion in the sorting process. Through this refined status management mechanism, provincial center users can directly obtain clean, allocateable inventory data, reduce the workload of manual screening, and ensure that sorting operations are performed only on valid data, thereby improving overall business processing efficiency.

[0038] Step S4: Check the transfer specifications of the order information. If the transfer specifications are the same, trigger the unpacking logic and unpack the target inventory.

[0039] Specifically, step S4 above includes:

[0040] Step b1: Detect the transfer specification of the order information. If the transfer specification is "book", determine the box status of the book to be transferred. If the box status is "full box", automatically unpack the box and split the full box record into individual book records.

[0041] Furthermore, when checking the transfer specifications of order information, the specification parameters in the order are analyzed in real time. If it is identified as a transfer of the "book" specification, the full box status verification logic is immediately triggered. By querying the relationship between the "book table" and the "box table" in the inventory table, the box number corresponding to the book to be transferred is queried to determine whether the box is in a full box status. If it is confirmed that the box is a full box, the unpacking operation is automatically performed, the full box record is deducted from the "box table", and the corresponding number of loose book records are generated in the "book table".

[0042] Step b2: Update the specification relationships in the inventory table and generate an unpacking log, recording the original box number, the split ticket number range, and the splitting time.

[0043] Furthermore, after the entire carton is split, the specification relationships in the inventory table are updated synchronously. Specifically, the quantity of the corresponding carton number in the "Carton Table" is reduced by 1, and a new record corresponding to the invoice number range is added to the "This Table" and associated with the original carton number, forming a complete data link for specification conversion. Simultaneously, an unpacking log is automatically generated. This log contains key information such as the original carton number, the range of invoice numbers split from the original carton, and the time of the splitting operation, stored in a structured data format in the log table. This method not only achieves real-time linkage updates between carton specifications and the data in the inventory table but also provides provincial center staff with traceable unpacking operation records. During inventory checks, the log allows for precise identification of the unpacking source for each invoice, significantly reducing the workload of manually verifying carton number ownership transfers and improving the level of refined management of instant invoicing business.

[0044] In some alternative embodiments, after a full box of records is split into individual records, the individual records cannot be restored to a full box.

[0045] Furthermore, for example, one box can be split into 100 independent records. Once unpacked, the individual records cannot be restored to a whole box. This ensures that the system's inventory status is completely consistent with the irreversible nature of unpacking during physical sorting, solving the technical pain point in traditional solutions where box-specification allocation cannot be accurately adjusted down to the individual record.

[0046] Step S5: Based on the order information, sort the target inventory and generate inbound / outbound records and inventory snapshots.

[0047] Specifically, step S5 above includes:

[0048] Step c1: Based on the order information, sort the target inventory, record the warehouse number, ticket specifications, quantity and operation time, and generate inbound and outbound records.

[0049] Furthermore, when sorting target inventory based on order information, key information during the sorting process is recorded in real time to generate inbound and outbound records. Data such as the warehouse number corresponding to the order, ticket specifications, actual sorted quantity, and operation execution time are automatically captured to form structured inbound and outbound records. These records are stored in the inbound and outbound statistics module of warehouses nationwide, enabling central and provincial center users to track the outbound and inbound processes of each sorting operation in real time, clearly understand the inventory flow status, and provide accurate data support for subsequent inventory management and business traceability.

[0050] Step c2: Generate an inventory snapshot at a preset time. The contents of the inventory snapshot include the generation time, warehouse number, game batch, inventory quantity of each specification, and hash check value.

[0051] Furthermore, an inventory snapshot generation mechanism is automatically triggered at preset times each day. The snapshot module collects and records the current inventory status of each warehouse. The generated inventory snapshot includes the specific time of snapshot generation, warehouse number, game batch information, and the inventory quantity of each specification ("prize group, set, box, notebook, sheet"), while also calculating and storing the hash check value of the data. In this way, sorting personnel at the provincial center and the central center can query the inventory snapshot based on conditions such as game, batch, and warehouse to understand the actual inventory status in stages.

[0052] This embodiment provides a rapid sorting method for instant invoices of different specifications. It receives order information from a distributed database and locks target inventory based on order type. Simultaneously, it triggers a triple-locking mechanism of distributed locks, optimistic locks, and database locks. Real-time read / write separation replaces the original quasi-real-time synchronization, solving the problem of low cross-database query efficiency caused by database sharding and ensuring the atomicity and consistency of inventory locking in high-concurrency scenarios. Target inventory is statistically analyzed horizontally by specification and vertically by game, batch, and status. When a smaller specification is insufficient, it borrows from a higher specification and records it independently. Through specification hierarchy association and dynamic borrowing, it achieves linked statistics for box-by-box specifications, solving the error problem of calculating the number of boxes required for allocation in the original solution, ensuring consistency between system inventory and physical quantity. The method filters the ticket status of the target inventory, removing "locked" and "problem tickets" from the data to be sorted. A composite index quickly locates valid status tickets, reducing invalid data traversal and lowering the workload of manual verification of non-allocation tickets at the provincial center, thus improving sorting efficiency. Finally, it detects the order allocation specification; if it is "book,"... The system automatically determines the status of the box and triggers unpacking, breaking the entire box into individual, unrecoverable records. The unpacking log records the specification conversion process, solving the problem of the original solution's inaccuracy to the last item and achieving refined management of ownership transfer. Based on order information, the system sorts target inventory, generating real-time inbound and outbound records containing warehouse number, specifications, and quantity. A snapshot module generates daily inventory snapshots containing the quantity and hash value of each specification. Through multi-dimensional data recording and snapshot queries, it supports phased traceability of inventory counts, solving the problem of data real-time latency and ensuring the continuity of business operations and data traceability. In summary, the rapid sorting method for different specifications of instant invoices provided in this embodiment comprehensively solves the problems of insufficient sorting specification accuracy, low efficiency due to database and table partitioning, large workload of manual verification, and delays in real-time data statistics in related technologies for instant invoice sorting.

[0053] The above are embodiments of the rapid sorting system for different specifications of instant invoices provided in this application. Other embodiments of the rapid sorting system for different specifications of instant invoices provided in this application are described below.

[0054] This embodiment also provides a rapid sorting system for instant invoices of different specifications. This system is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0055] This embodiment provides a rapid sorting system for instant invoices of different specifications, such as... Figure 2 As shown, it includes:

[0056] The locking module is used to receive order information through a distributed database, determine the order type based on the order information, lock the target inventory based on the order type, and trigger a triple locking mechanism.

[0057] The statistics module is used to perform horizontal and vertical statistics on the target inventory based on order information, obtain statistical results, perform inventory lending and borrowing processing based on the statistical results, and update the target inventory.

[0058] The filtering module is used to filter the ticket status of the target inventory, and remove tickets with the status of "locked" and "problem tickets" from the target inventory.

[0059] The unpacking module is used to detect the transfer specifications of the order information. If the transfer specifications are the same, the unpacking logic is triggered to unpack the target inventory.

[0060] The sorting module is used to sort target inventory based on order information and generate inbound / outbound records and inventory snapshots.

[0061] This embodiment provides a rapid sorting system for instant invoices of different specifications. It receives order information through a distributed database and locks target inventory based on order type. Simultaneously, it triggers a triple-locking mechanism of distributed locks, optimistic locks, and database locks. Real-time read / write separation replaces the original quasi-real-time synchronization, solving the problem of low cross-database query efficiency caused by database sharding and ensuring the atomicity and consistency of inventory locking in high-concurrency scenarios. Target inventory is statistically analyzed horizontally by specification and vertically by game, batch, and status. When a smaller specification is insufficient, it borrows from a higher specification and records it independently. Through specification hierarchy association and dynamic borrowing, it achieves linked statistics for box-by-box specifications, solving the error problem of calculating the number of boxes required for allocation in the original solution, ensuring consistency between system inventory and physical quantity. The system filters the ticket status of the target inventory, removing "locked" and "problem tickets" from the data to be sorted. A composite index quickly locates valid status tickets, reducing invalid data traversal and lowering the workload of manual verification of non-allocation tickets at the provincial center, thus improving sorting efficiency. The system detects the order allocation specification; if it is "book,"... The system automatically determines the status of the box and triggers unpacking, breaking the entire box into individual, unrecoverable records. The unpacking log records the specification conversion process, solving the problem of the original solution's inaccuracy to the last item, and achieving refined management of ownership transfer. Based on order information, the system sorts target inventory, generating real-time inbound and outbound records containing warehouse number, specifications, and quantity. A snapshot module generates daily inventory snapshots containing the quantity and hash value of each specification. Through multi-dimensional data recording and snapshot queries, it supports phased traceability of inventory counts, solving the problem of data real-time latency and ensuring the continuity of business operations and data traceability. In summary, the rapid sorting system for different specifications of instant invoices provided in this embodiment comprehensively solves the problems of insufficient sorting specification accuracy, low efficiency due to database and table partitioning, large workload of manual verification, and delays in real-time data statistics in related technologies for instant invoice sorting.

[0062] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

Claims

1. A method for rapid sorting of instant invoices of different specifications, characterized in that, The method includes: Order information is received through a distributed database. The order type is determined based on this information, and the target inventory is locked based on the order type, triggering a triple-locking mechanism. The order type includes orders placed by game and orders placed by batch. If the order is placed by game, the target inventory corresponding to the specified game batch quantity is randomly locked. If the order is placed by batch, the target inventory is locked according to the batch specified by the user. The triple-locking mechanism includes a distributed lock, an optimistic lock, and a database lock. The distributed lock is used to lock the target inventory in cross-server concurrent scenarios; the optimistic lock is used to execute a version number verification mechanism; and the database lock is used to maintain data atomicity during unboxing operations. Based on the order information, the target inventory is statistically analyzed horizontally and vertically to obtain statistical results. Based on the statistical results, inventory lending is performed to update the target inventory. Filter the ticket status of the target inventory and remove the tickets to be sorted that are "locked" or "problem tickets" from the target inventory; Check the transfer specifications of the order information. If the transfer specifications are the same, trigger the unpacking logic and unpack the target inventory. Based on order information, the target inventory is sorted to generate inbound and outbound records and inventory snapshots; The process of performing horizontal and vertical statistical analysis on the target inventory based on the order information to obtain statistical results, and then performing inventory lending processing based on the statistical results to update the target inventory includes: The target inventory is statistically analyzed layer by layer according to the specifications of prize groups, sets, boxes, notebooks, and sheets to obtain horizontal statistical results; The target inventory is indexed by the dimensions of game, batch, status, and quantity to obtain vertical statistical results; Based on order information, determine whether the inventory of each specification level is sufficient. When the inventory of the current specification level is insufficient, borrow from the next higher specification level and record the borrowed quantity in an independent field.

2. The method according to claim 1, characterized in that, The step of filtering the ticket status of the target inventory, removing tickets with statuses of "locked" and "problem tickets" from the target inventory, includes: Perform a composite index on the ticket status of the target inventory, filter out tickets with statuses of "locked" or "problem ticket" to be sorted, and retain tickets with statuses of "normal", "in transit" or "sold".

3. The method according to claim 2, characterized in that, If the transfer specification of the detected order information is "this", the unpacking logic is triggered, and the target inventory is unpacked, including: The system checks the transfer specifications of the order information. If the transfer specification is "book", it determines the box status of the book to be transferred. If the box status is "full box", it automatically unpacks the box and splits the full box record into individual book records. Update the specification relationships in the inventory table and generate an unpacking log, recording the original box number, the split ticket number range, and the splitting time.

4. The method according to claim 3, characterized in that, Once a full box of records is split into individual records, the individual records cannot be restored to a full box.

5. The method according to claim 4, characterized in that, The process of sorting the target inventory based on order information and generating inbound / outbound records and inventory snapshots includes: Based on order information, the target inventory is sorted, and the warehouse number, ticket specifications, quantity, and operation time are recorded to generate inbound and outbound records. An inventory snapshot is generated at a preset time. The contents of the inventory snapshot include the generation time, warehouse number, game batch, inventory quantity of each specification, and hash check value.

6. The method according to claim 5, characterized in that, After sorting the target inventory based on order information, the method further includes: marking tickets that are actually unallocated as abnormal tickets and updating the ticket status index synchronously.

7. A rapid sorting system for instant invoices of different specifications, characterized in that, The system includes: The locking module receives order information from a distributed database, determines the order type based on the order information, locks the target inventory based on the order type, and triggers a triple-locking mechanism. The order type includes orders placed by game and orders placed by batch. If the order is placed by game, the target inventory corresponding to the specified game batch quantity is randomly locked. If the order is placed by batch, the target inventory is locked according to the batch specified by the user. The triple-locking mechanism includes a distributed lock, an optimistic lock, and a database lock. The distributed lock is used to lock the target inventory in cross-server concurrent scenarios; the optimistic lock is used to execute a version number verification mechanism; and the database lock is used to maintain data atomicity during unboxing operations. The statistics module is used to perform horizontal and vertical statistics on the target inventory based on the order information, obtain statistical results, perform inventory lending processing based on the statistical results, and update the target inventory. The filtering module is used to filter the ticket status of the target inventory, and remove tickets with the status of "locked" and "problem ticket" from the target inventory. The unpacking module is used to detect the transfer specifications of the order information. If the transfer specifications are the same, the unpacking logic is triggered to unpack the target inventory. The sorting module is used to sort the target inventory based on order information and generate inbound and outbound records and inventory snapshots. The process of performing horizontal and vertical statistical analysis on the target inventory based on the order information to obtain statistical results, and then performing inventory lending processing based on the statistical results to update the target inventory includes: The target inventory is statistically analyzed layer by layer according to the specifications of prize groups, sets, boxes, notebooks, and sheets to obtain horizontal statistical results; The target inventory is indexed by the dimensions of game, batch, status, and quantity to obtain vertical statistical results; Based on order information, determine whether the inventory of each specification level is sufficient. When the inventory of the current specification level is insufficient, borrow from the next higher specification level and record the borrowed quantity in an independent field.

Images