Warehouse management method, device and electronic equipment

Abstract

The application discloses a warehouse management method and device and electronic equipment, the warehouse management method comprises the following steps: a mobile operation end pre-constructs a four-layer topological ontology model of a document, which comprises a document header, commodity items, serial numbers and storage positions, and converts mapping rules, storage permission constraints and quantity corresponding rules into topological constraint conditions; the original warehouse data topology is checked and marked with node credibility, character missing data is inferred and completed, and an operation document carrying a credibility level identifier is output. The inventory control service end constructs an inventory shard weight scoring model and executes dynamic granularity sharding, combines the document credibility to execute a correlation type dynamic optimistic lock scheduling, controls the hierarchical rollback of lock conflicts, and outputs inventory shard state data containing lock conflict logs. The background control end constructs a full-link digital twin topological model, generates two types of optimization instructions, and respectively issues the two types of optimization instructions to the two ends, adjusts the collection operation sequence and concurrent scheduling logic, and realizes warehouse management. Through the above setting, the accuracy of warehouse management can be improved.

Description

Technical Field

[0001] This application relates to the field of warehousing technology, and in particular to warehousing management methods, apparatus and electronic equipment. Background Technology

[0002] Existing warehouse management systems mostly adopt a linear stacked architecture of front-end data collection, back-end processing, and back-end display, with each module operating independently without any linkage. This architecture leads to delayed data verification on mobile devices, difficulty in timely interception of on-site errors, and the potential for dirty data to cause back-end inventory conflicts and transaction rollbacks. Inventory concurrency control uses fixed-granularity locks without dynamic adjustment based on business attributes and data quality, resulting in frequent lock conflicts and low throughput in high-concurrency scenarios. The back-end only displays static data and lacks reverse scheduling capabilities, failing to form a closed-loop optimization system that balances data accuracy, concurrency performance, and management efficiency. Summary of the Invention

[0003] In order to address the shortcomings of existing technologies, the purpose of this application is to provide a warehouse management method, apparatus, and electronic equipment that can improve the accuracy of warehouse management.

[0004] In a first aspect, embodiments of this application provide a warehouse management method, the method comprising: On the mobile work terminal, a four-layer topology ontology model of a document is pre-built, which includes four levels of subordinate nodes: document header, product item, serial number, and storage location. The mapping rules between products and serial numbers, the storage permission constraints between storage locations and products, and the correspondence rules between document type and quantity (positive and negative) are transformed into topological constraints between nodes. Based on topological constraints, the collected raw warehouse data is topologically verified and node credibility is marked; based on the features of nodes with marked credibility within the same document, the range of legal values ​​is inferred, and topological sensing is performed to complete warehouse data with missing characters, so as to output work orders with credibility level identifiers. The inventory management server receives work orders carrying a trust level identifier. Based on product turnover rate, storage area, document type, and operation priority, it constructs an inventory sharding weight scoring model and performs dynamic granular sharding of warehouse data according to the weight score. Based on the results of dynamic granular sharding and the trust level of the work order, it performs associative dynamic optimistic locking scheduling, assigning priority lock queues to high-trust documents and skipping the duplicate data verification step, and performing queuing scheduling for low-trust documents. At the same time, it dynamically adjusts the sharding granularity according to the real-time concurrency, performs hierarchical diversion and transaction rollback control for lock conflicts, and outputs inventory sharding status data including lock conflict logs. The back-end management terminal constructs a fusion full-link digital twin topology model based on inventory shard status data to obtain the overall warehouse operation progress, material space inventory distribution, goods flow nodes and shard conflict and abnormal locations. It then sends operation path and task allocation optimization instructions to the mobile operation terminal to adjust the collection operation order and feeds back the shard granularity and lock weight optimization parameters to the inventory management server to adjust the concurrent scheduling logic in order to achieve warehouse management.

[0005] Preferably, the original warehousing data collected is subjected to topology verification based on topology constraints, and the node credibility is marked. This specifically includes the following steps: Each time the mobile client completes the collection and entry of raw warehouse data, it immediately triggers the local topology verification engine. For the document header node, it verifies the matching of document type, operation date and permission scope; for the product item node, it verifies the consistency of product SKU, quantity and total document quota; for the serial number node, it verifies the affiliation relationship between serial number and corresponding product SKU; and for the storage location node, it verifies the compatibility of storage location permissions and product category. If the verification fails, the current input is immediately intercepted and the corresponding node's error message is output; if the verification passes, the node is marked with the corresponding credibility level. Simultaneously, a two-way synchronization channel for the semantic verification rules between the mobile operation terminal and the back-end management terminal is established. After the back-end management terminal updates business constraints such as pricing strategies, storage permissions, and batch number validity rules, it actively pushes the rule changes to the mobile operation terminal. The mobile terminal updates the topology constraint condition library in real time to perform topology verification on the collected raw warehousing data and mark the node credibility.

[0006] Preferably, based on the feature inference of the legal value range of the credibility nodes already marked within the same document, topology-aware completion is performed on the warehouse data with missing characters, specifically including the following steps: Identify the topological node level to which the missing data belongs, and locate its parent node and sibling nodes in the four-level topological ontology model of the document; extract the attribute features, value ranges, and constraint rules of the topological nodes at the same level within the same document that have passed the verification, and infer the legal value range of the missing data in combination with the topological constraints of the parent node; automatically complete the missing field content that conforms to the topological constraints based on the inference results; after completion, re-execute the full node topological verification, and if the verification passes, mark the corresponding confidence level for the completed data; if the verification fails, return to re-infer the value range.

[0007] Preferably, the associative dynamic optimistic locking scheduling is performed based on the results of dynamic granularity sharding and the credibility level of the job document, specifically including the following steps: Based on the credibility level carried by the work order, the documents are divided into a high-credibility priority queue and a normal priority queue. High-credibility priority documents directly enter the lock allocation priority channel, skipping the data validity verification of the inventory control server, and are configured with a longer lock timeout and more automatic retries. Normal priority documents enter the queuing channel and are sorted by the time of receipt to perform data verification and lock resource application in sequence. The system monitors the concurrent load in real time. When the number of documents processed per unit time exceeds the high concurrency threshold, it automatically splits the inventory shards corresponding to hot products into finer-grained sub-shards. When the number of documents processed per unit time is lower than the low concurrency threshold, it automatically merges multiple low-activity inventory shards into coarse-grained shards, dynamically balancing the probability of lock conflicts and the overhead of scheduling computing power.

[0008] Preferably, hierarchical traffic distribution and transaction rollback control are implemented for lock conflicts, specifically including the following steps: Before executing the inventory update operation, the data version number of the target inventory shard is compared. If the version numbers are inconsistent, a lock conflict is determined. The scope of the inventory shard involved in the conflict is identified. If it is a minor conflict across warehouses or sub-shards, only the inventory increase / decrease operation corresponding to the conflicting sub-shard is rolled back, the inventory update result of the conflict-free shard is retained, and the other conflict-free operations are executed in parallel. If a severe conflict occurs within the same shard, a complete transaction rollback is triggered, canceling all inventory updates, storage space occupancy, and status change operations corresponding to this document, and restoring the inventory data to the version before the operation. A lock conflict log is generated simultaneously, recording the conflicting document, shard number, conflict time, rollback scope, and conflict reason. When the conflict frequency of a single shard exceeds the set threshold within a unit of time, the automatic shard granularity splitting logic is triggered.

[0009] Preferably, the back-end control terminal constructs a fusion end-to-end digital twin topology model based on inventory shard status data to obtain the overall warehouse operation progress, material spatial inventory distribution, goods flow nodes, and shard conflict anomaly locations, specifically including the following steps: Based on the physical layout of the warehouse, the spatial coordinates of the storage location, and the nodes of the operation process, a basic topology for warehouse digital twin is constructed; inventory shard status data, lock conflict logs, and full-link data of document flow are accessed to perform spatial association and time-series fusion operations. The numerical data of inventory shards are mapped to the spatial coordinates of the corresponding physical storage locations to generate a heat map of material spatial inventory distribution; the document execution progress is associated with the location of the operators to generate a full warehouse operation progress view; the time sequence data of goods entering and leaving the warehouse is matched with process nodes to generate a goods flow node tracking link; the lock conflict log is mapped to the physical location of the corresponding shard to generate shard conflict anomaly location markers, and finally a global visualization situation view is formed.

[0010] Preferably, the optimization instructions for job paths and task allocation are sent to the mobile job terminal to adjust the order of data collection, and the optimization parameters for sharding granularity and lock weight are fed back to the inventory management server to adjust the concurrent scheduling logic. This specifically includes the following steps: Based on the overall warehouse operation progress and cargo flow nodes, identify the bottleneck areas of operation with task backlog and the positions with unbalanced personnel load. Combine the material space inventory distribution to plan the optimal operation path, generate operation path and task allocation optimization instructions, and send them to the mobile operation terminal in the corresponding area to adjust the execution order and task allocation of document collection, inbound and outbound operations. Based on the abnormal location of shard conflicts and material turnover rate data, high-frequency conflict hotspot shards and long-term idle low-conflict shards are identified. Shard granularity splitting / merging parameters, lock preemption weight adjustment parameters, and lock timeout time optimization parameters are generated and fed back to the inventory management server to update the inventory shard weight scoring model and optimistic lock scheduling rules.

[0011] Preferably, after the optimization instruction is issued, a self-optimizing closed loop is formed, specifically including the following steps: After receiving optimization instructions for job paths and task allocation, the mobile client re-plans the job execution order, adjusts the priority of data collection jobs, and synchronously adapts to the updated topology verification rules, and transmits the adjusted job execution data back to the backend management terminal in real time. After receiving the sharding granularity and lock weight optimization parameters, the inventory management server updates the dimension weights of the sharding weight scoring model, switches the granularity configuration of the corresponding shard, adjusts the timeout and retry strategy of optimistic lock scheduling, and sends the adjusted inventory sharding status data and conflict logs back to the backend management server in real time. The adjusted full data is re-input into the digital twin topology model to complete a new round of situation mapping and optimization analysis, forming a self-optimizing closed loop of data collection and purification, inventory, control and management, global intelligent scheduling, and reverse iterative optimization.

[0012] Secondly, embodiments of this application provide a warehouse management device for a warehouse management method, comprising: a mobile operation terminal, an inventory control server, and a back-end control terminal.

[0013] Thirdly, embodiments of this application provide an electronic device, which includes: The memory, processor, and computer program stored on the memory, wherein the processor is configured to run the computer program to execute the warehouse management method.

[0014] In the above setup, a three-layer progressive causal closed-loop architecture is constructed. A four-layer topology model for documents enables source data verification and incompleteness correction, outputting work orders with credibility identifiers. Dynamic sharding with multi-dimensional weights and associative optimistic locking scheduling balance conflict probability and computational overhead. Bidirectional optimization instructions are generated based on end-to-end digital twins, providing reverse support to upstream processes. Based on lightweight deployment, data accuracy, concurrency capacity, and the level of refined management are simultaneously improved, thereby enhancing the precision of warehouse management. Attached Figure Description

[0015] Figure 1 This is a structural block diagram of an electronic device according to an embodiment of this application.

[0016] Figure 2 This is a flowchart illustrating a warehouse management method according to an embodiment of this application.

[0017] Figure Labels 100. Electronic device; 11. Processor; 12. Memory. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in specific embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0019] It should be noted that the terms "first," "second," and similar terms used in this application specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, "one" or "a similar term" does not indicate a quantity limitation, but rather indicates the presence of at least one. "Multiple" indicates at least two. Terms such as "including" mean that the elements or objects appearing before "including" encompass the elements or objects listed after "including" and their equivalents, and do not exclude other elements or objects. Terms such as "connection" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0020] The singular form used in this application specification and appended claims, and the plural form, are also intended to include the plural form, unless the context clearly indicates otherwise.

[0021] The warehouse management method provided in this embodiment can be executed in electronic device 100 or similar device. Figure 1 This is a hardware structure block diagram of an electronic device 100 that implements an embodiment of this application. For example... Figure 1 As shown, the electronic device 100 may include one or more ( Figure 1(Only one is shown) memory 12 and processor 11. This electronic device 100 is the control terminal of the warehouse management device, which is used to detect the inventory of warehouse items, thereby improving the accuracy of subsequent warehouse management.

[0022] The memory 12 stores program instructions, such as software programs and modules for application software, like the computer program for a warehouse management method in this embodiment. The processor 11 executes the program instructions stored in the memory 12. By running the computer program stored in the memory 12, it can perform various functional applications and data processing, namely, acquiring relevant data for warehouse management.

[0023] The processor 11 may include, but is not limited to, a microprocessor 11 (Microcontroller Unit, abbreviated as MCU) or a programmable gate array (FPGA).

[0024] Those skilled in the art will understand that Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 100 described above. For example, the electronic device 100 may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0025] In some embodiments, a portion of the following warehouse management method is executed in electronic device 100, while the remainder of the warehouse management method is executed in a background control terminal to achieve warehouse management.

[0026] This embodiment also provides a warehouse management method, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating a warehouse management method according to an embodiment of this application. This method aims to improve the accuracy and efficiency of managing stored goods. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention. The specific steps of this warehouse management method are as follows: S1 pre-builds a four-layer topology ontology model of documents on the mobile work terminal, which includes four levels of subordinate nodes: document header, product item, serial number, and storage location. It transforms the mapping rules between products and serial numbers, the storage permission constraints between storage locations and products, and the correspondence rules between document type and quantity (positive and negative) into topological constraints between nodes.

[0027] In the above steps, the mobile client first completes the pre-construction and data collection and verification of the four-layer topological ontology model of the document. The four layers correspond to the inherent four-level hierarchical structure of warehouse documents. The topological ontology refers to a structured data model composed of constraints between nodes. Pre-construction means that this model is configured during the system deployment phase, rather than being generated temporarily during the operation. The core of this step is to transform unstructured business rules into computable structured constraints. Specifically, the four-layer topological ontology model of the document is divided into four levels of subordinate nodes from top to bottom: document header, product item, serial number, and storage location. The document header is the top-level root node, product items belong to their corresponding document headers, and serial numbers and storage locations belong to their corresponding product items, forming a clear subordinate mapping relationship. By constructing this model, the originally fragmented warehousing business rules that rely on manual judgment can be transformed into topological constraints that can be calculated and executed by the program between nodes. Specifically, it includes three core rules: the mapping rules between goods and serial numbers, the storage permission constraints between warehouse locations and goods, and the correspondence rules between document types and quantities (positive and negative). This gives the business rules that originally relied on manual verification a structured foundation that can be automatically calculated in real time.

[0028] Therefore, unlike the traditional model that deploys all verification logic on the backend and only returns verification results after the entire order is submitted, this step embeds topology constraints locally on the mobile work terminal. During the process of frontline personnel collecting raw warehouse data such as scanning and manual entry, a real-time topology verification is performed based on the topology constraints after each data entry is completed, and the corresponding credibility level is marked for the data nodes that pass the verification. For collected data with damaged barcodes or missing characters, the legitimate value range of the missing data is inferred based on the node characteristics that have been marked with credibility within the same document, and topology-aware completion is completed. Finally, a work order with a credibility level identifier is output. Through the above steps, data errors are corrected at the source of collection to avoid erroneous data flowing into the backend and causing subsequent inventory calculation deviations and transaction rollbacks. The core value of marking credibility levels is that it can provide a direct basis for the differentiated scheduling of subsequent inventory control links, so that the quality of front-end data can directly affect the processing efficiency of the backend. This step serves as the data entry layer for the entire warehouse management process. Its output of standardized and reliable documents is the only valid input for subsequent inventory control steps. This fundamentally reduces invalid lock contention and computing power consumption caused by dirty data, providing the necessary data quality prerequisites for the implementation of subsequent high-concurrency inventory control.

[0029] S2 performs topology verification on the collected raw warehouse data based on topology constraints and marks the node credibility. Based on the feature inference of the legal value range of the nodes with credibility marked in the same document, it performs topology-aware completion on the warehouse data with missing characters to output the work order with credibility level identifier.

[0030] In the above steps, the inventory control server receives the work order carrying the credibility level identifier output by the mobile work terminal and performs dynamic inventory sharding and optimistic locking scheduling. The weighted scoring model is a quantitative evaluation system used to assess the granularity of inventory sharding. Dynamic granularity sharding means that the sharding boundary is not fixed and can be dynamically adjusted according to the business load. The core of the associative dynamic optimistic locking is that the lock scheduling strategy is directly related to the credibility of the front-end document, rather than running independently.

[0031] Specifically, the inventory sharding weighted scoring model is a sharding evaluation system customized for the characteristics of warehousing operations. It selects four dimensions directly related to the frequency and importance of inventory operations—product turnover rate, storage area, document type, and operation priority—for weighted scoring. Unlike the fixed-rule sharding methods of general database systems, this model can dynamically shard inventory data according to the business patterns of warehousing scenarios. This allows for finer sharding of high-turnover, high-frequency hot-spot products, while low-turnover, low-frequency products are sharded with coarser merging, achieving a dynamic balance between the probability of lock conflicts and the computational cost of system scheduling. Based on the results of dynamic sharding, the system executes associative dynamic optimistic locking scheduling, directly linking the document credibility level output from the front end to the back end's lock scheduling strategy. For high-credibility work documents, the system allocates them to the priority lock queue and skips the duplicate data validity check on the back end, directly entering the inventory update process. For low-credibility work documents, they enter the queuing scheduling queue, complete the verification process according to the conventional procedure, and then request lock resources.

[0032] Simultaneously, the system monitors the current concurrent load in real time, dynamically adjusting the sharding granularity based on the peak and trough values ​​of document processing. Combined with a tiered transaction rollback control mechanism, differentiated rollback strategies are applied to lock conflicts of different ranges, ultimately outputting inventory sharding status data including lock conflict logs. This dynamic sharding reduces the probability of lock conflicts in high-concurrency scenarios, while reliability-based scheduling reduces wasted computational power from redundant verifications, improving the system's concurrent processing capabilities while ensuring inventory data consistency. This step receives highly reliable data input, fully utilizing front-end data verification results to improve back-end processing efficiency. Furthermore, its output of accurate inventory sharding status data and lock conflict logs forms the core data foundation for subsequent back-end management steps to conduct twin modeling and scheduling decisions, preventing upper-level scheduling failures due to underlying data distortion.

[0033] The S3 inventory management server receives work orders carrying a reliability level identifier. Based on product turnover rate, storage area, document type, and operation priority, it constructs an inventory sharding weight scoring model and performs dynamic granular sharding of warehouse data according to the weight score. Based on the results of dynamic granular sharding and the reliability level of the work order, it performs associative dynamic optimistic locking scheduling, allocating priority lock queues to high-reliability documents and skipping the duplicate data verification step, and performing queuing scheduling for low-reliability documents. At the same time, it dynamically adjusts the sharding granularity according to the real-time concurrency, performs hierarchical diversion and transaction rollback control for lock conflicts, and outputs inventory sharding status data including lock conflict logs.

[0034] In the above steps, the back-end management terminal constructs a fully integrated digital twin topology model based on the inventory sharding status data output by the inventory management server and executes closed-loop scheduling. Full-link integration means that the model does not only carry single-dimensional inventory data, but integrates multi-dimensional information such as space, process, and anomalies. Closed-loop scheduling means that scheduling instructions can act in reverse on the front-end execution links, forming a complete optimization cycle. Specifically, the fully integrated digital twin topology model is not a static data report that only displays inventory values ​​in the traditional sense. Instead, it is a digital mapping model based on the physical space layout of the warehouse, integrating multi-source data such as inventory sharding status, document flow process, and lock conflict anomalies. It can acquire and present four types of global status information in real time: overall warehouse operation progress, material space inventory distribution, goods flow nodes, and sharding conflict anomaly locations. These correspond to four management dimensions: personnel workload, material space distribution, business flow efficiency, and system anomaly nodes, providing comprehensive and intuitive status basis for global scheduling decisions. Unlike traditional digital twin systems that only have visualization capabilities and do not participate in actual business scheduling, this step generates two types of targeted optimization instructions based on the global situation presented by the twin model: one type is optimization instructions for work paths and task allocation, which are sent to the mobile work terminal to adjust the data collection order and task allocation of front-line personnel.

[0035] Another type involves optimizing parameters such as sharding granularity and lock weights, which are then fed back to the inventory management server to adjust the logic rules for concurrent inventory scheduling. Ultimately, this achieves optimized management and control across the entire warehouse supply chain through bidirectional command issuance. This upgrades backend management from passive post-event statistics to proactive in-process scheduling, filling the gap between traditional system management and execution. Based on the real operational data output from the first two steps, scheduling decisions are generated, and the optimization results are then applied back to the aforementioned steps. This creates a positive, progressive chain in the entire warehouse management process: data collection and purification, inventory management, and global intelligent scheduling. Consequently, it possesses the ability to create a reverse closed loop by optimizing scheduling to improve the efficiency of data collection and management.

[0036] The S4 backend management terminal constructs a fusion full-link digital twin topology model based on inventory shard status data to obtain the overall warehouse operation progress, material space inventory distribution, goods flow nodes and shard conflict and abnormal locations. It then sends operation path and task allocation optimization instructions to the mobile operation terminal to adjust the collection operation order and feeds back the shard granularity and lock weight optimization parameters to the inventory management server to adjust the concurrent scheduling logic in order to achieve warehouse management.

[0037] As one implementation method, topological verification is performed on the collected raw warehouse data based on topological constraints, and node credibility is marked. This specifically includes the following steps: Each time the mobile client completes the collection and entry of raw warehouse data, it immediately triggers the local topology verification engine. For the document header node, it verifies the matching of document type, operation date and permission scope; for the product item node, it verifies the consistency of product SKU, quantity and total document quota; for the serial number node, it verifies the affiliation relationship between serial number and corresponding product SKU; and for the storage location node, it verifies the compatibility of storage location permissions and product category. If the verification fails, the current input is immediately intercepted and the corresponding node's error message is output; if the verification passes, the node is marked with the corresponding credibility level.

[0038] Simultaneously, a two-way synchronization channel for the semantic verification rules between the mobile operation terminal and the back-end management terminal is established. After the back-end management terminal updates business constraints such as pricing strategies, storage permissions, and batch number validity rules, it actively pushes the rule changes to the mobile operation terminal. The mobile terminal updates the topology constraint condition library in real time to perform topology verification on the collected raw warehousing data and mark the node credibility.

[0039] In the above steps, the local topology verification engine is triggered immediately upon each instance of raw warehouse data collection and entry completed by the mobile work terminal. This feature forms the basis of the entire real-time verification mechanism, determining the timing and execution location of verification. It moves the verification process from backend batch processing to the frontend data collection site, completely changing the previous serial operation mode of data entry followed by verification. This triggering mechanism is a prerequisite for source error interception. Only by completing verification simultaneously with data collection can errors be detected and corrected immediately while frontline workers are still on-site, avoiding the efficiency losses caused by batch rework after the entire order is submitted. Simultaneously, the node-by-node triggering verification mode provides the execution basis for subsequent layered verification and node-by-node credibility marking, ensuring that each data node has an independent verification result, providing granular support for subsequent refined credibility grading.

[0040] The document header node, as the top-level root node, focuses on the overall legality and permission boundaries of the document. Document type verification matches the rule systems of different business scenarios such as procurement, sales, and inventory. Operation date verification controls the time compliance and modification permissions of the document. Permission scope verification matches the job function permissions and field permissions of the current operator, ensuring the overall compliance of the document from the top level. The product item node, as the intermediate core node, focuses on the logical consistency of detailed data. Product SKU verification confirms the validity of product information and its existence within the system. Quantity verification checks the aggregation relationship between detailed quantities and the total document quota, avoiding logical errors where the sum of item quantities exceeds the total document amount. The serial number node, as a single-item-level detailed node, focuses on the hierarchical relationship between individual items and products, ensuring that each serial number corresponds to the correct product SKU, supporting the need for refined serial number lifecycle management in warehousing. As a spatial dimension node, the storage location node focuses on the compatibility of physical storage rules to verify whether the current product is allowed to be stored in the designated location, thus avoiding warehousing violations such as mixed or incorrect placement.

[0041] The four-layer node differential verification corresponds one-to-one with the subordinate levels of the topology model, forming a comprehensive verification system from top to bottom, from the overall to the detailed, and from business rules to physical rules. This covers all constraint dimensions of the document, from attributes to quantity, and from individual items to space. The results of layered verification directly determine the credibility of the marked nodes; whether each node passes or fails verification directly determines its credibility level, thus affecting the overall credibility of the entire work order. Simultaneously, the constraint rules at each level provide boundary constraints for subsequent missing data processing, ensuring that the relevant data processing results conform to the topology requirements of each level. Furthermore, layered verification ensures full-dimensional compliance of the document from the overall to the detailed, preventing erroneous data from flowing into subsequent inventory control stages. This reduces logical conflicts and transaction rollbacks during inventory updates at the source, lowering backend computational overhead and data risk.

[0042] In this implementation, the features of immediately intercepting and outputting corresponding node error messages when verification fails, and marking the credibility level when verification passes, constitute the feedback and output links of the real-time verification mechanism. Immediate interception means blocking the current data entry process, preventing operators from entering the next data item, forcing error correction, and avoiding the accumulation of erroneous data that is only exposed after the entire order is submitted. The corresponding node error message accurately locates the error information to the specific node level and field, facilitating quick problem identification and correction by operators, reducing troubleshooting time. The credibility level is a credibility identifier assigned to each node based on the verification result. It transforms the verification result into a quantifiable and transferable data label, used to distinguish the credibility levels of different data in subsequent stages, and is the core carrier of cross-layer data linkage. This feature forms a complete closed loop of collection—verification—feedback / marking. The collection action triggers verification, and the verification result either triggers interception and error messages to guide correction, or completes credibility marking to enter the next stage, ensuring that each piece of entered data has a clear verification conclusion and status identifier. Furthermore, real-time interception and precise prompts directly improve the efficiency and accuracy of front-end data collection, reduce the cost of rework and reconciliation afterward, and strengthen the core role of the data collection and purification layer. Meanwhile, the credibility level label is the key data link connecting the front-end collection layer and the back-end inventory control layer. The inventory control server can perform relational dynamic optimistic locking scheduling and allocate priority queues for high-credibility documents, so that the data quality of the front end can directly affect the processing efficiency of the back end, forming a cross-layer causal linkage relationship.

[0043] Furthermore, establishing a bidirectional semantic synchronization channel between the mobile client and the backend management end for verification rules is a fundamental support for ensuring the long-term stable operation of the verification mechanism. Bidirectional semantic synchronization differs from simple rule file distribution; it emphasizes consistency in the semantic understanding and parsing logic of constraints between the front-end and back-end, avoiding discrepancies in the parsing results of the same rule and ensuring uniformity in rule execution. Proactive push refers to the backend management end actively pushing the updated business rules to the online mobile client, rather than waiting for the mobile client to actively retrieve them, ensuring real-time rule updates. The topology constraint library is a structured database that stores all verification rules locally on the mobile client. It forms the rule foundation for the local topology verification engine and supports local offline verification capabilities. These features solve the common problem of asynchronous rule updates in traditional front-end and back-end separation architectures. When the backend management end updates business constraints such as pricing strategies, storage permissions, and batch number validity rules, it can update the constraint library on the mobile client in real time through the synchronization channel, ensuring that the front-end verification rules and backend management rules remain consistent. This avoids the problem of verification failures where the front-end passes but the back-end rejects, eliminating the potential data conflict risks caused by rule asynchrony.

[0044] Furthermore, the rule synchronization mechanism ensures the authority and validity of front-end verification results, guaranteeing that documents marked as highly reliable on the front end also comply with business rules on the back end. This maintains the consistency and reliability of reliability level identifiers, thereby ensuring the rationality of subsequent inventory control scheduling based on reliability. It prevents highly reliable documents from failing back-end verification and wasting priority scheduling resources due to rule discrepancies. Simultaneously, the two-way synchronization channel allows back-end rule changes to be quickly implemented on the front-end, without waiting for mobile app updates, improving the flexibility of rule adaptation in warehouse management.

[0045] As one implementation method, based on the feature inference of the legal value range of the credibility nodes already marked in the same document, topology-aware completion is performed on the warehouse data with missing characters. The specific steps include: Identify the topological node level to which the missing data belongs, and locate its parent node and sibling nodes in the four-level topological ontology model of the document; extract the attribute features, value ranges, and constraint rules of the topological nodes at the same level within the same document that have passed the verification, and infer the legal value range of the missing data in combination with the topological constraints of the parent node; automatically complete the missing field content that conforms to the topological constraints based on the inference results; after completion, re-execute the full node topological verification, and if the verification passes, mark the corresponding confidence level for the completed data; if the verification fails, return to re-infer the value range.

[0046] In the above steps, the topology node level to which the missing data belongs is identified, and its parent node and sibling nodes in the four-layer topology ontology model of the document are located. The topology node level is not a simple classification of character format, but rather a business hierarchy of a predefined four-level structure of document header, product item, serial number, and storage location. The basis for determining the level is the business context of data collection, not the form of the characters themselves. The parent node refers to the direct superior node of the currently missing node in the topology hierarchy link, bearing the strong business constraints of that level. The sibling node refers to the same level node that shares the same parent node and has completed verification and credit rating, carrying the common feature reference of similar data.

[0047] In practice, the system first analyzes the context of the missing data collection scenario. If the missing data occurs during the serial number scanning and entry stage, it determines the serial number node to which it belongs; if the missing data occurs during the warehouse location scanning and selection stage, it determines the storage location node to which it belongs; and if the missing data occurs during the product quantity entry stage, it determines the product item node to which it belongs. After the hierarchy is determined, the system automatically matches the corresponding parent node based on the binding relationship of the current document line. The parent node of both the serial number node and the storage location node is the product item node of the current document line, and the parent node of the product item node is the document header node. At the same time, it pulls all verified nodes under the same document and the same parent node as peer reference nodes. The direct technical effect of this step is to transform the traditional image character repair problem into a node completion problem under the constraints of business structure. From the beginning of the completion stage, invalid candidates across categories and levels are eliminated. For example, a missing serial number will never be completed as the code corresponding to another product SKU, avoiding the fundamental error of similar character shapes that do not conform to business logic, which is easy to occur in pure image recognition.

[0048] Then, the attribute features, value ranges, and constraint rules of the topological nodes at the same level within the same document that have passed verification are extracted. Combined with the topological constraints of the parent node, the legal value range of the missing data is inferred. Attribute features refer to the common format patterns exhibited by nodes at the same level, including encoding prefixes, total character length, fixed-position rule characters, batch number segment rules, etc., which are common features at the format level. Value ranges refer to the legal numerical boundaries of value-type fields, which are pre-set by business rules, such as upper and lower limits of product quantity, batch number validity period range, etc. Constraint rules are the pre-converted topological constraints between nodes, which are mandatory business rules that must be met. The legal value range refers to the complete set of candidate values ​​that simultaneously satisfy all constraints; it is not a single optimal solution, but a candidate set sorted by matching degree.

[0049] In practice, the system performs three types of feature extraction on verified nodes at the same level: for coded fields, it extracts prefix characters, total length, fixed-position rule characters, and number segment patterns of codes in the same batch; for numerical fields, it extracts legal upper and lower limits and numerical precision rules; and for rule-based fields, it extracts effective subordinate constraints and permission constraints. Based on this, it overlays binding constraints carried by the parent node, such as the SKU code, product category, and document quantity quota corresponding to the parent node of the product item. Combined with preset topological constraints such as the sequence number belonging to the corresponding SKU and the warehouse location matching the product category, it performs layer-by-layer convergence filtering on the initial candidate set, eliminating all values ​​that violate any constraint. Finally, it obtains the legal value range of the missing field and sorts the candidate values ​​in descending order according to feature matching degree. This step replaces the core basis for completion from pixel similarity to the structured rules of warehousing operations. The completion result naturally conforms to business logic such as product ownership, storage permissions, and quantity matching, avoiding invalid completions that are formatted correctly but do not conform to actual business rules. Simultaneously, it outputs a candidate set instead of a single result, reserving correction space for subsequent iterative verification. The extracted constraint rules are directly derived from the topological constraints between the transformed nodes, ensuring that the completion rules and the overall verification rules are completely from the same source; all extracted node data are marked as trusted nodes, ensuring the reliability of the reasoning basis; the range of legal values ​​derived from the reasoning is the only input boundary for the next completion operation, ensuring that the completion action will never exceed the bottom line of the business rules.

[0050] Based on the above steps, the system automatically completes the missing field content that conforms to topological constraints based on the inference results. Automatic completion means the system proactively fills in the missing field content, eliminating the need for manual input of complete missing characters by operators. Conforming to topological constraints means the final filled value must be taken from the legal value range, and the system defaults to selecting the candidate value with the highest matching degree, prohibiting any values ​​outside the range. In practice, the system selects the result with the highest matching degree from the candidate set of legal values ​​and automatically fills in the current missing field. The mobile interface simultaneously highlights the completed field and provides a manual confirmation entry point. Operators can directly confirm the result or manually correct the completed content. This step solves the problems of repeated scanning and low efficiency of manual data entry in scenarios involving damaged barcodes and blurred characters, shortens the processing time for a single missing data entry, and reduces the interruption rate of on-site operations. The local execution feature also adapts to the unstable network environment of the warehouse, avoiding interruptions to the workflow due to network latency. Furthermore, the completion operation in this step does not assign any credibility attribute to the data. After completion, it must proceed to the next verification stage, which is completely consistent with the execution process of verification first and then marking, in order to avoid automatic completion in the warehouse management process lowering the verification standard. The completed fields will eventually be incorporated into the entire work order as part of the output document, without destroying the overall data structure and format specifications of the document.

[0051] Finally, after completion, a full-node topology check is re-executed. If the check passes, the completed data is assigned the corresponding confidence level; otherwise, the process returns to the re-inference value range. The full-node topology check does not only check the currently completed single node, but performs a complete review of all fourth-level nodes in the entire document to prevent the completion operation from disrupting the overall aggregation logic of the document. The corresponding confidence level refers to assigning a unique confidence level to the completed data, distinct from the original collected data, preserving the difference in data source. Returning to the re-inference value range is an iterative correction mechanism, which removes erroneous values ​​from the candidate set and selects the next-ranked candidate value to re-execute the completion.

[0052] In practice, after the completion and filling are completed, the system triggers a local topology verification engine to perform a complete topology verification on all four levels of nodes: document header, product items, serial numbers, and storage locations. This verification not only checks the compliance of the constraints of the completion node itself but also verifies the overall aggregation logic of the document. For example, after completing the serial numbers, does the total number of serial numbers match the number of product items? After completing the storage locations, does it comply with the storage permission constraints of the product category? If the verification passes, a unique completion category credibility level is marked for the completion node, and it is included in the credibility identification system of the entire document. If the verification fails, the current candidate value is removed from the legal value range, and the next candidate value in the sorting order is selected to re-execute the completion. This verification process is repeated until the completion result passes the verification, or the candidate set is exhausted, prompting the operator for manual intervention. The direct technical effect of this step is to ensure that the completed data and the original collected data are executed with completely consistent verification standards, preventing the completion operation from becoming a loophole in data verification. The full-node re-verification design avoids the problem of partial correctness but overall logical conflict. The hierarchical credibility label retains the differences in data quality and does not confuse the credibility levels of the original collected data and the completed data, ensuring that the credibility labels obtained in subsequent steps are accurate and distinguishable. The topology verification engine and credibility labeling system directly reused in this step ensure that the verification standards are completely consistent before and after. The final output completed node carries a standardized credibility level, conforms to the format requirements of the work order, and can be directly used as input for subsequent steps to avoid the data completion from damaging the front-end data quality and the linkage logic of subsequent processing steps. The iterative correction mechanism further ensures the accuracy of the completion and reduces the probability of erroneous data flowing out of the front end.

[0053] As one implementation method, associative dynamic optimistic locking scheduling is performed based on the results of dynamic granularity partitioning and the reliability level of the job document, specifically including the following steps: Based on the credibility level carried by the work order, the documents are divided into a high-credibility priority queue and a normal priority queue. High-credibility priority documents directly enter the lock allocation priority channel, skipping the data validity verification of the inventory control server, and are configured with a longer lock timeout and more automatic retries. Normal priority documents enter the queuing channel and are sorted by the time of receipt to perform data verification and lock resource application in sequence. The system monitors the concurrent load in real time. When the number of documents processed per unit time exceeds the high concurrency threshold, it automatically splits the inventory shards corresponding to hot products into finer-grained sub-shards. When the number of documents processed per unit time is lower than the low concurrency threshold, it automatically merges multiple low-activity inventory shards into coarse-grained shards, dynamically balancing the probability of lock conflicts and the overhead of scheduling computing power.

[0054] In the above steps, to avoid pre-classifying documents into high-reliability priority queues and ordinary priority queues based on the reliability level carried by the work order, the correlation in the associative dynamic optimistic locking means that the scheduling strategy of lock resources is not independent of the front-end data collection stage, but is directly bound to the reliability level of the documents output by the front-end. This breaks the traditional architectural paradigm of independent operation of front-end and back-end business modules and repeated verification at each layer. The high-reliability priority queue is not a regular priority queue divided solely based on business importance. Its determination is directly derived from the reliability identifier output by the front-end topology verification stage, which is a priority at the data quality level, not simply a business priority. Skipping duplicate data verification does not mean omitting all verification stages, but rather skipping the data validity verification that overlaps with the front-end topology verification content, thus maintaining inventory consistency.

[0055] In practice, after receiving a work order, the inventory control server first reads the credibility level identifier carried by the order. Orders marked as having passed the original data collection and full verification are placed in a high-credibility priority queue, while orders with lower credibility levels, including those containing completed fields or manual corrections, are placed in a normal priority queue. Orders in the high-credibility priority queue directly enter the lock allocation priority channel, without repeating the verification of product SKU validity, serial number and product affiliation, warehouse storage permissions, and quantity logical consistency—all of which have already been verified at the front end through four layers of topology. Only inventory version number comparison and inventory update operations are retained. At the same time, a longer lock timeout and more automatic retries are configured for high-credibility orders to reduce the probability of failure due to momentary conflicts. Orders in the normal priority queue enter the queuing channel and are sorted according to the time of receipt. They first complete the full data validity verification, and after confirming that all fields comply with business rules, they then apply for lock resources in sequence to execute inventory updates.

[0056] This step targets the most prevalent, high-reliability data collection documents, directly eliminating redundant backend verification steps. This significantly reduces ineffective computing power consumption and shortens the processing time for a single document. Prioritizing lock resource allocation also ensures the processing efficiency of mainstream business operations. On the other hand, the complete verification process for ordinary documents is retained to improve data security. Unlike existing technologies that perform complete verification on all data regardless of quality, this implementation uses differentiated scheduling based on frontend verification results. This allocates computing resources to high-quality data, avoiding redundant work caused by frontend verification results not being reused by the backend. Furthermore, the scheduling results of this step improve the execution order and processing efficiency of inventory updates, providing a foundation for subsequent lock conflict handling and inventory status output. The more orderly the document scheduling, the lower the probability of subsequent conflicts.

[0057] Then, the system's concurrent load is monitored in real time, and the inventory sharding granularity is dynamically adjusted based on the load threshold. Dynamic granularity sharding differs from the static sharding mechanism of traditional warehousing systems, which uses fixed SKUs and warehouses. The boundaries and coarseness of sharding are not set once during system deployment but are dynamically adjusted according to real-time concurrent load. High and low concurrency thresholds are preset load thresholds based on system computing power and business characteristics, used to trigger shard splitting and merging actions. Hot commodities, i.e., those with high turnover and high operation frequency in the inventory sharding weight scoring model, are high-incidence areas of concurrent conflicts and are the core targets of sharding adjustments. Dynamically balancing lock conflict probability and scheduling computing power overhead is the core objective of this mechanism, requiring a balance between reducing conflicts and lowering management costs.

[0058] In practice, the inventory management server continuously monitors the document processing volume per unit time and calculates the overall system concurrency load. When the document processing volume per unit time exceeds the preset high concurrency threshold, the system is considered to be entering a peak business period. At this time, based on the multi-dimensional weighted scoring model, the system automatically identifies the inventory shards corresponding to high-turnover, high-frequency operation hot items and splits the originally coarse shards into finer-grained sub-shards. For example, shards merged by product category are split into independent sub-shards based on single SKU and single warehouse location. By reducing the coverage of a single shard, the probability of multiple documents operating on the same shard is reduced, thus lowering the possibility of lock conflicts. When the document processing volume per unit time is lower than the preset low concurrency threshold, the system is considered to be entering a low business period. At this time, the system automatically identifies multiple inventory shards with long-term low activity and low operation frequency and merges them into a single coarse-grained shard, reducing the total number of shards and lowering the system computing power overhead caused by shard management and lock scheduling. This step addresses the issue of traditional fixed-granularity sharding failing to handle both high and low-peak scenarios. It avoids the problem of fixed, fine sharding generating excessive scheduling overhead during off-peak periods, while fixed, coarse sharding leads to frequent lock conflicts during peak periods. The dynamic granularity adjustment mechanism adaptively matches the optimal sharding granularity to the business load. During high concurrency, finer sharding reduces conflict probability and improves parallel processing capabilities, while coarser sharding compresses scheduling costs during low concurrency. This achieves a dynamic balance between lock conflict probability and system scheduling overhead, ultimately improving the overall system efficiency under different loads. The sharding dimensions in this step are based on a multi-dimensional inventory sharding weight scoring model. Weight data for dimensions such as product turnover rate and storage area are the core basis for identifying hot products and defining sharding boundaries. Simultaneously, adjusting the sharding granularity directly affects the conflict probability of optimistic lock scheduling in the previous step; finer sharding results in fewer conflicts within the same shard and higher execution smoothness of the priority queue. Improved front-end data collection efficiency leads to an increase in the number of documents. This increase in document volume triggers data sharding and splitting, which in turn enhances the back-end's concurrent processing capacity, thereby supporting the efficient processing of more front-end jobs and creating a positive synergistic benefit.

[0059] As one implementation method, hierarchical distribution and transaction rollback control are performed on lock conflicts, specifically including the following steps: Before executing the inventory update operation, the data version number of the target inventory shard is compared. If the version numbers are inconsistent, a lock conflict is determined. The scope of the inventory shard involved in the conflict is identified. If it is a minor conflict across warehouses or sub-shards, only the inventory increase / decrease operation corresponding to the conflicting sub-shard is rolled back, the inventory update result of the conflict-free shard is retained, and the other conflict-free operations are executed in parallel. If a severe conflict occurs within the same shard, a complete transaction rollback is triggered, canceling all inventory updates, storage space occupancy, and status change operations corresponding to this document, and restoring the inventory data to the version before the operation. A lock conflict log is generated simultaneously, recording the conflicting document, shard number, conflict time, rollback scope, and conflict reason. When the conflict frequency of a single shard exceeds the set threshold within a unit of time, the automatic shard granularity splitting logic is triggered.

[0060] In the above steps, before the inventory update operation is executed, the data version number of the target inventory shard is compared. If the version numbers are inconsistent, a lock conflict is determined to have occurred. The data version number is an incrementing identifier field bound to each independent inventory shard and is the core verification carrier of the optimistic locking mechanism. Unlike the blocking control of pessimistic locking that pre-occupies resources, optimistic locking does not lock in advance. It only checks for concurrent conflicts by comparing versions when the data is submitted for update. If there is no conflict, there is no blocking at all. Determining that a lock conflict has occurred does not mean that the operation is wrong, but that the current shard data has been modified by other concurrent operations, and the basic data read by this operation has become invalid. Continuing to update will lead to data overwriting errors.

[0061] In practice, after each document enters the inventory update stage, it first reads the current version number of all target inventory shards involved, and then executes the inventory add / delete update statement with that version number. If the database returns zero affected rows after execution, it indicates that the version number of the target shard has been modified by other operations during the read and update interval, and the baseline data for this operation has expired, thus indicating a lock conflict. This step uses a non-blocking optimistic lock verification mechanism to replace the traditional pessimistic lock pre-occupancy. In typical scenarios with fewer concurrent conflicts, all operations do not need to queue for lock resources and can directly execute updates, significantly reducing system scheduling overhead under normal conditions and improving the overall response speed of inventory updates. The binding granularity of version numbers corresponds perfectly to the dynamic sharding granularity. The finer the sharding, the smaller the inventory range covered by a single version number, and the smaller the operational scope affected by a single conflict. At the same time, this step is the core consistency verification link retained at the inventory level after high-reliability documents skip duplicate business verification. Even if the front end has completed full topology verification and the back end has skipped business rule verification, the version number comparison, this bottom-line verification, is always retained. This mechanism safeguards the core requirement of inventory data consistency, both reusing the data verification results from the front end to improve efficiency and without sacrificing the bottom line of data security.

[0062] Then, identify the scope of the inventory shards involved in the conflict. If it is a minor conflict across warehouses or sub-shards, only roll back the inventory increase / decrease operations corresponding to the conflicting sub-shards, retain the inventory update results of the conflict-free shards, and execute the remaining conflict-free operations in parallel. Tiered processing means that conflicts are divided into different levels according to the scope of the shards covered by the conflict, and different rollback and handling strategies are adopted for each level, rather than the coarse mode of rolling back the entire order as soon as a conflict occurs in the traditional solution. Minor conflicts refer to a single document involving multiple independent inventory shards, of which only a small number of shards have version conflicts, and the remaining shards are in a state that can be updated normally. The conflict does not cover all the operation objects of the document.

[0063] In practice, upon determining a lock conflict, the system immediately disassembles all inventory shards associated with the current document, verifies the version matching status of each shard, and counts the number and proportion of conflicting shards. If the conflict only occurs in a few sub-shards, and the remaining shards can be committed normally, it is determined to be a minor conflict. At this time, the system performs a partial transaction rollback, only canceling the inventory increase / decrease and warehouse space occupancy operations corresponding to the conflicting sub-shards, restoring the data of the conflicting shards to their pre-operation state; all conflict-free shard operations are committed and take effect normally, and multiple conflict-free operations can be executed in parallel without waiting for conflict resolution to complete. The direct technical effect of this step is to compress the scope of transaction rollback to the smallest unit, avoiding the waste of computing power caused by a single conflict rendering the entire order invalid. Most valid operations of a single document can be successfully implemented, with only a small number of conflicting operations entering the retry or queuing process, significantly improving the overall success rate of document processing and system resource utilization in high-concurrency scenarios, and also reducing the overhead of repeated submissions caused by rolling back the entire order. The implementation of tiered rollback relies entirely on a dynamic granular sharding architecture. Because inventory data is split into multiple independent sub-shards, each with its own version number, partial rollback and parallel commit are possible. The finer the sharding granularity, the more shards a single document involves, the higher the proportion of minor conflicts, and the more significant the performance gain of tiered rollback becomes, creating a positive synergistic benefit with the dynamic sharding mechanism. At the same time, this mechanism is compatible with the retry configuration of high-reliability documents, allowing sub-shards with minor conflicts to quickly complete a second commit using more automatic retries, further reducing the impact of conflicts on business execution.

[0064] Based on the above steps, if a severe conflict occurs within the same shard, a complete transaction rollback is triggered, undoing all inventory updates, storage space occupancy, and status change operations corresponding to this document, restoring the inventory data to the version before the operation. A lock conflict log is generated simultaneously, recording the conflicting document, shard number, conflict time, rollback scope, and conflict reason. A severe conflict refers to a conflict covering all core operation shards of a single document, or a scenario where concurrent contention within the same shard is intense, and multiple retries still fail to pass version verification. The complete transaction rollback adheres to the atomicity principle of database transactions, undoing all inventory operations and status changes associated with this document, ensuring that the data does not enter an intermediate state of partial effectiveness and partial invalidation. The lock conflict log is a structured runtime record, not a simple error message, but rather carries multi-field statistical data based on shard, time, and business dimensions, serving as the core data basis for subsequent optimizations.

[0065] In practice, if the verification finds version conflicts in all core inventory shards of the current document, or if a single shard fails version verification after a preset number of retries, it is considered a severe conflict. At this point, the system triggers a complete database transaction rollback, undoing all inventory value updates, warehouse occupancy markers, and document processing status changes corresponding to this document. All relevant data is strictly restored to the initial version before the operation, preventing discrepancies between records and actual inventory, overselling, and negative inventory caused by partial updates. After the rollback, the system automatically generates a structured lock conflict log, persistently storing core fields such as the conflicting document identifier, involved shard number, conflict occurrence time, rollback operation scope, and conflict triggering reason, forming a statistically analyzable conflict dataset. The direct technical effect of this step is that, in high-concurrency, intense conflict scenarios, atomic rollback strictly ensures the consistency and accuracy of inventory data, safeguarding the bottom line of data security. Simultaneously, the structured conflict log transforms scattered conflict events into quantifiable operational data, providing data support for system optimization and avoiding the problem of having no trace of conflict after it occurs and only being able to passively respond. The complete rollback mechanism and optimistic locking scheduling complement each other. Optimistic locking is responsible for improving the processing efficiency in normal scenarios, while complete rollback is responsible for ensuring data security in extreme scenarios. Together, they constitute a concurrency control system that balances efficiency and security, providing a real operational basis for subsequent system management and optimization.

[0066] Finally, when the frequency of conflicts in a single shard exceeds a set threshold within a unit of time, the automatic shard splitting logic is triggered. The conflict frequency threshold is a pre-set critical value for the number of conflicts per unit of time for a single inventory shard, used to quantitatively determine whether a shard is a hot shard. Unlike the adjustment triggering conditions based on global concurrent load, this is a precise triggering mechanism for a single shard. The automatic shard splitting logic is a self-adjusting mechanism that requires no manual intervention. It directly adjusts the shard structure in reverse based on conflict data, reducing the probability of conflicts at the source.

[0067] In practice, the system continuously counts the number of lock conflicts occurring in each independent inventory shard within a unit of time, calculating the conflict frequency in real time. When the conflict frequency of a shard continuously exceeds a preset threshold, the shard is identified as a high-frequency conflict hotspot shard, indicating that the current shard granularity is too coarse to handle the current concurrent operation volume. At this point, the system automatically triggers shard splitting logic, splitting the coarse-grained shard into multiple finer-grained sub-shards according to dimensions such as product SKU and storage location. Each sub-shard is assigned an independent data version number and lock scheduling queue, and the splitting takes effect automatically after completion. The direct technical effect of this step is to form a single-point self-adjusting closed loop of conflict occurrence—statistical identification—structural optimization—conflict reduction. It accurately splits hotspot shards, reducing concurrent contention within the same shard from the root, rather than waiting for the global load to increase before making unified adjustments. The optimization is more targeted and can quickly suppress the surge in conflicts caused by local hotspots, ensuring that the shard granularity always adapts to the actual business concurrency pressure. This step complements and extends the dynamic granularity sharding mechanism. It macroscopically adjusts the sharding granularity from the perspective of global concurrent load, while this step microscopically optimizes the sharding conflict frequency. Together, they constitute a complete dynamic sharding adjustment system. At the same time, this mechanism upgrades the conflict handling process from passive post-event remediation to proactive root cause optimization. Conflict data drives the sharding structure iteration in reverse, further reducing the probability of subsequent conflicts and forming a small-scale causal closed loop within the inventory control layer.

[0068] As one implementation method, the back-end control terminal constructs a fusion end-to-end digital twin topology model based on inventory shard status data to obtain the overall warehouse operation progress, material spatial inventory distribution, goods flow nodes, and shard conflict anomaly locations. Specifically, this includes the following steps: Based on the physical layout of the warehouse, the spatial coordinates of the storage location, and the nodes of the operation process, a basic topology for warehouse digital twin is constructed; inventory shard status data, lock conflict logs, and full-link data of document flow are accessed to perform spatial association and time-series fusion operations. The numerical data of inventory shards are mapped to the spatial coordinates of the corresponding physical storage locations to generate a heat map of material spatial inventory distribution; the document execution progress is associated with the location of the operators to generate a full warehouse operation progress view; the time sequence data of goods entering and leaving the warehouse is matched with process nodes to generate a goods flow node tracking link; the lock conflict log is mapped to the physical location of the corresponding shard to generate shard conflict anomaly location markers, and finally a global visualization situation view is formed.

[0069] In the above steps, a basic topology for a warehouse digital twin is constructed based on the physical layout of the warehouse, the spatial coordinates of storage locations, and the nodes of the operational process. Inventory shard status data, lock conflict logs, and full-link data of document flow are integrated, and spatial association and temporal fusion operations are performed. This basic topology for the warehouse digital twin is not a traditional 3D rendering model, but a structured mapping framework with physical spatial entities and business process nodes as its skeleton. All business and operational data are mounted on this framework, unlike the traditional flat data display mode of back-end reports that lacks space and process flow. Spatial association refers to matching abstract logical shards and log data with corresponding physical spatial coordinates, giving purely numerical data spatial location attributes. Temporal fusion refers to aligning and calibrating data from different sources and with different frequencies according to timestamps, forming a continuous and consistent time series, and avoiding temporal misalignment between different data.

[0070] In practice, the first step is to build the basic topology: input the physical layout parameters of the warehouse, including warehouse area division, shelf arrangement, and spatial coordinates of each storage location. Simultaneously, identify the standard process nodes for inbound operations, including key steps such as inspection, shelving, sorting, verification, and outbound. Physical storage locations and process nodes are uniformly abstracted into topology nodes, clarifying the spatial adjacency and process sequence relationships between nodes. This establishes the basic framework of the twin model, ensuring that each physical storage location is bound to unique spatial coordinates and the attributes of its associated process node. After completing the basic framework, the system connects to three core data sources: the first is the output inventory shard status data, including the real-time inventory quantity, data version number, shard number, and corresponding SKU information for each inventory shard; the second is the generated structured lock conflict log, including the shard number, occurrence time, rollback scope, and conflict reason for each conflict; and the third is the full-link data of document flow, including the current execution status of each document, the bound operator, and the current process node.

[0071] In this step, after data access is complete, the system performs two types of core operations: one is spatial association operation, which establishes a mapping relationship between logical inventory shards and physical storage locations, matching each inventory shard and each conflict log to the spatial coordinates of the corresponding physical storage location, anchoring abstract logical data to real physical spatial locations; the other is temporal fusion operation, which aligns and calibrates three types of data with different update frequencies according to a unified timestamp, ensuring that inventory status, operation progress, and conflict events correspond to each other in the same time dimension, eliminating temporal discrepancies between data, and forming a continuous dynamic situational data stream. This step unifies and integrates multi-source heterogeneous data that was originally scattered in the front-end acquisition layer and inventory control layer into a unified framework of physical space + business process, solving the problems of fragmented traditional back-end data, disconnect between inventory data and physical space, and separation between business processes and system operation data, allowing scattered data to form a unified situational foundation that is spatially locateable and temporally traceable. The digital twin basic topology is the carrier of all subsequent visualization mappings, enabling various subsequent views to generate a unified presentation benchmark. Meanwhile, spatial correlation and temporal fusion calculations are also necessary preprocessing steps for generating the subsequent four types of visualization views. This is to ensure that subsequent inventory distribution, work progress, circulation links, and conflict markers are not isolated and fragmented charts, and cannot form a globally unified and interconnected situational view.

[0072] Then, the visualization mapping of the four types of data is completed in sequence, and finally a global visualization situation view is formed.

[0073] This step maps the numerical data of the inventory segments to the spatial coordinates of the corresponding physical storage locations, generating a material spatial inventory distribution heatmap. This heatmap is not simply a bar chart of inventory quantities; rather, it uses the warehouse's physical layout as a base map and employs color gradients to represent the spatial distribution of inventory levels and turnover rates, essentially showcasing the spatial distribution characteristics of the inventory.

[0074] In practice, based on the mapping relationship obtained from spatial correlation calculations, the real-time inventory quantity, material category, and historical turnover rate data corresponding to each inventory segment are assigned to the coordinate points of the corresponding physical storage location. A preset color gradient rule distinguishes between high and low inventory levels and turnover rates; for example, high-inventory, low-turnover areas are marked with dark colors, and low-inventory, high-turnover areas with light colors. This ultimately forms an inventory heat map covering all storage areas in the entire warehouse. Managers can zoom in and out and interact with points to view detailed inventory information for any storage location. The direct technical effect of this mapping is to transform abstract inventory segment values ​​into an intuitive spatial distribution image. Managers can quickly grasp the spatial distribution status of the entire warehouse's inventory without having to query storage location values ​​one by one, intuitively identifying areas of inventory backlog and idle storage capacity, significantly improving the efficiency of perceiving the overall inventory status. This view is a core component of the global situational awareness view, providing intuitive spatial data for warehouse location planning and inventory allocation.

[0075] Secondly, the document execution progress is linked to the location of operators to generate a full-warehouse operation progress view. This view is a dynamic one that integrates task execution status and personnel spatial distribution, presenting the real-time task load and location of each warehouse area and each operator. During execution, real-time location data of operators transmitted from mobile terminals is integrated with the currently bound document information. The execution status of each document is matched with the physical warehouse area where the operator is located, marking the task saturation, number of on-duty personnel, and document completion rate of each area on the twin-structured topology, forming a dynamically updated panoramic view of the full-warehouse operation progress. This mapping allows for real-time monitoring of the warehouse's workload distribution and personnel on-duty status, quickly identifying areas with task backlogs, replacing the inefficient traditional method of manually reporting progress. Document execution progress data originates from real-time transmission from the front-end acquisition layer and is directly linked to the acquisition and verification process. Simultaneously, this view supplements the situational information of personnel and tasks, extending the overall situational awareness from simple material status to operation execution status.

[0076] The next step involves matching the inbound / outbound time-series data of goods with process nodes to generate a goods flow node tracking link. This goods flow node tracking link is a complete goods tracking view linked together by business process nodes, presenting the status of goods at each node from inbound to outbound, rather than an isolated inventory snapshot, to reconstruct the complete flow process of goods. In practice, the inbound / outbound time-series change data from the inventory control layer is extracted, and the inventory status changes of each batch of goods are matched one by one with preset operational process nodes. The current node and cumulative dwell time of each batch of goods are marked on the process nodes of the twin topology, and linked together in process sequence to form a complete flow tracking link, intuitively presenting the efficiency and bottleneck status of each link. This mapping transforms discrete inventory change data into a continuous business flow process, enabling intuitive identification of bottleneck nodes in the flow, replacing the lagging mode of traditional post-event statistics on flow efficiency, and achieving real-time perception of the flow status during the process. The inbound and outbound time-series data comes from the inventory update log. Each change in the inventory segment corresponds to the advancement of a flow node. The real-time nature of the inventory data directly determines the accuracy of the flow chain. At the same time, the identification of flow bottlenecks also provides an intuitive process basis for subsequent work process optimization.

[0077] Finally, the lock conflict logs are mapped to the physical locations of the corresponding shards, generating shard conflict anomaly location markers, and ultimately integrating them into a global visual situational view. Shard conflict anomaly location markers locate underlying technical concurrent conflict events to corresponding storage locations in the physical warehouse, giving lock conflict logs, which were originally only interpretable by technical personnel, a spatial attribute that is perceptible to the business. In practice, based on the shard and storage location mapping relationship obtained through spatial association calculations, each lock conflict log is mapped to a specific physical storage location shard. In the twin view, anomaly markers are used to mark high-frequency conflict areas, intuitively presenting the spatial distribution characteristics of conflicts. After completing the mapping generation of the four types of views, inventory distribution heatmaps, work progress, workflow links, and conflict markers are all integrated into the same twin topology framework, supporting layered switching and point-to-point linked queries, ultimately forming a unified global visual situational view. This mapping transforms lock conflict events, originally hidden at the database level and only accessible to technical personnel, into spatial anomaly markers that business managers can intuitively understand, allowing them to directly grasp the physical areas with the most concentrated concurrent operations and the most frequent conflicts.

[0078] As one implementation method, optimization instructions for job paths and task allocation are sent to the mobile client to adjust the order of data collection, and optimization parameters for sharding granularity and lock weight are fed back to the inventory management server to adjust the concurrent scheduling logic. This specifically includes the following steps: Based on the overall warehouse operation progress and cargo flow nodes, identify the bottleneck areas of operation with task backlog and the positions with unbalanced personnel load. Combine the material space inventory distribution to plan the optimal operation path, generate operation path and task allocation optimization instructions, and send them to the mobile operation terminal in the corresponding area to adjust the execution order and task allocation of document collection, inbound and outbound operations. Based on the abnormal location of shard conflicts and material turnover rate data, high-frequency conflict hotspot shards and long-term idle low-conflict shards are identified. Shard granularity splitting / merging parameters, lock preemption weight adjustment parameters, and lock timeout time optimization parameters are generated and fed back to the inventory management server to update the inventory shard weight scoring model and optimistic lock scheduling rules.

[0079] In the above steps, the first type of optimization instruction targets the front-end mobile work terminal, focusing on optimizing work execution efficiency. The first step is to identify bottleneck areas with task backlog and positions with unbalanced personnel load based on the overall warehouse operation progress and cargo flow nodes. The bottleneck area is not simply an area with a large number of tasks, but rather a physical warehouse area or process node where task passage efficiency is lower than normal, determined by both operation progress and flow nodes. This includes both spatial warehouse congestion and process-level bottlenecks. Personnel load imbalance refers to a significant difference in task saturation among on-duty personnel in different work positions and different warehouse areas, resulting in a resource mismatch where some personnel are overloaded and others are idle.

[0080] In practice, the system first extracts data from the overall warehouse operation progress view, statistically analyzing the amount of tasks pending, the number of on-duty personnel, and the average workload per person in each physical warehouse area, calculating the task saturation of each area. Simultaneously, it combines this with the cargo flow tracking chain to statistically analyze the cumulative dwell time of goods at each process node and the number of batches pending processing, identifying flow bottlenecks where dwell time exceeds thresholds. By combining spatial load and process bottleneck information, the system pinpoints operational bottleneck areas with task accumulation, such as cargo backlog in the inbound inspection area or task queues in the sorting area. Furthermore, it compares the average workload per person for each position to identify overloaded and underloaded positions, determining a personnel workload imbalance. This step transforms traditional bottleneck identification, relying on manual inspection and experience-based judgment, into automated and precise location based on full real-time data. It overcomes the limitations of limited human management perspective and statistical lag, enabling the immediate detection of operational efficiency bottlenecks and resource mismatches across the entire warehouse. Moreover, the location results cover both spatial and process dimensions, providing a more comprehensive identification.

[0081] Then, based on the material space and inventory distribution, the optimal work path is planned, generating work path and task allocation optimization instructions, which are then sent to the mobile work terminals in the corresponding areas to adjust the execution order and task allocation of document collection and inbound / outbound operations. The optimal work path is not simply the shortest physical distance path, but a comprehensive and efficient path planned by taking into account multiple dimensions such as bottleneck area priority, material distribution location, personnel current location, and task urgency. The core goal is to clear bottlenecks and balance the load, rather than simply shortening walking distance. The work path and task allocation optimization instructions are executable instructions pushed to the mobile work terminals of the corresponding operators, including the adjusted task execution order, suggested work routes, and newly added or transferred task items, rather than general management requirements.

[0082] In practice, the system prioritizes identified bottleneck areas, combining material location information from the material space inventory distribution heatmap with the current physical location of operators. With the goal of clearing bottlenecks and balancing task load across areas, the system re-plans the work execution sequence and movement paths for each operator. This includes dispatching personnel from idle areas to support bottleneck areas, adjusting the order of inbound and outbound operations to prioritize goods at bottleneck points, and planning continuous work routes passing through multiple task points. After the path and task plan are generated, the system sends optimization instructions to the mobile terminals of operators in the corresponding areas. Upon receiving the instructions, the mobile terminals automatically adjust the execution order and priority of the task list, guiding operators to perform operations such as data collection, barcode scanning, and inbound / outbound operations according to the optimized plan. The direct technical effect of this step is the automation and data-driven optimization of task dispatching and path planning, replacing traditional manual dispatching and experience-based path selection. This quickly clears operational bottlenecks, balances personnel load, improves the overall operational efficiency of the entire warehouse, reduces ineffective walking and waiting time for operators, and increases the output per unit time of frontline operations.

[0083] The second type of optimization instructions targets the mid-level inventory management server, focusing on optimizing inventory concurrency performance. The first step is to identify high-frequency conflict hotspot shards and long-term idle low-conflict shards based on shard conflict anomaly locations and material turnover rate data. High-frequency conflict hotspot shards refer to inventory shards where lock conflicts occur significantly more frequently than average per unit time, with highly concentrated concurrent operations, and are the core bottleneck restricting the system's concurrent throughput. Long-term idle low-conflict shards refer to inventory shards with extremely low operation frequency and almost no lock conflicts. Overly fine-grained granularity of these shards will increase unnecessary system scheduling overhead.

[0084] In practice, the system extracts the generated fragment conflict anomaly location marker data, counts the number of conflicts and conflict frequency of each inventory fragment within a set period, and combines this with the material turnover rate data corresponding to the material space inventory distribution to classify and evaluate all inventory fragments: fragments with high conflict frequency and high material turnover rate are identified as high-frequency conflict hotspot fragments; fragments with extremely low conflict frequency and low material turnover rate are identified as long-term idle low-conflict fragments. This step can accurately locate the core problem fragments affecting concurrent performance, replacing the traditional passive response mode that can only trigger adjustments for a single fragment. It can comprehensively evaluate the operating status of all fragments at the overall level, identify potential performance bottlenecks and resource waste points, and provide precise targets for systemic optimization.

[0085] The second step involves generating parameters for sharding granularity splitting / merging, lock preemption weight adjustment, and lock timeout optimization, which are then fed back to the inventory management server to update the inventory sharding weight scoring model and optimistic lock scheduling rules. These three types of parameters correspond to different optimization dimensions: sharding granularity splitting / merging parameters adjust the sharding structure, optimizing conflict probability at the spatial granularity level; lock preemption weight adjustment parameters adjust the scheduling priority of different document types, optimizing resource allocation at the business priority level; and lock timeout optimization parameters adjust the lock resource occupancy duration, optimizing resource utilization efficiency from a time perspective. These three types of parameters together constitute a complete concurrent scheduling optimization scheme, rather than a single-dimensional adjustment.

[0086] In practice, for identified high-frequency conflict hotspot shards, sharding granularity parameters are generated to clarify the dimensions of the split and the number of sub-shards after the split. This breaks down coarse-grained shards into finer-grained independent sub-shards, reducing the probability of concurrent preemption within a single shard. For long-term idle low-conflict shards, sharding granularity merging parameters are generated to merge multiple adjacent low-activity shards into a single coarse-grained shard, reducing the total number of shards and lowering the computational overhead of system scheduling and management. Simultaneously, based on the conflict level and business attributes of the shards, lock preemption weight adjustment parameters are generated to adjust the lock resource preemption weights for different document types and priorities, ensuring the priority execution of core business documents. Lock timeout optimization parameters are also generated, appropriately shortening lock timeouts for high-conflict shards to accelerate the failure retry rhythm, and appropriately extending timeouts for low-conflict shards to reduce unnecessary rollbacks. After all parameters are generated, they are fed back to the inventory control server in the warehouse management process. Upon receiving the parameters, the server synchronously updates the dimension weights of the inventory sharding weight scoring model and the corresponding rules for optimistic lock scheduling. The updated parameters take effect immediately. The direct technical effect of this step is to achieve a systematic and global optimization of inventory concurrency control from three dimensions: sharding structure, scheduling weights, and time configuration. Compared to single-point self-adjustment that only addresses splitting triggered by single shard conflicts, this optimization coordinates adjustments from a global perspective, achieving optimal overall concurrency performance. It reduces hotspot conflicts while avoiding increased scheduling costs caused by excessive sharding, achieving a better balance between system throughput and computing power. The optimized parameters output by this step directly affect the inventory sharding weight scoring model and optimistic locking scheduling rules, complementing the automatic sharding splitting logic and providing emergency adjustments triggered passively at single points, thereby improving the accuracy of warehouse management.

[0087] As one implementation method, the optimization instruction forms a self-optimizing closed loop after it is issued, specifically including the following steps: After receiving optimization instructions for job paths and task allocation, the mobile client re-plans the job execution order, adjusts the priority of data collection jobs, and synchronously adapts to the updated topology verification rules, and transmits the adjusted job execution data back to the backend management terminal in real time. After receiving the sharding granularity and lock weight optimization parameters, the inventory management server updates the dimension weights of the sharding weight scoring model, switches the granularity configuration of the corresponding shard, adjusts the timeout and retry strategy of optimistic lock scheduling, and sends the adjusted inventory sharding status data and conflict logs back to the backend management server in real time. The adjusted full data is re-input into the digital twin topology model to complete a new round of situation mapping and optimization analysis, forming a self-optimizing closed loop of data collection and purification, inventory, control and management, global intelligent scheduling, and reverse iterative optimization.

[0088] In the above steps, after receiving optimization instructions for job paths and task allocation, the mobile work terminal completes job adjustments and data feedback. Re-planning the job execution order and adjusting the priority of data collection jobs does not modify the document verification rules, but rather adjusts the task execution sequence and path arrangement of front-line jobs without changing the topology verification standards. The core objective is to alleviate business bottlenecks and balance personnel load. Synchronous adaptation to updated topology verification rules is a rule synchronization action attached to the instructions, ensuring that front-end verification rules and back-end management standards remain consistent. Real-time feedback refers to dynamically reporting status data during job execution, rather than batch uploading after the entire order is completed, ensuring the real-time nature of back-end situational awareness.

[0089] In practice, upon receiving the optimization command, the mobile work terminal first parses the task adjustment content and path planning scheme in the command, and reorders the local task list to be executed: prioritizing tasks in bottleneck areas and documents at stuck nodes, while reducing the execution priority of tasks in non-urgent areas. Simultaneously, based on the planned optimal work path, the order of data collection actions such as barcode scanning, inventory counting, and inbound / outbound confirmation is rearranged, guiding workers to execute tasks sequentially along the optimized route, reducing unnecessary walking and waiting. Meanwhile, if the optimization command includes updated verification rules, the local topology constraint database is updated synchronously through the established bidirectional synchronization channel for verification rule semantics, ensuring that the verification standards executed at the front end are completely consistent with the latest rules in the back end, avoiding rule discrepancies. After the work adjustment is completed, the mobile work terminal transmits the adjusted task execution progress, personnel location changes, document completion status, and other work data back to the back-end management terminal in real time, synchronously updating the overall warehouse work status. This step accurately implements the optimization decisions generated in the background to the front-line operation process, quickly clearing operational bottlenecks, balancing personnel workload, and improving the overall operational efficiency of the entire warehouse; at the same time, the rule synchronization mechanism ensures that the data verification standards do not deviate during the optimization process, avoiding a decline in data quality due to task acceleration.

[0090] Then, after receiving the sharding granularity and lock weight optimization parameters, the inventory management server completes the scheduling rule update and data feedback. Updating the dimensional weights of the sharding weight scoring model is a dynamic adjustment of the underlying evaluation system of inventory sharding, rather than just adjusting the granularity of a single shard. The core is to make the weight model adapt to the current business characteristics and operating status. Switching the granularity configuration of the corresponding shard is an actual adjustment of the inventory sharding structure, performing split or merge operations, and updating the shard boundaries and corresponding data version numbers. Adjusting the timeout and retry strategy of optimistic lock scheduling is an optimization of the time dimension of lock resources, matching the operating characteristics of shards with different conflict levels. Real-time feedback refers to the synchronized update of the inventory status and operation logs after the parameters take effect, ensuring that the backend can grasp the optimization effect of the middleware.

[0091] In practice, after receiving the feedback optimization parameters, the inventory management server updates the rules in three dimensions: First, it updates the dimensional weights of the inventory sharding weight scoring model, adjusting the weight ratios of four dimensions—product turnover rate, storage area, document type, and operation priority—according to the current business scenario. For example, it increases the weight ratio of product turnover rate during peak business periods and increases the weight ratio of storage area during inventory periods, making the sharding logic more aligned with current business priorities. Second, it switches the granularity configuration of the corresponding shards, performing splitting operations on identified high-frequency conflict hotspot shards, refining them into multiple independent sub-shards and assigning them new data version numbers, and performing merging operations on long-term idle low-conflict shards, integrating them into coarse-grained shards and unifying version numbers, thus completing the global optimization of the sharding structure. Third, it adjusts the timeout and retry strategies of optimistic lock scheduling, appropriately shortening the lock timeout time and accelerating the failure retry rhythm for high-conflict shards, and appropriately extending the lock timeout time and reducing unnecessary transaction rollbacks for low-conflict shards. At the same time, it adjusts the upper limit of the number of retry attempts for documents with different confidence levels, optimizing the time utilization efficiency of lock resources. After all parameters are adjusted and take effect, the inventory management server will send the adjusted inventory sharding status data, sharding structure information, and the latest round of lock conflict logs back to the backend management terminal in real time, synchronously updating the inventory operation status. This step achieves systematic optimization of inventory concurrency control through three dimensions: model weights, sharding structure, and scheduling strategy. Compared to emergency adjustments that passively trigger splitting of a single shard, this global proactive optimization can achieve the optimal configuration of overall concurrency performance, reducing hotspot conflicts while avoiding the increase in scheduling costs caused by excessive sharding, and continuously balancing the probability of lock conflicts with system computing power overhead.

[0092] Finally, the adjusted full data is re-input into the digital twin topology model to complete a new round of situation mapping and optimization analysis, forming a complete self-optimizing closed loop. This new round of situation mapping and optimization analysis is not the end of a single optimization, but rather the starting point of a cyclical iteration. The system will reassess the global state based on the optimized operational data, judge the optimization effect, identify new bottlenecks, and continuously generate optimization instructions. The self-optimizing closed loop means that the entire cycle requires no continuous human intervention; the system automatically completes the complete link of perception—decision—execution—feedback—re-perception, continuously iterating itself as business changes. Data collection and purification, consistent inventory management, global intelligent scheduling, and reverse iterative optimization correspond to the forward progression and reverse optimization paths of the three-layer architecture, forming the core logical links of the closed loop.

[0093] In practice, the backend management system re-enters the operational data from the frontend, the inventory status and conflict logs from the mid-end, along with the entire document flow data, into the digital twin topology model. It reuses spatial correlation and temporal fusion calculation logic to update four types of situational views: overall warehouse operation progress, material spatial inventory distribution, goods flow nodes, and segmented conflict anomaly locations, completing a new round of global situational mapping. Based on this, the system compares various operational indicators before and after optimization to evaluate the actual effect of this round of optimization: if bottlenecks have been eliminated and conflicts have decreased, the current configuration is maintained and monitoring continues; if unresolved bottlenecks remain, or new areas of operational congestion or conflict surges appear, a new round of optimization instructions is generated based on the new situational data and the analysis logic is reused, then reissued to the mobile operation terminal and inventory management server for adjustment. Through this iterative process, the system continuously iterates and optimizes around the current actual operating state, ultimately forming a stable self-optimizing closed loop. The direct technical effect of this step is to enable the entire warehouse management system to have the ability to iterate and evolve autonomously. It breaks away from the static model of traditional systems that are finalized upon launch and rely on manual optimization. It can automatically adapt to optimal operating strategies based on fluctuations in business volume, changes in product structure, and adjustments in personnel allocation, resulting in continuous improvement in overall efficiency over long-term operation. This step forms a complete causal link combining forward progression and reverse optimization: in the forward link, front-end data quality supports mid-end concurrency efficiency, and mid-end data accuracy supports back-end scheduling precision; in the reverse link, back-end scheduling optimization simultaneously improves front-end operational efficiency and mid-end concurrency performance. This cyclical process further improves the accuracy of data collection and inventory control, thereby enhancing the precision of warehouse management.

[0094] In this application, the warehouse management device may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. This warehouse management device is merely an example and should not be construed as limiting the functionality or scope of the embodiments of this invention.

[0095] This application also includes a warehouse management device, comprising a mobile operating terminal, an inventory control server, and a back-end control terminal, used to execute warehouse management methods.

[0096] It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A warehouse management method, applied to a mobile operation terminal, an inventory control server, and a back-end control terminal, characterized in that, Includes the following steps: On the mobile work terminal, a four-layer topology ontology model of a document is pre-built, which includes four levels of subordinate nodes: document header, product item, serial number, and storage location. The mapping rules between products and serial numbers, the storage permission constraints between storage locations and products, and the correspondence rules between document type and quantity (positive and negative) are transformed into topological constraints between nodes. Based on the aforementioned topological constraints, the collected raw warehouse data is subjected to topological verification and node credibility is marked; based on the feature inference of the legal value range of nodes with marked credibility within the same document, topological sensing is performed to complete warehouse data with missing characters, so as to output a work order carrying a credibility level identifier. The inventory control server receives work orders carrying a trust level identifier. Based on product turnover rate, storage area, document type, and operation priority, it constructs an inventory sharding weight scoring model and performs dynamic granular sharding of warehouse data according to the weight score. Based on the results of dynamic granular sharding and the trust level of the work order, it performs associative dynamic optimistic locking scheduling, including pre-dividing the work order into a high-trust priority queue and a normal priority queue according to the trust level carried by the work order. High-trust priority documents directly enter the lock allocation priority channel, skipping the data validity duplication check of the inventory control server, and are configured with a longer lock timeout and more automatic retries. Ordinary priority documents enter the queuing channel and are processed in sequence according to the time of receipt, including data verification and resource lock requests. The system's concurrent load is monitored in real time. When the number of documents processed per unit time exceeds the high concurrency threshold, the inventory shards corresponding to the hot products are automatically split into more granular sub-shards. When the number of documents processed per unit time is lower than the low concurrency threshold, multiple low-activity inventory shards are automatically merged into coarse-grained shards to dynamically balance the probability of lock conflicts and the overhead of scheduling computing power. Priority lock queues are allocated to high-reliability documents and the duplicate data verification process is skipped. Queue scheduling is performed for low-reliability documents. At the same time, the sharding granularity is dynamically adjusted according to the real-time concurrency. Tiered diversion and transaction rollback control are performed for lock conflicts. Before the inventory update operation is executed, the data version number of the target inventory shard is compared. If the version number is inconsistent, a lock conflict is determined. Identify the scope of the inventory shards involved in the conflict. If it is a minor conflict across warehouses or sub-shards, only roll back the inventory increase / decrease operations corresponding to the conflicting sub-shards, retain the inventory update results of the conflict-free shards, and execute the other conflict-free operations in parallel. If there is a severe conflict within the same segment, a complete transaction rollback will be triggered, canceling all inventory updates, storage space occupancy, and status change operations corresponding to this document, and restoring the inventory data to the version before the operation. Synchronously generate lock conflict logs, recording conflicting documents, shard numbers, conflict times, rollback ranges, and conflict reasons; When the frequency of conflicts in a single shard exceeds a set threshold within a unit of time, the shard granularity automatic splitting logic is triggered to output inventory shard status data, including lock conflict logs. The back-end management terminal constructs a fusion full-link digital twin topology model based on inventory shard status data to obtain the overall warehouse operation progress, material space inventory distribution, goods flow nodes and shard conflict and abnormal locations. It then sends operation path and task allocation optimization instructions to the mobile operation terminal to adjust the collection operation order and feeds back the shard granularity and lock weight optimization parameters to the inventory management server to adjust the concurrent scheduling logic in order to achieve warehouse management.

2. The warehouse management method according to claim 1, characterized in that, The process of performing topology verification and marking node credibility on the collected raw warehouse data based on the topology constraints specifically includes the following steps: Each time the mobile client completes the collection and entry of raw warehouse data, it immediately triggers the local topology verification engine. For the document header node, it verifies the matching of document type, operation date and permission scope; for the product item node, it verifies the consistency of product SKU, quantity and total document quota; for the serial number node, it verifies the affiliation relationship between serial number and corresponding product SKU; and for the storage location node, it verifies the compatibility of storage location permissions and product category. If the verification fails, the current input is immediately intercepted and the corresponding node's error message is output; if the verification passes, the node is marked with the corresponding credibility level. Simultaneously, a two-way synchronization channel for the semantic verification rules between the mobile operation terminal and the back-end management terminal is established. After the back-end management terminal updates the business constraints of pricing strategies, storage permissions, and batch number validity period rules, it actively pushes the rule changes to the mobile operation terminal. The mobile operation terminal updates the topology constraint condition library in real time to perform topology verification on the collected raw warehousing data and mark the node credibility.

3. The warehouse management method according to claim 2, characterized in that, The method of performing topology-aware completion on warehouse data with missing characters, based on the feature inference of the legal value range of the trust nodes marked within the same document, specifically includes the following steps: Identify the topological node level to which the missing data belongs, and locate its parent node and sibling nodes in the four-level topological ontology model of the document; extract the attribute features, value ranges, and constraint rules of the topological nodes at the same level within the same document that have passed the verification, and infer the legal value range of the missing data in combination with the topological constraints of the parent node; automatically complete the missing field content that conforms to the topological constraints based on the inference results; after completion, re-execute the full node topological verification, and if the verification passes, mark the corresponding confidence level for the completed data; if the verification fails, return to re-infer the value range.

4. The warehouse management method according to claim 3, characterized in that, The back-end control terminal constructs a fusion end-to-end digital twin topology model based on inventory shard status data to obtain the overall warehouse operation progress, material spatial inventory distribution, goods flow nodes, and shard conflict anomaly locations. Specifically, it includes the following steps: Based on the physical layout of the warehouse, the spatial coordinates of the storage location, and the nodes of the operation process, a basic topology for warehouse digital twin is constructed; inventory shard status data, lock conflict logs, and full-link data of document flow are accessed to perform spatial association and time-series fusion operations. The numerical data of inventory shards are mapped to the spatial coordinates of the corresponding physical storage locations to generate a heat map of material spatial inventory distribution; the document execution progress is associated with the location of the operators to generate a full warehouse operation progress view; the time sequence data of goods entering and leaving the warehouse is matched with process nodes to generate a goods flow node tracking link; the lock conflict log is mapped to the physical location of the corresponding shard to generate shard conflict anomaly location markers, and finally a global visualization situation view is formed.

5. The warehouse management method according to claim 4, characterized in that, The process of sending optimization instructions for job paths and task allocation to the mobile client to adjust the order of data collection, and feeding back optimization parameters for sharding granularity and lock weight to the inventory management server to adjust the concurrent scheduling logic, specifically includes the following steps: Based on the overall warehouse operation progress and cargo flow nodes, identify the bottleneck areas of operation with task backlog and the positions with unbalanced personnel load. Combine the material space inventory distribution to plan the optimal operation path, generate operation path and task allocation optimization instructions, and send them to the mobile operation terminal in the corresponding area to adjust the execution order and task allocation of document collection, inbound and outbound operations. Based on the abnormal location of shard conflicts and material turnover rate data, high-frequency conflict hotspot shards and long-term idle low-conflict shards are identified. Shard granularity splitting / merging parameters, lock preemption weight adjustment parameters, and lock timeout time optimization parameters are generated and fed back to the inventory management server to update the inventory shard weight scoring model and optimistic lock scheduling rules.

6. The warehouse management method according to claim 5, characterized in that, After the optimization command is issued, a self-optimizing closed loop is formed, which specifically includes the following steps: After receiving optimization instructions for job paths and task allocation, the mobile client re-plans the job execution order, adjusts the priority of data collection jobs, and synchronously adapts to the updated topology verification rules, and transmits the adjusted job execution data back to the backend management terminal in real time. After receiving the sharding granularity and lock weight optimization parameters, the inventory management server updates the dimension weights of the sharding weight scoring model, switches the granularity configuration of the corresponding shard, adjusts the timeout and retry strategy of optimistic lock scheduling, and sends the adjusted inventory sharding status data and conflict logs back to the backend management server in real time. The adjusted full data is re-input into the digital twin topology model to complete a new round of situation mapping and optimization analysis, forming a self-optimizing closed loop of data collection and purification, inventory control, global intelligent scheduling, and reverse iterative optimization.

7. A warehouse management apparatus for implementing the warehouse management method according to any one of claims 1 to 6, characterized in that, include: Mobile operation terminal, inventory management server terminal and back-end management terminal.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored on the memory, wherein the processor is configured to run the computer program to perform the warehouse management method according to any one of claims 1 to 6.

Images