A full-channel multi-dimensional inventory management and control and order routing and distribution system and method

Abstract

The present application relates to a kind of full channel multi-dimensional inventory management and method for order routing allocation system.The method includes: constructing full channel inventory collection management layer, mapping physically dispersed inventory entity as logically unified management inventory collection node;Obtain order data and parse order characteristic information;Perform order pre-checking;Multi-dimensional inventory matching is executed to generate candidate node set;Determine whether there is a node that can be whole order fulfillment in candidate node, if there is, then determine fulfillment node according to whole order routing strategy, if not, then split and distribute respectively according to split order strategy;After order allocation is completed, concurrent control is executed through concurrent lock mechanism and inventory data is updated;For offline self-pickup order, retail single automatic generation and cross-channel payment clearing are also executed.The present application realizes the inventory collection management of physically dispersed and logically unified, and the double mode intelligent routing allocation of whole order priority and split order bottom, improves the full channel order fulfillment success rate and inventory turnover efficiency.

Description

Technical Field

[0001] This invention relates to the field of omnichannel order fulfillment technology in the retail industry, and in particular to an omnichannel multi-dimensional inventory management and order routing allocation system and method. Background Technology

[0002] With omnichannel retail becoming the mainstream business model, inventory management between online e-commerce and offline stores has long been fragmented, forming so-called "channel inventory silos".

[0003] In practice, each channel maintains its own inventory pool. Online orders are fulfilled only by the central warehouse, and store inventory only serves in-store consumers. Businesses often face the awkward situation of online sales being sold out while stores have large stockpiles. Some companies have tried to incorporate store inventory into the online sales system, but simple inventory aggregation has brought new problems. Online orders excessively occupy store stock, affecting normal store sales. At the same time, managing full-price and discounted products together makes the pricing system extremely easy to get out of control.

[0004] In the order allocation process, most existing order allocation systems assign orders based on single rules such as geographical distance or inventory quantity. In actual operation, the nearest store may be saturated with orders for the day, while the store with the most inventory may have serious unsold goods. A single rule simply cannot take into account the complex business constraints.

[0005] When an order contains multiple items, existing order allocation systems often use a "one-size-fits-all" approach:

[0006] Either force the entire order to be shipped, or if the store is missing any item, the entire order cannot be fulfilled;

[0007] They either split orders and ship them regardless of the situation, which greatly increases logistics costs, or they lack the ability to determine the optimal fulfillment model based on the real-time inventory dynamics of each store.

[0008] In terms of geographical routing, most systems only consider the "city" level. When there is no available inventory in the city where the delivery address is located, the order is directly judged as a failure. In reality, other cities in the same province or even other stores in the same area may be able to cover the order.

[0009] The unique business constraints of the apparel industry, such as size and color attributes, separation of regular and special prices, store opening hours, and membership affiliation, are all subject to long adjustment cycles and slow response times when developed and solidified in the existing order allocation system.

[0010] In addition, online orders are disconnected from the offline POS retail system after being pushed to the store. When customers return goods, the POS system cannot find the original sales records, making financial reconciliation difficult and preventing members from accumulating points across channels. During major promotions, multiple orders simultaneously lock the same inventory, leading to overselling. The operations department can only apologize afterwards and has always lacked effective countermeasures. Summary of the Invention

[0011] To address the aforementioned technical problems, this invention provides a multi-dimensional inventory management and order routing system and method capable of achieving unified inventory control, intelligent routing allocation, and cross-channel business closed loop.

[0012] The present invention provides a method for multi-dimensional inventory management and order routing allocation across all channels, the specific implementation steps of which are as follows:

[0013] Build an omnichannel inventory aggregation and control layer to map physically dispersed inventory entities into logically unified inventory aggregation nodes;

[0014] Obtain order data and parse order feature information;

[0015] Perform pre-order verification;

[0016] Based on the aforementioned inventory set management layer, multi-dimensional inventory matching is performed to generate a set of candidate fulfillment nodes;

[0017] Determine whether there is a node in the candidate fulfillment node set that can fulfill the entire order. If there is, determine the fulfillment node from the candidate nodes according to the preset whole order routing strategy. If there is no, split the order according to the splitting strategy and allocate each split part to the corresponding fulfillment node.

[0018] After the order is assigned, concurrency control is performed and inventory data is updated using a concurrency lock mechanism;

[0019] After the order is submitted, for offline self-pickup orders, the retail order will be automatically generated and cross-channel payment settlement will be performed.

[0020] Furthermore, the construction of the omnichannel inventory aggregation control layer includes:

[0021] Real-time inventory data from inventory nodes distributed in different physical locations are aggregated into a shared inventory pool across all channels through a unified inventory access gateway, and multi-dimensional attribute tags are established for each inventory record.

[0022] The multidimensional attribute tags include physical location dimension, product attribute dimension, channel affiliation dimension, and distributor level dimension;

[0023] The physical location dimension includes store / warehouse identification, city, district / county, and region;

[0024] The product attribute dimensions include product identifier, attribute instance identifier, and barcode identifier;

[0025] The channel attribution dimension includes three channel type identifiers: regular price, special price, and clearance.

[0026] The distributor hierarchy includes headquarters, primary distributors, secondary distributors, and their affiliations.

[0027] The multidimensional attribute tags also include operational constraint dimensions, which include the node's daily order limit, monthly shipment limit, business hours, and the cost center to which it belongs.

[0028] Furthermore, the pre-execution verification of the order includes:

[0029] Perform verification of the legality of the order-placing entity and pre-verification of its order-accepting capability;

[0030] The verification of the legality of the ordering entity is based on a pre-built dealer hierarchical topology model. If the verification fails, the order will be rejected.

[0031] The order acceptance capacity pre-verification involves querying the store's operational constraint model to check whether the store's cumulative order volume exceeds the upper limit. If it does, a circuit breaker mechanism is triggered to reject the order.

[0032] Furthermore, the method for performing multi-dimensional inventory matching and generating a set of candidate fulfillment nodes is as follows:

[0033] Using each item in the order as a retrieval unit, the inventory records in the inventory collection management layer are traversed, and the multi-dimensional filtering logic is used to perform filtering. The inventory records that pass all the filtering conditions are summarized into a candidate fulfillment node set according to the inventory node dimension.

[0034] The multidimensional filtering logic includes:

[0035] Quantity matching: Filter inventory nodes where the available inventory is greater than or equal to the order demand.

[0036] Mutual exclusion: Exclude inventory nodes that have already been assigned in the current order's historical routing log;

[0037] Self-exclusion: Excludes the inventory nodes of the store where the order was placed;

[0038] Permission matching: Filter inventory nodes at the dealer level that meet the inventory sharing permission policy;

[0039] Capacity matching: Filter inventory nodes that have not exceeded the daily order limit and monthly shipment limit;

[0040] Attribute isolation: Match and verify the product's channel affiliation attribute with the store / warehouse type attribute of the inventory node. Regular-priced products are only assigned regular-priced inventory or warehouse node inventory, and discounted products are only assigned discounted inventory or warehouse node inventory. Warehouse node inventory can be assigned all types of inventory.

[0041] Furthermore, the method for determining whether there is a node in the candidate fulfillment node set that can fulfill the entire order is as follows:

[0042] The product category coverage of each candidate node in the candidate fulfillment node set that can be fulfilled independently is statistically analyzed. If the product category coverage of any candidate node is equal to the total number of product categories in the order, then the order is determined to be feasible for fulfillment of the entire order.

[0043] The whole order routing strategy is as follows: read the warehouse priority strategy configuration corresponding to the order type; if the warehouse priority strategy is hit, select the corresponding warehouse node as the fulfillment node; if the warehouse priority strategy is not hit or no valid node is selected, start the multi-dimensional routing rule engine, and perform step-by-step filtering on the candidate nodes according to the configurable multi-dimensional rule priority sequence until the cardinality of the candidate node set converges to 1 to determine the unique fulfillment node.

[0044] The multi-dimensional routing rule engine supports rule dimensions that include at least several of the following: address matching priority, member affiliation priority, store order time matching, store order threshold verification, inventory digestion speed priority, cost center proximity priority, credit limit priority, maximum inventory priority, delivery address proximity rule, order store proximity rule, and minimum number of packages priority.

[0045] The execution of the delivery address proximity rule and the order store proximity rule adopts a four-level progressive geographic matching strategy:

[0046] The first level of matching is the district / county level matching, which filters nodes that match the district / county code of the baseline geographic coordinates;

[0047] If the first-level matching result is empty, the candidate node set is restored to the complete input set before matching and downgraded to the second-level city-level matching.

[0048] If the second-level matching result is empty, it will be downgraded to the third-level provincial matching; if the third-level matching result is empty, it will be downgraded to the fourth-level regional matching.

[0049] If the matching result at any level is not empty, the matching result at that level is used as the filtered set of candidate nodes for output.

[0050] In the order placement store proximity rule, after each level of matching is completed, a cost center consistency constraint is further superimposed, prioritizing the screening of fulfillment nodes that belong to the same cost center as the order placement store.

[0051] Furthermore, the order splitting strategy is as follows:

[0052] Read the order splitting strategy switch configuration corresponding to this order type. If the order splitting strategy switch is in the off state, it is determined that the order cannot be fulfilled.

[0053] If the order splitting strategy switch is on, it will enter an iterative order splitting allocation loop. In each loop, the product details that have not yet been allocated will be processed to determine the corresponding fulfillment node and generate a sub-order, until all product details are allocated or the preset iteration termination condition is met.

[0054] In the iterative order splitting and allocation loop, the preset iteration termination condition is reaching the preset maximum iteration count threshold.

[0055] Furthermore, the automatic generation of retail orders and cross-channel payment clearing operations are as follows:

[0056] Trigger the retail order generation engine to generate a positive comprehensive detailed retail order, which summarizes the positive sales information of all product details in the order; and generate a negative virtual retail order, the sales amount of which is the negative value of the sales amount of the positive comprehensive detailed retail order, which is used to match the original receipt number when returning goods across channels;

[0057] The payment amount corresponding to each payment channel in the original order's payment information is analyzed, and retail payment details for each payment channel are generated and pushed to the settlement module of the offline POS retail system to complete cross-channel clearing and reconciliation.

[0058] Furthermore, after each order routing allocation is completed, the operational status of the fulfillment node is dynamically updated:

[0059] The fulfillment node identifier and the number of orders involved in this allocation are used as input parameters. The cumulative number of orders received and the cumulative number of orders shipped in the current month for the fulfillment node are updated asynchronously through the message queue middleware. The updated operational status data is written to the cache middleware and fed back to the inventory collection management layer as a real-time constraint condition for the capability matching link in the subsequent order routing allocation.

[0060] The routing assignment result will be persisted to the routing log table.

[0061] Furthermore, the method of performing concurrency control and updating inventory data through a concurrency lock mechanism is as follows:

[0062] Before the order submission transaction begins, an exclusive lock is acquired on the data row containing the order record in the main order table.

[0063] If the data row has been locked by another transaction, it will enter a waiting state until the lock is released or the wait times out.

[0064] After successfully acquiring the exclusive lock, an inventory update operation is performed within the same database transaction. The inventory update operation atomically completes the increase of the first inventory occupancy parameter and the decrease of the available inventory quantity field within the same update statement.

[0065] The first inventory occupancy parameter is the quantity in order, and the second inventory occupancy parameter is the quantity in transit;

[0066] If the order type is a sales order, update the order quantity;

[0067] If the order type is a return order, update the in-transit quantity.

[0068] A multi-channel, multi-dimensional inventory management and order routing system, through which the method is executed, specifically includes:

[0069] The unified inventory access gateway is used to aggregate real-time inventory data from inventory nodes distributed in different physical locations into a shared inventory pool across all channels, and to establish multi-dimensional attribute tags for each inventory record.

[0070] The order access gateway is used to receive raw order data messages and parse and extract order feature vectors from them.

[0071] The authorization verification module is used to verify the legality of the ordering entity's qualifications based on the dealer hierarchical topology model, and to verify whether the store's cumulative order volume exceeds the limit.

[0072] The multi-dimensional inventory matching engine is used to traverse the inventory records in the omnichannel shared inventory pool with each product in the order as the retrieval unit and perform multi-dimensional condition filtering, and summarize the filtering results into a set of candidate fulfillment nodes.

[0073] The whole order fulfillment determination module is used to count the coverage of product types that each candidate node can fulfill independently, and to determine whether the order is feasible to fulfill as a whole order or needs to be split into multiple orders for fulfillment.

[0074] The whole order routing module is used to determine the fulfillment node from the candidate nodes according to the preset whole order routing strategy when the whole order is feasible;

[0075] The order splitting and routing module is used to split an order according to an order splitting strategy when the whole order is not feasible, and to allocate each split part to the corresponding fulfillment node.

[0076] The order generation engine is used to generate sub-order records and update the shipping node field;

[0077] The concurrency control module is used to perform concurrency control and atomically update inventory data during the order submission phase using a concurrency lock mechanism.

[0078] The retail order generation engine is used to generate positive comprehensive detailed retail orders and negative virtual retail orders after the order is submitted. It parses each payment channel and generates retail payment detail records respectively, and pushes them to the settlement module of the offline POS retail system.

[0079] The operation status management module is used to asynchronously update the daily cumulative order quantity and monthly cumulative shipment quantity of the fulfillment node through a message queue, write the updated data to the cache middleware and feed it back to the multi-dimensional inventory matching engine.

[0080] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0081] First, a physically dispersed yet logically unified omnichannel inventory management system was constructed. Through multi-dimensional attribute tags, inventory scattered across online and offline nodes was uniformly modeled and managed, breaking down traditional channel inventory silos and resolving the disconnect between the logical inventory view and physical distribution. This provides enterprises with a better overall basis for inventory allocation decisions.

[0082] Second, it achieves dual-modal intelligent fulfillment decision-making, prioritizing whole orders and using split orders as a fallback. The system can dynamically determine the optimal fulfillment mode for orders based on real-time inventory distribution. When a single node has the conditions for fulfilling a whole order, the whole order mode is prioritized to reduce logistics costs and fulfillment complexity. When a single node has insufficient inventory, it automatically downgrades to the intelligent split order mode to maximize the order fulfillment rate. This solves the problem of rigid decision-making caused by the existing system's fixed use of either whole order or split order strategies.

[0083] Third, a configurable and scalable multi-dimensional routing rule engine was built. The rule engine supports more than ten dimensions of differentiated rule configuration, and the rule set and priority sequence can be independently customized according to the order type, which solves the technical problem of hard-coded rules that cannot flexibly configure differentiated rule sets for different order types.

[0084] Fourth, a four-level progressive geographic proximity routing strategy was designed. Through a progressive geographic matching and dynamic degradation mechanism at the district / county, city, province, and region levels, the order fulfillment failure rate caused by single-geographic-granularity matching failure is effectively reduced while ensuring delivery timeliness. This solves the problem of the coarse granularity of the existing geographic proximity principle, which only extends to the city level.

[0085] Fifth, the system has achieved modeling and decision embedding of special business constraints for the apparel retail industry. It abstracts industry-specific rules such as inventory isolation for regular and discounted items, distributor hierarchical access control, member priority, business hours constraints, and order limit circuit breakers into configurable constraint models and deeply embeds them into routing decisions, enabling the general order allocation system to have professional adaptability for the apparel retail industry.

[0086] Sixth, it has established a closed-loop business model between online O2O orders and offline retail systems. Through the automatic generation of retail orders and cross-channel clearing across multiple payment channels, it has achieved a complete business chain of online ordering, store fulfillment, offline returns, and unified settlement, thus solving the problem of business disconnect between online orders and offline systems.

[0087] Seventh, concurrency control and inventory locking mechanisms ensure inventory consistency in high-concurrency scenarios. A pessimistic locking strategy is used to isolate concurrency during the order submission process, combined with a real-time deduction mechanism for in-order and in-transit quantities, eliminating the risk of overselling and improving the strong consistency of inventory data.

[0088] Eighth, a dynamic closed-loop optimization mechanism of allocation, fulfillment, feedback, and redistribution has been formed. The operational status data of the fulfillment node is fed back to the inventory collection layer in real time, serving as a dynamic constraint for subsequent allocation. This enables the system's allocation strategy to adapt to changes in store operational load, achieving an evolution from static rule-based allocation to dynamic intelligent allocation. Attached Figure Description

[0089] Figure 1 This is an overall flowchart of the method of the present invention;

[0090] Figure 2 This is the system architecture diagram of the present invention. Detailed Implementation

[0091] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0092] The technical solution provided by this invention is applicable to retail enterprises with multiple channel types, including online e-commerce platforms, offline physical stores, central warehouses, and regional forward warehouses.

[0093] like Figures 1 to 2 The following is stated:

[0094] Example:

[0095] I. The specific implementation steps of the omnichannel multi-dimensional inventory management and order routing allocation method of the present invention are as follows:

[0096] Step 1: Construct a multi-dimensional inventory management and control layer across all channels.

[0097] More specifically, system administrators pre-configure basic information for each inventory node in the system, including fields such as node identifier, node name, node type, city, district / county, region, distributor level, cost center, daily order limit, monthly shipment limit, start time of business hours, and end time of business hours. After the above information is entered, it is stored in the inventory node information table.

[0098] The system establishes data interface connections with the inventory management systems, warehouse management systems, and store POS systems of various online e-commerce platforms through a unified inventory access gateway.

[0099] Furthermore, the preferred connection method for the data interface is an HTTP RESTful API or a message queue middleware, with the specific method determined according to the interface specifications of each external system. After the data interface is established, the system pulls real-time inventory quantities from each external system according to a preset synchronization cycle. For example, a full synchronization is performed every 30 seconds by default, or each external system actively pushes inventory change data to this system at the same cycle.

[0100] Furthermore, during the inventory data aggregation process, the system establishes multi-dimensional attribute tags for each inventory item.

[0101] More specifically:

[0102] The physical location dimension of the label is constructed as follows: the system reads the city, district, and area field values ​​corresponding to the node from the inventory node information table and writes them into the attribute label field of the inventory record in the form of key-value pairs.

[0103] The value of the region field is pre-configured by the system administrator according to the enterprise's sales region division strategy. It can be divided according to administrative regions, such as East China, South China, North China, Southwest China, etc., or according to the enterprise's custom sales region division.

[0104] As a preferred approach, the tagging method for product attribute dimensions is as follows:

[0105] The system reads the product identifier, attribute instance identifier, and barcode identifier of the corresponding product in the product information table.

[0106] For clothing items, the attribute instance identifier must contain at least a combination of attribute values ​​for two dimensions: color and size.

[0107] For other product categories, the attribute instance identifier is determined based on the specification parameters of that product category.

[0108] The above information is written to the attribute label field of the inventory record in key-value pairs.

[0109] Furthermore, the label construction method for the channel affiliation dimension is as follows:

[0110] The system determines the channel affiliation label based on the value of the inventory node type field.

[0111] If the node type is an offline physical store, it is further determined whether it is a regular-priced store or a special-offer store based on the store's discount strategy identifier.

[0112] If the node type is a central warehouse or a regional forward warehouse, it will be uniformly marked as a storage node. The inventory of the storage node type can be allocated to orders of any channel type.

[0113] Furthermore, the labeling method for the dealer level dimension is as follows:

[0114] The system reads the dealer identifier of the node from the inventory node information table. Starting from the identifier, it recursively queries upward along the parent pointer in the pre-built dealer hierarchy topology table until it reaches the headquarters node. The system then writes the identifiers of all dealer nodes along the recursive path and their corresponding hierarchy codes into the attribute label field of the inventory record in a list format.

[0115] Furthermore, the label construction method for the operational constraint dimension is as follows: the system directly reads the daily order limit, monthly shipment limit, business hours start time, business hours end time, and cost center code of the node from the inventory node information table, and writes them into the attribute label field of the inventory record in the form of key-value pairs.

[0116] In this embodiment, the system establishes an independent inventory balance record table in the database for each inventory node. Each record in this table contains at least the following fields:

[0117] Record unique identifier, node identifier, product identifier, attribute instance identifier, available inventory quantity, quantity in order, quantity in transit, and last update timestamp.

[0118] The "Quantity in Order" field records the quantity of goods that have been reserved for orders but have not yet been shipped, while the "Quantity in Transit" field records the quantity of goods that have been shipped but have not yet been confirmed for warehousing.

[0119] After each order allocation, the system updates the values ​​of the above fields synchronously based on the allocation results.

[0120] 2. Step two: Receive orders and parse order feature vectors.

[0121] When an order enters this system through online sales channels or an offline POS system, the order access gateway receives the original data message of the order.

[0122] More specifically, the original data message includes at least the order source channel identifier, order time, recipient information, delivery address information, product details list, payment information, and the store identifier or user identifier of the order.

[0123] Furthermore, the system performs format and integrity checks on the received raw data packets.

[0124] After successful verification, the system will write the order data into the pending status record of the main order table.

[0125] As a preferred approach, the system parses and extracts order feature vectors from the order data.

[0126] The specific method is as follows:

[0127] The parsing method for order type features is as follows:

[0128] The system reads the order source channel identifier field and compares its value with the system's preset channel-type mapping table to determine the corresponding order type code. The order type code includes at least the following values: offline sales order, online Tmall order, online JD.com order, online Douyin order, and return order. This type code is extracted and stored in the type dimension slot of the order feature vector for subsequent differential matching by the rule engine.

[0129] The method for parsing delivery address features is as follows:

[0130] The system extracts the complete text of the delivery address field from the order data and uses this text as input to call the geocoding service interface. The geocoding service interface returns the province code, city code, and district code corresponding to the address. If the geocoding service interface cannot precisely match the address text, the system initiates a fuzzy matching algorithm, comparing the address text with each record in the geocoding database based on similarity, and selecting the geocoding corresponding to the record with the smallest edit distance as the geocoding for the order's delivery address. After parsing, the province code, city code, and district code are stored in the geographic dimension slots of the order feature vector.

[0131] The method for parsing the order subject characteristics is as follows:

[0132] The system reads the order store identifier field from the order data. If this field is not empty, the system uses the store identifier as an index to query the store information table to obtain the distributor identifier and distributor level information of the store. If this field is empty, the system reads the order user identifier field and uses the user identifier as an index to query the member information table to obtain the member's affiliated store identifier and corresponding distributor level information. The query results are stored in the main dimension slot of the order feature vector.

[0133] The parsing method for order product features is as follows: The system iterates through the product detail list in the order data, reading the product identifier, attribute instance identifier, and order quantity line by line. The system counts the number of rows in the product detail list as the number of product categories, and stores the identifier, attribute instance identifier, and order quantity of each product in the product dimension slot of the order feature vector as a list of key-value pairs.

[0134] 3. Step three: Perform verification of the legality of the ordering entity's qualifications and pre-verification of its order acceptance capabilities.

[0135] More specifically, the system first performs a verification of the legitimacy of the ordering entity. The system reads the distributor node identifier of the ordering store from the entity dimension slot of the order feature vector obtained in step two, and uses this node identifier as the starting node.

[0136] Furthermore, the system pre-builds and stores a dealer hierarchy topology table. Each record in this table includes fields such as node identifier, node name, direct parent node identifier, hierarchy code, and whether it has omnichannel inventory sharing permissions. This topology table uses the headquarters node as the root node, and all dealer nodes are attached to the root node according to their actual affiliation, forming a tree-like data structure.

[0137] As a preferred option, the specific execution process for qualification and legality verification is as follows:

[0138] The system uses the identifier of the current starting node as an input parameter to call the recursive query function.

[0139] Specifically, the function first queries the record corresponding to the current node in the dealer-level topology table and reads the value of the "whether it has omnichannel inventory sharing permission" field of that record.

[0140] If the value of this field is yes, the function returns a valid result and the recursion terminates.

[0141] If the value of this field is negative, then read the value of the "Direct Parent Node Identifier" field of the record.

[0142] Use the parent node identifier as a new input parameter to continue the recursive query.

[0143] Preferably, the termination condition for recursion is:

[0144] If the query finds no headquarter node with an empty direct parent node identifier and no node has full-channel inventory sharing permissions, the function returns a verification failure result.

[0145] The system also sets an upper limit on recursion depth as an auxiliary protection mechanism. The default value of this upper limit is ten levels, and its function is limited to preventing endless recursive loops caused by abnormal data in the topology table.

[0146] If the recursive query depth reaches the upper limit and the headquarters node is not reached, the system will not immediately terminate the verification, but will continue to query upwards along the topology path until the headquarters node, taking the permission status of each node on the entire path into the judgment criteria; only when the value of the "whether it has full-channel inventory sharing permission" field of all nodes on the entire path is no, the system will finally return the verification failure result.

[0147] If the recursive query returns a verification failure result, the system rejects the order access, generates a prompt message containing the rejection reason code and returns it to the order source system, and the order process is terminated.

[0148] If the recursive query returns a valid result, the system enters the order acceptance capability pre-verification stage.

[0149] Furthermore, the specific execution process of order acceptance capability pre-verification is as follows:

[0150] The system uses the order store identifier as an index to query the store's operational constraint model. The store operational constraint model is stored in the store operational status table. Each record in this table includes fields such as store identifier, cumulative order quantity for the day, cumulative order quantity for the month, daily order limit, monthly order limit, and last update date. The system reads the cumulative order quantity and monthly order limit values ​​for the store for the current month and compares their values.

[0151] If the cumulative number of orders shipped in a month has reached or exceeded the monthly shipping limit, the system will trigger the circuit breaker mechanism, determine that the order cannot be fulfilled by the store, generate a prompt message containing the circuit breaker reason code and return it to the order source system, terminate the order process, and at the same time, the system will push a store circuit breaker warning notification message to the system management platform.

[0152] If the total number of orders shipped in a month does not exceed the monthly shipping limit, the order acceptance capacity pre-verification passes and the order enters the subsequent processing flow.

[0153] 4. Step four: Perform multi-dimensional inventory matching and candidate fulfillment node screening.

[0154] More specifically, after the verification in step three, the flag indicating that the verification has passed has been written into the order feature vector, and the qualification information of the ordering entity and the order acceptance capability status of the store have been confirmed as legal and valid.

[0155] The entity qualification information and store status information that pass the verification in step three will be used as the comparison benchmark in the fourth screening, namely permission matching, and the fifth screening, namely capability matching, in this step.

[0156] The system uses each product in the order product feature list obtained in step two as the basic retrieval unit to perform a traversal retrieval of all inventory records in the omnichannel shared inventory pool constructed in step one.

[0157] As a preferred approach, the system performs the following seven-step filtering logic for each product:

[0158] The first layer of filtering, quantity matching: The system uses the product identifier and attribute instance identifier as a combined index condition to retrieve the value of the available inventory quantity field in the inventory balance record table of each inventory node, and compares this value with the required quantity of the product in the order.

[0159] An inventory record is filtered only if the available inventory quantity is greater than or equal to the demand quantity; otherwise, it is excluded.

[0160] The second layer of filtering, mutual exclusion: The system uses the current order identifier as an index to query the routing log table to see if there is a historical allocation record for the order.

[0161] If it exists, read the list of fulfillment node identifiers from the historical allocation records, and exclude all inventory records corresponding to any node in the list from the candidate set. The purpose of this re-filtering is to prevent the same inventory node from being repeatedly allocated in multiple routing attempts for the same order, thus avoiding order data errors.

[0162] The third layer of filtering, self-exclusion: The system reads the order store identifier from the main dimension slot of the order feature vector and excludes all inventory records in the candidate set whose node identifier matches the order store identifier.

[0163] The purpose of this re-screening is to avoid business logic contradictions caused by orders being assigned to the stores that placed the orders for fulfillment.

[0164] The fourth layer of filtering, permission matching: The system reads the distributor node identifier and corresponding hierarchical code of the order subject from the subject dimension slot of the order feature vector.

[0165] For each inventory record in the current candidate set, the system reads the list of dealer node identifiers stored in the dealer level dimension attribute label of that inventory record.

[0166] The system determines whether the distributor node identifier of the ordering entity exists in the list, or whether there is a direct hierarchical relationship between the distributor node identifier of the ordering entity and the distributor node identifier to which the inventory record belongs. That is, when the ordering entity is a higher-level distributor, it can allocate the inventory of lower-level distributors; when the ordering entity is a lower-level distributor, it can only allocate the inventory of its own level.

[0167] If any of the above conditions are met, the selection passes this screening; otherwise, it is excluded.

[0168] The fifth screening step is capability matching: The system reads the daily order limit and monthly shipment limit values ​​of each inventory node in the candidate set, and at the same time reads the cumulative number of orders received and the cumulative number of shipments for the corresponding node in the store operation status table.

[0169] More specifically, the system performs the calculations separately for each node, as follows:

[0170] Whether the total number of orders received on a given day is less than the daily order limit, and whether the total number of orders shipped in a given month is less than the monthly shipping limit.

[0171] Nodes that meet both conditions pass this round of screening, while nodes that do not meet either condition are excluded.

[0172] The sixth layer of filtering, attribute isolation: The system reads the channel affiliation attribute tag corresponding to the current product from the product dimension slot of the order feature vector.

[0173] At the same time, the system reads the channel affiliation dimension attribute label of each inventory record in the candidate set.

[0174] The system matches and verifies the channel affiliation of a product with the store / warehouse type of the inventory node.

[0175] More specifically, if a product is marked as full price, only the inventory records of stores or warehouse nodes marked as full price will be retained;

[0176] If a product is marked as a special offer, only the inventory records of stores or warehouses marked as special offer will be retained.

[0177] Inventory records at warehouse nodes retain both full-price and discounted items. Inventory records that do not meet the above matching criteria are excluded.

[0178] The seventh filtering step, result summary: The system will group and summarize the inventory records that have passed all six filtering steps above by node identifier. Each node identifier corresponds to a group of inventory records, which contains inventory information for all product types currently available at that node.

[0179] The system summarizes the results and writes them into a data structure for the candidate fulfillment node set. This data structure uses the node identifier as the primary key, and each primary key contains a list of products that the node can provide and the available inventory quantity of each product.

[0180] Furthermore, if, after performing the above seven-fold screening, no available inventory record is found for a certain product in the order across all inventory nodes, the system marks the product as an inventory matching failure and records the product's identifier and failure reason code in the order exception log table.

[0181] 5. Step five: Perform a feasibility assessment of the entire order.

[0182] More specifically, the system reads the candidate fulfillment node set data structure generated in step four.

[0183] The system performs a full order coverage check on each node identifier in the data structure.

[0184] Preferably, the specific method for checking the overall order coverage capability is as follows:

[0185] The system uses the currently inspected node identifier as an index to retrieve the list of available products attached to that node.

[0186] The system compares each product category recorded in the order product feature list with the product categories in that list.

[0187] If every item in the order appears in the list of available items for that node, and the available inventory quantity for each item on that node is greater than or equal to the order quantity for the corresponding item in the order, then that node is deemed to have the capability to fulfill the entire order.

[0188] If at least one product is not listed in the product list available for this node, or if the available inventory is insufficient, then this node is deemed not capable of fulfilling the entire order.

[0189] After the system traverses all nodes in the candidate fulfillment node set, it counts the number of nodes with the ability to fulfill the entire order.

[0190] More specifically, if the quantity is greater than or equal to 1, the system determines that the order is feasible to fulfill the entire order, writes the identifiers of all nodes with the ability to fulfill the entire order into the list of feasible nodes for the entire order, and directs the process to step six.

[0191] If the quantity is 0, the system determines that the order is not feasible to fulfill as a whole and will redirect the process to step seven.

[0192] 6. Step six: Execute the whole order intelligent routing allocation process.

[0193] Specifically, when step five determines that an order is feasible for fulfillment, the system enters the intelligent routing allocation process for the entire order.

[0194] The system uses the order type code of the current order as an index to read the warehouse priority strategy configuration item corresponding to that type from the strategy configuration table.

[0195] Furthermore, the strategy configuration table is entered by system administrators through the configuration interface during system initialization. Each record in this table contains fields such as order type code, warehouse priority strategy identifier, order splitting strategy on / off status, and rule priority sequence.

[0196] As a preferred option, the legal values ​​for the warehouse priority strategy identifier include "e-commerce warehouse priority", "city warehouse priority" and "not set".

[0197] More specifically, if the warehouse priority strategy identifier is set to "e-commerce warehouse priority," the system filters nodes marked as either e-commerce warehouses or general warehouses from the list of feasible nodes for the entire order obtained in step five. After filtering, the system reads the warehouse priority weight field value of each candidate e-commerce warehouse. This field value is pre-configured by the system administrator, and the preferred value range is an integer from 1 to 100, with larger values ​​indicating higher priority. The system sorts the candidate nodes in descending order of weight value and selects the node at the top of the sorted list, i.e., the node with the largest weight value, as the final fulfillment node. After selection, the system directly calls the order generation engine to update the original order's shipping node field with the identifier of the selected node and updates the order status to "routed."

[0198] If the warehouse priority strategy flag is set to "City Warehouse Priority," the system reads the city code of the delivery address from the geographic dimension slot of the order feature vector. The system then filters the list of feasible nodes for the entire order, selecting nodes whose city code matches the delivery address city code and whose node type is warehouse. After filtering, the system sorts the candidate nodes in descending order of warehouse priority weight, selecting the node with the highest weight as the final fulfillment node. Once selected, the above order generation engine call operation is executed.

[0199] If the warehouse priority strategy flag is set to "not set", or if the filtering result after executing the above two priority strategies is an empty set, the system starts the multidimensional routing rule engine.

[0200] The working mechanism of the multi-dimensional routing rule engine is as follows:

[0201] The system uses the current order type code as an index to read the rule priority sequence stored in the strategy configuration table.

[0202] The rule priority sequence is an ordered list, where each element is a rule dimension identifier.

[0203] The system retrieves the rule dimension identifiers one by one in the list order, and executes the filtering function corresponding to the current candidate node set as input.

[0204] As a preferred solution, the multi-dimensional routing rule engine supports rule dimensions that include at least the following:

[0205] The address matching priority rule is used to select nodes that have the same delivery address as the node's registration address or have a physical inclusion relationship, while other nodes are excluded.

[0206] The selection method for the member affiliation priority rule is as follows: the system uses the member affiliation store identifier stored in the main dimension slot of the order feature vector as the benchmark, selects and retains nodes that are consistent with the affiliation store identifier from the candidate nodes, and excludes the remaining nodes.

[0207] The filtering method for the store order time period matching rule is as follows: the system reads the current system time and compares it with the start and end times of the business hours of each candidate node. Nodes whose current system time is within the business hours are retained, and nodes outside the business hours are excluded.

[0208] The filtering method for the store order acceptance threshold verification rule is as follows: the system reads the cumulative number of orders accepted and the daily order acceptance limit for each candidate node, filters and retains nodes whose cumulative number of orders accepted is less than the daily order acceptance limit, and excludes nodes that have reached or exceeded the limit.

[0209] The selection method for the inventory digestion speed priority rule is as follows: The system uses the identifier of each candidate node as an index to query the sales and outbound records of each product for that node in the past 7 days, calculates the average daily sales quantity of each product, and sums up the average daily sales quantities of each product to obtain the inventory digestion speed score for that node. The node with the highest score is selected and retained. If multiple nodes have the same score and all of them are the highest values, then all of them are retained.

[0210] The cost center proximity priority rule is implemented as follows: the system reads the cost center code of the ordering store from the main dimension slot of the order feature vector, and selects and retains nodes whose cost center codes match those of the candidate nodes. If the selection result is an empty set, the constraint on that dimension is canceled, and the candidate set before selection is restored.

[0211] The selection method for the credit limit priority rule is as follows: the system uses the dealer identifier to which each candidate node belongs as an index to query the remaining credit limit of that dealer in the credit limit table, and selects the node with the highest remaining credit limit. If multiple nodes have the same remaining credit limit and all of them are the highest value, then all of them are retained.

[0212] The selection method for the maximum available inventory priority rule is as follows: For all product types required by the current order, the system calculates the sum of the available inventory quantities for each candidate node, and selects the node with the largest sum of available inventory quantities. If multiple nodes have the same sum and all are the maximum values, then all are retained.

[0213] The filtering method for the nearest delivery address rule is as follows: the system uses the geocode of the delivery address obtained in step two as the basis and calls the four-level progressive geomatching method described in step eight to filter candidate nodes.

[0214] The selection method for the order store proximity rule is as follows: the system uses the geocode of the registered address of the order store as the basis, calls the four-level progressive geomatching method described in step eight to filter candidate nodes, and superimposes cost center consistency constraints on each level of matching results.

[0215] The selection method for the least number of package splits priority rule is as follows: the system calculates the number of order product types that each candidate node can cover, and selects the node with the most covered product types. If multiple nodes have the same number of covered product types and all of them are the maximum value, then all of them are retained.

[0216] The above-mentioned rule dimensions are executed sequentially according to the priority order stored in the policy configuration table.

[0217] More specifically, after each rule dimension is filtered, the system determines the cardinality of the current candidate node set, i.e., the number of nodes.

[0218] If the base number is equal to 1, the system will identify the unique node as the final fulfillment node and terminate the subsequent execution of the rule engine.

[0219] If the base number is greater than 1, the system continues to execute the filtering of the next rule dimension.

[0220] If, after all rule dimensions in the rule priority sequence have been executed, the cardinality of the candidate node set is still greater than 1, the system determines the final fulfilling node according to the preset fallback strategy.

[0221] More specifically, the fallback strategy is as follows:

[0222] The node with the largest node identifier code value in lexicographical order is selected from the candidate node set as the final fulfilling node.

[0223] After the fulfillment node is determined, the system calls the order generation engine to update the original order's shipment node.

[0224] 7. Step seven: Execute the intelligent routing allocation process for order splitting.

[0225] Specifically, when step five determines that an order is not feasible to fulfill as a whole, the system enters the intelligent routing allocation process for splitting the order.

[0226] The system uses the order type code of the current order as an index to read the value of the order splitting strategy switch status field corresponding to that type in the strategy configuration table.

[0227] Furthermore, if the order splitting strategy switch is set to "off", the system directly determines that the order cannot be fulfilled, updates the order's status field to "allocation failed", generates a prompt message containing the failure reason code and returns it to the order source system, and the order process is terminated.

[0228] If the order splitting strategy switch is set to "On", the system updates the current order's status field to "can be split" and sets the splitting flag field in the order's main table to "Yes". The system then enters an iterative order splitting allocation loop.

[0229] As a preferred approach, the specific execution process of the iterative order splitting and allocation loop is as follows:

[0230] At the start of the first iteration, the system reads all product detail rows that are not split from the product detail list in the main order table, and constructs these detail rows into an unassigned product list.

[0231] The system uses each product in the unassigned product list as a retrieval unit and repeatedly executes the multidimensional inventory matching and candidate fulfillment node screening process described in step four to obtain a set of candidate fulfillment nodes for the current unassigned product set.

[0232] The system performs the order fulfillment feasibility determination described in step five for the set of candidate fulfillment nodes.

[0233] More specifically: if the determination result is that there is a node that can simultaneously cover all the products in the unassigned product list, the system will determine the final fulfillment node for the group of products according to the whole order intelligent routing allocation process described in step six.

[0234] If the determination result is that no node can simultaneously cover all unallocated goods, the system sorts the goods in the unallocated goods list from high to low according to the degree of inventory tightness. This sorting is recalculated at the beginning of each iteration to reflect the impact of changes in the candidate node set after the allocated goods are excluded on the degree of inventory tightness.

[0235] Furthermore,

[0236] The inventory tightness is measured as follows: using the candidate fulfillment node set constructed in step four of this iteration for the currently unallocated goods as the statistical caliber, the total available inventory of each goods in all candidate nodes is traversed. The lower the total available inventory of a goods, the higher its tightness.

[0237] After sorting, the system retrieves each item in turn, reconstructs a candidate fulfillment node set for each item, and performs node filtering for each item according to the multi-dimensional rule engine described in step six to determine the final fulfillment node for that item.

[0238] As a preferred approach, after determining the fulfillment milestone for a single item or a group of items, the system invokes the order generation engine to perform the following operations:

[0239] Generate a new sub-order record, assign a unique sub-order identifier to the sub-order, and establish a one-to-many traceability relationship between the identifier and the original order identifier through an association field;

[0240] Copy the details, price, receipt, and payment information of the item or group of items from the atomic order to the corresponding fields in the sub-order;

[0241] Update the shipping node field of the sub-order to the assigned fulfillment node identifier; record the order splitting source traceability information in the sub-order's description field in structured text format, including at least the atomic order identifier, the splitting sequence number, and the list of rule dimensions hit by this route.

[0242] After the sub-order is generated, the system updates the split status field of these product detail rows that have been assigned in the atomic order from unsplit to split.

[0243] After the first iteration, the system checks whether there are still product detail rows in the atomic order whose split status field is "not split".

[0244] Specifically, if it exists, the system starts a second round of iterations and repeats the above process.

[0245] If it does not exist, the system determines that all product details have been allocated and exits the iteration loop.

[0246] The system also sets a maximum iteration threshold during the iterative loop, with a default value of twice the number of product types in the current order.

[0247] The system increments the iteration counter by 1 after each iteration and compares the current value of the counter with the maximum number of iterations threshold before the start of each iteration.

[0248] If the counter value has reached or exceeded the threshold and there are still unassigned product details in the atomic order, the system will forcibly exit the iteration loop, mark the order as partially successfully assigned, return the list of successfully assigned sub-orders and the list of unassigned products, and push an order splitting timeout alarm message to the system management platform.

[0249] 8. Step eight: Execute multi-level progressive geographic proximity routing.

[0250] During the execution of the delivery address proximity rule and the order store proximity rule described in step six, the system calls the multi-level progressive geographic proximity routing method described in this step.

[0251] More specifically, the input parameters of this method are the current set of candidate nodes and the baseline geographic coordinates. The baseline geographic coordinates are the geographic code of the order's delivery address in the scenario of proximity to the delivery address, and the geographic code of the registered address of the ordering store in the scenario of proximity to the ordering store. The baseline geographic coordinates contain geographic information at four levels: district / county code, city code, province code, and the area identifier to which it belongs.

[0252] As a preferred approach, this method performs a four-level progressive matching, as follows:

[0253] The first level of matching is at the district / county level. The system uses the district / county code in the baseline geographic coordinates as the matching condition to filter the current candidate node set, retaining only nodes whose district / county code in their physical location label matches the baseline district / county code. If the node set after the first level of matching is not empty, the system uses this set as the output of this rule, and the matching process terminates. If the node set after the first level of matching is empty, the system restores the candidate node set to the complete input set before the first level of matching and proceeds to the second level of matching.

[0254] The second level of matching is city-level matching. The system uses the city code in the baseline geographic coordinates as the matching condition to filter the current candidate node set, retaining only nodes whose city code in their physical location label matches the baseline city code. If the node set after the second-level matching is not empty, the system uses this set as the output of this rule, and the matching process terminates. If the node set after the second-level matching is empty, the system restores the candidate node set to the complete input set before the second-level matching was executed and proceeds to the third level of matching.

[0255] The third level of matching is provincial-level matching. The system uses the province code in the baseline geographic coordinates as the matching condition to filter the current candidate node set, retaining only nodes whose province code in their physical location label matches the baseline province code. If the node set after third-level matching is not empty, the system uses this set as the output of this rule, and the matching process terminates. If the node set after third-level matching is empty, the system restores the candidate node set to the complete input set before the third-level matching execution and proceeds to the fourth level of matching.

[0256] The fourth level of matching is area-level matching. The system uses the area identifier in the baseline geographic coordinates as the matching condition to filter the current candidate node set, retaining only nodes whose area identifier in their physical location label matches the baseline area identifier. If the node set after fourth-level matching is not empty, the system uses this set as the output of this rule, and the matching process terminates. If the node set after fourth-level matching is still empty, the system removes the geographic dimension constraint and restores the candidate node set to the complete input set before the fourth-level matching execution, using this as the output of this rule.

[0257] Furthermore, in the order placement store proximity rule, after each level of matching is completed, the system further superimposes cost center consistency constraints on the matching results:

[0258] The system reads the cost center code of the store that placed the order and filters the nodes with the same cost center code from the matching results.

[0259] If the number of filtered nodes is greater than or equal to 1, then these nodes will be used as the final output of the matching at this level.

[0260] If the number of nodes after filtering is 0, then the cost center constraint is cancelled, and all nodes in the matching results are used as the final output of this level of matching.

[0261] 9. Step nine: Execute sub-order generation and route log persistence.

[0262] In step six or seven, after each fulfillment node is determined and the order generation engine is invoked, the system synchronously performs routing log persistence operations.

[0263] Furthermore, the specific method for persisting the routing log is as follows: the system inserts a new record into the routing log table during the current database transaction.

[0264] The order identifier field of this record should be filled with the identifier of the currently processed order; the fulfillment node identifier field should be filled with the node identifier assigned; the allocation timestamp field should be filled with the current system time; and the allocation rule hit record field should be filled with a list of all rule dimension names executed during this routing process and the number of candidate nodes after each rule execution. The primary key of the routing log table is a unique identifier for the log record, generated by the system using the snowflake algorithm.

[0265] Furthermore, after both sub-order generation and routing log persistence are successfully completed, the system commits the current database transaction. If either operation fails, the system rolls back the transaction to ensure consistency between the sub-order records and the routing log records.

[0266] For order splitting scenarios, the system maintains a splitting status field in the product detail rows of each atomic order.

[0267] More specifically, when a product detail row is successfully assigned and a corresponding sub-order is generated, the system updates the split status field value of the row from 0 to 1, and writes the generated sub-order identifier into the sub-order association identifier field of the row.

[0268] In subsequent iterations, the system only queries rows with a split status field value of 0 when constructing the unassigned product list, thus ensuring that the same product details are not processed repeatedly in multiple iterations.

[0269] 10. Step 10: Ensure consistency between order submission and inventory.

[0270] After an order is routed and sub-orders are generated, the system enters the commit phase. Once the commit phase begins, the system first initiates a database transaction and performs concurrency control operations within the transaction.

[0271] Furthermore, the specific method for concurrency control operations is as follows: the system targets the data row containing the order record in the current order master table and executes a SELECT FOR UPDATE query statement.

[0272] When this statement is executed, it requests an exclusive lock on the data row from the database engine.

[0273] More specifically, if the data row is not currently locked by other transactions, the database engine grants an exclusive lock, and the current transaction continues to execute.

[0274] If the data row is already locked by another transaction, the current transaction enters a waiting state until the lock is released or the wait times out. The waiting timeout is determined by the lock timeout parameter in the system configuration file, with a default value preferably 30 seconds.

[0275] If the lock is not acquired after the timeout period, the system throws a lock acquisition failure exception, the current transaction is rolled back, the order submission fails, and a timeout message is returned.

[0276] For scenarios where the system is deployed using a distributed database, the above row-level locking mechanism can be replaced or supplemented with a distributed lock component to achieve cross-node inventory update mutual exclusion. The selection of the specific lock component does not affect the substantive logic of the inventory consistency guarantee method described in this step.

[0277] Furthermore, after successfully acquiring the exclusive lock, the system executes different inventory update logic based on the type of order being processed.

[0278] More specifically, if the order type is a sales order, the system uses a composite index of the fulfillment node identifier and the product identifier to query the inventory balance record table for that fulfillment node. The system then increments the current value of the "Quantity in Order" field in that record by the quantity ordered for the corresponding product in the order, and simultaneously decrements the current value of the "Available Inventory Quantity" field by the quantity ordered. These two updates are performed within the same UPDATE statement, ensuring the atomicity of the changes.

[0279] If the order type is a return order, the system uses the fulfillment node identifier and product identifier as a composite index to query the inventory balance record table for that fulfillment node. The system adds the current value of the "Quantity in Transit" field in that record to the quantity of the corresponding returned goods in the return order. The current value of the "Available Inventory Quantity" field is not updated temporarily; it will be updated by the inbound confirmation process after the returned goods have been actually received into the warehouse.

[0280] Furthermore, after the inventory update is completed, the system performs different order status update operations depending on whether the currently processed order is a split order scenario.

[0281] More specifically, if the current order is an atomic order that has been split, the system updates the status field of the atomic order to "cancelled" and records it as "cancelled due to splitting" in the cancellation reason field.

[0282] If the current order is the original order that has not been split or a sub-order generated after splitting, the system updates the status field of the order to "submitted" and records the current system time in the submission timestamp field.

[0283] After completing the order status update, the system reads the auto-confirmation rule configuration item corresponding to the current order type from the strategy configuration table. If the configuration item is set to "Enabled," the system automatically triggers the confirmation document generation process before the current transaction is committed, generating the corresponding confirmation document record and writing it to the confirmation document table. If the configuration item is set to "Disabled," the system skips the confirmation document generation step.

[0284] After all the above database operations are executed successfully, the system commits the current transaction and releases the exclusive lock. If any of the above operations fail, the system rolls back the current transaction, releases the exclusive lock, the order submission fails, and an error message is returned.

[0285] 11. Step eleven: Execute automatic generation of omnichannel retail orders and cross-channel payment settlement.

[0286] For orders with an offline self-pickup type, the system automatically triggers the retail order generation engine after the order is submitted in step ten.

[0287] Furthermore, the retail order generation engine first creates a forward comprehensive detailed retail order record. The primary key of this record is the retail order number, which is generated by the system according to a preset numbering rule: the business date plus a sequence number.

[0288] Furthermore, the order identifier field of the record is filled with the identifier of the current order, the product details list field stores the complete information of all product details of the order in JSON format, the total sales amount field is filled with the total payment amount of the order, and the generation timestamp field is filled with the current system time.

[0289] As a preferred approach, after the positive comprehensive detailed retail order record is created, the retail order generation engine then creates a negative virtual retail order record.

[0290] Specifically, the retail order number in this record is different from the forward retail order, but they are linked through an association identifier field. The total sales amount field is set to the opposite of the total sales amount of the forward retail order, i.e., a negative value. This negative virtual retail order is used to match the original forward sales receipt number with this negative record when cross-channel returns occur, thereby completing price tracing and inventory return in the return process.

[0291] After the two retail order records are written to the main retail order table, the retail order generation engine pushes these two records to the settlement module of the offline POS retail system through the data interface.

[0292] Subsequently, the system performs payment settlement. The system reads the payment information field from the order data, which records the payment amount corresponding to each payment channel in key-value pairs. Payment channels include cash, VIP stored-value card amount, VIP gift amount, points deduction amount, and shopping voucher amount.

[0293] The system iterates through each key-value pair in the above payment information fields and generates an independent retail payment detail record for each key-value pair.

[0294] Furthermore, each retail payment record must include at least the following fields: retail order number, payment channel identifier, payment amount, and settlement status.

[0295] The retail order number field should be filled with the retail order number of the forward comprehensive detailed retail order, the payment channel identifier should be filled with the channel name of the current key-value pair, the payment amount should be filled with the corresponding payment amount, and the settlement status field should be initially set to pending settlement.

[0296] After all retail payment details are generated, the system writes them into the retail payment details table in batches and pushes the data changes in the table to the settlement module of the offline POS retail system and the reconciliation module of the financial system.

[0297] 12. Step twelve: Dynamically update the operational status of the fulfillment nodes.

[0298] After each order routing assignment is completed, regardless of whether the order is fulfilled as a whole or split, the system initiates an asynchronous update process for the operational status after the transaction is committed in step ten.

[0299] Furthermore, the asynchronous update process works as follows: the system uses the fulfillment node identifier and the number of orders involved in this allocation as input parameters to send a status update message to the message queue middleware. The message queue middleware asynchronously distributes this message to the operational status update consumer process, which performs the following database update operations upon receiving the message:

[0300] Furthermore, the daily cumulative order count is updated as follows: The consumer process queries the store's daily operation status table using the fulfillment node identifier and the current date as a composite index. If a record for the corresponding date exists in the table, the current value of the daily cumulative order count field for that record is incremented by 1; otherwise, a new record is inserted, and the daily cumulative order count field is initialized to 1.

[0301] Furthermore, the update method for the cumulative order quantity for the current month is as follows: The consumer process queries the store's monthly operation status table using the fulfillment node identifier and the current month as a composite index. If a record for the corresponding month exists in the table, the current value of the cumulative order quantity field for the current month in that record is incremented by 1; otherwise, a new record is inserted, and the cumulative order quantity field for the current month is initialized to 1.

[0302] All of the above update operations are implemented using an optimistic locking mechanism, which checks whether the version number field is consistent with the version number read during the update. If they are inconsistent, the update is retried.

[0303] More specifically, after the update operation is completed, the consumer process writes the updated cumulative number of orders received that day and the cumulative number of orders shipped that month into the cache middleware. The data stored in the cache middleware uses the fulfillment node identifier as the key and a JSON object containing the values ​​of the above two fields as the value, with the cache expiration time set to the end of the current calendar day.

[0304] Furthermore, when subsequent orders undergo the fifth step of screening (capability matching) in step four, the system prioritizes reading the cumulative number of orders received that day and the cumulative number of orders shipped that month for each candidate node from the cache middleware. If the corresponding node's data exists in the cache, the system directly uses the cached data for comparison and judgment; if it does not exist in the cache, the system falls back to querying the daily and monthly store operation status tables in the database.

[0305] II. Detailed Implementation of the System

[0306] Based on the above methods and steps, this invention also provides an omnichannel multi-dimensional inventory management and order routing system. This system is used to implement the above methods and specifically includes:

[0307] The unified inventory access gateway is configured with interface units to establish data connections with multiple external inventory systems. These interface units establish data connections with online e-commerce platform inventory management systems, warehouse management systems, and store POS systems via HTTP RESTful APIs or message queue middleware. Internally, the gateway includes a data aggregation unit and a tag generation unit. The data aggregation unit is used to pull real-time inventory quantities from various external systems according to a preset synchronization cycle or to write inventory change data pushed by external systems into the local inventory balance table. The tag generation unit is used to read corresponding multi-dimensional attribute field values ​​from the inventory node information table, product information table, and distributor hierarchical topology table when inventory data is written, generate attribute tags in key-value pairs, and associate them with inventory records for storage.

[0308] The order access gateway is configured with a message receiving unit, a verification unit, and a feature parsing unit. The message receiving unit receives raw order data messages from different sales channels. The verification unit performs format and integrity checks on the received messages. The feature parsing unit extracts order type, shipping address geocode, order entity distributor level information, and product details from the verified messages, and writes the extraction results into an order feature vector table according to a preset data structure.

[0309] The permission verification module is configured with a recursive query unit and a comparison unit. The recursive query unit starts with the order-placing distributor node identifier in the order feature vector table and recursively queries upwards along the parent pointer in the distributor hierarchical topology table until it reaches the headquarters node. It then determines whether a node with omnichannel inventory sharing permissions exists in the path. A depth limit is set during the recursive query process to prevent endless loops caused by topology data anomalies. When the depth limit is reached and the path has not yet reached the headquarters node, the query continues until the headquarters node is reached, and the permission status of the entire path is considered to make a judgment. The comparison unit uses the store identifier as an index to query the cumulative shipment volume field of the store operation status table for the current month and compares it with the monthly shipment limit field value to determine whether a circuit breaker is triggered.

[0310] The multi-dimensional inventory matching engine is configured with a traversal unit and a multi-dimensional filtering unit. The traversal unit is used to traverse all records in the inventory balance table, using each product in the order product feature list as the retrieval unit. The multi-dimensional filtering unit integrates seven filters connected in sequence: quantity filter, mutual exclusion filter, self-exclusion filter, permission matching filter, capability matching filter, attribute isolation filter, and result aggregator. Each filter is executed sequentially according to the order described in step four above. The result aggregator summarizes the finally passed records into a candidate fulfillment node set.

[0311] The order fulfillment determination module is configured with a coverage calculation unit and a determination unit. The coverage calculation unit identifies each node in the candidate fulfillment node set and calculates the ratio of the number of product types that the node can provide to the total number of product types in the order. The determination unit marks the order as entirely feasible if the ratio of any node is equal to 1; otherwise, it marks the order as entirely infeasible.

[0312] The order routing module is configured with a strategy reading unit and a first rule invocation unit. The strategy reading unit is used to read the warehouse priority strategy identifier in the strategy configuration table using the order type code as an index. The first rule invocation unit is used to perform warehouse node filtering when the warehouse priority strategy is hit, and to invoke the multi-dimensional rule engine when the warehouse priority strategy is not hit or no filtering results are found.

[0313] The order splitting and routing module is configured with a switch reading unit and an iterative allocation unit. The switch reading unit is used to read the switch status of the order splitting strategy in the strategy configuration table using the order type code as an index. The iterative allocation unit is used to start an iterative loop when the switch status is on. In each loop, it calls the multi-dimensional inventory matching engine and the whole order fulfillment judgment module for the current unallocated product list. Based on the judgment result, it calls the whole order routing module or the item-by-item allocation process, and calls the order generation engine to generate sub-orders. The iterative allocation unit contains a sorting sub-unit, which is used to recalculate the inventory tightness of each product and determine the allocation order based on the current candidate node set at the beginning of each iteration.

[0314] The multi-dimensional rule engine is configured with a rule sequence reading unit, a rule dimension function library, and an execution unit. The rule sequence reading unit reads the rule priority sequence stored in the strategy configuration table, indexed by the order type code. The rule dimension function library contains the implementations of the filtering functions corresponding to each rule dimension described in step six above. The execution unit calls the corresponding filtering functions one by one according to the rule sequence order, and checks the cardinality of the candidate node set after each round of filtering. Execution terminates when the cardinality equals 1; if the cardinality is still greater than 1 after all rules have been executed, the fallback strategy unit is called.

[0315] The geographic routing module is configured with a geocoding parsing unit and a four-level progressive matching unit. The geocoding parsing unit is used to input the delivery address text or store registration address text into the geocoding service interface to obtain the district / county code, city code, province code, and area identifier. The four-level progressive matching unit sequentially performs district / county, city, province, and area-level matching. If each level of matching fails, the input set is restored and the process is downgraded to the next level. The process terminates immediately upon successful matching at any level.

[0316] The order generation engine is configured with a sub-order creation unit, an information copying unit, and a status update unit. The sub-order creation unit generates a new sub-order identifier and creates a sub-order record. The information copying unit copies the product details, price, receipt, and payment information from the original order to the sub-order. The status update unit updates the split status field of the assigned product detail rows in the original order to "split".

[0317] The routing log management module is configured with a log insertion unit and a query unit. The log insertion unit inserts a record row into the routing log table after each route allocation, containing the order identifier, fulfillment node identifier, allocation timestamp, and allocation rule hit record. The query unit queries the routing log table using the order identifier as a condition during the mutual exclusion process in step four above, returning a list of allocated node identifiers.

[0318] The concurrency control module is configured with a row-level lock acquisition unit and an inventory atomic update unit. The row-level lock acquisition unit performs a SELECT FOR UPDATE operation on the record rows of the order master table at the start of the order commit transaction; for distributed deployment scenarios, this unit also provides a calling interface for the distributed lock component as an alternative or supplementary solution. The inventory atomic update unit atomically updates the "order quantity" and "available inventory quantity" fields in the inventory balance table within the same UPDATE statement after acquiring an exclusive lock.

[0319] The retail order generation engine is configured with a positive retail order generation unit, a negative retail order generation unit, a payment details splitting unit, and a push unit. The positive retail order generation unit creates a positive retail order record that summarizes all product details for the order. The negative retail order generation unit creates a virtual retail order record with a negative sales amount. The payment details splitting unit iterates through the key-value pairs for each channel in the order payment information and generates corresponding retail payment details records. The push unit pushes the retail order record and payment details record to the settlement module of the offline POS retail system.

[0320] The operations status management module is configured with an asynchronous update unit and a cache read / write unit. The asynchronous update unit is used to asynchronously update the daily cumulative order quantity field in the daily operations status table and the monthly cumulative shipment quantity field in the monthly operations status table of the store via message queue middleware. The cache read / write unit is used to write the updated data to the cache middleware and read the latest operations status data of each candidate node from the cache middleware during the capability matching process.

[0321] The data connections between the above modules are as follows: The output of the unified inventory access gateway is connected to the input of the multi-dimensional inventory matching engine. The output of the order access gateway is connected to the inputs of both the permission verification module and the multi-dimensional inventory matching engine. The output of the permission verification module is connected to the rejection feedback interface of the order access gateway and the startup of the multi-dimensional inventory matching engine. The output of the multi-dimensional inventory matching engine is connected to the input of the whole order fulfillment determination module. The whole order feasibility output of the whole order fulfillment determination module is connected to the input of the whole order routing module, and the whole order infeasibility output is connected to the input of the split order routing module. The outputs of both the whole order routing module and the split order routing module are connected to the callers of the multi-dimensional rules engine and the geographic routing module. The routing result outputs of both the whole order routing module and the split order routing module are connected to the inputs of the order generation engine and the routing log management module. The output of the order generation engine is connected to the input of the concurrency control module. The output of the concurrency control module is connected to the input of the retail order generation engine and the operation status management module.

[0322] In actual physical implementation, the above modules can be integrated and deployed on the same physical server, or they can be distributed and deployed on multiple physical servers according to system load and operation and maintenance needs. Data interaction between modules is achieved through inter-process communication within the system or remote procedure calls. The specific communication method does not affect the implementation of the technical solution of this invention.

[0323] III. Further explanation of the technical solution of the present invention is as follows:

[0324] In the methods described in steps one through twelve above, the step numbers are only used to distinguish different operational stages and do not constitute an absolute limitation on the execution order. For example, the multi-level progressive geographic proximity routing method described in step eight is invoked and executed in step six, and it is not executed independently after step seven. The calling relationships between the steps have been clearly explained in the above technical description combined with the specific process.

[0325] It should be noted that the data processing, status judgment, node filtering and inter-module calling operations involved in all the above embodiments of the present invention are all performed on data objects stored in the computer system, and are completed by the computer processor executing instruction sequences. The results are manifested as changes in field values ​​in the database table, migration of order status, and generation and storage of sub-order records.

[0326] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for multi-dimensional inventory management and order routing across all channels, characterized in that, The specific implementation steps are as follows: Build an omnichannel inventory aggregation and control layer to map physically dispersed inventory entities into logically unified inventory aggregation nodes; Obtain order data and parse order feature information; Perform pre-order verification; Based on the aforementioned inventory set management layer, multi-dimensional inventory matching is performed to generate a set of candidate fulfillment nodes; Determine whether there is a node in the candidate fulfillment node set that can fulfill the entire order. If there is, determine the fulfillment node from the candidate nodes according to the preset whole order routing strategy. If there is no, split the order according to the splitting strategy and allocate each split part to the corresponding fulfillment node. After the order is assigned, concurrency control is performed and inventory data is updated using a concurrency lock mechanism; After the order is submitted, for offline self-pickup orders, the retail order will be automatically generated and cross-channel payment settlement will be performed.

2. The method for multi-dimensional inventory management and order routing allocation across all channels as described in claim 1, characterized in that, The construction of the omnichannel inventory aggregation management layer includes: Real-time inventory data from inventory nodes distributed in different physical locations are aggregated into a shared inventory pool across all channels through a unified inventory access gateway, and multi-dimensional attribute tags are established for each inventory record. The multidimensional attribute tags include physical location dimension, product attribute dimension, channel affiliation dimension, and distributor level dimension; The physical location dimension includes store / warehouse identification, city, district / county, and region; The product attribute dimensions include product identifier, attribute instance identifier, and barcode identifier; The channel attribution dimension includes three channel type identifiers: regular price, special price, and clearance. The distributor hierarchy includes headquarters, primary distributors, secondary distributors, and their affiliations. The multidimensional attribute tags also include operational constraint dimensions, which include the node's daily order limit, monthly shipment limit, business hours, and the cost center to which it belongs.

3. The method for multi-dimensional inventory management and order routing allocation across all channels as described in claim 1, characterized in that, The pre-execution verification of the order includes: Perform verification of the legality of the order-placing entity and pre-verification of its order-accepting capability; The verification of the legality of the ordering entity is based on a pre-built dealer hierarchical topology model. If the verification fails, the order will be rejected. The order acceptance capacity pre-verification involves querying the store's operational constraint model to check whether the store's cumulative order volume exceeds the upper limit. If it does, a circuit breaker mechanism is triggered to reject the order.

4. The method for multi-dimensional inventory management and order routing allocation across all channels as described in claim 1, characterized in that, The method for performing multi-dimensional inventory matching and generating a set of candidate fulfillment nodes is as follows: Using each item in the order as a retrieval unit, the inventory records in the inventory collection management layer are traversed, and the multi-dimensional filtering logic is used to perform filtering. The inventory records that pass all the filtering conditions are summarized into a candidate fulfillment node set according to the inventory node dimension. The multidimensional filtering logic includes: Quantity matching: Filter inventory nodes where the available inventory is greater than or equal to the order demand. Mutual exclusion: Exclude inventory nodes that have already been assigned in the current order's historical routing log; Self-exclusion: Excludes the inventory nodes of the store where the order was placed; Permission matching: Filter inventory nodes at the dealer level that meet the inventory sharing permission policy; Capacity matching: Filter inventory nodes that have not exceeded the daily order limit and monthly shipment limit; Attribute isolation: Match and verify the product's channel affiliation attribute with the store / warehouse type attribute of the inventory node. Regular-priced products are only assigned regular-priced inventory or warehouse node inventory, and discounted products are only assigned discounted inventory or warehouse node inventory. Warehouse node inventory can be assigned all types of inventory.

5. The method for multi-dimensional inventory management and order routing allocation across all channels as described in claim 1, characterized in that, The method for determining whether there is a node in the candidate fulfillment node set that can fulfill the entire order is as follows: The product category coverage of each candidate node in the candidate fulfillment node set that can be fulfilled independently is statistically analyzed. If the product category coverage of any candidate node is equal to the total number of product categories in the order, then the order is determined to be feasible for fulfillment of the entire order. The whole order routing strategy is as follows: read the warehouse priority strategy configuration corresponding to the order type, and if the warehouse priority strategy is matched, select the corresponding warehouse node as the fulfillment node. If the warehouse priority strategy fails to hit or fails to filter out a valid node, the multi-dimensional routing rule engine is started, and the candidate nodes are filtered step by step according to the configurable multi-dimensional rule priority sequence until the cardinality of the candidate node set converges to 1, at which point a unique fulfilling node is determined. The multi-dimensional routing rule engine supports rule dimensions that include at least several of the following: address matching priority, member affiliation priority, store order time matching, store order threshold verification, inventory digestion speed priority, cost center proximity priority, credit limit priority, maximum inventory priority, delivery address proximity rule, order store proximity rule, and minimum number of packages priority. The execution of the delivery address proximity rule and the order store proximity rule adopts a four-level progressive geographic matching strategy: The first level of matching is the district / county level matching, which filters nodes that match the district / county code of the baseline geographic coordinates; If the first-level matching result is empty, the candidate node set is restored to the complete input set before matching and downgraded to the second-level city-level matching. If the second-level matching result is empty, it will be downgraded to the third-level provincial matching; if the third-level matching result is empty, it will be downgraded to the fourth-level regional matching. If the matching result at any level is not empty, the matching result at that level is used as the filtered set of candidate nodes for output. In the order placement store proximity rule, after each level of matching is completed, a cost center consistency constraint is further superimposed, prioritizing the screening of fulfillment nodes that belong to the same cost center as the order placement store.

6. The method for multi-dimensional inventory management and order routing allocation across all channels as described in claim 1, characterized in that, The order splitting strategy is as follows: Read the order splitting strategy switch configuration corresponding to this order type. If the order splitting strategy switch is in the off state, it is determined that the order cannot be fulfilled. If the order splitting strategy switch is on, it will enter an iterative order splitting allocation loop. In each loop, the product details that have not yet been allocated will be processed to determine the corresponding fulfillment node and generate a sub-order, until all product details are allocated or the preset iteration termination condition is met. In the iterative order splitting and allocation loop, the preset iteration termination condition is reaching the preset maximum iteration count threshold.

7. The method for multi-dimensional inventory management and order routing allocation across all channels as described in claim 1, characterized in that, The automatic generation of retail orders and cross-channel payment clearing operations are as follows: Trigger the retail order generation engine to generate a positive comprehensive detailed retail order, which summarizes the positive sales information of all product details in the order; and generate a negative virtual retail order, the sales amount of which is the negative value of the sales amount of the positive comprehensive detailed retail order, which is used to match the original receipt number when returning goods across channels; The payment amount corresponding to each payment channel in the original order's payment information is analyzed, and retail payment details for each payment channel are generated and pushed to the settlement module of the offline POS retail system to complete cross-channel clearing and reconciliation.

8. The method for multi-dimensional inventory management and order routing allocation across all channels as described in claim 1, characterized in that, After each order routing assignment is completed, the operational status of the fulfillment node is also dynamically updated. The fulfillment node identifier and the number of orders involved in this allocation are used as input parameters. The cumulative number of orders received and the cumulative number of orders shipped in the current month for the fulfillment node are updated asynchronously through the message queue middleware. The updated operational status data is written to the cache middleware and fed back to the inventory collection management layer as a real-time constraint condition for the capability matching link in the subsequent order routing allocation. The routing assignment result will be persisted to the routing log table.

9. The method for multi-dimensional inventory management and order routing allocation across all channels as described in claim 1, characterized in that, The method of performing concurrency control and updating inventory data through a concurrency lock mechanism is as follows: Before the order submission transaction begins, an exclusive lock is acquired on the data row containing the order record in the main order table. If the data row has been locked by another transaction, it will enter a waiting state until the lock is released or the wait times out. After successfully acquiring the exclusive lock, an inventory update operation is performed within the same database transaction. The inventory update operation atomically completes the increase of the first inventory occupancy parameter and the decrease of the available inventory quantity field within the same update statement. The first inventory occupancy parameter is the quantity in order, and the second inventory occupancy parameter is the quantity in transit; If the order type is a sales order, update the order quantity; If the order type is a return order, update the in-transit quantity.

10. A multi-channel, multi-dimensional inventory management and order routing system, characterized in that, Performing the method as described in any one of claims 1-9 through the system specifically includes: The unified inventory access gateway is used to aggregate real-time inventory data from inventory nodes distributed in different physical locations into a shared inventory pool across all channels, and to establish multi-dimensional attribute tags for each inventory record. The order access gateway is used to receive raw order data messages and parse and extract order feature vectors from them. The authorization verification module is used to verify the legality of the ordering entity's qualifications based on the dealer hierarchical topology model, and to verify whether the store's cumulative order volume exceeds the limit. The multi-dimensional inventory matching engine is used to traverse the inventory records in the omnichannel shared inventory pool with each product in the order as the retrieval unit and perform multi-dimensional condition filtering, and summarize the filtering results into a set of candidate fulfillment nodes. The whole order fulfillment determination module is used to count the coverage of product types that each candidate node can fulfill independently, and to determine whether the order is feasible to fulfill as a whole order or needs to be split into multiple orders for fulfillment. The whole order routing module is used to determine the fulfillment node from the candidate nodes according to the preset whole order routing strategy when the whole order is feasible; The order splitting and routing module is used to split an order according to an order splitting strategy when the whole order is not feasible, and to allocate each split part to the corresponding fulfillment node. The order generation engine is used to generate sub-order records and update the shipping node field; The concurrency control module is used to perform concurrency control and atomically update inventory data during the order submission phase using a concurrency lock mechanism. The retail order generation engine is used to generate positive comprehensive detailed retail orders and negative virtual retail orders after the order is submitted. It parses each payment channel and generates retail payment detail records respectively, and pushes them to the settlement module of the offline POS retail system. The operation status management module is used to asynchronously update the daily cumulative order quantity and monthly cumulative shipment quantity of the fulfillment node through a message queue, write the updated data to the cache middleware and feed it back to the multi-dimensional inventory matching engine.

Images