Supply chain replenishment data processing method for multi-level inventory

Abstract

This invention relates to the interdisciplinary field of computer data processing and supply chain management, and provides a supply chain replenishment data processing method for multi-level inventory. To address the problems of insufficient real-time performance, poor stability, and difficulty in adapting to dynamic constraints caused by the globally coupled architecture in traditional technologies, the method instantiates each inventory node in the supply chain network as an autonomous decision-making unit, constructs a collaborative rule graph structure of the collaborative relationships between autonomous decision-making units, and, in response to replenishment demand events, matches corresponding collaborative rules from the collaborative rule graph structure to enable the first autonomous decision-making unit to initiate a real-time responsive decision-making process, sends a consensus request to the second autonomous decision-making unit, receives its response proposal, and then aggregates the response proposal into a replenishment decision instruction and sends it to the execution system. This realizes autonomous and collaborative replenishment decisions for each node in the multi-level inventory system, significantly improving the real-time performance, stability, and dynamic adaptability of supply chain replenishment decisions.

Description

Technical Field

[0001] This invention relates to the interdisciplinary field of computer data processing and supply chain management, and particularly to distributed collaborative decision-making, event-driven architecture and rule graph structure technology, specifically to a supply chain replenishment data processing method for multi-level inventory. Background Technology

[0002] Supply chain replenishment data processing for multi-level inventory refers to the data processing process that generates decision-making instructions for replenishment quantity, timing, and source for each node in a multi-level inventory network, including central warehouses, regional warehouses, forward warehouses, and mobile inventory nodes (such as salesperson vehicle inventory), based on the real-time inventory status, historical sales data, and order demand of each node. It is a core functional module in modern supply chain management systems. With the rapid development of the fast-moving consumer goods (FMCG) distribution industry, distributors face complex management needs involving multiple product categories, multi-level warehouses, and multiple business roles, placing higher demands on the real-time performance, stability, and dynamic adaptability of replenishment decisions.

[0003] In traditional technologies, supply chain replenishment data processing typically employs the following methods: ERP systems based on safety stock alerts (such as SAP) pre-set safety stock thresholds for each warehouse, triggering replenishment suggestions when inventory falls below the threshold; centralized optimization systems based on demand forecasting (such as advanced planning and scheduling systems) collect inventory, sales, and cost data from all nodes to build a global optimization model, using linear programming or mixed-integer programming to solve for the optimal replenishment plan; and traditional inventory management systems based on the reorder point method calculate the economic order quantity based on historical sales data and generate purchase orders. These methods generally adopt a processing model of "centralized data aggregation - global model solving - plan order distribution downwards."

[0004] However, the fundamental technical problem with the aforementioned traditional technologies lies in their insufficient real-time performance, poor stability, and inability to adapt to dynamic constraints in replenishment decisions. This often leads to inventory imbalances in multi-level inventory systems, where localized overstocking and shortages coexist. The core reason for this problem is that traditional technologies employ a "globally coupled" data processing architecture. Under this architecture, data from all inventory nodes is aggregated at a central node to construct a unified global optimization model. Any data fluctuation at any node or new business constraints (such as vehicle malfunctions, temporary promotions, or empty bottle recycling) will cause the global model to need to be re-solved, resulting in an exponential increase in computational complexity. Furthermore, the actual situation at the execution end after the plan is issued cannot be fed back to the model in real time, forming an open-loop decision-making mode without execution feedback. Long-term technological improvements in this field have focused on optimizing solution algorithms, improving computing hardware performance, and shortening polling intervals, attempting to approach real-time performance through faster centralized computing. However, the globally coupled architecture cannot fundamentally overcome the "single-point computing bottleneck" and "global data dependency," creating a technical dilemma where "the more optimized, the more fragile the system; the more the optimal solution is pursued, the worse the real-time performance becomes."

[0005] Therefore, how to achieve autonomous and collaborative replenishment decisions for each node in a multi-level inventory system while avoiding a globally coupled architecture has become a pressing technical problem in the field of supply chain replenishment data processing. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a supply chain replenishment data processing method for multi-level inventory. By decoupling the globally coupled architecture into a distributed collaborative and self-regulating architecture, it constructs an event-driven real-time response mechanism and a consensus-driven collaborative decision-making mechanism. Unlike the optimization mode that relies on centralized solutions in traditional technologies, this method can achieve real-time synchronization between replenishment decisions and dynamic changes in multi-level inventory, thereby improving the adaptability, accuracy, and efficiency of system decisions.

[0007] To address the aforementioned technical problems, this invention provides the following technical solution: a supply chain replenishment data processing method for multi-level inventory, comprising: instantiating each inventory node in the supply chain network as a corresponding autonomous decision-making unit; constructing a collaborative rule graph structure, wherein the collaborative rule graph structure is used to define collaborative interaction rules and relationships between different autonomous decision-making units; responding to a replenishment demand event detected from an inventory node in the supply chain network, identifying the event type of the replenishment demand event, matching the corresponding collaborative rule from the collaborative rule graph structure according to the event type, and initiating a real-time responsive decision-making process for a first autonomous decision-making unit related to the replenishment demand event; through the real-time responsive decision-making process, the first autonomous decision-making unit sends a consensus request to at least one second autonomous decision-making unit related to the replenishment demand event according to the collaborative rule; receiving a response proposal returned by the second autonomous decision-making unit, wherein the response proposal is independently generated by the second autonomous decision-making unit according to its own state and the collaborative rule; the first autonomous decision-making unit aggregates the response proposal into a replenishment decision instruction according to a locally stored priority weight table, and issues the replenishment decision instruction to the execution system.

[0008] As a preferred embodiment of the supply chain replenishment data processing method for multi-level inventory described in this invention, the method further includes enabling a first autonomous decision-making unit related to the replenishment demand event to initiate a real-time responsive decision-making process, and enabling the first autonomous decision-making unit to initiate a predictive responsive decision-making process in parallel with the real-time responsive decision-making process: acquiring historical replenishment demand time-series data of the inventory nodes managed by the first autonomous decision-making unit, wherein the historical replenishment demand time-series data includes the actual replenishment outbound quantity for each time unit within a past preset period; based on the historical replenishment demand time-series data, calculating the predicted replenishment demand quantity within a future preset time period using a time series prediction model; and determining when the predicted replenishment demand quantity exceeds the inventory... When the difference between the node's safety stock threshold and the current inventory level is reached, a predictive replenishment demand event is generated. This predictive replenishment demand event includes a predicted replenishment demand product identifier, a predicted replenishment demand quantity, and a predicted replenishment demand time window. Based on the start timestamp within the predicted replenishment demand time window, a predictive responsive decision task is created in the local event queue of the first autonomous decision-making unit, and the priority of this predictive responsive decision task is set to be lower than the preset priority value of the real-time responsive decision task. When the predicted replenishment demand time window arrives, the status of the predictive responsive decision task is switched from pending to executable to initiate the predictive responsive decision process corresponding to the predictive responsive decision task.

[0009] Beneficial Effects: The solution implemented in this invention first achieves node-level decoupling of the multi-level inventory system by instantiating each inventory node in the supply chain network as an autonomous decision-making unit. This breaks down the highly coupled data processing units in the traditional centralized architecture into independent, autonomously running software objects, eliminating single-point computational bottlenecks caused by global data dependencies. Based on this, a collaborative rule graph structure is constructed to define the collaborative interaction rules and relationships between different autonomous decision-making units. This achieves standardized definition of distributed node interaction behavior and rule-level relationship modeling. Unlike the traditional "master-slave" collaborative model that relies on a central node for unified coordination, the rule graph structure pushes collaborative logic down from the central node to each individual decision-making unit, providing an executable rule foundation for decentralized collaboration. Furthermore, by responding to detected replenishment demand events, the event type is identified, and corresponding collaborative rules are matched from the rule graph structure. This triggers the relevant autonomous decision-making units to initiate a real-time responsive decision-making process, enabling immediate perception and local response to inventory changes. Unlike the "post-event compensation" mode that relies on timed polling or batch import in traditional technologies, the event-driven mechanism eliminates the inherent delay between data changes and decision responses. Furthermore, in the real-time responsive decision-making process, the first autonomous decision-making unit sends a consensus request to the second autonomous decision-making unit and receives response proposals independently generated by the second unit based on its own state and collaboration rules. This achieves a distributed negotiation mechanism among multiple nodes, decomposing the global optimization problem into multiple sub-problems of local autonomous decision-making and consensus-building, avoiding the exponential computational complexity caused by resolving the global model. On this basis, the first autonomous decision-making unit aggregates the response proposals into replenishment decision instructions based on the locally stored priority weight table and issues them to the execution system, realizing the intelligent fusion of multi-source response proposals and the closed-loop output of decision instructions.

[0010] By combining the aforementioned interconnected effects, a four-in-one collaborative self-regulatory replenishment decision-making architecture was constructed, consisting of "node decoupling into autonomous decision-making units, collaborative rule graph structure defining interaction, event-driven responsive decision-making, and consensus-driven collaborative aggregation".

[0011] Therefore, unlike traditional replenishment decision-making methods that rely on a "global coupling" model to aggregate all data to a central node to solve for the global optimal solution, this invention decouples the globally coupled architecture into a distributed collaborative self-regulating architecture, constructs an event-driven real-time response mechanism and a consensus-driven collaborative decision-making mechanism, and transforms the traditional passive and lagging "centralized solution" model into an active and real-time "collaborative self-regulating" model. This enables autonomous and collaborative replenishment decisions by each node in a multi-level inventory system, solving the technical problem of "how to achieve autonomous and collaborative replenishment decisions by each node in a multi-level inventory system without avoiding a globally coupled architecture," and significantly improving the real-time performance, stability, and dynamic adaptability of supply chain replenishment decisions. Attached Figure Description

[0012] Figure 1 A flowchart illustrating the supply chain replenishment data processing method for multi-level inventory provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the first sub-process of the supply chain replenishment data processing method for multi-level inventory provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the second sub-process of the supply chain replenishment data processing method for multi-level inventory provided in an embodiment of the present invention. Detailed Implementation

[0013] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0014] This invention provides a supply chain replenishment data processing method for multi-level inventory. This method can be a distributed collaborative decision engine hosted on a server or cloud platform, capable of driving supply chain management applications including but not limited to the following dimensions: First, in the digital management platform of FMCG distributors, by instantiating central warehouses, regional warehouses, forward warehouses, and salesperson vehicle-mounted inventory as autonomous decision-making units, and combining them with a collaborative rule graph structure, autonomous replenishment decisions and dynamic collaboration of multi-level inventory nodes are achieved, effectively reducing inventory turnover days and mitigating inventory imbalances caused by both stockouts and overstocking. Second, in the channel digital management system of brand owners, by aggregating replenishment decision data from distributor nodes to generate a channel inventory health assessment report, data support is provided for optimizing channel inventory strategies, achieving an upgrade from single-point inventory management to omnichannel inventory collaboration. Third, in intelligent replenishment tools for retail stores, by using store inventory as the end-user autonomous decision-making unit, and combining it with historical sales time-series data to generate predictive replenishment demand reference information, bidirectional collaboration between proactive replenishment at the store end and passive response from upstream warehouses is achieved. This invention addresses the technical challenges of insufficient real-time performance and poor stability caused by the globally coupled architecture in multi-level inventory systems, providing reusable core data capabilities for the fast-moving consumer goods distribution industry and the broader field of supply chain management.

[0015] The following detailed description of some embodiments of the present invention is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0016] Example 1: Supply chain replenishment data processing method for multi-level inventory.

[0017] Please see Figure 1 , Figure 1This is a flowchart illustrating a supply chain replenishment data processing method for multi-level inventory provided in an embodiment of the present invention. Figure 1 As shown, in this embodiment, taking the supply chain network of a fast-moving consumer goods distributor as an example, the network includes a central warehouse, regional warehouses, forward warehouses, and mobile inventory nodes in vehicles used by salespersons. The monitoring nodes are centralized monitoring servers deployed in the cloud. The method includes the following steps S11-S16: S11: Instantiate each inventory node in the supply chain network as a corresponding autonomous decision-making unit.

[0018] Autonomous Decision-Making Unit (ADI): This refers to a software object created for each inventory node in the supply chain network, encapsulating the node's static attributes and dynamic states, and incorporating built-in decision-making logic. An ADI should include at least: a node identifier, node type (e.g., central warehouse, regional warehouse, forward warehouse, or mobile inventory node), current inventory level, in-transit inventory level, safety stock threshold, a locally stored topology graph, and a locally stored priority weight table. An ADI can independently perceive its state changes, autonomously generate decisions based on a pre-defined collaborative rule graph structure, and collaboratively interact with other ADIs. ADIs can be implemented using well-known technologies in the field, such as class instances in object-oriented programming languages, independent service processes in microservice architectures, or containerized functional modules, which will not be elaborated upon here.

[0019] The specific implementation of this step is as follows: First, during the system initialization phase, the central server acquires the complete topology information of the supply chain network. This supply chain network comprises multiple levels of inventory nodes, including but not limited to brand owner central warehouses, distributor central warehouses, regional distribution warehouses, forward warehouses, and mobile inventory nodes mounted on vehicles by sales personnel. The central server parses the configuration parameters of each node, including node identifier, node type, geographical coordinates, storage capacity, supply and demand hierarchy relationship with adjacent nodes, and spatial distance relationship.

[0020] Secondly, the central server creates a corresponding autonomous decision-making unit instance for each inventory node. For each inventory node, a unique unit identifier is assigned, its state variables (such as current inventory, in-transit inventory, and safety stock threshold) are initialized, its static attributes (node ​​type, geographic coordinates, and storage capacity) are loaded, and the local topology graph and priority weight table are initialized. The topology graph defines the supply and demand hierarchy (such as the supply relationship between the central warehouse → regional warehouse → forward warehouse) and spatial distance relationship (Euclidean distance or logistics path distance calculated based on geographic coordinates) between the node and other autonomous decision-making units in the supply chain network. The priority weight table records multiple decision dimensions (such as time priority, cost priority, and supplier reliability) and their corresponding weight coefficients. The initial weight coefficients can be preset according to business rules or obtained statistically from historical data.

[0021] Third, the central server registers the instantiated autonomous decision-making units to the distributed collaborative network and synchronizes the current version of the collaborative rule graph structure to the local cache, enabling each autonomous decision-making unit to have independent rule parsing and execution capabilities.

[0022] Fourth, each autonomous decision-making unit enters the running state, independently maintains its local event queue, and continuously listens for status change events from the physical inventory system corresponding to its node, as well as collaboration requests from other autonomous decision-making units.

[0023] It should be noted that the instantiation methods of the aforementioned autonomous decision-making units are not limited to the examples given. In one example, a containerized deployment approach can be used, encapsulating each autonomous decision-making unit as an independent Docker container and orchestrating and managing it through Kubernetes. This approach is suitable for large-scale supply chain scenarios with a large number of nodes and the need for elastic scaling. In another example, a serverless function computation approach can be used, deploying the core decision-making logic of the autonomous decision-making unit as a cloud function, which is triggered and executed on demand. This approach is suitable for scenarios with large fluctuations in business volume and the desire to reduce the cost of idle resources. Any technical means that can achieve object-oriented encapsulation of inventory node software and enable it to make independent decisions is within the scope of protection of this invention.

[0024] For example, taking the supply chain network of a fast-moving consumer goods distributor as an example, assume that the supply chain network includes 1 central warehouse (node ​​identifier W00), 3 regional distribution warehouses (W01, W02, W03), 5 forward warehouses (W011, W012, W013, W014, W015) and 20 salespersons (S001 to S020). During system initialization, the central server creates an autonomous decision-making unit instance ADU_W00 for the central warehouse, initializing its current inventory (e.g., 5000 cases of a beverage), in-transit inventory (800 cases procured from the supplier), and safety stock threshold (1000 cases). For the regional warehouse W01, an ADU_W01 instance is created, initializing its current inventory (1200 cases), in-transit inventory (300 cases transferred from the central warehouse), and safety stock threshold (400 cases). For the salesperson S001, a mobile autonomous decision-making unit ADU_S001 is created, initializing its vehicle-mounted inventory (80 cases) and safety stock threshold (30 cases). After instantiation, each autonomous decision-making unit registers with the distributed collaborative network, becoming aware of the network topology (e.g., ADU_W01 is a downstream node of ADU_W00, and ADU_S001 is under the jurisdiction of ADU_W01), and loads the collaborative rule graph structure into its local cache, entering an independent operating state.

[0025] In step S11, by instantiating each inventory node in the supply chain network as an autonomous decision-making unit, node-level decoupling of the multi-level inventory system is first achieved. The highly coupled data processing unit in the traditional centralized architecture is split into independent, autonomously running software objects, eliminating the single-point computing bottleneck caused by global data dependence. This provides an independently running and collaboratively interactive basic unit for the collaborative self-discipline replenishment decision-making architecture of claim 1.

[0026] S12: Construct a collaborative rule graph structure, which is used to define the collaborative interaction rules between different autonomous decision-making units and the relationships between the rules.

[0027] Collaborative rule graph structure: This refers to a rule organization architecture that uses graph data structures to model the collaborative interaction rules and relationships between autonomous decision-making units. A collaborative rule graph structure contains at least one collaborative rule node and directed or bidirectional edges connecting different collaborative rule nodes. Each collaborative rule node corresponds to a type of collaborative interaction rule, including but not limited to hierarchical replenishment rules (defining supply and demand response relationships between upstream and downstream nodes), spatial allocation rules (defining inventory allocation relationships between peer nodes), time scheduling rules (defining time windows and priority relationships for decision-making tasks), and resource constraint rules (defining the allocation relationships of dynamic resources such as vehicles and personnel). The edges connecting nodes carry relationship type identifiers (such as dependency, priority, and mutual exclusion relationships) and relationship weight values, used to characterize the strength of the association or execution order between rules.

[0028] Collaborative interaction rules refer to predefined rule expressions within a collaborative rule graph structure, used to regulate the interaction behavior between different autonomous decision-making units. Each collaborative interaction rule includes at least: a rule identifier, a rule type, triggering condition parameters (e.g., inventory below a threshold, receipt of a consensus request), execution condition parameters (e.g., node status is online, availability of a logistics path), and a set of output actions (e.g., generating a replenishment commitment, sending a transfer request). Collaborative interaction rules are stored in the node attributes of the graph database in a structured data format (e.g., JSON or Protocol Buffers), allowing autonomous decision-making units to query and invoke them in real time during decision-making.

[0029] The specific implementation of this step is as follows: First, the central server acquires the set of business rules for supply chain collaborative management. For example, in the FMCG distribution sector, the set of business rules can be predefined based on business practices in the FMCG distribution sector, including but not limited to: hierarchical rules for replenishing goods from the central warehouse to downstream regional warehouses, spatial rules for inventory transfers between adjacent forward warehouses, time-based scheduling rules for prioritizing urgent orders, and resource allocation rules constrained by vehicle occupancy rates. The central server parses each business rule into structured data, extracting the rule type, triggering conditions, execution conditions, and output actions to form the raw data record of collaborative interaction rules.

[0030] Secondly, the central server creates a corresponding collaborative rule node for each collaborative interaction rule. For example, for a hierarchical replenishment rule, a rule node N_hierarchy is created, defining its input parameter set (such as upstream node inventory and downstream node demand) and output action set (such as generating a replenishment order and deducting upstream inventory). Similarly, for a spatial allocation rule, a rule node N_spatial is created, defining its input parameter set (such as the inventory difference between adjacent nodes and allocation cost) and output action set (such as generating an allocation order and updating the inventory of both nodes); for a time scheduling rule, a rule node N_temporal is created, defining its input parameter set (such as task priority and time window) and output action set (such as task queuing and priority skipping); for a resource constraint rule, a rule node N_resource is created, defining its input parameter set (such as the current vehicle load and remaining capacity) and output action set (such as allocating vehicles and planning routes). Each collaborative rule node is stored in the graph database with a unique identifier, and the node attributes contain a complete rule definition.

[0031] Third, the central server creates edges connecting different collaborative rule nodes based on the logical relationships between the collaborative interaction rules. The central server analyzes the dependencies (e.g., resource constraint rules must execute time scheduling rules before execution), priority relationships (e.g., hierarchical replenishment rules have higher priority than space allocation rules), and mutual exclusion relationships (e.g., the same resource cannot be called by two rules simultaneously), creating directed or bidirectional edges for rule nodes with related relationships. Each edge carries a relationship type identifier (e.g., "depends_on", "higher_priority_than", "mutual_exclusive") and a relationship weight value (e.g., priority difference, dependency strength). The weight value can be represented numerically; for example, the weight of an edge pointing from a higher-priority rule node to a lower-priority rule node is 0.8.

[0032] Fourth, the central server stores the collaborative rule nodes and edges in the graph database to form a collaborative rule graph structure, and synchronously distributes them to the local cache of each instantiated autonomous decision-making unit in the supply chain network, enabling each autonomous decision-making unit to independently query and parse the collaborative rules.

[0033] It should be noted that the specific implementation of the above-mentioned collaborative rule graph structure is not limited to the examples given. In one example, a knowledge graph based on RDF can be used to construct rule relationships, and complex rule reasoning can be achieved through the SPARQL query language. This is suitable for scenarios where the relationships between rules are highly complex and semantic reasoning is required. In another example, a rule-based expert system can be used to encapsulate collaborative rules into production rules (IF-THEN structure), and rule matching and execution can be performed through a rule engine (such as Drools). This is suitable for scenarios with a small number of rules and high execution efficiency requirements. Any technical means that can realize graph structure modeling and dynamic querying of collaborative interaction rules are within the protection scope of this invention.

[0034] For example, following the previous example, the central server creates a hierarchical replenishment rule node N1, defining its input parameters as "upstream node inventory > safety stock threshold + downstream node demand" and "downstream node inventory < safety stock threshold", with the output action being "generate replenishment order"; it also creates a spatial allocation rule node N2; a time scheduling rule node N3; and a resource constraint rule node N4. A directed edge N1→N2 is created, with the relation type identified as "higher_priority_than" and a weight of 0.9; a directed edge N3→N4 is created, with the relation type identified as "depends_on" and a weight of 1.0; and a bidirectional edge N1-N3 is created, with the relation type identified as "mutual_exclusive" and a weight of 0.5. After storing these nodes and edges in the Neo4j graph database, they are synchronously distributed to all autonomous decision-making units.

[0035] In step S12, by constructing a collaborative rule graph structure, the traditional "implicit coupling" rule execution mode is transformed into an "explicit graph structure" rule query mode, providing a unified technical foundation for rule definition, rule association, and rule execution for the collaborative self-regulatory replenishment decision architecture of claim 1.

[0036] S13: In response to a replenishment demand event detected from an inventory node in the supply chain network, identify the event type of the replenishment demand event, match the corresponding collaborative rule from the collaborative rule graph structure according to the event type, and enable the first autonomous decision-making unit related to the replenishment demand event to start a real-time responsive decision-making process.

[0037] Real-time responsive decision-making process: This refers to a local decision-making process initiated by the first autonomous decision-making unit, starting with event triggering and characterized by real-time response. The real-time responsive decision-making process includes at least the following steps: identifying replenishment demand event types, matching corresponding collaborative rules from the collaborative rule graph structure, sending consensus requests to relevant second autonomous decision-making units, receiving response proposals, and aggregating and generating replenishment decision instructions. This real-time responsive decision-making process differs from the "timed batch processing" mode of traditional centralized optimization systems, employing an event-driven, instant processing mechanism to ensure that the delay from demand occurrence to decision generation is controlled within milliseconds.

[0038] The specific implementation of this step is as follows: First, the central server starts the event listening service. The event listening service registers multiple event sources, including status change events of each autonomous decision-making unit, inventory threshold trigger events, and external order receipt events.

[0039] Secondly, when the event listening service receives an event message from an inventory node in the supply chain network, it parses the event message and extracts the event type field and the event content field. The event type field is used to identify the business type of the event, such as "inventory below the lower limit threshold", "new order", or "salesperson reports stock shortage". The event content field contains the specific parameters of the event, such as the inventory node identifier, the product identifier of the replenishment request, and the quantity of the replenishment request.

[0040] Third, if the event type field indicates that inventory is below the lower threshold, an order has been added, or a salesperson reports stockouts, the event message will be identified as a replenishment demand event. A replenishment demand event refers to a data-driven event triggered by an inventory node in the supply chain network, indicating that the node has a replenishment demand. A replenishment demand event must include at least the event type field, the event source identifier (a unique identifier of the triggering node), the event trigger timestamp, the replenishment demand product identifier, and the replenishment demand quantity.

[0041] Fourth, extract the event type identifier from the event message and use this identifier as the query key to retrieve matching collaborative rule nodes in the collaborative rule graph structure. Specifically, using the event type identifier as the query key, search the rule nodes in the collaborative rule graph structure to find collaborative rule nodes whose trigger condition parameters in the input parameter set match the current event type. For example, if the event type is "stock_below_threshold", then match the tiered replenishment rule node; if the event type is "new_order", then match a combination of the time scheduling rule node and the tiered replenishment rule node. The matching process can be implemented using a query language of the graph database (such as Cypher or Gremlin), with a query statement like: MATCH (n:RuleNode) WHERE n.trigger_type = $eventType RETURN n.

[0042] Fifth, based on the inventory node identifier in the replenishment demand event, query and determine the autonomous decision-making unit corresponding to the inventory node identifier from all instantiated autonomous decision-making units as the first autonomous decision-making unit, and send a start command to it to enable the first autonomous decision-making unit to start the real-time responsive decision-making process.

[0043] For example, continuing from the previous example, the inventory management system of the front warehouse W011 detects that the inventory of a certain beverage has decreased from 450 cases to 380 cases, which is below the preset safety stock threshold of 400 cases. It generates an inventory threshold trigger event message with the event type field "stock_below_threshold". The central server event listening service receives this message, identifies it as a replenishment demand event, and matches it to the hierarchical replenishment rule node N1 using the event type as the query key. Based on the event source identifier "W011", it retrieves the autonomous decision-making unit ADU_W011, identifies it as the first autonomous decision-making unit, and sends a start command to it.

[0044] In step S13, the replenishment demand is instantly perceived and matched according to rules through an event-driven mechanism. This transforms the traditional decision-making initiation mode of "timed batch - global solution" into a real-time triggering mode of "instant perception - local response", providing millisecond-level response initiation capability for the collaborative self-disciplined replenishment decision architecture of claim 1.

[0045] S14: Through the real-time responsive decision-making process, the first autonomous decision-making unit sends a consensus request to at least one second autonomous decision-making unit related to the replenishment demand event according to the collaborative rules.

[0046] Consensus Request: This refers to a standardized negotiation message sent by the first autonomous decision-making unit to other autonomous decision-making units during a real-time responsive decision-making process to solicit replenishment capabilities. A consensus request must include at least: the initiating unit identifier (i.e., the unit identifier of the first autonomous decision-making unit), the request type identifier, the replenishment demand product identifier, the replenishment demand quantity, the request timestamp, and the expected response time window.

[0047] The specific implementation of this step is as follows: First, the first autonomous decision-making unit retrieves the topology graph from local storage. The topology graph records the supply and demand hierarchy and spatial distance relationships between itself and other autonomous decision-making units in the supply chain network.

[0048] Secondly, based on the type of replenishment demand event, the scope of the decision-making unit to be queried is determined, including at least one of upstream supply nodes, downstream demand nodes, and peer-level collaborative nodes. The specific determination rules are defined by the collaborative rules matched in the collaborative rule graph structure: if a hierarchical replenishment rule is matched, the query scope is upstream supply nodes (e.g., central warehouse to regional warehouse); if a spatial allocation rule is matched, the query scope is peer-level collaborative nodes (e.g., adjacent forward warehouses); if a resource constraint rule is matched, the query scope is associated resource nodes (e.g., vehicle dispatch units). The determination of the decision-making unit scope can be achieved by parsing the "target node type" field in the output action set of the collaborative rule node.

[0049] Third, based on the topology graph, autonomous decision-making units that meet preset response conditions are selected as second autonomous decision-making units within the decision-making unit scope. These preset response conditions include, but are not limited to: the autonomous decision-making unit is online (e.g., the unit's heartbeat is normal), its current inventory is greater than zero (i.e., there is available inventory), and there is a usable logistics path between it and the first autonomous decision-making unit (i.e., there is a connected path in the topology graph and the path is available). The selection process can be achieved by traversing the adjacent nodes that meet the conditions in the topology graph, such as using a graph traversal algorithm (e.g., breadth-first search) to find nodes that meet the conditions within a limited depth.

[0050] Fourth, generate a consensus request message containing the unit identifier of the first autonomous decision-making unit, the type of replenishment demand event, the product identifier of the replenishment demand, and the quantity of the replenishment demand, and send the consensus request message to each of the selected second autonomous decision-making units.

[0051] In step S14, the consensus request mechanism enables collaborative negotiation among distributed nodes, transforming the traditional "central coordination-one-way command" collaborative mode into a "node negotiation-two-way interaction" collaborative mode, thus providing a communication foundation for collaborative interaction among nodes for the collaborative self-regulatory replenishment decision-making architecture of claim 1.

[0052] S15: Receive the response proposal returned by the second autonomous decision-making unit, which is independently generated by the second autonomous decision-making unit based on its own state and the collaboration rules.

[0053] Response Proposal: This refers to the response data independently generated by the second autonomous decision-making unit in response to the consensus request sent by the first autonomous decision-making unit, based on its own inventory status, current load capacity, and coordination rules. The response proposal must include at least: the responder unit identifier, the requester unit identifier, the replenishable quantity, the replenishable time window, replenishment cost information, and the response timestamp.

[0054] The specific implementation of this step is as follows: First, the second autonomous decision-making unit receives the consensus request and parses out the product identifier and replenishment quantity required from it.

[0055] Secondly, query the local inventory database to obtain the current inventory, in-transit inventory, and safety stock threshold corresponding to the product identifier required for replenishment.

[0056] Third, based on the target collaboration rules matched in the collaboration rule graph structure, determine the adjustable inventory limit. The adjustable inventory limit refers to the maximum replenishment quantity that the second autonomous decision-making unit can provide to other nodes under the premise of meeting its own safety stock and normal sales needs.

[0057] Fourth, based on the current inventory level, in-transit inventory level, safety stock threshold, and adjustable inventory limit, calculate the maximum committable replenishment quantity. The maximum committable replenishment quantity is the smaller value between the adjustable inventory limit and the demand quantity in the consensus request: I_commit = min(I_available, I_demand). If I_available is 0 or negative, the maximum committable replenishment quantity is 0, indicating that the replenishment demand cannot be met.

[0058] Fifth, obtain the current load status, including the length of the pending task queue and the available processing capacity for the current time period.

[0059] Sixth, based on the maximum committable replenishment quantity, the current load status, and the replenishment cost rules defined in the collaborative rule graph structure, generate a response proposal containing information such as the replenishable quantity and the replenishment time window.

[0060] In step S15, the autonomous and independent decision-making capability of the second autonomous decision-making unit transforms the traditional "central command-passive execution" response mode into an intelligent response mode of "autonomous assessment-proactive proposal," providing the autonomous decision-making capability foundation for each node in the collaborative self-discipline replenishment decision-making architecture of claim 1.

[0061] S16: The first autonomous decision-making unit aggregates the response proposals into replenishment decision instructions according to the priority weight table stored locally, and sends the replenishment decision instructions to the execution system.

[0062] Priority Weight Table: This refers to the decision parameter configuration table stored locally in the first autonomous decision-making unit, used for comprehensively scoring multiple response proposals. The Priority Weight Table contains at least one decision dimension and its corresponding weight coefficient. Decision dimensions include time priority, cost priority, and supplier reliability. Each dimension corresponds to a weight coefficient, which characterizes the importance of that dimension in the aggregated decision. The weight coefficient is a value between 0 and 1, and the sum of the weight coefficients for all dimensions is 1.

[0063] The specific implementation of this step is as follows: First, the first autonomous decision-making unit receives response proposals from N second autonomous decision-making units and stores them in a local queue to be aggregated.

[0064] Next, iterate through each response proposal in the local aggregation queue and extract the replenishable quantity, replenishable time window, and replenishment cost information. For each response proposal R_i, extract its committed quantity Q_i, earliest available shipping time T_earliest_i, latest available delivery time T_latest_i, and replenishment cost C_i.

[0065] Third, based on the M decision dimensions and their corresponding weight coefficients recorded in the priority weight table, a decision score is calculated for each response proposal. Decision dimensions include at least one of the following: time priority, cost priority, and supplier reliability. Specifically, the time priority score can be calculated based on the relationship between the replenishment window of the response proposal and the urgency of the demand, such as score S_time_i = f(T_earliest_i, T_latest_i, T_required); the cost priority score can be calculated based on the relationship between replenishment cost and the budget ceiling, such as score S_cost_i = 1 - C_i / C_max; and the supplier reliability score can be calculated based on the historical response adoption rate of the second autonomous decision-making unit, such as score S_reliability_i = N_adopted_i / N_total_i. The comprehensive decision score calculation formula is: Score_i = Σ(w_j × S_j_i), where w_j is the weight coefficient of the j-th dimension, and S_j_i is the normalized score of the i-th response proposal in the j-th dimension.

[0066] Fourth, the response proposals are ranked in descending order of decision scores.

[0067] Fifth, the replenishable quantities of the sorted response proposals are accumulated sequentially until the total accumulated quantity meets the total demand corresponding to the replenishment demand event. The response proposals used in the accumulation process are then identified as the target proposals for this replenishment decision.

[0068] Sixth, the replenishable quantity, replenishable time window, and replenishment cost information carried in the target proposals are merged to generate a replenishment decision instruction. This merging process may include: summarizing the total replenishable quantity by product identifier; taking the earliest replenishable time window among all target proposals as the lower limit of the planned execution time window; taking the latest replenishable time window among all target proposals as the upper limit of the planned execution time window; and summing the replenishment costs of all target proposals as a reference for the total replenishment cost. The generated replenishment decision instruction includes the target execution system type (determined based on the type of replenishment source and target node), replenishable product identifier, the summarized total replenishable quantity, identifiers of each replenishment source node, identifier of the replenishment target node, planned execution time window, and instruction generation timestamp.

[0069] Seventh, the replenishment decision instruction is sent to the execution system. Before sending, the first autonomous decision-making unit identifies the target execution system type corresponding to the replenishment decision instruction, including at least one of the following: Enterprise Resource Planning (ERP) system, Warehouse Management System, Transportation Management System, and Salesperson Terminal System. Based on the target execution system type, the replenishment decision instruction is converted into a standard instruction message conforming to the target execution system's interface specification. After conversion, the standard instruction message is sent to the target execution system through a preset message queue, and an instruction reception confirmation message is received from the target execution system.

[0070] In step S16, through multi-dimensional weighted scoring and a merit-based accumulation mechanism, the traditional "single source - simple judgment" decision-making mode is transformed into an intelligent decision-making mode of "multi-source fusion - comprehensive merit-based selection", providing the final decision aggregation capability for the collaborative self-discipline replenishment decision-making architecture of claim 1.

[0071] In this embodiment, through sequential processing of S11-S16, and through a series of interconnected technical means such as node decoupling instantiation, collaborative rule graph construction, event-driven triggering, consensus request negotiation, response proposal generation, and intelligent aggregation decision-making, the supply chain replenishment data processing method for multi-level inventory as described in claim 1 is fully realized, providing a complete distributed collaborative replenishment decision-making technology implementation scheme for multi-level inventory management systems in the field of fast-moving consumer goods distribution.

[0072] Example 2: Determination of the first autonomous decision-making unit and task creation mechanism.

[0073] In this embodiment, the first autonomous decision-making unit related to the replenishment demand event initiates a real-time responsive decision-making process, including: Analyze the replenishment demand event and extract the inventory node identifier and event trigger timestamp corresponding to the replenishment demand event; Based on the inventory node identifier, query and determine the autonomous decision-making unit corresponding to the inventory node identifier from all instantiated autonomous decision-making units as the first autonomous decision-making unit; Based on the event trigger timestamp, a real-time responsive decision task is created in the local event queue of the first autonomous decision-making unit, and the status of the real-time responsive decision task is marked as pending, so as to start the real-time responsive decision process of the first autonomous decision-making unit.

[0074] Real-time responsive decision-making tasks refer to executable task units created by the first autonomous decision-making unit in its local event queue based on replenishment demand events. A real-time responsive decision-making task includes at least: a task identifier, an associated replenishment demand event identifier, a task creation timestamp, a task status (e.g., pending, executing, completed, canceled), and contextual data required for task execution (including the matched collaboration rule identifier, replenishment demand product identifier, replenishment demand quantity, etc.). Real-time responsive decision-making tasks are the instantiation carriers of the real-time responsive decision-making process. After a task is created and marked as pending, it is scheduled and executed by the task scheduler of the first autonomous decision-making unit according to a local scheduling strategy (e.g., priority queue scheduling, first-in-first-out scheduling).

[0075] The specific implementation of this embodiment is as follows: First, upon receiving the instruction to initiate the real-time responsive decision-making process, the first autonomous decision-making unit performs parsing and processing of the replenishment demand event. It obtains the original message of the replenishment demand event from the initiation instruction, and deserializes it according to a preset event message format (such as JSON or Protocol Buffers) using a message parser. This extracts the inventory node identifier field (e.g., "source_id": "W011") and the event trigger timestamp field (e.g., "timestamp": "2024-10-23T10:23:15.123Z"). The parsing process can be implemented using well-known JSON parsing libraries or Protocol Buffers decoding libraries, which will not be elaborated upon here.

[0076] Secondly, the first autonomous decision-making unit, based on the extracted inventory node identifier, queries and identifies the autonomous decision-making unit corresponding to the inventory node identifier from all instantiated autonomous decision-making units. Specifically, the first autonomous decision-making unit performs a search operation in its locally maintained autonomous decision-making unit registry. The registry uses the unit identifier as the key and the autonomous decision-making unit's network address or server endpoint as the value, stored in a hash table structure. The first autonomous decision-making unit uses the inventory node identifier as the query key to retrieve a matching autonomous decision-making unit instance from the registry. Since the source node of the replenishment demand event is the node that triggers the decision, this query operation will return to the first autonomous decision-making unit currently performing the parsing. After completing the query, the first autonomous decision-making unit confirms that it is the executor that initiates the real-time responsive decision-making process.

[0077] Third, the first autonomous decision-making unit creates a real-time responsive decision-making task in its local event queue based on the event trigger timestamp. Specifically, the first autonomous decision-making unit generates a unique task identifier (e.g., "task_20241023_102315_001"), sets the task creation timestamp to the current system time (synchronized with the unified system timeline), and initializes the task status to "pending". The context data required for task execution is extracted from the replenishment demand event and the matched collaboration rules, including but not limited to: the replenishment demand product identifier (e.g., "cola_500ml"), the replenishment demand quantity (e.g., "50 boxes"), and the matched collaboration rule identifier (e.g., "rule_hierarchy_001"). The first autonomous decision-making unit enqueues the encapsulated real-time responsive decision-making task object into the local event queue.

[0078] Fourth, the first autonomous decision-making unit marks the created real-time responsive decision-making task as pending to initiate its real-time responsive decision-making process. After the status marking operation is completed, the task scheduler of the first autonomous decision-making unit detects a pending task in its local event queue and selects the task for execution according to a preset scheduling strategy (such as priority scheduling, with urgent tasks given priority). When the task is executed, the first autonomous decision-making unit enters the execution phase of consensus request sending, response proposal reception, and decision aggregation, that is, it begins executing the processing logic of the real-time responsive decision-making process.

[0079] This embodiment, as an independent and optional optimization solution, utilizes core technologies such as replenishment demand event parsing and field extraction, inventory node identifier querying and first autonomous decision-making unit determination, event trigger timestamp acquisition and real-time responsive decision-making task creation, task status marking and scheduling initiation. This enables precise positioning of the decision-making entity and an asynchronous task scheduling mechanism, shifting the decision-making authority from the central node to the event source node. Building upon the distributed collaborative decision-making architecture implemented in the above embodiment, it further independently achieves source-based execution and asynchronous scheduling of decision-making tasks. This further resolves the single-point bottleneck and serial latency issues caused by the central node processing all requests in traditional centralized systems, significantly improving the response speed and concurrent processing capabilities of the supply chain replenishment decision-making system.

[0080] Example 3: Predictive response decision-making mechanism.

[0081] In this embodiment, please refer to Figure 2 , Figure 2 This is a schematic diagram of the first sub-process of the supply chain replenishment data processing method for multi-level inventory provided in an embodiment of the present invention. Figure 2 As shown, in this embodiment, the first autonomous decision-making unit related to the replenishment demand event initiates a real-time responsive decision-making process, and the process further includes initiating a predictive responsive decision-making process in parallel with the real-time responsive decision-making process by the first autonomous decision-making unit: S21: Obtain the historical replenishment demand time series data of the inventory nodes managed by the first autonomous decision-making unit. The historical replenishment demand time series data includes the actual replenishment outbound quantity for each time unit within the past preset period. S22: Based on the historical replenishment demand time series data, a time series prediction model is used to calculate the predicted replenishment demand quantity within a future preset time period; S23: When the predicted replenishment demand quantity exceeds the difference between the safety stock threshold of the inventory node and the current inventory quantity, a predictive replenishment demand event is generated. The predictive replenishment demand event includes the product identifier of the predicted replenishment demand, the predicted replenishment demand quantity, and the predicted replenishment demand time window. S24: Based on the start timestamp in the predicted replenishment demand time window, create a predictive response decision task in the local event queue of the first autonomous decision unit, and set the priority of the predictive response decision task to be lower than the preset priority value of the real-time response decision task. S25: When the predicted replenishment demand time window arrives, the status of the predictive response decision task is switched from pending to executable to initiate the predictive response decision process corresponding to the predictive response decision task.

[0082] Historical replenishment demand time-series data refers to the sequence of actual replenishment and outbound quantities recorded chronologically within the past preset period for the inventory nodes managed by the first autonomous decision-making unit. This data is sampled at fixed time intervals (e.g., hourly, daily, or weekly) to form an evenly spaced time series, used to capture the periodic patterns and trends in replenishment demand. The storage period for this data can be configured according to product characteristics and business needs; for example, fast-moving consumer goods typically retain daily data for the most recent 90 days.

[0083] Time series forecasting models are computational models used to predict future replenishment demand based on historical replenishment demand time-series data. Time series forecasting models can be implemented using well-known techniques in the field, such as Autoregressive Moving Average (ARIMA), exponential smoothing models (e.g., Holt-Winters), or Long Short-Term Memory (LSTM) networks. Model parameters (such as the order p, d, q of ARIMA, or the smoothing coefficients α, β, γ of exponential smoothing) are estimated and configured based on the statistical characteristics of historical data (such as trends and seasonality) to ensure that the forecast results reflect the cyclical changes in demand.

[0084] Predictive-responsive decision-making tasks refer to executable task units created by the first autonomous decision-making unit in its local event queue based on predictive replenishment demand events, used to execute replenishment decisions when the predicted demand time window arrives. A predictive-responsive decision-making task includes at least: a task identifier, an associated predictive replenishment demand event identifier, a task creation timestamp, a task execution time window, a task priority (set to be lower than real-time responsive decision-making tasks), and contextual data required for task execution (including predicted product identifier, predicted demand quantity, and predicted time window). Predictive-responsive decision-making tasks are in a "pending" state upon creation. When the system time reaches the start timestamp of the predicted demand time window, the task status switches to "executable," and it is scheduled for execution by the task scheduler.

[0085] Predictive-responsive decision-making process: This refers to a replenishment decision-making process triggered by predictive-responsive decision-making tasks and starting with predictive replenishment demand events. The execution logic of the predictive-responsive decision-making process is the same as that of the real-time responsive decision-making process, including sending consensus requests to the second autonomous decision-making unit, receiving response proposals, and aggregating and generating replenishment decision instructions. The predictive-responsive decision-making process and the real-time responsive decision-making process run in parallel, sharing the same consensus negotiation mechanism and decision aggregation mechanism. The only differences lie in the triggering source (predictive events vs. real-time events) and the difference in task priority.

[0086] The specific implementation of this embodiment is as follows: First, during the initialization phase or periodic maintenance task, the first autonomous decision-making unit obtains the historical replenishment demand time-series data of its managed inventory nodes, including the actual replenishment and outbound quantity for each time unit (e.g., daily) within the past preset period (e.g., the past 90 days).

[0087] Secondly, based on historical replenishment demand time-series data, a time series forecasting model is used to calculate the predicted replenishment demand quantity within a preset future time period. This embodiment uses the Holt-Winters exponential smoothing model as an example, which is suitable for time series forecasting with trends and seasonality. The model expression is: The level term L_t = α×(d_t / S_{tL}) + (1-α)×(L_{t-1}+T_{t-1}); Trend term T_t = β×(L_t-L_{t-1}) + (1-β)×T_{t-1}; Seasonal term S_t = γ×(d_t / L_t) + (1-γ)×S_{tL}; The predicted value is F_{t+m} = (L_t + m×T_t)×S_{t+mL}; Where α, β, and γ are smoothing coefficients (ranging from 0 to 1), L is the length of the seasonal cycle (e.g., 7 days corresponds to a weekly cycle), and m is the prediction step size. The smoothing coefficients can be estimated by minimizing historical prediction errors (e.g., root mean square error), with typical values ​​of α=0.3, β=0.2, and γ=0.4.

[0088] The first autonomous decision-making unit inputs the data from the most recent complete cycle into the model to calculate the predicted replenishment demand quantity F_pred for a future preset time period (such as the next 24 hours or the next 7 days).

[0089] Third, determine whether the predicted replenishment demand exceeds the difference between the safety stock threshold and the current inventory level. Specifically, obtain the current inventory level I_current and the safety stock threshold I_safety, and calculate the replenishment trigger condition: if F_pred > (I_safety - I_current), it indicates that the predicted demand will cause the inventory to fall below the safety level, requiring advance replenishment preparation, and generating a predictive replenishment demand event; otherwise, no predictive replenishment demand event is generated, and the process waits for the next forecast period. When I_current ≥ I_safety, the difference may be negative or zero; in this case, the condition is not met, and predictive replenishment is not triggered.

[0090] Fourth, when the predicted replenishment demand exceeds a threshold, the first autonomous decision-making unit generates a predictive replenishment demand event. This event includes the product identifier for the predicted replenishment demand, the predicted replenishment demand quantity, and the predicted replenishment demand time window. The predicted replenishment demand time window is determined based on the time period in which the predicted demand occurs. For example, if the predicted demand for the next 24 hours is 50 boxes, the time window can be set to the start and end times of 24 hours after the current time.

[0091] Fifth, based on the start timestamp of the predicted replenishment demand time window, a predictive responsive decision-making task is created in the local event queue of the first autonomous decision-making unit, and its priority is set to a lower preset priority value than that of the real-time responsive decision-making task (e.g., real-time task priority is 10, and predictive task priority is 5). Since the priority of the predictive responsive decision-making task is lower than that of the real-time responsive decision-making task, when both real-time responsive decision-making tasks and predictive responsive decision-making tasks exist in the local event queue, the task scheduler prioritizes scheduling the real-time responsive decision-making task for execution, ensuring a rapid response to real-time replenishment demands.

[0092] Sixth, when the predicted replenishment demand time window arrives, the status of the predictive response decision task is switched from "pending" to "executable" to start the predictive response decision process corresponding to the predictive response decision task (including sending consensus requests to the second autonomous decision unit, receiving response proposals, aggregating and generating replenishment decision instructions, etc., the specific process is the same as the real-time response decision process).

[0093] It should be noted that the specific selection of the time series forecasting model mentioned above is not limited to Holt-Winters. In one example, an Autoregressive Moving Average (ARIMA) model can be used, with the model order determined through autocorrelation and partial autocorrelation function analysis, suitable for stationary time series or series that become stationary after differencing. In another example, a Long Short-Term Memory (LSTM) network can be used, capturing long-term dependencies through multi-layer LSTM units, suitable for scenarios with complex demand patterns and strong nonlinear relationships. Any technical means capable of predicting future demand based on historical data falls within the scope of protection of this invention.

[0094] This embodiment, as an independent and optional optimization solution, utilizes historical time-series data collection, time-series forecasting model calculation, forecasting condition judgment, forecasting task creation and priority setting, and time window activation to achieve a predictive response decision-making mechanism. This upgrades replenishment triggering from "post-event response" to "pre-event prediction." Building upon the real-time responsive replenishment decision-making achieved in the above embodiment, it further independently realizes forward-looking replenishment preparation capabilities, further solving the problem of replenishment lag caused by passive response in traditional technologies. This significantly improves the timeliness of supply chain replenishment decisions and the predictability of inventory management.

[0095] Example 4: Second autonomous decision-making unit screening and consensus request sending mechanism.

[0096] In this embodiment, sending a consensus request to at least one second autonomous decision-making unit related to the replenishment demand event includes: Obtain the topology diagram stored locally by the first autonomous decision-making unit. The topology diagram defines the supply and demand hierarchy and spatial distance relationship between the first autonomous decision-making unit and other autonomous decision-making units in the supply chain network. Based on the type of the replenishment demand event, determine the scope of the decision-making unit to be queried, which includes at least one of the upstream supply node, downstream demand node, and peer collaboration node; Based on the topology diagram, autonomous decision-making units that meet preset response conditions are selected as second autonomous decision-making units within the decision-making unit range. The preset response conditions include: the autonomous decision-making unit is online, the current inventory is greater than zero, and there is an available logistics path between the autonomous decision-making unit and the first autonomous decision-making unit. Generate a consensus request message containing the unit identifier of the first autonomous decision-making unit, the type of the replenishment demand event, the replenishment demand product identifier, and the replenishment demand quantity; The consensus request message is sent to each of the selected second autonomous decision-making units.

[0097] The specific implementation of this embodiment is as follows: First, the first autonomous decision-making unit obtains the topology graph from its local storage. The topology graph adopts a directed graph or undirected graph model, where nodes represent autonomous decision-making units and edges represent the relationships between nodes. At least two types of relationships are defined: supply and demand hierarchical relationships (such as directed edges of "upstream supply-downstream demand") and spatial distance relationships (numerical attributes of Euclidean distance or logistics path distance calculated based on geographical coordinates).

[0098] Secondly, based on the type of replenishment demand event, the scope of decision-making units to be queried is determined. The scope of decision-making units refers to the candidate set of second-level decision-making units that the first autonomous decision-making unit determines to be queried based on the type of replenishment demand event. The scope of decision-making units includes upstream supply nodes (i.e., upstream nodes that can provide replenishment to the first autonomous decision-making unit, such as a central warehouse to a regional warehouse), downstream demand nodes (i.e., downstream nodes that require replenishment from the first autonomous decision-making unit, such as a regional warehouse to a forward warehouse), and peer-level collaborative nodes (i.e., nodes at the same level as the first autonomous decision-making unit that can perform inventory transfers, such as between adjacent forward warehouses). The determination of the scope of decision-making units is determined by the "target node type" field in the output action set of the matched collaborative rule nodes.

[0099] Specifically, an event type field is extracted from replenishment demand events, and this event type is mapped to the "target node type" field in the output action set of the matched collaborative rule nodes in the collaborative rule graph structure. If a hierarchical replenishment rule is matched, the decision unit scope is determined to be the upstream supply node; if a spatial allocation rule is matched, the decision unit scope is determined to be the peer collaborative node; if a resource constraint rule is matched, the decision unit scope is determined to be the associated resource node (such as the vehicle dispatching unit). If a rule node defines multiple target node types, the decision unit scope is the union of these types.

[0100] Third, based on the topology graph, autonomous decision-making units that meet preset response conditions are selected as second autonomous decision-making units within the defined decision-making unit scope. The selection process includes: extracting a list of candidate nodes within the decision-making unit scope from the topology graph; for each node in the candidate node list, checking whether its status is online (through heartbeat detection), whether its current inventory is greater than zero (querying local cached inventory information), and whether there is an available logistics path (querying whether there is a connected path between nodes in the topology graph and whether the path status is available); and determining the candidate nodes that simultaneously meet the above three conditions as the second autonomous decision-making units.

[0101] Fourth, generate a consensus request message containing the unit identifier of the first autonomous decision-making unit, the type of replenishment demand event, the identifier of the replenishment demand product, and the quantity of replenishment demand.

[0102] Fifth, the consensus request message is sent to each of the selected second autonomous decision-making units, and an independent timeout timer is started for each sent consensus request.

[0103] It should be noted that the selection method for the second autonomous decision-making unit is not limited to the examples provided. In one example, a multi-level selection strategy can be adopted, first selecting all candidate nodes based on the topology graph, and then performing a secondary selection based on the current load status of the nodes, prioritizing nodes with lower loads as the second autonomous decision-making units, which is suitable for high-concurrency request scenarios. In another example, a weighted selection based on historical response quality can be adopted, recording the adoption rate of each node's historical response proposals, and prioritizing nodes with high adoption rates, which is suitable for scenarios that require optimization of decision quality.

[0104] This embodiment, as an independent and optional optimization solution, utilizes core technologies such as topology graph acquisition, decision unit range determination, multi-dimensional condition filtering, consensus request message generation and transmission to achieve a precise targeted negotiation target selection mechanism, realizing a shift from "global broadcast" to "local targeting" communication mode. Therefore, based on the distributed negotiation achieved in the above embodiment, it further independently realizes precise targeted transmission of consensus requests, further solving the problem of ineffective overhead caused by flooding communication in traditional technologies, and significantly improving the communication efficiency and system resource utilization of distributed negotiation.

[0105] Example 5: Independent generation mechanism for response proposals.

[0106] Please see Figure 3 , Figure 3 This is a schematic diagram of the second sub-process of the supply chain replenishment data processing method for multi-level inventory provided in an embodiment of the present invention. Figure 3 As shown, in this embodiment, the response proposal is independently generated by the second autonomous decision-making unit based on its own state and the collaborative rules, including: S31: The second autonomous decision-making unit receives the consensus request and parses the replenishment demand product identifier and replenishment demand quantity from the consensus request; S32: Query the local inventory database of the second autonomous decision-making unit to obtain the current inventory, in-transit inventory, and safety stock threshold corresponding to the replenishment demand product identifier; S33: Determine the adjustable inventory limit of the second autonomous decision-making unit based on the target collaborative rule matched in the collaborative rule graph structure that corresponds to the consensus request; S34: Based on the current inventory, the in-transit inventory, the safety stock threshold, and the adjustable inventory limit, calculate the maximum restocking quantity that the second autonomous decision-making unit can commit to for the product identifier of the replenishment demand; S35: Obtain the current load status of the second autonomous decision-making unit, the current load status including the length of the task queue to be processed and the available processing capacity for the current time period; S36: Generate the response proposal based on the maximum committable replenishment quantity, the current load status, and the replenishment cost rules defined in the collaborative rule graph structure. The response proposal includes replenishable quantity, replenishable time window, and replenishment cost information.

[0107] The specific implementation of this embodiment is as follows: First, the second autonomous decision-making unit receives the consensus request sent by the first autonomous decision-making unit and parses the replenishment demand product identifier and replenishment demand quantity from the consensus request message.

[0108] Secondly, query its local inventory database to obtain the current inventory quantity I_current, the in-transit inventory quantity I_intransit, and the safety stock threshold I_safety corresponding to the product identifier of the replenishment request.

[0109] Third, based on the target collaborative rule matched in the collaborative rule graph structure and corresponding to the consensus request, the adjustable inventory limit is determined. The adjustable inventory limit refers to the maximum replenishment quantity that the second autonomous decision-making unit can provide to other nodes under the premise of meeting its own safety stock and normal sales needs. It is calculated as follows: I_available = max(0, I_current + I_intransit - I_safety - I_reserved), where I_reserved is the reserved inventory quantity that has been committed but not yet delivered.

[0110] Fourth, based on the current inventory level, in-transit inventory level, safety stock threshold, and adjustable inventory limit, calculate the maximum committable replenishment quantity for the product identifier requiring replenishment. The maximum committable replenishment quantity is the smaller value between the adjustable inventory limit and the demand quantity in the consensus request: I_commit = min(I_available, I_demand). If I_available is 0 or negative, the maximum committable replenishment quantity is 0, indicating that the replenishment demand cannot be met; if I_available is greater than or equal to I_demand, the maximum committable replenishment quantity is I_demand, indicating that it can be fully met; otherwise, the maximum committable replenishment quantity is I_available, indicating that it can only be partially met.

[0111] Fifth, obtain the current load status, including the length of the pending task queue L_queue and the available processing capacity (such as CPU utilization CPU_usage) for the current time period. Quantify the load status as a load factor F_load = L_queue × w_q + CPU_usage × w_c, where w_q and w_c are preset weighting coefficients (such as w_q=0.6, w_c=0.4), used to comprehensively evaluate the current load.

[0112] Sixth, based on the maximum committable replenishment quantity, the current load status, and the replenishment cost rules defined in the collaborative rule graph structure, a response proposal is generated. The replenishment cost rules refer to predefined rule expressions in the collaborative rule graph structure used to calculate replenishment costs. Each replenishment cost rule must include at least the following cost factors: transportation costs (calculated by distance or number of boxes), warehousing costs (calculated by storage time or number of boxes), and expedited costs (dynamically adjusted according to the urgency of demand). The replenishment cost rules are stored as structured expressions (e.g., "C_total = Q × (C_transport_per_unit + C_storage_per_unit) + C_urgent") in the attributes of the collaborative rule nodes, and are invoked by the second autonomous decision-making unit when generating the response proposal.

[0113] For example, the generated response proposal is as follows: 1) Determine the replenishable quantity: Take the maximum committable replenishable quantity I_commit as the value of the replenishable quantity field in the response proposal.

[0114] 2) Determine the replenishment window: Calculated based on the current load status and the transportation time of the logistics route. If the load factor F_load is below the threshold (e.g., 0.7), the processing capacity is strong, and the time window can be set to the current time plus the shortest processing time to the current time plus the longest processing time. If the load factor F_load is above the threshold (e.g., 0.9), the processing capacity is strained, and the time window is correspondingly delayed. The time window calculation formula is: t_earliest = t_now + t_process × (1 + F_load), t_latest = t_earliest + t_transport, where t_process is the baseline processing time and t_transport is the transportation time.

[0115] 3) Determine replenishment cost: Calculate based on the replenishment cost rules defined in the collaborative rule graph structure. In this embodiment, the cost rule expression is C_total = I_commit × (C_transport_per_unit + C_storage_per_unit) + C_urgent, where C_transport_per_unit is the transportation cost per box (e.g., 0.5 yuan), C_storage_per_unit is the storage cost per box (e.g., 0.1 yuan), and C_urgent is the expedited fee (increased if the demand is urgent, otherwise 0).

[0116] 4) Generate response proposal message: Encapsulate the above calculation results into a response proposal, which includes the responder unit identifier (the unit identifier of the second autonomous decision-making unit), the requester unit identifier (the unit identifier of the first autonomous decision-making unit), the replenishable quantity I_commit, the replenishable time window [t_earliest, t_latest], the replenishment cost C_total, and the response timestamp (synchronized with the unified system timeline).

[0117] It should be noted that the calculation method for the maximum committable replenishment quantity is not limited to the examples given above. In one example, a tiered commitment strategy can be adopted, setting different commitment ratios based on the urgency of demand. Urgent demand can have a higher commitment ratio (e.g., 80%), while regular demand can have a lower commitment ratio (e.g., 50%), which is suitable for scenarios with clear demand priorities. In another example, a dynamic commitment strategy can be adopted, dynamically adjusting the calculation coefficient of the adjustable inventory limit based on historical demand volatility, which is suitable for scenarios with large demand fluctuations.

[0118] The calculation method for replenishment costs described above is not limited to a fixed unit price. In one example, a dynamic pricing factor can be introduced to adjust the cost coefficient based on the current inventory level. Costs are lower when inventory is ample and higher when inventory is tight, making this suitable for scenarios where supply and demand balance is adjusted through cost control. In another example, a time cost factor can be introduced to dynamically adjust rush fees based on the urgency of demand. Rush fees are higher for urgent demands, making this suitable for scenarios where urgent orders are prioritized. Other calculation methods follow the same logic and will not be elaborated further here.

[0119] This embodiment, as an independent and optional optimization solution, utilizes core technologies such as consensus request parsing, local inventory query, determination of adjustable inventory upper limit, calculation of maximum committable quantity, load status acquisition, and response proposal generation to achieve an autonomous and accurate response proposal generation mechanism. This enables the second autonomous decision-making unit to comprehensively consider its own inventory, load, and cost. Thus, based on the distributed negotiation achieved in the above embodiment, it further independently realizes the multi-dimensional information carrying of response proposals, significantly improving the information richness and decision quality of aggregated decision-making.

[0120] Example 6: Mechanism for Response Proposal Aggregation and Replenishment Decision Instruction Generation.

[0121] In this embodiment, the first autonomous decision-making unit aggregates the response proposals into replenishment decision instructions based on a locally stored priority weight table, including: The first autonomous decision-making unit receives response proposals from N second autonomous decision-making units and stores the response proposals in a local queue to be aggregated, where N≥2 and is a natural number; Iterate through each response proposal in the local queue to be aggregated, and extract the replenishable quantity, replenishable time window and replenishment cost information from each response proposal; Based on the M decision dimensions and their corresponding weight coefficients recorded in the priority weight table, calculate the decision score for each response proposal. The decision dimensions include at least one of time priority dimension, cost priority dimension, and supplier reliability dimension, where M is a natural number. The response proposals are sorted in descending order of the decision scores; The replenishable quantities of the sorted response proposals are added up sequentially until the total quantity meets the total demand corresponding to the replenishment demand event. The response proposals used in the accumulation process are then identified as the target proposals for this replenishment decision. The replenishable quantity, replenishable time window, and replenishment cost information carried in the target proposal are combined and processed to generate a replenishment decision instruction.

[0122] The priority weight table, stored locally in the first autonomous decision-making unit, is a configuration table of decision parameters used to comprehensively evaluate multiple response proposals. It contains at least one decision dimension and its corresponding weight coefficient. Decision dimensions include, but are not limited to, time priority (corresponding to the replenishment time window in the response proposal), cost priority (corresponding to replenishment cost information in the response proposal), and supplier reliability (corresponding to the historical response adoption rate of the second autonomous decision-making unit). Each dimension corresponds to a weight coefficient, representing its importance in the aggregated decision. The weight coefficient is a value between 0 and 1, and the sum of the weight coefficients for all dimensions is 1. The priority weight table supports dynamic updates and can adaptively adjust the weight coefficients based on historical decision results and feedback data.

[0123] The specific implementation of this embodiment is as follows: First, within a timeout window after sending a consensus request, the first autonomous decision-making unit receives response proposals from N second autonomous decision-making units and stores the received proposals in a local aggregation queue. The first autonomous decision-making unit sets a timeout timer for each consensus request and continuously listens for response proposals before the timeout. Upon receiving a response proposal, the first autonomous decision-making unit performs a validity check (e.g., verifying the match between the responder's identifier and the requester's identifier, and whether the response timestamp is within the expected window). If the check passes, the proposal object is enqueued in the local aggregation queue. The local aggregation queue can be stored using a list or array structure, supporting subsequent traversal operations. Here, N≥2, and is a natural number, indicating that this aggregation decision is more suitable when multiple candidate proposals exist.

[0124] Secondly, iterate through each response proposal in the local queue to be aggregated, and extract the replenishable quantity Q_i, replenishable time window T_i (including t_earliest_i and t_latest_i), and replenishment cost C_i from each response proposal.

[0125] Third, based on the M decision dimensions and their corresponding weight coefficients recorded in the priority weight table, a decision score is calculated for each response proposal. In this embodiment, the decision dimensions include time priority, cost priority, and supplier reliability. The specific calculation steps are as follows: 1) Obtain the priority weight table: The first autonomous decision-making unit reads the priority weight table from local storage and obtains the weight coefficients for each dimension. For example, the weight of the time priority dimension w_time=0.3, the weight of the cost priority dimension w_cost=0.4, the weight of the supplier reliability dimension w_reliability=0.3, and the sum of all weights is 1.

[0126] 2) Calculate the normalized scores for each dimension: Time priority score S_time_i: Calculated based on the relationship between the replenishment time window of the response proposal and the urgency of the demand. If the urgency of the demand requires the earliest delivery time T_required, then S_time_i = 1 - (t_earliest_i - T_required) / (T_latest - T_required), with a value range of [0,1]. The earlier the delivery, the higher the score.

[0127] Cost priority score S_cost_i: Calculated based on the relationship between replenishment cost and budget ceiling. S_cost_i = 1 - C_i / C_max, where C_max is the preset cost ceiling, and the lower the cost, the higher the score.

[0128] Supplier reliability score S_reliability_i: Calculated based on the historical response adoption rate of this second autonomous decision-making unit. S_reliability_i = N_adopted_i / N_total_i, where N_adopted_i is the number of historical adoptions and N_total_i is the total number of historical responses. The higher the adoption rate, the higher the score.

[0129] 3) Calculate the overall decision score: Score_i = w_time × S_time_i + w_cost × S_cost_i + w_reliability × S_reliability_i. The overall score Score_i is the decision score for this response proposal, which is used for subsequent ranking.

[0130] Fourth, the first autonomous decision-making unit sorts the response proposals in descending order of the decision scores. The sorting can be implemented using well-known algorithms in the art such as quicksort or heapsort, and the proposal with the highest score is placed at the head of the sequence. After the sorting is completed, the response proposals are arranged in descending order of Score_i to form an ordered list R_sorted.

[0131] Fifth, sequentially accumulate the replenishable quantities of the sorted response proposals until the accumulated total meets the total demand corresponding to the replenishment demand event, and determine the response proposals used in the accumulation process as the target proposals for this replenishment decision. Exemplarily, the accumulation process is as follows: Let the total demand be D_total, traverse the ordered list R_sorted in descending order of scores, and maintain the initial accumulated quantity S_acc as 0. For each response proposal R_i: If S_acc + Q_i ≤ D_total, then fully adopt the committed quantity of this response proposal, mark this response proposal as a target proposal, and S_acc = S_acc + Q_i.

[0132] If S_acc + Q_i > D_total, then only adopt a partial quantity to meet the demand. The adopted quantity is D_total - S_acc. Mark this response proposal as a target proposal and record the partially adopted quantity, and S_acc = D_total, ending the accumulation.

[0133] When S_acc reaches D_total or after traversing all the proposals, the accumulation process ends. If S_acc < D_total after traversing all the proposals, it means that the total replenishable quantities of all response proposals are not sufficient to meet the demand. At this time, all the proposals are marked as target proposals, and partial fulfillment replenishment decision instructions are generated in the subsequent merging process.

[0134] Sixth, merge and process the replenishable quantity, replenishable time window, and replenishment cost information carried in the target proposals: summarize the total replenishment quantity by product identifier; take the earliest lower limit of the replenishable time window among all target proposals as the lower limit of the planned execution time window, and the latest upper limit as the upper limit; accumulate the replenishment costs of each target proposal as the total replenishment cost reference; generate a replenishment decision instruction.

[0135] It should be noted that the specific calculation method of the above decision score is not limited to weighted summation. In one example, the analytic hierarchy process (AHP) can be used to construct a judgment matrix, and the relative weights of each dimension are calculated after passing the consistency test, which is applicable to scenarios with many decision dimensions and complex weight relationships; in another example, a multi-objective optimization algorithm (such as Pareto optimality) can be used to screen the optimal proposal combination without presetting weights, which is applicable to scenarios where multiple decision objectives are equally important.

[0136] The specific implementation of the above accumulation strategy is not limited to the examples given. In one example, a knapsack algorithm can be used to optimize the proposal combination, selecting the subset of proposals with the highest comprehensive score while meeting the total demand. This is suitable for scenarios with a large number of response proposals and requiring global optimization. In another example, a proportional allocation strategy can be used to allocate the total demand according to the score ratio. This is suitable for scenarios that require balancing the supply of each supplier.

[0137] This embodiment, as an independent and optional optimization solution, utilizes core technologies such as multi-source response proposal reception and storage, information extraction, multi-dimensional decision scoring calculation, optimization ranking, cumulative target proposal determination, and merging instruction generation to achieve an intelligent multi-source decision fusion mechanism. This enables the intelligent conversion from multi-source proposals to the optimal replenishment plan. Building upon the distributed negotiation achieved in the above embodiment, it further independently realizes the comprehensive optimization and intelligent fusion of multi-source proposals, further solving the problem of low decision quality caused by a single proposal failing to meet needs or simple random selection in traditional technologies. This significantly improves the overall quality and resource utilization of supply chain replenishment decisions.

[0138] Example 7: Collaborative rule graph structure construction mechanism.

[0139] In this embodiment, constructing a collaborative rule graph structure includes: Define at least one collaborative rule node, each of the collaborative rule nodes corresponding to a type of collaborative interaction rule. The collaborative interaction rule is used to define the interaction behavior between different autonomous decision-making units. The collaborative interaction rule includes at least one of hierarchical replenishment rule, spatial allocation rule, time scheduling rule, and resource constraint rule. For each of the collaborative rule nodes, an input parameter set and an output action set are defined. The input parameter set includes trigger condition parameters and execution condition parameters. The trigger condition parameters include the unit identifier of the initiating party's autonomous decision-making unit, the unit identifier of the target party's autonomous decision-making unit, and the current state parameters between the two. The output action set includes the response action type and the action target object. Based on the dependency, priority, or mutual exclusion relationships between the collaborative interaction rules, directed or bidirectional edges are created to connect different collaborative rule nodes, with each edge carrying a relationship type identifier and a relationship weight value. The collaborative rule nodes and the directed or bidirectional edges are stored in a graph database to construct a collaborative rule graph structure.

[0140] The specific implementation of this embodiment is as follows: First, based on the business needs of supply chain collaborative management, the central server defines at least one collaborative rule node. Each collaborative rule node corresponds to a type of collaborative interaction rule, including at least one of the following: hierarchical replenishment rules, spatial allocation rules, time scheduling rules, and resource constraint rules. Here, a collaborative rule node refers to a data node in the collaborative rule graph structure used to encapsulate a single type of collaborative interaction rule. Each collaborative rule node corresponds to a type of collaborative interaction rule, including but not limited to hierarchical replenishment rules, spatial allocation rules, time scheduling rules, and resource constraint rules. Collaborative rule nodes are stored in the graph database with unique identifiers, and node attributes include fields such as rule name, rule type, input parameter set, output action set, and rule priority. Specifically, in this embodiment, the following four types of collaborative rule nodes are defined: 1) Hierarchical replenishment rule node N_hierarchy: Used to define the supply and demand response relationship between upstream and downstream nodes. The set of input parameters for this rule node includes: initiator unit identifier (downstream node ID), target unit identifier (upstream node ID), current inventory of downstream node, current inventory of upstream node, and safety stock threshold of downstream node; the set of output actions includes: response action type is "generate replenishment order", and the target object of the action is "upstream supply node".

[0141] 2) Spatial transfer rule node N_spatial: Used to define inventory transfer relationships between sibling nodes. The set of input parameters for this rule node includes: initiator unit identifier (low inventory node ID), target unit identifier (high inventory node ID), inventory difference between the two nodes, and transfer cost threshold; the set of output actions includes: response action type is "generate transfer order", and the action target object is "sibling collaborative node".

[0142] 3) Time scheduling rule node N_temporal: Used to define the time window and priority relationship of decision tasks. The set of input parameters for this rule node includes: task type identifier, task creation timestamp, and task urgency identifier; the set of output actions includes: response action type of "priority skipping" or "task queuing", and action target object of "local event queue scheduler".

[0143] 4) Resource constraint rule node N_resource: Used to define the allocation relationship of dynamic resources such as vehicles and personnel. The set of input parameters for this rule node includes: resource type identifier, current resource load, maximum resource capacity, and resource quantity required by the task; the set of output actions includes: response action type of "allocate resources" or "resource reservation", and action target object of "resource scheduler".

[0144] Secondly, for each collaborative rule node, define the set of input parameters and the set of output actions for that node.

[0145] The input parameter set refers to the set of input parameters defined in the collaborative rule node that are used to trigger rule execution. The input parameter set includes at least trigger condition parameters and execution condition parameters. The trigger condition parameters are used to determine whether the rule should be triggered, including the unit identifier of the initiating party's autonomous decision-making unit, the unit identifier of the target party's autonomous decision-making unit, and the current status parameters between the two (such as inventory, distance, load status, etc.). The execution condition parameters are used to determine whether the execution conditions are met after the rule is triggered, including whether the system time is within the allowed execution window and whether resources are available.

[0146] The output action set refers to the set of actions defined in the collaborative rule node that should be executed after a rule is triggered. The output action set includes at least the response action type (such as "generate replenishment order", "send allocation request", "create decision task") and the action target object (such as "upstream supply node", "peer-level collaborative node", "resource scheduler"). The output action set is stored in the rule node attributes in structured data form and is invoked by the autonomous decision-making unit after a rule match is successful.

[0147] For example, taking a hierarchical replenishment rule node as an example, the triggering condition parameters of the input parameter set include: the initiator unit identifier (e.g., "ADU_W011"), the target unit identifier (e.g., "ADU_W01"), the initiator's current inventory (e.g., "380 boxes"), the target's current inventory (e.g., "1500 boxes"), and the initiator's safety stock threshold (e.g., "400 boxes"). The execution condition parameters of the input parameter set include: whether the system time is within the business-allowed replenishment time window (e.g., "08:00-20:00"), and whether transportation resources are available. The output action set includes: the response action type is "Generate Replenishment Order", and the action target object is "Upstream Supply Node". The output action also carries action parameters, such as the order type being "Standard Replenishment" and the order priority being "Normal". Third, the central server creates directed or bidirectional edges connecting different collaborative rule nodes based on the dependencies, priorities, or mutual exclusions between the collaborative interaction rules. For example, specifically: 1) Dependency Identification: Analyze the execution dependencies between rules. For example, a resource constraint rule must be completed before a time scheduling rule can be executed to determine the task's time window. Create a directed edge N_temporal→N_resource, with the relation type identified as "depends_on" and the relation weight value set to 1.0 (indicating a strong dependency).

[0148] 2) Priority Relationship Identification: Analyze the priority order among rules. For example, hierarchical replenishment rules have higher priority than spatial allocation rules. When the same node satisfies both rules simultaneously, hierarchical replenishment is executed first. Create a directed edge N_hierarchy→N_spatial, with the relationship type identified as "higher_priority_than", and the relationship weight value set to 0.9 (indicating the degree of priority difference).

[0149] 3) Mutual Exclusion Relationship Identification: Analyze the mutual exclusion between rules. For example, the same resource cannot be invoked by two rules simultaneously, and time scheduling rules and resource constraint rules are mutually exclusive under certain conditions. Create a bidirectional edge N_temporal-N_resource, with the relationship type identified as "mutual_exclusive" and the relationship weight value set to 0.5 (indicating mutual exclusion strength).

[0150] Fourth, the directed or bidirectional edges of the collaborative rule nodes and connecting nodes are stored in a graph database to construct a collaborative rule graph structure. The graph database can be implemented using well-known technologies in the field, such as Neo4j, JanusGraph, or Amazon Neptune. The storage operations include: inserting each collaborative rule node as a node in the graph database, setting node labels (e.g., "RuleNode") and node attributes (e.g., rule_id, rule_type, input_params, output_actions); and inserting each edge as a relation in the graph database, setting the relation type (e.g., "DEPENDS_ON", "HIGHER_PRIORITY_THAN", "MUTUAL_EXCLUSIVE") and relation attributes (e.g., weight). After storage, the collaborative rule graph structure is synchronously distributed to the local cache of each autonomous decision-making unit in the supply chain network, enabling each autonomous decision-making unit to independently query and parse the collaborative rules.

[0151] It should be noted that the definition methods for collaborative rule nodes described above are not limited to the examples given. In one example, a structured definition based on JSON Schema can be used, defining the input and output parameters of the rule node as a description file conforming to the JSON Schema specification, which facilitates dynamic parsing and execution by the rule engine. In another example, an XML-based rule definition language can be used, ensuring the consistency of rule definitions through schema constraints, which is suitable for scenarios that require exchanging rule definitions with other systems.

[0152] For example, following the previous example, the central server constructs a collaborative rule graph structure for the FMCG distributor supply chain, creating four collaborative rule nodes: N_hierarchy: Hierarchical replenishment rules, input parameters (initiator ID, target ID, initiator inventory, target inventory, safety threshold), output action (generate replenishment order, target: upstream supply node).

[0153] N_spatial: Spatial transfer rules, input parameters (initiator ID, target ID, inventory difference, cost threshold), output action (generate transfer order, target: peer collaborative node).

[0154] N_temporal: Time scheduling rule, input parameters (task type, creation time, urgency), output action (priority queueing, target: event queue scheduler).

[0155] N_resource: Resource constraint rules, input parameters (resource type, current load, maximum capacity, task requirements), output action (allocate resources, target: resource scheduler).

[0156] Create inter-rule relationships: N_temporal → N_resource, type "depends_on", weight 1.0; N_hierarchy → N_spatial, type "higher_priority_than", weight 0.9; N_temporal-N_resource bidirectional edge, type "mutual_exclusive", weight 0.5.

[0157] Four nodes and three edges are stored in the Neo4j graph database. After storage, the collaborative rule graph structure is synchronously distributed to the local caches of all autonomous decision-making units, including ADU_W00, ADU_W01, and ADU_W011. When ADU_W011 needs to query the hierarchical replenishment rule, it directly locates the N_hierarchy node through the locally cached graph structure to obtain its input parameter set and output action set, without needing to access the central server.

[0158] In this embodiment, as an optional optimization solution, a rule graph structure construction mechanism is realized through core technical means such as rule node definition, input and output parameter definition, creation of relationship edges between rules, and graph database storage. This achieves a transformation of the rule execution mode from "implicit coupling" to "explicit graph structure." Thus, based on the distributed collaborative decision-making achieved in the above embodiment, a unified technical foundation for rule definition, rule association, and rule execution is further independently realized. This further solves the problem of difficulty in maintenance and expansion caused by hard-coded rule logic in traditional technologies, and significantly improves the flexibility of rule configuration and the scalability of the system.

[0159] Example 8: Mechanism for listening to and identifying replenishment demand events.

[0160] In this embodiment, the response to a detected replenishment demand event from an inventory node in the supply chain network includes: An event listening service is started on the server side. The event listening service is registered with event sources. Each event source includes a status change event of its own main decision-making unit, an inventory threshold trigger event, and an external order receipt event. The event listening service receives event messages from inventory nodes in the supply chain network. Parse the event message and extract the event type field and event content field from the event message; When the event type field is inventory below the lower limit threshold, new order, or salesperson's report of stock shortage, the event message will be identified as the replenishment request event; Based on the event content fields, determine the inventory node, replenishment demand product identifier, and replenishment demand quantity corresponding to the replenishment demand event.

[0161] The specific implementation of this embodiment is as follows: First, an event listening service is started on the server side. This service registers event sources, which are the registered sources capable of generating event messages. Each event source corresponds to a type of event generation channel, including but not limited to: status change events of their respective decision-making units (e.g., unit online, offline, load changes), inventory threshold trigger events (e.g., inventory below the lower threshold, inventory above the upper threshold), and external order receipt events (e.g., customers placing orders through a B2B marketplace). Event sources are identified through message queue topics or event channels. The event listening service can subscribe to these topics to receive corresponding types of event messages.

[0162] Secondly, the event listening service receives event messages from inventory nodes in the supply chain network. An event message is a structured data unit generated by the event source and encapsulates relevant event information. Each event message contains at least an event type field and an event content field. The event type field identifies the business type of the event, such as "stock_below_threshold" (inventory below the lower threshold), "order_new" (new order), and "salesman_shortage" (salesperson reports stockout). The event content field contains specific parameters of the event, such as the inventory node identifier, the identifier of the replenishment request product, and the quantity required for replenishment. Event messages are serialized and transmitted using structured data formats such as JSON, XML, or Protocol Buffers. The event listening service, as a consumer, can pull event messages from subscribed message queue topics or passively receive them.

[0163] Third, parse the event message to extract the event type and event content fields. The parsing process involves deserialization based on the message's serialization format: if JSON is used, a JSON parsing library (such as Jackson or Gson) is used to convert the message into a key-value pair structure; if Protocol Buffers is used, the corresponding decoder is used for deserialization. From the parsed data structure, extract the event type field (e.g., "event_type") and the event content field (e.g., "event_data"). The event type field can be a string or an enumeration type, used to identify the business meaning of the event; the event content field can be a nested structure, containing the specific parameters of the event.

[0164] Fourth, the event listening service determines whether the event message is a replenishment demand event based on the extracted event type field. When the event type field is "inventory below the lower limit threshold", "new order", or "out-of-stock report by salesperson", the event message is identified as a replenishment demand event.

[0165] Fifth, the event monitoring service determines the inventory node, replenishment request product identifier, and replenishment request quantity corresponding to the replenishment request event based on the event content fields in the event message identified as a replenishment request event. The following key parameters are parsed from the event content fields: 1) Inventory node identifier (e.g., “source_id”: “W011”): indicates the inventory node that triggered the replenishment demand event, which will be used as the basis for the determination of the first autonomous decision-making unit.

[0166] 2) Product ID for Replenishment Request (e.g., “sku_id”: “cola_500ml”): Indicates the product that needs to be replenished.

[0167] 3) Replenishment demand quantity (e.g., “demand_quantity”: 50): indicates the quantity that needs to be replenished.

[0168] After parsing, the event listening service encapsulates the replenishment request event into a standardized internal event object, passes it to the event handler, and initiates the subsequent collaborative rule matching and decision-making process.

[0169] In this embodiment, as an optional optimization solution, core technologies such as event listening service startup, event source registration, event message reception, message parsing and field extraction, event type identification, and event content parameter determination are used to realize an event-driven proactive perception mechanism, achieving a shift from "periodic polling" to "event-driven" perception mode. Building upon the distributed collaborative decision-making achieved in the above embodiment, this embodiment further independently realizes millisecond-level perception of replenishment demand events, further solving the fundamental problem of decision delays caused by data acquisition lag in traditional technologies, and significantly improving the real-time performance of supply chain replenishment decisions.

[0170] Example 9: Consensus request timeout handling and reliability weight update mechanism.

[0171] In this embodiment, after sending a consensus request to at least one second autonomous decision-making unit related to the replenishment demand event, the method further includes: A request timeout timer is set for the consensus request sent to each of the second autonomous decision-making units, and the timeout duration of the request timeout timer is dynamically adjusted according to the historical response time of the second autonomous decision-making unit; If a response proposal is received from the corresponding second autonomous decision-making unit before the request timeout timer is triggered, the request timeout timer is canceled and the received response proposal is stored in the local aggregation queue. When the request timeout timer is triggered, if no response proposal is received from the corresponding second autonomous decision-making unit, a preset timeout processing strategy is executed according to the rules defined in the collaborative rule graph structure. The preset timeout processing strategy includes resending the consensus request, sending a consensus request to the alternative second autonomous decision-making unit, or marking the second autonomous decision-making unit as temporarily unavailable. The number of response timeouts for each second autonomous decision-making unit within a preset time period is counted. When the number of timeouts exceeds a preset threshold, the reliability dimension weight coefficient of the corresponding second autonomous decision-making unit in the priority weight table is updated.

[0172] The specific implementation of this embodiment is as follows: The implementation is as follows: When the first autonomous decision-making unit sends a consensus request to each second autonomous decision-making unit, it sets an independent request timeout timer for each request. Before sending the consensus request, the first autonomous decision-making unit dynamically calculates the timeout duration based on the historical response times of the second autonomous decision-making units. Specifically, the first autonomous decision-making unit maintains a list of historical response time records for each second autonomous decision-making unit, storing the response duration (the time interval from request to response reception) of the most recent K (e.g., K=10) successful responses. The timeout duration T_timeout is calculated as: T_timeout = P95(history_response_times) × α, where P95 is the 95th percentile of the historical response times, and α is a safety factor (e.g., 1.2, reserving 20% ​​buffer time). If there is no historical record (first communication), the default timeout duration (e.g., 100ms) is used. The first autonomous decision-making unit creates an independent timer instance for each request, and the timer triggers a timeout callback function when the timeout period arrives.

[0173] Secondly, if a response proposal is received from the corresponding second autonomous decision-making unit before the request timeout timer is triggered, the request timeout timer corresponding to the request is canceled, and the received response proposal is stored in the local queue to be aggregated.

[0174] Third, if no response proposal is received from the corresponding second autonomous decision-making unit when the request timeout timer is triggered, the preset timeout processing strategy is executed according to the timeout processing rules defined in the collaborative rule graph structure, including: resending the consensus request (retry), sending the consensus request to the alternative second autonomous decision-making unit (switching targets), or marking the second autonomous decision-making unit as temporarily unavailable (isolating faulty nodes).

[0175] Fourth, count the number of timeouts for each second autonomous decision-making unit within a preset time period. When the number of timeouts exceeds a preset threshold, update the reliability dimension weight coefficient of the corresponding second autonomous decision-making unit in the priority weight table. Specifically, multiply the original reliability weight coefficient by a decay factor β (β < 1, such as 0.8) to lower the reliability score of that node, thereby reducing the priority of its proposal in subsequent aggregation decisions. Simultaneously, the first autonomous decision-making unit reports the timeout event to the central server for maintenance personnel to investigate the cause of the node failure. The updated priority weight table is persisted to local storage and used for scoring calculations in subsequent decisions.

[0176] It should be noted that the dynamic adjustment method for the timeout duration mentioned above is not limited to quantiles of historical response times. In one example, a weighted moving average based on an adaptive sliding window can be used, assigning higher weights to the most recent response time, which is suitable for scenarios with large fluctuations in network latency. In another example, a response time prediction model based on machine learning can be used to predict the timeout duration based on features such as node load and network conditions, which is suitable for scenarios requiring more precise timeout control.

[0177] This embodiment, as an independent and optional optimization solution, utilizes core technologies such as dynamic timeout settings, normal response processing, timeout fault tolerance processing, timeout count statistics, and weight updates to achieve a distributed communication fault tolerance and adaptive reliability assessment mechanism. This realizes a shift in communication mode from "single request - timeout equals failure" to "dynamic timeout - multiple fault tolerance - adaptive weights." Therefore, based on the distributed negotiation achieved in the above embodiment, it further independently realizes the fault tolerance and adaptability of distributed negotiation, further solving the problem of decision failure caused by single point of failure or network fluctuations in traditional technologies, and significantly improving the robustness and reliability of the supply chain replenishment decision system.

[0178] Example 10: Decision contribution data statistics and priority weight adaptive update mechanism.

[0179] In this embodiment, the method further includes: After each aggregation of the response proposals into a replenishment decision instruction, the decision contribution data of the second autonomous decision unit corresponding to the target proposal used in this aggregation process is recorded. The decision contribution data includes: the number of times the response proposal returned by the second autonomous decision unit was adopted by the first autonomous decision unit, and the proportion of the replenishment quantity in the adopted response proposal to the total replenishment demand of the replenishment demand event. Regularly collect decision contribution data for each second autonomous decision-making unit within a preset statistical period, and calculate the comprehensive contribution score for each second autonomous decision-making unit based on the statistical results; The comprehensive contribution score is correlated with the weight coefficients of each dimension of the corresponding second autonomous decision-making unit in the priority weight table to generate a new combination of weight coefficients; The weight coefficients in the priority weight table are updated with the new combination of weight coefficients to update the priority weight table.

[0180] The decision contribution data refers to the statistical information recorded by the first autonomous decision-making unit after each aggregated decision, used to quantitatively evaluate the decision contribution of the second autonomous decision-making unit. This decision contribution data includes at least two dimensions: first, the number of times a response proposal is adopted, i.e., the number of times a response proposal returned by the second autonomous decision-making unit is selected as a target proposal in the aggregated decision of the first autonomous decision-making unit; second, the proportion of replenishment quantity in adopted response proposals to the total replenishment demand, i.e., the proportion of replenishment quantity contributed by the second autonomous decision-making unit in the total demand of this decision. The decision contribution data is used to subsequently calculate the comprehensive contribution score of each second autonomous decision-making unit.

[0181] The specific implementation of this embodiment is as follows: First, after each response proposal is aggregated into a replenishment decision instruction, the decision contribution data of the second autonomous decision-making unit corresponding to the target proposal used in this aggregation process is recorded. Specifically, after the target proposal is determined and the replenishment decision instruction is generated, the first autonomous decision-making unit iterates through all target proposals for this decision and performs the following recording operation on the second autonomous decision-making unit corresponding to each target proposal: 1) Update adoption count: In the local statistics table, find the record for this second autonomous decision-making unit and increment its "Number of times a response proposal was adopted" field by 1. If the unit has no historical records, create a new record and initialize the adoption count to 1.

[0182] 2) Record the percentage of replenishment quantity adopted: Calculate the percentage of the adopted replenishment quantity to the total replenishment demand in the replenishment demand event. If the proposal of this second autonomous decision-making unit is partially adopted (e.g., the total demand is 50 boxes, and the proposal contributes 20 boxes), then record its contribution percentage as 20 / 50=0.4 (i.e., 40%); if it is fully adopted, then record the percentage as 1.0 (100%). Add this percentage to the "Total percentage of adopted replenishment quantity" field of this unit, and also add the "Adopted replenishment quantity" and "Total demand quantity" fields for subsequent percentage calculations.

[0183] 3) Record the total number of requests: The first autonomous decision-making unit also maintains the total number of requests (i.e. the number of consensus requests sent) of each second autonomous decision-making unit, which is used to calculate the adoption rate.

[0184] Secondly, the decision contribution data of each second autonomous decision-making unit is periodically collected within a preset statistical period, and the comprehensive contribution score of each second autonomous decision-making unit is calculated based on the statistical results. The calculation formula is as follows: Score_i = w_adopt × (N_adopted_i / N_total_i) + w_quantity × (Q_adopted_ratio_avg_i); Wherein, N_adopted_i is the number of times the proposal of unit i was adopted within the statistical period; N_total_i is the total number of consensus requests sent to this unit within the statistical period; Q_adopted_ratio_avg_i is the average proportion of the replenishment quantity adopted by this unit to the total demand within the statistical period (the sum of the proportions of the replenishment quantity adopted divided by the number of adoptions); w_adopt and w_quantity are preset weighting coefficients, which can be initially set to 0.5 each, or adjusted according to business preferences (e.g., increasing w_quantity if more emphasis is placed on quantity contribution). The higher the comprehensive contribution score, the greater the contribution of this second autonomous decision-making unit in historical decisions and the higher the quality of its response proposals.

[0185] For units that have never received a request during the statistical period, their comprehensive contribution score is set to a baseline value (e.g., 0.5) to avoid weight anomalies due to lack of data.

[0186] Third, the comprehensive contribution score is correlated with the weight coefficients of each dimension of the corresponding second autonomous decision-making unit in the priority weight table to generate a new combination of weight coefficients. The priority weight table records the weight coefficients of each second autonomous decision-making unit in the reliability dimension (other dimensions such as time and cost are globally uniform coefficients), and the correlation calculation can adopt a weighted fusion method: W_reliability_new_i = W_reliability_old_i × (1 - β) + Score_i × β; Where W_reliability_old_i is the current reliability weight coefficient, Score_i is the overall contribution score, and β is the learning rate (e.g., 0.3), which controls the speed at which historical weights and new scores are integrated. The larger the learning rate, the greater the impact of new statistical data on the weights, and the faster the system response; the smaller the learning rate, the smoother the weight changes, and the higher the system stability.

[0187] For other decision-making dimensions (time priority and cost priority), their weighting coefficients are globally uniform and do not change with individual units, but can be manually adjusted according to overall business needs. If the priority weighting table also contains unit-specific coefficients for other dimensions (such as unit-specific cost adjustment coefficients), they can be updated in a similar manner.

[0188] Fourth, update the weight coefficients in the priority weight table with new weight coefficient combinations to update the priority weight table and make it effective in subsequent aggregate decision-making, so that the first autonomous decision-making unit can dynamically adjust its trust in each second autonomous decision-making unit based on historical contribution data.

[0189] It should be noted that the specific calculation method for the above comprehensive contribution score is not limited to weighted average. In one example, exponential decay weighting can be used to give higher weight to recent decision contributions, making the score more reflective of the node's current performance, which is suitable for scenarios where node performance changes over time. In another example, the Bayesian update method can be used, treating the number of adoptions as a Bernoulli trial and calculating the posterior probability as a reliability score, which is suitable for scenarios that require more accurate probability estimation.

[0190] This embodiment, as an independent and optional optimization solution, utilizes core technologies such as decision contribution data recording, periodic statistics and comprehensive scoring calculation, and weight coefficient correlation calculation and updating to achieve a data-driven self-learning decision optimization mechanism. This realizes a shift from a "static fixed weight" to a "data-driven - dynamic adaptive" decision-making mode. Building upon the intelligent aggregation decision-making achieved in the above embodiment, it further independently realizes the adaptive optimization of the decision model, further solving the problem that fixed weight coefficients in traditional technologies prevent the decision model from adapting to environmental changes. This significantly improves the accuracy and adaptability of supply chain replenishment decisions, enabling the decision system to leap from "passive execution" to "active learning."

[0191] The supply chain replenishment data processing methods for multi-level inventory described in the above embodiments can be recombined as needed to obtain combined implementation schemes, but all are within the protection scope claimed by this invention.

[0192] Those skilled in the art will understand that the methods provided in the embodiments of the present invention can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. The methods can also be implemented as a computer program product stored in one or more computer-readable storage media, including but not limited to: disks, optical disks, read-only memory (ROM), random access memory (RAM), flash memory, etc. When the computer program product is executed by one or more data processing devices (such as computers), the devices perform the steps as described in any of the foregoing method embodiments.

[0193] The software tools, components, or models not belonging to our company that appear in the embodiments of this invention are merely illustrative examples and do not represent actual use.

[0194] The data collection in this embodiment of the invention complies with the requirements of relevant laws and regulations, such as the Data Security Law of the People's Republic of China, the Personal Information Protection Law of the People's Republic of China, GDPR (General Data Protection Regulation of the European Union), or information security standards of other countries and regions.

[0195] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A supply chain replenishment data processing method for multi-level inventory, characterized in that, include: Instantiate each inventory node in the supply chain network as a corresponding autonomous decision-making unit; Construct a collaborative rule graph structure, which is used to define the collaborative interaction rules between different autonomous decision-making units and the relationships between the rules; In response to a replenishment demand event detected from an inventory node in the supply chain network, the event type of the replenishment demand event is identified, and the corresponding collaborative rule is matched from the collaborative rule graph structure according to the event type. The first autonomous decision-making unit related to the replenishment demand event then initiates a real-time responsive decision-making process. Through the real-time responsive decision-making process, the first autonomous decision-making unit sends a consensus request to at least one second autonomous decision-making unit related to the replenishment demand event according to the collaboration rules. Receive the response proposal returned by the second autonomous decision-making unit, which is independently generated by the second autonomous decision-making unit based on its own state and the collaboration rules; The first autonomous decision-making unit aggregates the response proposals into replenishment decision instructions based on the priority weight table stored locally, and sends the replenishment decision instructions to the execution system.

2. The supply chain replenishment data processing method for multi-level inventory as described in claim 1, characterized in that, The first autonomous decision-making unit related to the replenishment demand event initiates a real-time responsive decision-making process, including: Analyze the replenishment demand event and extract the inventory node identifier and event trigger timestamp corresponding to the replenishment demand event; Based on the inventory node identifier, query and determine the autonomous decision-making unit corresponding to the inventory node identifier from all instantiated autonomous decision-making units as the first autonomous decision-making unit; Based on the event trigger timestamp, a real-time responsive decision task is created in the local event queue of the first autonomous decision-making unit, and the status of the real-time responsive decision task is marked as pending, so as to start the real-time responsive decision process of the first autonomous decision-making unit.

3. The supply chain replenishment data processing method for multi-level inventory as described in claim 1 or 2, characterized in that, The process of initiating a real-time responsive decision-making process by a first autonomous decision-making unit related to the replenishment demand event also includes initiating a predictive responsive decision-making process in parallel with the real-time responsive decision-making process by the first autonomous decision-making unit. Obtain historical replenishment demand time-series data of the inventory nodes managed by the first autonomous decision-making unit, wherein the historical replenishment demand time-series data includes the actual replenishment outbound quantity for each time unit within a past preset period; Based on the historical replenishment demand time series data, a time series prediction model is used to calculate the predicted replenishment demand quantity within a future preset time period. When the predicted replenishment demand exceeds the difference between the safety stock threshold of the inventory node and the current inventory level, a predictive replenishment demand event is generated. The predictive replenishment demand event includes the product identifier of the predicted replenishment demand, the predicted replenishment demand quantity, and the predicted replenishment demand time window. Based on the start timestamp of the predicted replenishment demand time window, a predictive responsive decision task is created in the local event queue of the first autonomous decision unit, and the priority of the predictive responsive decision task is set to be lower than the preset priority value of the real-time responsive decision task. When the predicted replenishment demand time window arrives, the status of the predictive response decision task is switched from pending to executable to initiate the predictive response decision process corresponding to the predictive response decision task.

4. The supply chain replenishment data processing method for multi-level inventory as described in claim 1, characterized in that, Sending a consensus request to at least one second autonomous decision-making unit related to the replenishment demand event, including: Obtain the topology diagram stored locally by the first autonomous decision-making unit. The topology diagram defines the supply and demand hierarchy and spatial distance relationship between the first autonomous decision-making unit and other autonomous decision-making units in the supply chain network. Based on the type of the replenishment demand event, determine the scope of the decision-making unit to be queried, which includes at least one of the upstream supply node, downstream demand node, and peer collaboration node; Based on the topology diagram, autonomous decision-making units that meet preset response conditions are selected as second autonomous decision-making units within the decision-making unit range. The preset response conditions include: the autonomous decision-making unit is online, the current inventory is greater than zero, and there is an available logistics path between the autonomous decision-making unit and the first autonomous decision-making unit. Generate a consensus request message containing the unit identifier of the first autonomous decision-making unit, the type of the replenishment demand event, the replenishment demand product identifier, and the replenishment demand quantity; The consensus request message is sent to each of the selected second autonomous decision-making units.

5. The supply chain replenishment data processing method for multi-level inventory as described in claim 1 or 4, characterized in that, The response proposal is independently generated by the second autonomous decision-making unit based on its own state and the collaborative rules, including: The second autonomous decision-making unit receives the consensus request and parses the replenishment demand product identifier and replenishment demand quantity from the consensus request; Query the local inventory database of the second autonomous decision-making unit to obtain the current inventory, in-transit inventory, and safety stock threshold corresponding to the replenishment demand product identifier; Based on the target collaborative rule matched in the collaborative rule graph structure and corresponding to the consensus request, the adjustable inventory limit of the second autonomous decision-making unit is determined; Based on the current inventory, the in-transit inventory, the safety stock threshold, and the adjustable inventory limit, the second autonomous decision-making unit calculates the maximum committable replenishment quantity for the product identifier of the replenishment demand; Obtain the current load status of the second autonomous decision-making unit, the current load status including the length of the pending task queue and the available processing capacity for the current time period; The response proposal is generated based on the maximum committable replenishment quantity, the current load status, and the replenishment cost rules defined in the collaborative rule graph structure. The response proposal includes replenishable quantity, replenishable time window, and replenishment cost information.

6. The supply chain replenishment data processing method for multi-level inventory as described in claim 1, characterized in that, The first autonomous decision-making unit aggregates the response proposals into replenishment decision instructions based on a locally stored priority weight table, including: The first autonomous decision-making unit receives response proposals from N second autonomous decision-making units and stores the response proposals in a local queue to be aggregated, where N≥2 and is a natural number; Iterate through each response proposal in the local queue to be aggregated, and extract the replenishable quantity, replenishable time window and replenishment cost information from each response proposal; Based on the M decision dimensions and their corresponding weight coefficients recorded in the priority weight table, calculate the decision score for each response proposal. The decision dimensions include at least one of time priority dimension, cost priority dimension, and supplier reliability dimension, where M is a natural number. The response proposals are sorted in descending order of the decision scores; The replenishable quantities of the sorted response proposals are added up sequentially until the total quantity meets the total demand corresponding to the replenishment demand event. The response proposals used in the accumulation process are then identified as the target proposals for this replenishment decision. The replenishable quantity, replenishable time window, and replenishment cost information carried in the target proposal are combined and processed to generate a replenishment decision instruction.

7. The supply chain replenishment data processing method for multi-level inventory as described in claim 1, characterized in that, Constructing a collaborative rule graph structure includes: Define at least one collaborative rule node, each of the collaborative rule nodes corresponding to a type of collaborative interaction rule. The collaborative interaction rule is used to define the interaction behavior between different autonomous decision-making units. The collaborative interaction rule includes at least one of hierarchical replenishment rule, spatial allocation rule, time scheduling rule, and resource constraint rule. For each of the collaborative rule nodes, an input parameter set and an output action set are defined. The input parameter set includes trigger condition parameters and execution condition parameters. The trigger condition parameters include the unit identifier of the initiating party's autonomous decision-making unit, the unit identifier of the target party's autonomous decision-making unit, and the current state parameters between the two. The output action set includes the response action type and the action target object. Based on the dependency, priority, or mutual exclusion relationships between the collaborative interaction rules, directed or bidirectional edges are created to connect different collaborative rule nodes, with each edge carrying a relationship type identifier and a relationship weight value. The collaborative rule nodes and the directed or bidirectional edges are stored in a graph database to construct a collaborative rule graph structure.

8. The supply chain replenishment data processing method for multi-level inventory as described in claim 1, characterized in that, In response to detected replenishment demand events from inventory nodes in the supply chain network, including: An event listening service is started on the server side. The event listening service is registered with event sources. Each event source includes a status change event of its own main decision-making unit, an inventory threshold trigger event, and an external order receipt event. The event listening service receives event messages from inventory nodes in the supply chain network. Parse the event message and extract the event type field and event content field from the event message; When the event type field is inventory below the lower limit threshold, new order, or salesperson's report of stock shortage, the event message will be identified as the replenishment request event; Based on the event content fields, determine the inventory node, replenishment demand product identifier, and replenishment demand quantity corresponding to the replenishment demand event.

9. The supply chain replenishment data processing method for multi-level inventory as described in claim 1, characterized in that, After sending a consensus request to at least one second autonomous decision-making unit related to the replenishment demand event, the process further includes: A request timeout timer is set for the consensus request sent to each of the second autonomous decision-making units, and the timeout duration of the request timeout timer is dynamically adjusted according to the historical response time of the second autonomous decision-making unit; If a response proposal is received from the corresponding second autonomous decision-making unit before the request timeout timer is triggered, the request timeout timer is canceled and the received response proposal is stored in the local aggregation queue. When the request timeout timer is triggered, if no response proposal is received from the corresponding second autonomous decision-making unit, a preset timeout processing strategy is executed according to the rules defined in the collaborative rule graph structure. The preset timeout processing strategy includes resending the consensus request, sending a consensus request to the alternative second autonomous decision-making unit, or marking the second autonomous decision-making unit as temporarily unavailable. The number of response timeouts for each second autonomous decision-making unit within a preset time period is counted. When the number of timeouts exceeds a preset threshold, the reliability dimension weight coefficient of the corresponding second autonomous decision-making unit in the priority weight table is updated.

10. The supply chain replenishment data processing method for multi-level inventory as described in claim 1, characterized in that, The method further includes: After each aggregation of the response proposals into a replenishment decision instruction, the decision contribution data of the second autonomous decision unit corresponding to the target proposal used in this aggregation process is recorded. The decision contribution data includes: the number of times the response proposal returned by the second autonomous decision unit was adopted by the first autonomous decision unit, and the proportion of the replenishment quantity in the adopted response proposal to the total replenishment demand of the replenishment demand event. Regularly collect decision contribution data for each second autonomous decision-making unit within a preset statistical period, and calculate the comprehensive contribution score for each second autonomous decision-making unit based on the statistical results; The comprehensive contribution score is correlated with the weight coefficients of each dimension of the corresponding second autonomous decision-making unit in the priority weight table to generate a new combination of weight coefficients; The weight coefficients in the priority weight table are updated with the new combination of weight coefficients to update the priority weight table.

Images