A method and system for splitting a pick wave

Abstract

The application discloses a picking wave splitting method and system, comprising querying splitting trigger indicators of each picking wave, locating abnormal waves, and performing intersection verification on the abnormal waves, attributing orders in the abnormal waves to corresponding order sets according to the intersection verification results, performing splitting verification on orders in the order sets according to splitting preconditions, and starting splitting logic of the picking wave after passing the splitting verification: standardizing splitting nodes based on a preset packaging format, monitoring execution results of the standardization, and obtaining new waves after successful execution, recording wave relationships between the waves, and adjusting wave states of the waves. The method and the corresponding system can improve the picking efficiency of the warehouse end, maintain traceability of new and old waves, rebuild executable states of the new waves, and ensure consistency of multi-layer business data.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and system for splitting picking waves, a method and system for synchronizing the delivery status of warehouse orders, and a method and system for selecting order fulfillment warehouses. Background Technology

[0002] Overseas warehouse systems are internet software systems used to perform online warehousing management, logistics management, and shipping management. They typically interface with numerous e-commerce platforms, logistics providers, and e-commerce ERP systems, processing tens of millions of orders daily, resulting in extremely large and complex datasets. Therefore, continuously improving the precision of warehouse management and enhancing warehousing and shipping efficiency are key objectives for overseas warehouse systems during product upgrades and improvements.

[0003] During the order packing stage, the warehouse groups multiple orders as a batch and sorts them in waves. However, when there are many orders within a picking wave or when warehouse picking activity fluctuates significantly, the picking time for a single wave can become excessively long. In this case, already picked orders are locked within the wave, waiting for the entire wave to complete, which affects order fulfillment. Furthermore, the presence of abnormal orders within a picking wave can slow down the entire wave and consequently impact warehouse picking activities. Traditional wave picking typically addresses the issue of wave locking by discarding some orders, but this method creates data gaps, resulting in discontinuities in the execution status of old and new waves and mismatches in business data across different terminals, ultimately leading to order fulfillment failures.

[0004] During the order parcel transportation phase, after completing its internal processing, the warehouse hands the parcel over to the logistics company, at which point the order status is updated to "shipped." However, when the number of outbound parcels is large, there may be missed orders or delayed pickups. In such cases, the warehouse cannot promptly inform the seller of the latest order status, and the seller cannot handle abnormally picked-up parcels, leading to order non-fulfillment. Therefore, a method is needed to allow sellers to instantly update the parcel delivery status after handing over the parcel to the logistics company.

[0005] Before order parcels are packaged and shipped, order warehousing and logistics allocation need to be pre-processed. However, this typically relies on manual experience or simple static rule configuration to determine the fulfillment warehouse and logistics for each order. In a globalized, multi-platform fulfillment scenario, orders face complex constraints such as dynamic inventory changes, real-time fluctuations in logistics costs, and uncontrollable return costs. Manually selecting fulfillment warehouses is no longer suitable for the current cross-border e-commerce landscape and can easily lead to order fulfillment failures and uncontrolled logistics costs.

[0006] Other technical issues related to this application will be further elaborated below. The above content is only for assisting in understanding the technical solutions of this application and does not imply that all of the above content is prior art. Summary of the Invention

[0007] The primary objective of this application is to provide a method and system for splitting picking waves, which improves picking efficiency at the warehousing end, maintains the traceability of old and new waves, reconstructs the executable state of new waves, and ensures the consistency of multi-layered business data. Furthermore, this application also provides a method and system for synchronizing the delivery status of warehouse orders, enabling second-level synchronization of delivery status after order shipment and timely handling of situations such as missing or incorrect packages, avoiding order shipment errors and package loss. Additionally, this application provides a method and system for selecting order fulfillment warehouses, which integrates order warehousing and logistics allocation as a whole, considers order returns, and selects the warehousing and distribution combination with the highest overall economic efficiency and feasibility for each order, thereby improving order fulfillment success rate.

[0008] To achieve the above objectives, this application proposes a method for splitting picking waves, the method comprising: Step A1: Query the split trigger indicators for each picking wave and locate the abnormal wave. The split trigger indicators include picking time, order status, and picking details. Step A2: Perform an intersection check on the wave data and picking details data of the abnormal wave, and assign the orders within the abnormal wave to the corresponding order set according to the intersection check result. The order set includes the set of picked orders and the set of unpicked orders. Step A3: Perform split verification on the orders within the already picked order set according to the splitting preconditions, and after passing the split verification, initiate the splitting logic for the picking wave. The splitting logic includes: Step A31: Standardize and encapsulate the split nodes based on a preset encapsulation format. The split nodes include wave framework construction, order migration, and wave update. The wave framework construction is to establish a wave framework based on the wave data of abnormal waves. The order migration is to atomically encapsulate each migration node of the picked order set based on a preset three-layer data structure. The wave update is to update the wave data of abnormal waves and new waves. Step A32: Monitor the execution result of standardized packaging, and after successful execution, obtain a new wave, which includes a wave to be packaged containing picked orders and a sub-wave containing unpicked orders, and record the wave relationship between abnormal waves, waves to be packaged, and sub-waves. Step A4: Adjust the wave status of the wave to be packaged to be packaged, and keep the wave status of the sub-wave to be picked.

[0009] Other features and technical effects of this application will be described in the latter part of the specification. The technical problem-solving approach and related product design scheme of this application are as follows: When picking orders in waves at the warehouse, a large number of orders within a wave can lead to excessively long picking times, necessitating wave adjustments to improve efficiency. A common approach is to rebuild the wave entirely, but this generates massive amounts of extra data and is highly error-prone. Furthermore, when the workload of a single wave exceeds the capacity of pickers / picking equipment, or when picked / abnormal orders are locked within a wave, picking time becomes idle and warehouse resources are wasted, impacting order fulfillment. Discarding some orders to resolve wave locking issues results in data loss, creating a data gap between old and new waves and discarded orders, causing data inconsistencies across different endpoints (warehouse, e-commerce ERP, etc.). Therefore, the applicant proposes a method of selectively splitting only a portion of orders within the old wave without rebuilding the wave.

[0010] When the number of orders to be split within a wave is huge, some dirty data may appear during the splitting process, with some migrations succeeding and others failing. In this case, it's impossible to detect whether the migration was successful or to locate failed orders. To address this, the applicant proposes dividing the splitting operation of a picking wave into three splitting nodes: building a wave framework (establishing a wave framework based on wave data from abnormal waves), order migration (atomically encapsulating each migration node of the already picked order set based on a pre-defined three-layer data structure), and wave update (updating wave data from abnormal waves and the new wave). A pre-defined encapsulation format is used to standardize the splitting nodes—encapsulating the splitting operation into an independent, indivisible transaction. This ensures that the splitting operation of abnormal waves either succeeds entirely or fails entirely, effectively avoiding data inconsistencies.

[0011] Furthermore, the applicant noted that during order migration, the decision-making power for splitting orders was centralized at the planning level, with a lack of real-time intervention mechanisms at the picking end. However, delegating the splitting decision-making power to the picking end could not ensure data consistency across multiple platforms, potentially leading to data gaps. To address this, the applicant proposed establishing a consistency baseline based on a pre-defined three-layer data structure: a new wave master record (wave layer) must have corresponding detailed data (order layer); detailed data must have corresponding product inventory locks (product layer); and product relationships must have corresponding associations (associations between picking waves, orders, and products). This three-layer data structure and the consistency baseline for each layer ensures that while splitting authority is delegated, multi-layer data consistency is achieved, and the generation of dirty data is avoided.

[0012] In summary, this solution breaks through the rigid, one-wave picking process of traditional batch picking, pioneering a flexible, pick-and-packet-as-you-go operational model. This avoids complete waste and rebuilding, enabling immediate package release and multi-threaded parallel processing. This solution seamlessly integrates picking and packaging operations, allowing new batches to re-enter standard operating procedures, effectively eliminating waiting gaps in traditional processes and significantly shortening order fulfillment cycles. Furthermore, it decentralizes splitting decision-making power to the frontline picking end, empowering them to dynamically split batches in real time, effectively improving the responsiveness and resource utilization efficiency of warehousing operations. This solution also retains most of the stable attributes of the original batches, improving the efficiency of new batch generation, and ensuring data consistency during splitting operations and order migration through encapsulation and transaction mechanisms.

[0013] Furthermore, this application also provides a method for synchronizing the delivery status of warehouse orders, the method comprising: Step D1: After completing the warehouse process and transferring the package to the logistics end, update the order status of the warehouse order corresponding to the package; Step D2: Confirm that warehouse orders with the status of "shipped" are the target orders, and determine the order type of the target orders. Obtain the delivery data of the target orders through the synchronization method corresponding to the order type. The synchronization method is to obtain the delivery data used to construct the delivery record from the order system, the logistics end, and the e-commerce platform respectively. Step D3: Construct the delivery record of the target order based on the delivery data and delivery record template, and determine the pre-selected delivery status of the target order based on the consistent delivery data. The delivery record includes delivery time, order identifier, package identifier, delivery status and confirmation status. Step D4: Send the pre-selected delivery status to the warehouse and receive the receipt result sent by the warehouse, wherein the receipt result is the verification result of the warehouse after confirming the order based on the pre-selected delivery status; Step D5: When the receipt result is confirmed, update the delivery status of the target order based on the receipt result and the pre-selected delivery status.

[0014] Other features and technical effects of this application will be described in the latter part of the specification. The technical problem-solving approach and related product design scheme of this application are as follows: After the warehouse hands over the package to the logistics company, the order status is updated to "shipped," at which point it's assumed the package has been picked up and is being delivered normally. However, if there are any issues with the logistics company's pickup process, the package may not actually have started delivery, making it highly susceptible to penalties from e-commerce platforms for false shipment. Buyers may also file complaints based on the situation where the order has been shipped but the logistics tracking shows no pickup for an extended period, significantly increasing the operational pressure on sellers. On the other hand, when there are large volumes of orders, the warehouse cannot track the outbound process or the pickup process between the warehouse and the logistics company. This data gap between the warehouse and logistics companies during the package's transit means sellers cannot know the pickup process after the package leaves the warehouse, nor can they promptly handle packages with pickup issues, leading to order defaults.

[0015] Based on this, the applicant proposes that after a package completes its outbound process at the warehouse, its delivery status should be further displayed, specifically whether the shipped package has been successfully picked up by the logistics company. If the warehouse directly connects to the logistics company via an interface and obtains real-time logistics data to determine the package's delivery status, this method requires the warehouse to connect with numerous logistics providers individually, consuming significant resources and manpower. Furthermore, with a large volume of packages, this method is time-consuming, preventing sellers from promptly knowing the package's pickup status. Building on this, the applicant further proposes determining the delivery status based on existing data from the e-commerce platform and the warehouse, and sending the determination result to the warehouse for confirmation, thus achieving a synchronous closed-loop system for delivery status monitoring.

[0016] In practical applications, e-commerce platforms only display order statuses adjusted according to the package processing flow at the warehouse. Generally, after an order status changes to "shipped," the e-commerce platform initiates a logistics status verification. If there's no change in the logistics trajectory, it triggers a penalty for false shipment. Therefore, it's necessary to decouple the delivery status from the order status and update the delivery status promptly after an order status change. Specifically, delivery status synchronization is decoupled from the order synchronization link, forming an independent synchronization link that only synchronizes delivery status. The order status of warehouse orders is used as the trigger condition; when the order status is "shipped," delivery status synchronization for warehouse orders is initiated. During delivery status synchronization, raw data is pulled from multiple endpoints based on the type of warehouse order. Heterogeneous platform data is uniformly transformed into standardized synchronization objects, and a package delivery record (format: delivery time + order identifier, package identifier + delivery status + confirmation status) is established using the order number and waybill number as the core. Based on the confirmed delivery status, the warehouse's receipt result is obtained to supplement the confirmation status in the delivery record, thus forming a closed loop for delivery status synchronization. Furthermore, when constructing delivery records, a strategy of prioritizing records with the same tracking number, backfilling empty slots, and otherwise adding new records is adopted. This prioritizes matching delivery records based on the waybill number, resolving issues such as waybill backfilling, multiple package splitting, and duplicate triggering. Further, when sending the delivery status to the warehouse, the order number, waybill number, and delivery time are simultaneously transmitted. An order status-based verification process is introduced to address package interception issues when the order status is cancelled. Additionally, upon receiving the warehouse's confirmation, the confirmation status in the delivery record is updated (confirmed, no order in warehouse, or pending confirmation), and different processes are executed for delivery records with different confirmation statuses, including scheduled re-push, stopping subsequent pushes, and delivery synchronization termination.

[0017] In summary, this solution significantly improves the accuracy, real-time performance, idempotency, and traceability of order delivery status synchronization, reducing the risks of missed, erroneous, and duplicate synchronizations across multiple platforms and multiple parcel orders. It also resolves conflicts between order and delivery statuses, enabling high-precision, low-conflict, and traceable synchronization of platform order delivery statuses in scenarios involving multiple platforms, multiple parcels, multiple trigger sources, and multiple systems. It ensures consistency between the delivery time recorded on the e-commerce platform and the actual delivery time of the parcel, minimizing time deviations. Furthermore, it addresses the issue of covering multiple statuses under multiple departure conditions. Finally, it helps sellers and overseas warehouses clearly understand order delivery statuses, enabling timely optimization and processing of orders and shipments, preventing order shipment errors, parcel delays, and losses from impacting store performance.

[0018] Furthermore, this application also provides a method for selecting an order fulfillment warehouse, the method comprising: Step S1: Receive orders from buyers on the e-commerce platform, obtain order data for orders to be fulfilled, and determine candidate warehouses and candidate logistics for the orders to be fulfilled; Step S2: Prioritize the candidate warehouses and candidate logistics based on the first screening factor to obtain the warehouse and distribution combination sequence. The first screening factor includes a rejection factor for eliminating candidate warehouses and candidate logistics that cannot fulfill their obligations and a weight factor for calculating the weight of each candidate warehouse and candidate logistics. Step S3: Integrate the return risk and return cost of pending orders to construct a second screening factor, and adjust the order of each warehousing and distribution combination according to the second screening factor. The return cost includes return logistics cost and return warehouse cost. Step S4: Determine the warehouse and distribution combination with the highest priority after the order adjustment as the target warehouse and distribution combination, and start the order fulfillment process based on the candidate warehouses and candidate logistics within the target warehouse and distribution combination.

[0019] Other features and technical effects of this application will be described in the latter part of the specification. The technical problem-solving approach and related product design scheme of this application are as follows: Currently, the method of selecting warehouses and logistics based on their characteristics when allocating fulfillment warehouses and logistics is highly dependent on human experience and separates warehouse and logistics selection into two isolated, sequential steps. At this point, orders face complex constraints such as dynamic changes in warehouse inventory, real-time fluctuations in logistics pricing, and significant differences in logistics requirements across e-commerce platforms. Manually selecting fulfillment warehouses is unsuitable for the current cross-border e-commerce landscape, easily leading to order fulfillment failures and uncontrolled logistics costs. Furthermore, single-dimensional selection decisions ignore heterogeneous, multi-source data, failing to achieve optimal warehousing and distribution across the entire system. Therefore, the applicant proposes combining warehouse selection and logistics allocation in order fulfillment. By leveraging the interplay between warehouses and logistics, a suitable warehousing and distribution combination can be selected, overcoming the high failure rate and low economic efficiency inherent in single-objective decision-making.

[0020] Furthermore, the applicant noted that traditional warehousing only considers forward transportation during order fulfillment. However, buyers may return goods. In such cases, warehouses and logistics selected based on forward fulfillment may lack return processing capabilities, leading to order delays or uncontrolled costs. Therefore, the applicant proposes incorporating return factors into the selection of warehouses and logistics for order fulfillment, using this as an enabling indicator for warehousing and distribution combinations. After determining the value of the enabling indicator, the priority order of warehousing and distribution combinations is adjusted to determine a combination that balances order fulfillment and returns. Specifically, the applicant quantifies return factors into return risks and return costs for orders awaiting fulfillment. A pre-set return risk model is used to determine the probability of order returns, and the additional costs incurred after initiating the return process are determined by statistically analyzing logistics and warehousing costs during reverse transportation.

[0021] In summary, this solution enables millisecond-level selection of warehousing and distribution combinations, significantly reducing the time and resources required for manual intervention. It dramatically improves the throughput and efficiency of automated order fulfillment during high-concurrency or peak sales periods, effectively enhancing order fulfillment efficiency and success rate. Furthermore, this solution effectively avoids the hidden sunk costs caused by high-frequency failures and resends resulting from a sole focus on low prices, significantly reducing operational error correction investment and achieving globally optimal allocation of comprehensive logistics costs and overall operational management costs in multinational, multi-warehouse, and multi-logistics environments. Additionally, it incorporates return metrics when selecting warehousing and distribution combinations, comprehensively considering both forward and reverse fulfillment costs to select the warehousing and distribution combination with the lowest overall cost, optimizing reverse logistics timeliness and improving user experience.

[0022] Other implementation schemes and their technical effects will be described later.

[0023] Furthermore, this application also includes systems corresponding to various methods. These systems contain the functional modules involved in this application, execute operation instructions for the corresponding functional modules or methods, and output relevant data information to the system front-end interface. The system is stored in a server and / or computer device containing a processor, which executes the system's operation instructions.

[0024] Declaration: The functional modules of this application can be integrated with each other, or they can exist independently, or one functional module can be a sub-module of another functional module; the step numbers S1, S2, etc. do not limit the order of the corresponding operation steps. Attached Figure Description

[0025] The accompanying drawings are provided to further understand this application and do not constitute a limitation thereof; the content shown in the drawings may be actual data of the embodiments and falls within the protection scope of this application.

[0026] Figure 1 This is a schematic diagram illustrating the principle of the picking wave splitting method in one embodiment of this application.

[0027] Figure 2 This is a schematic diagram illustrating the principle of a warehouse order delivery status synchronization method in one embodiment of this application.

[0028] Figure 3 This is a schematic diagram illustrating the principle of generating warehouse and distribution combinations in one embodiment of this application.

[0029] Figure 4 This is a schematic diagram illustrating the principle of the order fulfillment warehouse selection method in one embodiment of this application.

[0030] Figure 5 This is a schematic diagram illustrating the working principle of the common interface in one embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0032] refer to Figure 1 This application proposes a method for splitting picking waves. In one embodiment of this application, the method includes steps A1-A4, as follows.

[0033] Step A1: Query the split trigger indicators for each picking wave to locate the abnormal wave. The split trigger indicators include picking time, order status (order status stored in the database), and picking details (referring to the picking details of the goods at the picking end, such as goods 1 - 5 items picked).

[0034] Inside the picking terminal, pickers perform picking tasks for picking waves using picking equipment and obtain picking details data. The picking details data includes the order product code and the corresponding quantity of picked items. The picking equipment is an industrial-grade handheld smart data terminal (i.e., PDA, with a barcode / QR code scanner for pickers / warehouse managers to operate on-site) and picking carts (loaded with order products).

[0035] In actual picking scenarios, there are various situations that trigger wave splitting, such as excessively long picking times, overloaded picking equipment, and order cancellations. Therefore, when locating abnormal waves, it is necessary to determine indicators from multiple ends and dimensions. Based on this, this solution proposes a method for determining abnormal picking waves based on three dimensions: picking time, order status, and picking details. Specifically, automatic / manual triggering mechanisms are designed for multiple ends, including the picking end at the parcel picking line, the warehouse end for overall warehouse management, and the database end for storing data. Rapid location and traceability of abnormal waves are achieved through multi-end data linkage. For example, when wave splitting is triggered based on the picking time dimension, the database end can periodically create wave splitting tasks and automatically execute wave splitting at the designated time, or automatically split when picking times out; the warehouse end can manually trigger wave splitting when the picking start time exceeds the deadline or the picking countdown expires; the picking end can trigger wave splitting when picking tasks exceed the threshold or when pickers manually submit splitting requests.

[0036] In one embodiment, the warehouse determines whether a picking wave has been aborted based on an internal log table. This internal log table tracks the picking process, including the picking start time, picking time, and picking progress of each picking wave. If an abortion occurs, the picking wave is identified as abnormal and wave splitting is triggered. Picking abortion occurs when, based on the picking start time, the picking time exceeds a preset threshold or the picking progress is not updated within a given time period, preventing the picking wave from proceeding normally. The internal log table also includes estimated picking time and outbound cutoff time (order departure time). If picking is not completed after the estimated picking time or outbound cutoff time, a picking wave abortion is confirmed. The picking end determines whether the number of picked items in an order is less than the required quantity based on the picking details of each picking wave. If not, a splittable order exists within the picking wave, and wave splitting is triggered. If the number of picked items in an order is less than the required quantity, the load status of the picking equipment is retrieved. If the load status is overloaded, the picking equipment at the picking end is confirmed to be overloaded, and wave splitting is initiated based on the picker's user operation. The database determines whether the first order status of each order within the picking wave is canceled based on internal data tables. These internal data tables include a table showing the order status relationship received by the database from the e-commerce platform after order creation, including "order placed," "cancelled," "picking," "packing," "outbound," "delivered," and "delivered." If the order is canceled, the picking wave is confirmed as an abnormal wave, and wave splitting is triggered. The first order status is the order status of each order (including picked and unpicked orders) within the picking wave stored in the database, and the second order status is the order status of picked orders stored in the e-commerce platform, including "order placed," "cancelled," "picking," "packing," "outbound," "delivered," and "delivered."

[0037] In one embodiment, before triggering the split, the wave microservice configuration interface is called to query the wave configuration of the warehouse corresponding to the picking wave based on the current user ID and warehouse ID, confirming that the warehouse has wave splitting capability. If no wave configuration is found, or the configuration subject is empty, the process is terminated and a "wave splitting not enabled" message is returned. This means that wave splitting is not allowed without completing the warehouse-level configuration. After obtaining the configuration, the switch in the configuration item is further checked to see if it is enabled. If the switch is empty or not equal to the enabled state, it is determined that the current warehouse has not enabled the wave splitting function, and a failure result is returned directly. In this scheme, the abnormal wave is the old wave, and the sub-waves (including unpicked orders) and the waves to be packaged (including picked orders) are the new waves.

[0038] Step A2: Perform an intersection check on the wave data and picking details data of the abnormal wave, and assign the orders within the abnormal wave to the corresponding order set according to the intersection check result. The order set includes the set of picked orders and the set of unpicked orders.

[0039] The wave data includes basic information about the picking wave, the orders included in the picking wave, the order items, and the required quantities. A first quantity matrix for abnormal waves is established based on the picking details data. This first quantity matrix contains an array of item codes for picked orders and the corresponding picked quantities. A second quantity matrix for abnormal waves is established based on the wave data. This second quantity matrix contains an array of item codes for each order within the abnormal wave and the corresponding order quantity requirements. A hash comparison algorithm is constructed to locate corresponding data through item codes, and the first and second quantity matrices are matched to obtain the intersection verification result. In practical applications, the real-time matching engine acts as the entry gateway, receiving picking details data uploaded by the picking end. Internally, the engine constructs a hash comparison algorithm to match the input data with the products in each package within a picking wave. The real-time matching model employs the following structure: The first layer uses the product code as the key to bind the hash-matched product to its corresponding picked quantity, filtering out invalid picking due to mismatched product codes. The second layer iterates through each order within the picking wave, constructing the relationship between orders and products, and calculating the intersection of product picking for each order. The third layer further compares the picking quantity of each product with the order's required quantity; for a single order, there is no partial picking of the required quantity.

[0040] When the intersection check of orders shows a successful match, the order is confirmed as a picked order and assigned to the picked order set. When the intersection check shows a failed match, the order is confirmed as an unpicked order and assigned to the unpicked order set. Additionally, it is determined whether the number of orders in the picked order set is 0. If so, the order status of the orders in the unpicked order set is obtained, and it is determined whether there are any abnormal orders, including exception orders and priority orders. If so, a pending wave is established based on the exception orders for exception handling, and a priority wave is established based on the priority orders for priority picking.

[0041] Step A3: Perform split verification on the orders within the already picked order set according to the splitting preconditions, and after passing the split verification, initiate the splitting logic for the picking wave. The splitting logic includes: Step A31: Standardize and encapsulate the split nodes based on a preset encapsulation format. The split nodes include wave framework construction, order migration, and wave update. The wave framework construction is to establish a wave framework based on the wave data of abnormal waves. The order migration is to atomically encapsulate each migration node of the picked order set based on a preset three-layer data structure. The wave update is to update the wave data of abnormal waves and new waves. Step A32: Monitor the execution result of standardized packaging, and after successful execution, obtain a new wave, which includes a wave to be packaged containing picked orders and a sub-wave containing unpicked orders, and record the wave relationship between abnormal waves, waves to be packaged, and sub-waves.

[0042] Query the picking status of picked orders within the picked order set in the warehouse to determine if the picking status is "picked". If so, confirm that the picked order has passed the warehouse entry verification. Query the second order status of picked orders within the picked order set in the e-commerce platform. If the second order status is "picking in progress" (e-commerce platforms generally do not display the specific picking progress of orders in the warehouse; the status changes to "picking in progress" after the order enters the warehouse and only changes to "outbound" when the order is shipped out), confirm that the picked order has passed the status verification. If the second order status is "cancelled", confirm that the picked order has failed the status verification.

[0043] A wave framework is established based on the basic information in the wave data of abnormal waves. The wave framework inherits the basic information of abnormal waves, such as warehouse identifier, owner information, outbound type, and operation rules, but does not carry the order data and picking details of abnormal waves. The preset three-layer data structure is populated based on the picked orders in the abnormal waves, and the order extraction, new wave assembly, and abnormal wave update in the migration nodes are executed in sequence. Each migration node is atomically encapsulated through a transaction mechanism. The preset three-layer data structure includes a wave layer containing wave dimension data at the top, an order layer containing order dimension data at the middle, and a product layer containing product dimension data at the bottom. In addition, for order migration, the picked orders in the abnormal wave are extracted and their unique identifiers are recorded. Using the picked orders in the abnormal wave as the data source, the wave layer is populated first to construct the wave global information, then the order layer is populated to match the order body data of the picked orders, and finally the product layer is populated to associate the product data and picking details of each picked order. A transaction mechanism is initiated to atomically encapsulate the three migration nodes of order extraction, new wave assembly, and abnormal wave update into a single transaction unit. The atomic encapsulation includes: performing non-empty verification on the order data of the picked orders at the order layer and using the order number as a unique index; encapsulating the product data of the picked orders at the product layer and associating it with the order number; and encapsulating the relationship between the picking wave, order, and product at the wave layer. Furthermore, for the wavelet framework, a new wavelet number is generated by calling the wavelet microservice interface and the wavelet number generation rule. The wavelet number generation rule uses the original wavelet number as the seed input for the suffix increment algorithm, extracts the basic encoding and existing suffix through regular expression parsing, performs a summation operation on the wavelet number string, and outputs the new wavelet number. A wavelet framework object is created based on the abnormal wavelet, and the request parameters required to assemble the wavelet framework are obtained to obtain the wavelet framework. Further, for wavelet updates, data update processing is performed on the abnormal wavelet. In the order association ledger and product detail ledger of the abnormal wavelet, the order data that has been migrated is removed, and the remaining orders that are not picked or partially picked are retained, completing the closed-loop update of the original wavelet data.

[0044] In one embodiment, the order migration includes extracting the set of picked orders from the abnormal wave, creating a wave framework, assembling the wave framework and the set of picked orders, deleting the set of picked orders from the abnormal wave, and updating the order records of the abnormal wave. The transaction mechanism employs distributed transaction encapsulation, recording the execution status (not executed, executing, successful, failed) of each migration node through a transaction log. Each migration node executes sequentially in the aforementioned order; the next node can only proceed after the previous node has successfully executed, preventing data corruption caused by disordered node execution. The atomic encapsulation method solves consistency problems that arise during order migration involving multiple tables and multiple layers of data, avoiding orphan data and duplicate operations caused by partially successful migrations. It also avoids various data gap phenomena such as old waves being deleted before new waves are generated, new waves being generated while old waves still retain their original relationships, and orders being successfully migrated but products not synchronized. During the filling process of the preset three-layer data structure, a field mapping method is used for association. The order number in the basic order information layer corresponds one-to-one with the order numbers in the order product details layer and the association relationship layer, forming a complete order data link and ensuring that data is not fragmented during the migration process. Specifically, delete all three layers of data corresponding to picked orders from the order base ledger (order layer), product detail ledger (product layer), and relationship ledger (wave layer) of the abnormal wave; write the order layer data into the order base ledger of the new wave, write the product layer data into the product detail ledger of the new wave, and write the wave layer data into the relationship ledger of the new wave; compare the three layers of data of picked orders in the new wave's ledger with the three layers of data of picked orders in the abnormal wave to verify the consistency of the data.

[0045] Furthermore, the transaction mechanism consists of three sub-transaction units: an encoding generator, an attribute cloner, and a state transitioner. An exception in any of these sub-units triggers a global rollback. Specifically, the encoding generator outputs the new wave number; the attribute cloner connects to the repository and database via an interface to obtain the fields of the wave data from the exception wave in real time, and writes them to the new wave object using a deep copy method to avoid data pollution caused by reference associations; the state transitioner receives the complete wave object output by the attribute cloner, forcibly assigns its state field to the value to be wrapped, and triggers a persistent layer write operation.

[0046] Specifically, this solution does not invalidate the old wave entity. Instead, it updates its release count after migration, allowing the old wave to retain its business identity while accurately representing the parts that have been split off. This balances the flexibility of splitting with historical traceability, reducing the damage to management data caused by full reconstruction. Specifically, after a selected order is removed from the old wave, the release quantity statistics of the old wave are updated synchronously, accumulating the number of orders released or split off from the old wave. This ensures that the old wave still has interpretability in subsequent business analysis, tracking, and statistics. When a new wave is generated from a migrated order, it does not inherit the original execution state of the old wave. Instead, it is uniformly reset to a preset job state, making the new wave a schedulable and executable standard work unit again. This solves the problem of state chaos after splitting and the issue of new waves being unable to re-enter the standard process. Furthermore, the order-product relationships corresponding to the selected orders in the old wave are copied and migrated, so that each order in the new wave can still maintain the mapping with the original product relationships. This ensures that the new wave retains the operational relationships at the product level associated with the order, thereby ensuring that the new wave has a complete product-level execution context, ensuring full structural decomposition, and solving the problem of orders being migrated but products being missing.

[0047] In one embodiment, unlike full-wave reconstruction, this solution splits arbitrarily selected orders from existing waves, achieving partial migration rather than overall reconstruction. This reduces wave reorganization costs and improves the flexibility of warehouse scheduling. Furthermore, by inheriting the basic business attributes of the old wave and rewriting the differing fields to create a new wave, redundant calculations and assembly are avoided, ensuring the continuity of business attributes before and after splitting. Specifically, a wave copy is generated based on the old wave's master record, and key fields are overwritten to form a new wave's master record. Overwritten fields include: wave number, number of orders within the wave, product code and number of types, wave status, creator information, etc., while basic scheduling attributes such as warehouse, logistics attributes, and wave type are inherited from the old wave. This method of copying the original wave's basic attributes and overwriting differing fields, compared to complete reconstruction, can quickly retain a large number of stable operational attributes of the old wave, reducing the data reconstruction costs required for assembling the new wave.

[0048] Step A4: Adjust the wave status of the wave to be packaged to be packaged, and keep the wave status of the sub-wave to be picked.

[0049] For a picking wave to proceed to the packaging stage, it must meet the following requirements: The wave status must be valid, recognizable and deployable by the job engine; picking details, order relationships, and product location relationships must be complete and without gaps; execution resources such as inventory locking must be effective, without conflicts or overselling; it must be completely isolated from the old wave to prevent duplicate execution; and the data must be seamless and free of contamination, allowing direct entry into the picking process. In wave splitting scenarios, new waves generated based on the original wave inherit the wave fields from the original wave. In this case, the wave status of the new wave may not match the actual status, making it invalid and requiring manual intervention to configure the wave status. Therefore, this solution proposes cloning the original wave and migrating orders, then forcibly overwriting the status field to "pending packaging," forming a complete new wave object submitted to the database. After splitting, the new wave is restored to the correct, executable job status, eliminating the need for manual attribute configuration and reducing single-wave processing time by over 40%.

[0050] For the sub-waves after splitting, abnormal wave locations and splits can be performed again until normal picking wave execution can be achieved. However, in multi-level splitting scenarios, the relationship between waves is difficult to trace, thus affecting end-to-end auditing. Based on this, this solution uses characteristic naming based on the initial picking wave number to ensure clear business association and traceability between old and new waves, and also strengthens the readable association between old and new waves, reducing manual identification and investigation costs. Specifically, the wave number microservice interface and wave number generation rules are called to generate new wave numbers. The wave number generation rules use the original wave number as the seed input of the suffix increment algorithm, extract the basic code and existing suffix through regular expression parsing, perform a summation operation on the wave number string, and output the new wave number. The wave number microservice interface is an independent functional module (microservice) specifically responsible for managing waves and generating wave numbers. All new wave numbers must be generated through it, ensuring that the numbers are unique and conform to warehouse specifications, avoiding conflicts created manually. The seed serves as the unique template for generating new wave numbers. New wave numbers must be generated based on the original abnormal wave numbers and cannot be created out of thin air, thus enabling wave number tracing. Regular expression parsing splits the original wave number into two parts: a base code (a fixed letter / symbol prefix, unchanged) + an existing suffix (pure numbers, used for incrementing). An addition operation is performed on the split numerical suffix, incrementing it by 1 to ensure a consistent numbering format. Furthermore, a wave number generation operation is performed by an encoding generator. This generator has a built-in regular expression parsing module and a suffix incrementing algorithm. Upon receiving the original wave number, the regular expression module performs pattern matching: extracting the base code and numerical suffix; if no suffix is ​​matched, the entire original wave number is used as the base code, and the suffix is ​​initialized to -1; the incrementing algorithm performs a suffix increment operation and concatenates it with the base code to output the new wave number. Simultaneously, the encoding generator writes associated records to the operation log table, including the original wave number, the new wave number, and the split timestamp, establishing a tree-like index structure to support upward tracing and downward traversal after multi-level splitting. The above scheme can ensure the uniqueness of the encoding when splitting an unlimited number of times, so that any sub-wave can be traced back to the original wave within 3 steps of query, thus meeting audit compliance requirements.

[0051] In addition, while generating a new wave, an operation log is created that is bound to the new wave. The log records at least: the operator, the operation type, the new wave number, and the new wave identifier, thus forming an auditable and replayable business trajectory.

[0052] In one embodiment, a split monitoring module is used to receive wave splitting triggered by the picking end, database end, and warehouse end, and generate a splitting request event based on the triggering event; a splitting module is used to sequentially start intersection verification and splitting verification based on the splitting request event, and start the splitting logic of the picking wave after all verifications pass, outputting the picking wave and sub-waves, wherein the picking wave contains all orders in the set of picked orders and can be directly packaged, and the sub-waves contain all remaining orders after the picked orders have been migrated out of the abnormal wave; a state routing module is used to receive the picking wave and sub-waves output by the splitting module, and perform differentiated routing according to the binding status of the picking equipment, wherein the binding status includes unbound and bound, and the differentiated routing includes sending an instruction to stay on the picking page of the abnormal wave and prompting to continue picking in the unbound state, and sending an instruction to jump to the picking equipment binding page and prompting to continue picking after binding the picking equipment in the bound state. Furthermore, since the decision-making power for splitting picking waves is centralized at the planning layer, the front-line picking end lacks real-time intervention methods. Pickers cannot flexibly schedule picking tasks based on actual picking conditions, thus reducing warehouse operation efficiency. Based on this, this solution also includes a wave picking details page module. This module is deployed on the picking end. When the warehouse backend enables the wave splitting configuration switch, this module dynamically renders a wave splitting button in the upper right corner of the page and receives splitting request events output by the splitting monitoring module. It binds the splitting request event and the user-triggered click event through an event listening mechanism. Upon receiving the user's click instruction, it starts the splitting module. This wave picking details page module has two built-in response entries: confirm splitting and cancel, which are mapped to the verification interface and the close command in the business logic layer, respectively. By delegating splitting authority from the planning layer to the picking end, front-line picking personnel can make decisions within seconds based on real-time on-site conditions; it improves the flexibility of resource allocation, allowing operators to flexibly schedule resources based on on-site congestion, personnel load, equipment status, and other real-time conditions, achieving precise allocation of capacity to high-value tasks and comprehensively improving the elasticity of warehouse operations and resource utilization efficiency.

[0053] In summary, this solution provides a transactional migration mechanism for warehouse waves that supports partial order subset splitting. It maintains the traceability of both old and new waves while rebuilding the executable state of the new wave and ensuring consistency of multi-layered business data. Based on the existing old wave, this solution receives the set of orders to be split; reads the master data, order details, and order-product relationship data corresponding to the old wave; generates a new wave master record that inherits the basic attributes of the old wave; removes the selected order details and order-product relationships from the old wave and migrates them to the new wave; simultaneously resets the new wave and its subordinate data to the preset job state; and finally, completes the old wave update, new wave writing, and log storage within the same transaction, thereby achieving consistency, traceability, and continued operation during the wave splitting process.

[0054] refer to Figure 2 This application also proposes a method for synchronizing the delivery status of warehouse orders. In one embodiment of this application, the method for synchronizing the delivery status of warehouse orders includes steps D1-D5, as follows.

[0055] Step D1: After completing the warehouse process and transferring the package to the logistics end, update the order status of the warehouse order corresponding to the package.

[0056] This solution targets the cross-border e-commerce warehouse end, primarily addressing issues such as heterogeneous data across multiple platforms, split orders from multiple parcels, inconsistent sources and specific times for multiple delivery times, and coupling between order status and delivery status. Specifically, it constructs a delivery status synchronization system independent of the order status synchronization system. This system retrieves data through various methods, including acquisition from the e-commerce platform, order system push notifications, and user-generated data. It extracts order status, waybill number, and delivery time information using delivery status identification rules, waybill number extraction rules, and platform delivery time extraction rules, establishing delivery records. The primary key format of the delivery record is order number + waybill number. Enabling delivery status synchronization is controlled by a store-level switch. Delivery status updates are implemented using a matching strategy that prioritizes identical order numbers, fills empty slots, and adds new ones otherwise. The warehouse orders mentioned in this solution refer to orders that have already entered the warehouse for picking and outbound processing. The warehouse process refers to the process of picking and outbound orders within the warehouse.

[0057] For split orders (one order split into multiple packages), the delivery status of each package under the target order is obtained. When a package has a delivery status of "delivered," the delivery status of the target order is adjusted to "delivered." In practical applications, due to the multiple sources of delivery data, when multiple devices repeatedly push delivery data for the same package, dirty data is added, affecting system stability. Furthermore, when the push process is abnormal, delivery data overwriting can occur, i.e., older delivery data arrives in the system due to a push error, thus overwriting the latest delivery data. Based on this, a solution is proposed that for cases of repeated pushes from multiple devices, only the original delivery record is updated, without creating new ones, thereby achieving idempotent updates. Specifically, each package corresponds to an independent waybill number, using the waybill number as the unique matching primary key for fallback matching. When upstream pushes delivery data, existing delivery records are matched first based on the waybill number. If the waybill number matches successfully, the existing delivery record is directly overwritten and updated, and the delivery status, delivery time, etc., are updated synchronously. When the target order is a split order, if the waybill number fails to match (i.e., there is no matching waybill number in the existing delivery records), the system searches for a blank placeholder record (i.e., a delivery record with only a framework but no substantive content) under the same order number. If it exists, it is filled in; otherwise, it indicates that the package is a new package (a temporary replacement package, an extra package, or a new package exceeding the pre-split quantity), and a new delivery record is created and its delivery status is updated. For example, when an order is split into 3 packages, the warehouse will pre-create 3 empty delivery records (only bound to the order number, no waybill, no status) as slots. Subsequently, newly received waybills and delivery information will be filled into the empty blank slots under the same order, occupying the record without creating additional ones. This solution can adapt to multi-package scenarios with batch outbound and batch push, ensuring that the number of package records is consistent with the actual number of split orders. It can also achieve idempotency by avoiding the creation of dirty data and preventing multiple packages from overwriting each other in scenarios where delivery data is repeatedly pushed to multiple terminals.

[0058] In addition to the order status changing to "shipped," the triggering conditions for synchronizing delivery status also include incremental synchronization, historical inventory rescanning synchronization, e-commerce platform status push notifications, and failed record re-push synchronization. Once the warehouse completes the sorting and packing of goods for an order, the order status will be updated to "shipped." However, after a package is shipped, it may need to wait for the last-mile delivery network (courier) to pick it up. When the courier picks up the package, they will scan it. During this process, there may be instances of missed scans, incorrect scans, lost packages, or failure to upload pickup data (after the courier scans the package, the logistics data cannot be properly transmitted back to the logistics network). This leads to a discrepancy between the package's shipping status and the logistics pickup status. Especially when the volume of packages is large, the warehouse needs to be able to promptly locate packages and orders with pickup issues. This asynchrony prevents sellers from handling these issues in a timely manner, resulting in order fulfillment problems.

[0059] Order status includes Cancelled (buyer cancels order), Shipped (e-commerce platform receives package outbound notification from warehouse and adjusts order status to Shipped), In Transit (package corresponding to order is being transported normally by logistics), and Signed for (package has been signed for by buyer). Order types include e-commerce platform orders, order system push orders, and warehouse-created orders. E-commerce platform orders are orders synchronized from the e-commerce platform by the warehouse through an interface with the e-commerce platform. Order system push orders are multi-channel orders pushed by the order management system. Warehouse-created orders are orders manually created by sellers in the warehouse management system (which manages the entire process of product inbound to outbound, i.e., overseas warehouse system). Delivery status (indicating the handover status between the warehouse and external logistics providers) includes Delivered, Not Delivered (indicating that the package has not yet been formally transferred to the logistics provider and has not been picked up), and No Delivery. An order status of Shipped represents the final state of the internal warehouse operation process, indicating that the package has completed all warehouse operations and is ready for delivery to the logistics provider.

[0060] Step D2: Confirm that warehouse orders with the status of "shipped" are the target orders, and determine the order type of the target orders. Obtain the delivery data of the target orders through the synchronization method corresponding to the order type. The synchronization method is to obtain delivery data for constructing delivery records from the order system, logistics end, and e-commerce platform respectively.

[0061] When a warehouse order is an e-commerce platform order, the system determines whether the warehouse has received a status notification from the e-commerce platform. If received, the system extracts the delivery record of the target order based on the status notification. If not received, the system sends a polling request to the e-commerce platform, receives the polling response from the e-commerce platform, and extracts the delivery record of the target order based on the polling response. When a warehouse order is a push order from the order system, the system sends a query request to the order system based on the order number of the target order, receives the query response from the order system, and extracts the query response to obtain the delivery record of the target order. When a warehouse order is a warehouse-created order, the system queries the logistics end for pickup data based on the waybill number of the target order, and extracts the pickup data to obtain the delivery record of the target order.

[0062] For e-commerce platform orders, the platform adjusts the order status to "shipped" based on the warehouse's outbound notification. After receiving logistics data from the logistics side, it generates a status notification based on the logistics data and proactively sends it (notifying the package that it has been picked up or is in normal transit). One form of status notification is a Webhook (a callback method between systems, where one system sends a request to a pre-set address and pushes event information). When the warehouse does not receive the status notification, there may be a push delay. That is, the logistics side has completed the pickup, but there is a delay in sending the pickup notification from the logistics side / status notification from the e-commerce platform, causing the delivery time recorded by the e-commerce platform / warehouse to be later than the actual shipping time. This can lead to misjudgment of slow delivery, resulting in a discontinuity in the delivery trajectory and causing customer complaints. The phenomenon of delayed notification sending can be effectively solved by using methods such as timed incremental fetching / historical inventory rescanning / notification callback / failure re-push. Furthermore, when no status notification is received from the e-commerce platform, a polling request is proactively sent to the e-commerce platform, and the platform's polling response is received.

[0063] When a warehouse order is an e-commerce platform order, the system extracts the order status change time and logistics pickup time from the status notification sent by the e-commerce platform, prioritizing the logistics pickup time as the highest priority and the order status change time as the second highest priority. It also retrieves the package outbound time stored in the warehouse, using this as a fallback time. The delivery time for the target order is determined based on the order and time priority. When both the delivery time from the notification push and the actual delivery time from the periodically retrieved order details are received simultaneously, the earlier time is used as the final platform delivery time. This prevents delivery times recorded by the platform from being later than the actual delivery time due to notification delays, which could affect timeliness assessments or consumer experience, thus resolving the issue of inaccurate delivery times caused by notification delays.

[0064] Step D3: Construct the delivery record of the target order based on the delivery data and delivery record template, and determine the pre-selected delivery status of the target order based on the consistent delivery data. The delivery record includes the delivery time of the package, order identifier, package identifier, delivery status, and confirmation status.

[0065] When updating the delivery status based on delivery data, a conditional update mechanism based on the original delivery status is introduced during the delivery record update process. Writing is only allowed when the record is still in the expected state, thereby reducing the state overwrite problem under concurrent threads. Regarding data retrieval and delivery record construction, order status, package status, waybill number, and platform delivery time are extracted according to platform API call / callback parsing. An adaptation layer effectively shields the differences between multiple platforms, converting the API formats, field definitions, and callback protocols of different e-commerce platforms into a unified format. Whether calling the platform's order retrieval API or parsing notification callbacks, key information can be uniformly parsed.

[0066] The standardization process involves converting delivery data obtained from multiple sources into data in a unified format that is recognizable by the warehouse. Delivery data is retrieved from different sources based on the order type of the target order, and this data is processed to obtain the processing results. The processing includes identifying the delivery status field, extracting the waybill number, and extracting the delivery time. When the warehouse order is an e-commerce platform order, the received polling responses / status notifications from the e-commerce platform are adapted according to the platform's configuration characteristics. These configuration characteristics include interface protocols, field structures, and status rules. The adaptation includes calling the corresponding platform interface or parsing the corresponding callback content, and extracting the order status, package status, waybill number, and platform delivery time. In one embodiment, information such as the business entity identifier, store authorization identifier, platform order number, package status, waybill number, and platform delivery time are uniformly encapsulated. Through a standardized data structure, the differences between multiple platforms are decoupled, and data extracted from different platforms is converted into a unified standard synchronization object within the system. All subsequent business logic depends only on this object, eliminating the need to distinguish between platforms and reducing complexity. By creating a synchronization task carrier—the delivery record—the end-to-end tracking status is converted into a delivery record. Subsequent matching, updating, distribution, and receipt processing all revolve around this record, making it convenient to track the status of the entire synchronization process.

[0067] In practical applications, delivery data is a structured collection of information that runs through the entire order fulfillment process. In this solution, delivery data may include the status nodes of the package at the warehouse and logistics end (a package status node indicating it has been loaded can also confirm that the package has been delivered), the order status of the corresponding order (e.g., an order status indicating it has been received can also confirm that the package has been delivered), and so on. The pre-selected delivery status is the delivery status determined based on the delivery data, but which has not been confirmed by the warehouse.

[0068] Step D4: Send the pre-selected delivery status to the warehouse and receive the acknowledgment result sent by the warehouse. The acknowledgment result is the verification result of the warehouse after confirming the order based on the pre-selected delivery status.

[0069] When the pre-selected delivery status is "delivered," the warehouse order undergoes sequential verification of order identity, business status, and idempotency. Order identity verification checks if the order exists in the warehouse and if the store to which it belongs is correct. Business status verification determines if the package has been shipped based on the warehouse's internal process nodes. Idempotency verification checks if the warehouse order has completed the delivery status confirmation process based on its delivery status confirmation. If the order identity verification result is that the warehouse order exists and the store to which it belongs is correct, the business status verification result is that the package has been shipped, and the idempotency verification result is that the warehouse order has not completed the delivery status confirmation process, then the warehouse order confirmation receipt is considered passed. Specifically, after an order's delivery status changes, the delivery status and delivery time are sent to the warehouse, and the synchronous record is marked as confirmed, no order in the warehouse, or pending re-push based on the warehouse receipt result, thus forming a closed loop. Preferably, this solution also employs a unified status coding system, merging the platform cancellation status and delivery status into a single status value. This preserves the delivery semantics while supporting unified querying and processing under the cancellation status. This solution can significantly improve the accuracy, real-time performance, idempotency, and traceability of platform order delivery status synchronization, reducing the risks of missed synchronization, erroneous synchronization, and duplicate synchronization under multi-platform, multi-parcel orders.

[0070] When the delivery status is sent to the warehouse, the warehouse order undergoes sequential verification of order identity, business status, and idempotency. The receipt results include "No order in warehouse," "Confirmed," and "Confirmed." "No order in warehouse" means the order / package does not exist in the warehouse management system, indicating that the delivery record is dirty data or an invalid push, and the process is terminated directly to avoid invalid operations. "Confirmed" means the expected conditions are met (e.g., the order / package has been shipped from the warehouse), and the delivery status update is correct. "Confirmed" means the delivery record has been successfully synchronized, and the delivery status has not changed, so it is not updated again to prevent duplicate pushes and polling / retrieving that could lead to duplicate operations. After receiving the receipt from the warehouse, corresponding actions are executed based on the receipt result, transforming the synchronization between the e-commerce platform and the warehouse from a one-way push to a two-way closed loop.

[0071] In one embodiment, when an order status is cancelled, the system needs to perform corresponding actions based on the platform status. First, a cancellation synchronization command is sent to the warehouse management system to notify the warehouse to stop shipping. If the delivery status is delivered, a delivery synchronization command is sent to the warehouse management system to update the package status. If the delivery status is not delivered, only the local delivery record is updated, and no command is sent to avoid invalid operations.

[0072] Step D5: When the receipt result is confirmed, update the delivery status of the target order based on the receipt result and the pre-selected delivery status.

[0073] If the tracking number for the package corresponding to the target order cannot be found, the delivery status is confirmed as "not delivered". When the order status is "cancelled", the delivery status is checked. If the delivery status is "not delivered", the delivery is intercepted; if the delivery status is "delivered", the logistics department is notified to intercept the package and initiate the return process.

[0074] In one embodiment, the solution includes a triggering module for synchronizing the delivery status of warehouse orders based on changes in order status; an adaptation module for adapting the delivery data of the target order according to the data format of the warehouse, wherein the adaptation process involves unifying the delivery data of various data formats to obtain delivery data of the same format; a management module for generating delivery records based on the delivery data; a warehouse write-back module for sending the pre-selected delivery status to the warehouse and receiving the acknowledgment result sent by the warehouse; and an acknowledgment closure module for updating the confirmation status of the delivery record based on the acknowledgment result from the warehouse.

[0075] This solution is compatible with collaborative architectures that run on order systems, overseas warehouse systems, and transportation systems, and can also be applied to e-commerce ERP systems.

[0076] In summary, this solution significantly improves the accuracy, real-time performance, idempotency, and traceability of order delivery status synchronization, reducing the risks of missed, erroneous, and duplicate synchronizations across multiple platforms and multiple parcel orders. It also resolves conflicts between order and delivery statuses, enabling high-precision, low-conflict, and traceable synchronization of platform order delivery statuses in scenarios involving multiple platforms, multiple parcels, multiple trigger sources, and multiple systems. It ensures consistency between the delivery time recorded on the e-commerce platform and the actual delivery time of the parcel, reducing time deviations. Furthermore, it addresses the issue of covering multiple statuses under multiple departure conditions. It helps sellers and overseas warehouses clearly understand order delivery statuses, enabling timely optimization and processing of orders and shipments, preventing order shipment errors, parcel delays, and losses from impacting store performance. Moreover, it achieves reliable, accurate, and non-duplicative synchronization of delivery statuses for any type of order, while resolving various abnormal scenarios such as delays, lost parcels, duplicates, and multiple parcels, forming a closed-loop delivery status synchronization mechanism.

[0077] refer to Figures 3-4 This application also provides a method for selecting an order fulfillment warehouse. In one embodiment of this application, steps S1-S4 are included, as follows.

[0078] Step S1: Receive orders from buyers on the e-commerce platform, obtain order data for orders to be fulfilled, and determine candidate warehouses and candidate logistics for the orders to be fulfilled.

[0079] After a buyer places an order and makes payment, the e-commerce platform or e-commerce ERP system splits / combines the orders, verifies product attributes, quantities, remarks, shipping addresses, etc., and calls the global inventory center to retrieve real-time available inventory from all warehouses, generating a candidate warehouse list. First, it obtains the order data from the buyer on the e-commerce platform and determines the product structure of the order (including bundled products, set products, etc.). This product structure is then deconstructed and mapped into a demand quantity matrix at the warehouse product level. Specifically: for ordinary products, it is directly mapped to the basic SKU (product code) at the warehouse product level; for bundled products, their products are multiplied, expanded, and summed to obtain the absolute demand quantity at the warehouse product level (e.g., if an order contains 3 bundled products A, and product A consists of 2 SKU1 and 1 SKU2, then it is converted into a demand of 6 SKU1 and 3 SKU2). This solves the problem of overselling or misjudging stockouts of bundled products caused by verifying inventory based on surface-level product codes in existing technologies, providing standard data input for accurate comparison of multi-warehouse inventory.

[0080] Step S2: Prioritize the candidate warehouses and candidate logistics based on the first screening factor to obtain the warehouse and distribution combination sequence. The first screening factor includes a rejection factor for eliminating candidate warehouses and candidate logistics that cannot fulfill their obligations and a weight factor for calculating the weight of each candidate warehouse and candidate logistics.

[0081] The order data includes the delivery address, product characteristics, product quantity, and remarks. The elimination factors are used to remove candidate logistics that cannot be delivered to the delivery address, and to remove candidate warehouses where the product inventory is less than the product quantity. Based on the elimination factors, candidate logistics and candidate warehouses are eliminated, retaining the set of candidate warehouses and candidate logistics that pass the elimination factor verification, forming a warehouse-distribution combination. Specifically, candidate warehouses and candidate logistics are initially screened based on the delivery address and product inventory. The delivery coverage of each candidate logistics is matched with the geographical area corresponding to the order delivery address, eliminating candidate logistics that cannot be delivered to the delivery address. Furthermore, the real-time available inventory of the target product corresponding to each candidate warehouse is verified one by one (only real-time available inventory is counted, excluding locked inventory, reserved inventory, and inventory unsellable during quality inspection), eliminating candidate warehouses where the product inventory is less than the product quantity. The two elimination processes are performed independently, without any mandatory order constraint, and the final filtered candidate warehouses and candidate logistics are output synchronously. In addition, weighted scores are calculated for each warehousing and distribution combination based on weighting factors, including at least the inventory redundancy of the candidate warehouse (the more remaining inventory in the warehouse after deducting current order demand, the higher the score, to avoid depleting warehouse inventory) and the fulfillment cost of the warehousing and distribution combination. Finally, the warehousing and distribution combinations are prioritized according to their weighted scores to obtain a warehousing and distribution combination sequence.

[0082] In one embodiment, the inventory redundancy P1 = (available inventory quantity of goods corresponding to the candidate warehouse - quantity of goods required for the current order) / available inventory quantity of goods corresponding to the candidate warehouse, and the fulfillment cost P2 = forward transportation cost of the candidate logistics + packing cost of the candidate warehouse. The inventory redundancy P1 ranges from (0,1], with a higher value indicating a higher priority for the corresponding candidate warehouse. The packing cost of the candidate warehouse includes the handling costs incurred by the order goods within the warehouse and the cost of reserving inventory for the order in the candidate warehouse. The forward transportation cost of the candidate logistics includes the trunk transportation cost of transporting the order goods from the warehouse to the logistics distribution center and the last-mile transportation cost from the logistics distribution center to the delivery address.

[0083] In one embodiment, the exclusion factors also include: system hardware problems, such as unavailable communication or interfaces between systems, warehouse interface call timeouts / network anomalies / connection failures, etc.; abnormal warehouse status, such as network errors returned by the warehouse interface, warehouse shutdown, etc.; goods frozen, removed from shelves, near expiration, or damaged and unsellable in the warehouse; the warehouse does not support delivery to the buyer's delivery address; and special goods warehouses lack the necessary transportation qualifications.

[0084] Step S3: Integrate the return risk and return cost of pending orders to construct a second screening factor, and adjust the order of each warehousing and distribution combination according to the second screening factor. The return cost includes return logistics cost and return warehouse cost.

[0085] Based on the delivery address in the order data, the return ratio and rejection ratio of regional orders within a standard period are calculated. The return ratio and rejection ratio are then input into a preset return risk model, and the output value of the return risk model is received to obtain the return risk R of the order. The return risk model is obtained by quantitatively modeling at least one dimension, including order user profile, historical data of product category returns, and logistics timeliness sensitivity coefficient. The sum of return logistics cost C1 and return warehouse cost C2 is calculated to obtain the return cost C. The return risk R and return cost C are then integrated to construct a second screening factor.

[0086] Specifically, the integration of return risk R and return cost C includes: defining the assignment calculation model for the second screening factor as assignment Y = k1 * (1-R) ​​- k2 * C / Cmax, where k1 and k2 are the control weight coefficients corresponding to risk and cost, and Cmax is the maximum value of the total return cost for all warehousing and distribution combinations; determining the fulfillment type of the order to be fulfilled, which includes cost-type and time-type; when the fulfillment type is cost-type, the control weight coefficient k2 corresponding to cost is greater than k1; when the fulfillment type is time-type, both k2 and k1 are less than the weight threshold; and calculating the assignment Y for each warehousing and distribution combination based on the assignment calculation model. k1 and k2 can be configured in the background (e.g., risk accounts for 0.4, cost accounts for 0.6), and can also be adjusted according to the e-commerce scenario, such as increasing the risk weight to 0.6 and decreasing the cost weight to 0.4 during a major promotion.

[0087] In one embodiment, the metrics for measuring the return logistics cost C1 include the average reverse shipping cost per item, the reverse transit markup coefficient, and the return warehousing processing fee. The return logistics cost C1 = average reverse shipping cost per item + return warehousing processing fee * reverse transit markup coefficient. The average reverse shipping cost per item can be obtained by calculating the total shipping cost per order for all return orders and dividing it by the number of return orders. The reverse transit markup coefficient indicates that the more times a return requires transit, the higher the markup coefficient. It can be obtained by querying the number of regular transit nodes in the reverse logistics link from the order's delivery address to the candidate warehouse and matching the corresponding coefficient according to the number of transits. The return warehousing processing fee refers to the average cost of the entire process of handling returns in the warehouse, covering four core links: return quality inspection, sorting, barcode scanning, and shelving. It can be obtained by statistically analyzing the labor costs and consumable costs of handling returns in the warehouse over a period of time and then taking the average value. The return warehouse cost C2 includes return receiving and sorting costs, storage costs, and defective goods handling costs. Return warehouse cost C2 = fixed sorting cost per return order + daily storage cost per unit volume * average number of days returned goods remain in the return warehouse + amortization cost of defective goods handling per order * probability of defective goods being returned within the warehouse and distribution group. When an order contains valuable or fragile items, C2 also needs to calculate the defective goods cost = amortization cost of defective goods handling per order * probability of defective goods being returned within the warehouse and distribution group. Additionally, C1 can represent the total logistics cost incurred from the order's goods being transported back from the user's delivery address to the designated return warehouse, which can be calculated based on transportation distance, chargeable weight of the goods, unit freight rate, and amortization costs of reverse transit nodes. C2 can represent the warehousing operation costs incurred after the goods are returned to the warehouse, including return receiving and sorting costs, storage costs for returned goods, defective goods inspection and handling costs, and amortization costs of manual operations in the return warehouse.

[0088] In one embodiment, the assignment of the second screening factor corresponding to each warehousing and distribution combination is determined; the order of the warehousing and distribution combination sequence is converted into a fixed score, and the assigned value is converted into a score within the same interval. The total score of each warehousing and distribution combination is calculated, and the order of the warehousing and distribution combination sequence is adjusted according to the total score; or, the order of the warehousing and distribution combination sequence is adjusted according to the assigned value; or, it is determined whether the return risk and return cost in the second screening factor exceed the corresponding threshold; if they exceed, when the assigned value is less than 0, the warehousing and distribution combination corresponding to the assigned value is removed from the warehousing and distribution combination sequence. Alternatively, the priority level in the warehousing and distribution combination sequence is determined, and the priority level to which each warehousing and distribution combination belongs is determined. For example, the three warehousing and distribution combinations with positions 1-3 are the first priority level, and the remaining warehousing and distribution combinations are the second priority level. The upper priority level takes precedence over the lower priority level, and skipping levels is not allowed. That is, only the order of warehousing and distribution combinations within the same priority level can be adjusted, and the warehousing and distribution combinations of each priority level are adjusted according to the assigned value. Furthermore, the applicant noted that buyer return behavior is highly uncertain, and with a massive order volume, performing two rounds of screening for each pending order would significantly increase computational costs and potentially cause order congestion. Additionally, for orders with a low probability of return, considering return factors when determining warehousing and distribution combinations might lead to the selection of combinations with high positive fulfillment costs, thus failing to achieve optimal economic efficiency. Therefore, the applicant proposes prioritizing the return risk of pending orders, and when the return risk is below a preset value, order fulfillment is directly based on the warehousing and distribution combination sequence. Moreover, this solution assigns values ​​to warehousing and distribution combinations through a second screening factor, rather than directly adjusting high-priority combinations, also considering that the uncertainty of returns prevents the selection of warehousing and distribution combinations with low positive fulfillment costs. This approach considers return factors without overemphasizing them at the expense of positive economic factors, achieving optimal economic efficiency.

[0089] The return risk can be determined by combining multiple dimensions such as user's historical return behavior characteristics, inherent return characteristics of product categories, fulfillment timeliness characteristics of warehousing and distribution links, and stability of reverse return links. In one embodiment, the regional return ratio and regional rejection ratio of the statistical area (the area corresponding to the delivery address) are calculated; at least two of the following feature dimensions are quantified to obtain corresponding dimension quantified feature parameters: user profile dimension (determined based on the ratio of the user's historical order return frequency to the user's historical total order frequency), product category return history dimension (determined based on the ratio of the historical return order volume of the corresponding product category to the total transaction order volume of the category), and logistics timeliness sensitivity coefficient dimension (determined based on the proportion of orders that fail to meet the regional logistics fulfillment timeliness). A preset return risk model integrating multi-dimensional features is pre-built, and the solved regional return ratio, regional rejection ratio, and quantitative feature parameters of each dimension are input into the return risk calculation model. The preset return risk model is called to perform numerical calculations, and the return risk R corresponding to the order to be fulfilled is output. The larger the value, the higher the probability of the corresponding order being returned and the higher the return risk level.

[0090] Step S4: Determine the warehouse and distribution combination with the highest priority after the order adjustment as the target warehouse and distribution combination, and start the order fulfillment process based on the candidate warehouses and candidate logistics within the target warehouse and distribution combination.

[0091] After the second screening factor is used to adjust the order of the warehousing and distribution combinations, the combinations with the highest order are prioritized as the optimal distribution and delivery plan. Simultaneously, several other warehousing and distribution combinations with high order are listed as alternative plans. If the optimal warehousing and distribution combination experiences inventory locking failure or temporary disruption of the supply chain, alternative warehousing and distribution combinations are used sequentially to fulfill the order. The top m warehousing and distribution combinations in the adjusted sequence can be retained as alternatives, where m is a preset retention quantity, satisfying 2 ≤ m, with m = 5 being the preferred value. The warehouse in this plan can be a warehouse associated with an overseas warehouse system.

[0092] In summary, this solution enables millisecond-level warehousing and distribution combination selection and ensures transaction consistency in complex cross-border scenarios, meeting the stringent business requirements for decision interpretability and end-to-end auditing. It supports seamless collaboration in warehousing and distribution order creation under cross-border direct mail models, freeing the operations team from cumbersome routing rule maintenance and significantly improving the certainty of business fulfillment and the flexibility of operational scheduling. It effectively avoids the hidden sunk costs caused by high-frequency failures and re-transmissions resulting from a focus solely on low prices; it replaces manual troubleshooting and optimization with a system-level dynamic closed-loop feedback mechanism, significantly reducing operational error correction investment; and it reduces physical operational fluctuations at the warehouse level through anti-jitter control, achieving globally optimal configuration of comprehensive logistics costs and overall operational management costs in a multi-warehouse, multi-logistics environment. This solution can effectively reduce fulfillment costs by approximately 15-20%, guarantee an on-time delivery rate of 99.5%, and shorten delivery time by 25%. This solution can also incorporate return indicators when selecting warehousing and distribution combinations, taking into account both forward and reverse fulfillment costs to select the warehousing and distribution combination with the lower overall cost, optimize reverse logistics timeliness, improve inventory turnover efficiency, and enhance user experience.

[0093] This solution pre-processes order warehousing and logistics allocation throughout the entire order fulfillment process, while also considering order returns, selecting the warehousing and distribution combination with the highest overall economic efficiency and feasibility for each order. After selecting a fulfillment warehouse, the warehouse initiates the picking process. In the event of abnormal picking in a picking wave, picked orders are split, and while maintaining the traceability of old and new waves, the executable status of the new wave is rebuilt, further ensuring the consistency of multi-layered business data. After the order package completes its in-warehouse process and leaves the warehouse, the order status is updated to "shipped." When the delivery status cannot be updated in a timely manner, delivery data from multiple terminals is obtained and the package's delivery status is updated, achieving second-level synchronization of delivery status after order shipment and helping sellers to promptly handle situations of missed or incorrect package shipments.

[0094] Furthermore, the picking wave segmentation method, warehouse order delivery status synchronization method, and order fulfillment warehouse selection method in this solution can be used in overseas warehouse systems, e-commerce ERP systems, or other systems. In one embodiment, the overseas warehouse system of this application also includes an interface management module. Through the interface management module, various interfaces of the overseas warehouse system are pre-configured to connect with external interfaces such as e-commerce platform interfaces and logistics provider interfaces, thereby obtaining relevant data and realizing the connection and data transmission between the overseas warehouse system and external systems.

[0095] However, in practical applications, to meet the needs of different users, overseas warehouse systems need to connect with a large number of logistics providers, warehouses, e-commerce platforms, etc. Therefore, to improve interface configuration efficiency and reduce the amount of code programming during the connection process, this application also proposes an interface configuration method based on public interfaces for overseas warehouse systems to connect with e-commerce platform interfaces, logistics provider interfaces, and other systems. Taking the connection with a logistics provider system as an example (see reference...). Figure 5 The interface configuration method based on the public interface in this application includes the following steps B1-B6 (when connecting to the interface of other systems, the logistics provider interface and its associated features in steps B1-B6 need to be replaced with the corresponding other system interface and its associated features).

[0096] Because the specifications of logistics provider interfaces vary greatly and there is a lack of unified standards among different logistics provider systems, when connecting to logistics interfaces, the corresponding interface is usually configured separately for each logistics provider system (the system being connected) in the connecting system (overseas warehouse system). This requires developers to write a lot of code, resulting in low integration efficiency and difficulty in upgrading and maintaining the interface.

[0097] Step B1: Create a connection table to record basic information for each logistics provider's interface. This basic information includes the logistics provider identifier, logistics provider interface identifier, interface request address, interface request parameters, parameter mapping rules, and policy rule item identifiers. The basic information for each logistics provider's interface is created as a corresponding basic information group. Specifically, interface request parameters refer to the interface parameters corresponding to the request task for each interface type (including authorization verification interface, logistics order creation interface, logistics tracking number retrieval interface, logistics waybill retrieval interface, and logistics fee retrieval interface, etc.) during interface connection. Parameter mapping rules refer to the correspondence between field parameters in the connection system and field parameters in the logistics provider's system. Furthermore, the connection table can be set to an editable state, and information for multiple logistics provider interfaces that need to be connected can be pre-entered into the connection table to achieve batch configuration of the connected interfaces and facilitate subsequent expansion by adding other logistics provider interfaces.

[0098] Step B2: Define the general strategy for each logistics provider's interface. The general strategy rules include encryption rules, request header format setting rules, and return content encapsulation rules. Each general strategy rule is pre-configured with one or more strategy rule items (for example, encryption rules such as MD5 and SHA256 can be pre-configured). The strategy rule items correspond to the corresponding strategy rule items in the interface table.

[0099] Step B3: Create corresponding strategy implementation classes according to the specification requirements of each logistics provider's interface, which differ from the general strategy rules. The execution priority of the strategy implementation classes is higher than that of the general strategy rules. Map the general strategy and the strategy implementation classes to the factory pattern.

[0100] For example, when the encryption rules, request header formatting rules, return content encapsulation rules, or other rules required by a logistics provider's interface specification differ from the corresponding rules of the general strategy, corresponding strategy implementation classes need to be created for different rules. In this case, only the corresponding programming code needs to be added to the different rule parts, while the same rule parts can continue to use the strategy rule items to avoid additional programming, thereby significantly reducing the programming workload. The association relationship between each strategy rule and each strategy implementation class is stored in the virtual machine, enabling the system to accurately obtain callable and assemblable logistics provider data from the complex logistics provider data (data corresponding to the requirements of different types of logistics provider interface specifications) of different types, different levels, different formats, and different storage methods through the factory pattern, logistics provider identifier, logistics provider interface identifier, and strategy rule item identifier. This solves the problem of calling complex logistics provider data and reduces the difficulty of creating shared logical relationships between different logistics provider interfaces.

[0101] Step B4: Configure a common interface for unified invocation of interfaces from various logistics providers, including: Step B41: Create the first logic to obtain the target basic information group from the docking table based on the request task, logistics provider identifier and logistics provider interface identifier. The first logic also includes identifying the corresponding logistics provider identifier and logistics provider interface identifier according to the type of request task. Step B42: Create the second logic based on the strategy rule item identifier of the request task, logistics provider identifier, and target basic information group to obtain the corresponding target strategy rule item and target strategy implementation class from the factory pattern; Step B43: Assemble logistics provider data based on the acquired target basic information group, all target strategy rule items, and target strategy implementation class; Step B44: Create a third logic that automatically calls the corresponding logistics provider interface based on the assembly-based logistics provider data.

[0102] Step B5: In response to the initial logistics data returned by the logistics provider interface, perform a reversal operation on the initial logistics data. That is, perform a uniform reversal operation on all data returned by the logistics provider interfaces to obtain target logistics data with a uniform format.

[0103] Step B6: After performing the reversal operation, clear the assembled logistics provider data. Configure a common interface for unified invocation of various logistics provider interfaces. This allows a temporary interface that can accurately connect to the logistics provider interface to be assembled in real time each time the system needs to connect to a specific logistics provider system to execute a request task. After the interface connection and request task are completed, the assembled logistics provider data is cleared, and the temporary interface is released for use by other request tasks, thereby solving the problem of interface allocation between the common interface and the logistics provider interface.

[0104] This interface configuration method based on public interfaces allows for batch configuration of interfaces, significantly reducing the amount of code required for the integration process, shortening configuration time, and improving the stability and scalability of the interfaces. In contrast, configuring an interface for a logistics provider system using the direct programming method typically takes about 2-3 days, while this batch integration method can reduce the configuration time for expanding a new logistics provider interface to about 20 minutes. The new method significantly improves the configuration efficiency of logistics provider interfaces and enhances the flexibility and compatibility of interface expansion and maintenance.

[0105] Furthermore, the applicant discovered that a very small number of logistics provider interfaces, even after passing null value validation (checking whether the interface request parameters in the request body and request header are empty, with null values ​​indicating an error) and interface configuration validation (verifying whether the configuration content of parameters such as the interface request address and request method is normal), and with all parameter values ​​correctly matched, still failed to return data from the logistics provider interfaces. After detailed investigation, it was found that the reason was that some users' browser environments cleared or disabled cookie data, causing the warehouse system to fail to successfully send cookie data to the logistics provider system, thus preventing the interface from returning data. Therefore, a special cookie request verification step was added to the integration system to improve the success rate of logistics data retrieval. Specifically, in step K4, a cookie request verification is performed on the logistics provider interfaces that need to send cookie data. This verification includes checking whether cookie data exists. If the cookie file exists, the cookie request verification is considered normal, and the integration request sending operation continues based on the normal cookie data; if the cookie file does not exist, the cookie request verification is considered abnormal, and the cookie data is regenerated (implemented through Java code), and the integration request sending operation continues based on the regenerated cookie data. Furthermore, when a cookie request verification fails, the error information can be logged, and an error report can be sent to the backend of the integrated system. Accordingly, logistics provider interfaces that require sending cookie data can be pre-marked in the integration table. When the system detects the corresponding cookie verification identifier, the cookie request verification operation will then be initiated. A cookie is simple text data stored on a client machine, used for session state management, personalization settings, and user behavior tracking, among other things.

[0106] The above description is merely a preferred embodiment of this application and does not limit the patent scope of this application. All equivalent modifications made based on the inventive concept of this application and the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. A method for splitting picking waves, characterized in that, include: Step A1: Query the split trigger indicators for each picking wave and locate the abnormal wave. The split trigger indicators include picking time, order status, and picking details. Step A2: Perform an intersection check on the wave data and picking details data of the abnormal wave, and assign the orders within the abnormal wave to the corresponding order set according to the intersection check result. The order set includes the set of picked orders and the set of unpicked orders. Step A3: Perform split verification on the set of picked orders according to the splitting preconditions, and after passing the split verification, initiate the splitting logic for the picking wave. The splitting logic includes: Step A31: Standardize and encapsulate each split node of the abnormal wave based on a preset encapsulation format. The split nodes include wave framework construction, order migration, and wave update. The wave framework construction is to establish a wave framework based on the wave data of the abnormal wave. The order migration is to atomically encapsulate each migration node of the picked order set based on a preset three-layer data structure. The wave update is to update the wave data of the abnormal wave and the new wave. Step A32: Monitor the execution result of standardized packaging, and after successful execution, obtain a new wave, which includes a wave to be packaged containing picked orders and a sub-wave containing unpicked orders, and record the wave relationship between abnormal waves, waves to be packaged, and sub-waves. Step A4: Adjust the wave status of the wave to be packaged to be packaged, and keep the wave status of the sub-wave to be picked.

2. The method for splitting picking waves as described in claim 1, characterized in that, Step A1 also includes: The warehouse determines whether there is a picking interruption in a picking wave based on the internal log table, which includes the picking start time, picking time, and picking progress of the picking wave; if there is, the picking wave is confirmed as an abnormal wave and wave splitting is triggered. The picking end determines whether the number of items picked in an order is less than the required quantity based on the picking details data of each picking wave; if it is not less, it confirms that there is a splittable order within the picking wave and triggers wave splitting. The database determines whether the first order status of each order within a picking wave is cancelled based on an internal data table. The internal data table includes the order status relationship table received by the database from the e-commerce platform. If the order status is cancelled, the picking wave is confirmed as an abnormal wave, and wave splitting is triggered.

3. The method for splitting picking waves as described in claim 1, characterized in that, Also includes: The split monitoring module is used to receive wave splits triggered by the picking end, database end, and warehouse end, and generate split request events based on the triggering events; The splitting module is used to sequentially initiate intersection verification and split verification based on splitting request events, and after all verifications pass, initiate the splitting logic of picking waves, outputting the picking wave and sub-wave. The picking wave contains all orders in the set of picked orders and can be directly packaged. The sub-wave contains all remaining orders after the picked orders have been migrated out of the abnormal wave. The status routing module is used to receive the picking waves and sub-waves output by the splitting module, and perform differentiated routing according to the binding status of the picking equipment. The binding status includes unbound and bound. The differentiated routing includes sending an instruction to stay on the picking page of the abnormal wave and prompting to continue picking in the unbound state, and sending an instruction to jump to the picking equipment binding page and prompting to continue picking after binding the picking equipment in the bound state.

4. The method for splitting picking waves as described in claim 1, characterized in that, Step A2 also includes: A first quantity matrix for abnormal waves is established based on picking details data. The first quantity matrix contains an array of product codes for picked orders and the corresponding picked quantities. A second quantity matrix for abnormal waves is established based on wave data. The second quantity matrix contains the product code array of each order product within the abnormal wave and the corresponding order demand quantity. A hash comparison algorithm is constructed to perform data matching between the first and second quantity matrices and obtain the intersection verification result.

5. The method for splitting picking waves as described in claim 4, characterized in that, Step A2 also includes: When the intersection check of the orders shows a successful match, the order is confirmed as a picked order and assigned to the picked order set. When the intersection check of orders fails to match, the order is confirmed as an unpicked order and assigned to the unpicked order set.

6. The method for splitting picking waves as described in claim 1, characterized in that, Step A3 also includes: Query the picking status of the picked orders in the set of picked orders in the warehouse, and determine whether the picking status is "picked"; if so, confirm that the picked order has passed the warehouse entry verification. Query the status of the second order within the set of picked orders on the e-commerce platform; if the status of the second order is not "cancelled", confirm that the picked order has passed the status verification.

7. The method for splitting picking waves as described in claim 1, characterized in that, Step A31 also includes: A wave framework is established based on the basic information in the wave data of abnormal waves. The wave framework inherits the basic information of abnormal waves, which includes warehouse identifier, owner information, outbound type, and operation rules, but does not carry the order data and picking details data of abnormal waves. The preset three-layer data structure is populated based on the picked orders in the abnormal wave, and the order extraction, new wave assembly and abnormal wave update in the migration nodes are executed in sequence. Each migration node is atomically encapsulated through the transaction mechanism. The preset three-layer data structure includes a wave layer containing wave dimension data at the top, an order layer containing order dimension data at the middle, and a product layer containing product dimension data at the bottom.

8. The method for splitting picking waves as described in claim 7, characterized in that, The order migration includes: Extract picked orders from abnormal waves and record the unique identifier of each picked order; Using the picked orders within the abnormal wave as the data source, the wave layer is populated sequentially to construct the wave global information; the order layer is populated to match the order body data of the picked orders; and the product layer is populated to associate the product data and picking details data of each picked order. A transaction mechanism is initiated, atomically encapsulating the three migration nodes—order retrieval, new wave assembly, and abnormal wave update—into a single transaction unit. This atomic encapsulation includes: performing non-empty checks on the order data of picked orders at the order layer, using the order number as a unique index; encapsulating the product data of picked orders at the product layer and associating it with the order number; and encapsulating the relationship between picking waves, orders, and products at the wave layer.

9. The method for splitting picking waves as described in claim 7, characterized in that, The wavelet framework established based on anomalous wavelets includes: The wavelet microservice interface and wavelet number generation rules are called to generate a new wavelet number. The wavelet number generation rules are to use the original wavelet number as the seed input of the suffix increment algorithm, extract the basic code and the existing suffix through regular expression parsing, perform a summation operation on the wavelet number string, and output the new wavelet number. A wave frame object is created based on the abnormal wave, and the request parameters required to assemble the wave frame are obtained to obtain the wave frame.

10. A picking wave splitting system, characterized in that, The system executes the operation instructions contained in the picking wave splitting method according to any one of claims 1-9.

Images