A logistics rule dynamic matching and automatic processing method and system of an e-commerce ERP system and a storage medium

Abstract

The application discloses a kind of logistics rule dynamic matching and automatic processing method, system and storage medium of e-commerce ERP system.The present scheme includes: constructing three-layer data model specially used for logistics decision, the three-layer data model includes the factor layer for defining computing factor, the operator layer for defining set operation operator, and the strategy layer for decoupling configuration of condition group and action group;Standardized preprocessing including heterogeneous field mapping, unit normalization, address cleaning and completion and feature pre-computation is performed on multi-source heterogeneous order data to generate standard order object;The rule strategy configured is loaded to memory and pre-compiled, and the rule subset is located by rough screening based on the country attribute and platform source attribute of standard order object through inverted index, and the rule condition in rule subset is screened and evaluated by expression engine, and short circuit mechanism is triggered to stop subsequent matching after hitting;According to the action group configured in the rule strategy that hits, at least one execution action of logistics channel distribution, order interception, exception marking or automatic order splitting is executed.The application realizes the dynamic configuration of logistics rule, multi-dimensional fine matching and automatic execution, and improves the flexibility and efficiency of order processing.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, specifically to a method and system for automatic order logistics channel allocation and anomaly interception applied to a cross-border e-commerce ERP system. Background Technology

[0002] In the order processing workflow of a cross-border e-commerce ERP system, automatically assigning sales orders to appropriate logistics channels is a key step in achieving efficient fulfillment. Orders generated by e-commerce platforms (such as Amazon, Shopify, TikTok, etc.) require a comprehensive assessment based on factors such as the destination country, product weight, product attributes, and order amount to select the optimal logistics channel for shipment.

[0003] The existing order logistics channel allocation technology mainly has the following problems: First, the rules are rigid and lack flexibility. Traditional logistics matching logic is usually hard-coded into the system code. When a new logistics channel is added, the freight strategy is adjusted, or a logistics provider temporarily suspends delivery to a certain area, developers need to modify the code, compile, and redeploy the system. The response cycle is long and cannot meet the rapidly changing needs of e-commerce business.

[0004] Second, the matching dimensions are too limited to support complex combinations of conditions. Most existing technologies only support simple matching based on order weight or destination country. However, in actual business, the selection of logistics channels often involves multi-dimensional and complex judgments, such as combinations of conditions like "specified SKU + specific postal code range + order amount range", or aggregate logic like "if any blacklisted SKU is included, a special channel will be used", which existing technologies cannot effectively support.

[0005] Third, there is a lack of integration mechanisms with risk control actions. Existing technologies typically only handle the single function of "matching logistics channels," lacking subsequent automated management of the matching results. For example, it is impossible to directly define risk control actions such as "blocking orders" or "marking as manual review" in the matching rules, which makes it easy for abnormal orders (such as blacklisted buyers or suspected fraudulent orders) to be missed or sent incorrectly, causing economic losses to merchants.

[0006] Fourth, the matching efficiency is insufficient in large-scale order scenarios. During major promotional events, the system needs to handle a massive number of concurrent order requests. The traditional database polling matching method requires querying and judging each rule in the database one by one, which is inefficient and can easily cause system blocking and response delays.

[0007] Fifth, the order data structures differ significantly across platforms, making preprocessing difficult. Order data output by different e-commerce platforms varies significantly in terms of field naming, units of measurement, and address formats. Existing technologies lack dedicated data standardization processing solutions for logistics matching scenarios, which affects the accuracy and efficiency of subsequent matching processes.

[0008] For example, Chinese patent application CN106372778A discloses a vehicle dispatching system and method based on a dynamic rule engine, which dynamically configures and executes dispatching rules through the rule engine. However, when applied to the field of vehicle dispatching, this solution uses a general key-value matching model as its rule model, failing to build a dedicated data model for logistics channel decision-making scenarios, and does not involve standardized processing of multi-source heterogeneous order data, nor does it integrate diverse execution actions. Similarly, Chinese patent application CN117827295A discloses a logistics contract configuration method that configures logistics contract information through a rule engine platform. However, this solution is based on preset formulas, resulting in limited rule expression capabilities and combination flexibility, making it difficult to support the integration of complex conditions and risk control actions with multi-dimensional free combinations.

[0009] In summary, existing technologies urgently need a dynamic matching solution for logistics rules that can support flexible configuration of logistics rules, multi-dimensional combination matching, integration of risk control actions, and efficient concurrent processing. Summary of the Invention

[0010] This invention aims to provide a flexible and efficient dynamic matching method and system for logistics rules, in order to solve the technical problems of severely rigid rules, single matching dimensions, lack of risk control action integration, and low matching efficiency in large-scale order scenarios in the prior art.

[0011] This invention achieves accurate and automatic matching of sales orders to logistics products and automated execution of diverse subsequent actions by constructing a three-layer rule data model dedicated to logistics decision-making, standardized preprocessing of multi-source heterogeneous order data, a fast matching mechanism based on memory pre-compilation and inverted index, and a configurable structure that decouples condition groups and action groups. This reduces manual operation costs and improves the accuracy, timeliness, and concurrent processing capabilities of order processing.

[0012] To achieve the above-mentioned objectives, the present invention provides the following technical solution: Solution 1: A method for dynamic matching and automated processing of logistics rules in an e-commerce ERP system, comprising the following steps: Rule definition steps: Construct a dynamic rule model based on logistics characteristics. The dynamic rule model includes a factor layer, an operator layer, and a strategy layer. The factor layer is used to define computational factors required for logistics decision-making. The operator layer is used to define set operation operators that perform logical judgments on the factors. The strategy layer is used to decouple the condition group and the action group. Data preprocessing steps: Obtain multi-source heterogeneous order data, perform standardization preprocessing on the multi-source heterogeneous order data, and generate standard order objects; Rule matching steps: Load the configured rule strategy into memory and precompile it; filter and match the rule strategy based on the attribute information of the standard order object; and output the matching rule strategy. Action execution steps: Based on the action group configured in the hit rule strategy, execute at least one of the following actions: logistics channel allocation, order interception, anomaly marking, or automatic order splitting.

[0013] Preferably, the computational factors defined in the factor layer include static factors and dynamic computational factors. The static factors include order weight, and the dynamic computational factors include a billing weight factor and a postal code partition factor. The billing weight factor is used to calculate the billing weight by taking the maximum value of the volumetric weight and physical weight of the order. The postal code partition factor is used to obtain the partition identifier by matching the postal code prefix of the recipient address with the logistics provider's partition table.

[0014] Preferably, the set operation operators defined in the operator layer include a inclusion operator and an intersection non-empty operator; the inclusion operator is used to determine whether the set of goods in the order is a subset of the specified set of goods; the intersection non-empty operator is used to determine whether the set of goods in the order has an intersection with the specified set of goods.

[0015] Preferably, in the strategy layer, the condition group is configured with a logic tree structure, supporting AND, OR, and NOT logical combinations among multiple conditions; the action group is configured with a serial instruction set, supporting the sequential execution of multiple actions in a predetermined order.

[0016] Preferably, the data preprocessing step specifically includes: Heterogeneous field mapping: Based on the pre-configured field mapping relationship, heterogeneous fields of order data from different e-commerce platforms are uniformly mapped to the internal fields of the standard order object; Unit normalization: Identify the units of measurement in the multi-source heterogeneous order data, and convert the different units of measurement into standard units of measurement according to the pre-configured conversion table; Address cleaning and completion: Perform regular expression matching on the recipient address, remove non-printable characters, and complete the full name of the country based on the country code and verify the postal code format; Feature pre-computation: Traverse the order line items, accumulate the product weights, and generate order-level attribute labels.

[0017] Preferably, the rule matching step specifically includes: Rule loading and pre-compilation: Load the enabled rule policies in the database into memory, construct an ordered linked list according to the priority attributes configured in the rule policies, and pre-compile the condition expressions in the rule policies into executable code; Index coarse screening: Based on the country and platform origin attributes of the standard order object, a subset of rules related to the standard order object is quickly located through a pre-built inverted index, and irrelevant rules are filtered out; Expression filtering: The standard order object is injected into the expression engine as a context, the rule subset is traversed, and the expression engine evaluates the condition group of each rule strategy. Short-circuit output: When the evaluation result of the condition group of any of the rule strategies is true, immediately stop the traversal of subsequent rule strategies and output the rule strategy as the hit result.

[0018] Preferably, the rule matching step further includes conflict arbitration: when multiple non-exclusive rule strategies are matched simultaneously, the action groups of the multiple non-exclusive rule strategies are merged and executed according to a preset weighting algorithm, wherein the weighting algorithm calculates a comprehensive weight based on action priority and rule priority.

[0019] Preferably, in the action execution steps, the execution action includes at least one of the following: logistics channel allocation action, order interception action, anomaly marking action, and automatic order splitting action; the logistics channel allocation action is used to allocate the order to a designated logistics channel; the order interception action is used to prevent the order from entering the subsequent logistics allocation process; the anomaly marking action is used to mark the order status as an abnormal status; and the automatic order splitting action is used to split the order into multiple sub-orders for separate processing.

[0020] Option 2: A dynamic matching and automated processing system for logistics rules in an e-commerce ERP system, comprising: The rule definition module is configured to construct a dynamic rule model based on logistics characteristics. The dynamic rule model includes a factor layer, an operator layer, and a strategy layer. The factor layer is used to define computational factors required for logistics decision-making. The operator layer is used to define set operation operators that perform logical judgments on the factors. The strategy layer is used to decouple the condition group and the action group. The data preprocessing module is configured to acquire multi-source heterogeneous order data, perform standardized preprocessing on the multi-source heterogeneous order data, and generate standard order objects; The rule matching engine is configured to load the configured rule strategies into memory and pre-compile them, filter and match the rule strategies based on the attribute information of the standard order object, and output the matched rule strategies. The action execution module is configured to perform at least one of the following actions based on the action group configured in the hit rule strategy: logistics channel allocation, order interception, anomaly marking, or automatic order splitting.

[0021] Option 3: A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-mentioned method for dynamic matching and automated processing of logistics rules in an e-commerce ERP system.

[0022] Compared with the prior art, the present invention has the following beneficial technical effects: 1. This invention, through a three-layer data model (factor layer, operator layer, and strategy layer) and visualized rule configuration, allows operations personnel to dynamically adjust delivery strategies without modifying code. When a logistics channel temporarily raises prices or suspends delivery to a certain region, operations personnel can immediately adjust the rule configuration, with the configuration taking effect in seconds, significantly shortening the business response cycle.

[0023] 2. This invention supports the free arrangement and combination of hundreds of fields. Through the extensible factor definition of the factor layer and the set operation operator of the operator layer, it effectively supports complex combination conditions such as "specified SKU + specific postal code segment + order amount range" and set logic such as "blocking if any blacklisted SKU is included", thus solving the business pain point that special products (such as pure electric vehicles and special goods) need to go through specific channels.

[0024] 3. This invention combines logistics matching with risk control, integrating multiple actions such as order interception, anomaly marking, and automatic order splitting into its rules and strategies. Abnormal orders can be intercepted and processed during the matching stage, effectively preventing missed or incorrect shipments and reducing financial losses for merchants.

[0025] 4. This invention significantly reduces the computational load in the matching process of a single order by combining a two-level matching mechanism that integrates rule pre-compilation and memory loading, coarse screening with inverted index and fine screening with expression, as well as a short-circuit mechanism that stops when a match is found. This enables the invention to maintain a high-efficiency matching response speed and avoid system blocking in scenarios with a large number of orders during promotional events.

[0026] 5. Based on the abstract rule factor design, this invention does not require refactoring the core engine when adding new judgment conditions (such as "buyer credit rating", "membership level" etc.). It only requires extending the new factor definition at the factor layer, which reduces the maintenance cost and expansion difficulty of the system. Attached Figure Description

[0027] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0028] Figure 1 This is a flowchart illustrating the dynamic matching and automated processing method for logistics rules according to the present invention.

[0029] Figure 2 This is a schematic diagram of the overall architecture of the e-commerce ERP logistics rule dynamic matching and automated processing system of the present invention. Detailed Implementation

[0030] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to specific illustrations.

[0031] To address the technical problems of poor flexibility, limited dimensions, lack of risk control integration, and low matching efficiency in large-scale order scenarios in existing e-commerce ERP systems, this invention employs the following core technical methods: First, a three-layer data model (factor layer, operator layer, and strategy layer) specifically designed for logistics decision-making was constructed. Unlike the simple key-value matching model of traditional general-purpose rule engines, this invention, tailored to the characteristics of logistics scenarios, introduces dynamically calculated factors (such as automatic calculation of billing weight and automatic matching of postal code partitions) at the factor layer, set operation operators (such as inclusion and non-empty intersection) at the operator layer, and decouples the configuration of condition groups and action groups at the strategy layer. This layered architecture significantly enhances the expressive power of logistics rules while maintaining the flexibility and maintainability of rule configuration.

[0032] Second, a dedicated data preprocessing link for logistics matching was established. Addressing the heterogeneous nature of order data across multiple cross-border e-commerce platforms, this invention designed a complete preprocessing workflow including heterogeneous field mapping, unit normalization, address cleaning and completion, and feature pre-calculation. This transforms raw order data into standard order objects, laying the data foundation for subsequent accurate matching.

[0033] Third, a multi-level accelerated matching architecture is adopted, consisting of "in-memory pre-compilation + inverted index coarse screening + expression fine screening + short-circuit mechanism". During matching, the inverted index is used to quickly locate the relevant rule subset, and then the expression engine is used to accurately evaluate the subset; the short-circuit mechanism, which stops when a match is found, further reduces invalid calculations. This architecture effectively solves the matching efficiency problem in large-scale order scenarios.

[0034] Through the mutual cooperation and synergy of the above-mentioned technical means, flexible configuration, multi-dimensional matching, risk control integration and efficient execution of logistics rules are achieved, which constitutes the complete technical solution of this invention.

[0035] like Figure 1As shown, it is an overall flowchart of the dynamic matching and automated processing method of e-commerce ERP logistics rules based on the above-mentioned technical means.

[0036] Based on the illustrations, the e-commerce ERP logistics rule dynamic matching and automated processing method provided by this invention includes the following main steps: Step S100, rule definition step. In the rule definition step, based on the logistics decision factors provided by the factor layer and the set operation operators provided by the operator layer, condition groups and action groups are configured in the strategy layer to form a complete rule strategy; wherein, each rule strategy is configured with a priority attribute, which is used to control the matching order.

[0037] Step S200, Data Preprocessing Step. In the data preprocessing step, multi-source heterogeneous raw order data is obtained from the interfaces of various e-commerce platforms, and standardized preprocessing is performed on the raw order data to eliminate data format differences between different platforms and generate a standard order object with a unified structure.

[0038] Step S300, rule matching step. In the rule matching step, the pre-configured and stored enabled rule strategies are loaded into memory and pre-compiled; for each order to be processed, the key attributes of the standard order object of the order are extracted, and the relevant rule subset is quickly located through the inverted index. Then, the expression engine evaluates the conditions of each rule in the subset. If a match is found, the short-circuit mechanism is triggered to stop subsequent matching.

[0039] Step S400, Action Execution Step. In the action execution step, according to the action group configured in the matching rule strategy, the corresponding actions are executed sequentially according to the order of the serial instruction set. The actions include, but are not limited to, logistics channel allocation, order interception, anomaly marking, and automatic order splitting.

[0040] Based on an understanding of the overall function and logical coordination of the above steps, the following section provides a more detailed explanation of the specific implementation plan for each step from a technical implementation perspective.

[0041] As an example of an implementable form, step S100 of the method of the present invention is configured to construct a dynamic rule model based on logistics characteristics, which adopts a three-layer architecture: (1) Implementation of the factor layer. The factor layer defines all computable factors required for logistics decision-making, including two categories: static factors and dynamic computable factors.

[0042] Static factors are derived directly from field values ​​of the standard order object, including but not limited to: order weight, destination country, platform origin, order amount, quantity of goods, buyer ID, and mailing postal code.

[0043] Dynamically calculated factors are derived values ​​calculated at runtime based on raw data. They are implemented by using a pre-built calculation function library, with each dynamic factor bound to a specific calculation function. When rule matching is required, a standard order object is used as input, and the corresponding calculation function is called to generate the factor value. Specifically: The implementation logic for the billing weight factor is as follows: The physical weight (normalized to grams) and volumetric weight (calculated based on the package's length, width, and height, calculated as length × width × height ÷ billing coefficient) of the order are obtained from the standard order object, and the maximum value between the two is taken as the billing weight output. This factor allows logistics rules to be matched based on the actual billing weight rather than the physical weight, which is closer to the billing logic of logistics providers.

[0044] The implementation logic for the zip code zone factor is as follows: Extract the zip code of the recipient address from the standard order object, extract the prefix of that zip code (e.g., the first 3 or 5 digits of a US zip code), use this prefix as the key to query the pre-configured logistics provider zone mapping table, and return the corresponding zone ID. This factor allows rules to be matched based on the logistics provider's zone pricing strategy, eliminating the need to hardcode specific zip code ranges in the rules.

[0045] (2) Implementation of the operator layer. The operator layer defines the operators used for logical judgment of factor values. In addition to the usual comparison operators (greater than, less than, equal to, not equal to), this invention specifically defines the following set operation operators for the common SKU set judgment requirements in e-commerce scenarios: The `IN_SUBSET` operator takes two arguments: the order's product set and a specified product set. It determines whether the former is a subset of the latter. The logic is as follows: iterate through each SKU in the order's product set and check if that SKU exists in the specified product set. If all SKUs exist, return true; otherwise, return false. This operator is suitable for scenarios where "all products in the order are of the specified category."

[0046] Intersection Non-empty Operator (INTERSECTS): This operator takes two parameters—the order product set and a specified product set—and determines whether there is an intersection between them. Its logic is as follows: iterate through each SKU in the order product set and check if that SKU exists in the specified product set. If a match is found, return true immediately; otherwise, return false. This operator is suitable for scenarios where "the rule is triggered if any specified SKU is present in the order," such as blacklist SKU blocking rules.

[0047] (3) Implementation of the strategy layer. The strategy layer adopts a metadata-based configuration structure, which completely decouples the condition group and the action group.

[0048] The condition groups are configured using a logic tree structure. The leaf nodes of the logic tree are atomic conditions (triples of factor + operator + threshold), and the non-leaf nodes are logical operators (AND, OR, NOT). During matching, the logic tree is recursively evaluated: from bottom to top, the Boolean values ​​of the leaf nodes are calculated first, then the Boolean values ​​of the parent nodes are calculated based on the logical operator combinations, ultimately yielding the Boolean result of the entire condition group. The logic tree structure supports condition combinations of arbitrary complexity and is theoretically unlimited in the number of conditions.

[0049] Action groups are configured using a serial instruction set. Each action instruction includes an action type and action parameters. Actions are executed sequentially according to their order in the serial instruction set. Action types include, but are not limited to: logistics channel allocation action (parameter is the logistics channel identifier, which updates the logistics channel field of the order to the specified value upon execution); order interception action (no parameters, which changes the order status to "intercepted" upon execution); exception marking action (parameter is the mark type, which adds the specified tag to the order upon execution); and automatic order splitting action (parameter is the order splitting rule, which splits the order into multiple sub-orders upon execution).

[0050] Each complete rule policy contains the following metadata: unique rule identifier, rule name, condition group (logic tree structure), action group (serial instruction set), priority (integer value, the smaller the value, the higher the priority), whether it is exclusive (boolean value, if true, no other rules will be matched after the match), and enabled status (boolean value).

[0051] As an example of an implementable form, step S200 of the method of the present invention is configured to standardize raw order data from different e-commerce platforms, specifically including the following sub-steps: Sub-step S210, Heterogeneous Field Mapping. Establish a middleware adaptation layer to configure the field mapping relationship between the JSON data structures of different e-commerce platforms and the system's internal standard order objects. For example, in the order data structure of the Amazon platform, the shipping address field is "Ship-To-Address-Line1", in the Shopify platform it is "address1", and in the TikTok platform it might be "shipping_address.line1". Through mapping configuration, the address line 1 field of all platforms is uniformly mapped to the internal standard field "address1". The mapping configuration is stored in key-value pairs, supporting dynamic CRUD operations. When adding a new platform, only the mapping configuration needs to be added; no code modification is required.

[0052] Sub-step S220: Unit Normalization. Identify the units of measurement for each numerical field in the original order data and convert all values ​​to standard units of measurement using an internal conversion table. For weight units, oz (ounce) and lb (pound) are converted to g (gram), with the conversion relationships: 1 oz = 28.3495 g, 1 lb = 453.592 g. For length units, in (inch) is converted to cm (centimeter), with the conversion relationship: 1 in = 2.54 cm. For monetary units, convert multiple currency amounts to the base currency (e.g., USD) based on the real-time exchange rate to eliminate dimensional errors when comparing values.

[0053] Sub-step S230, Address Cleaning and Completion. Perform the following cleaning and completion operations on the recipient address: Use regular expressions to match and remove non-ASCII characters (such as emojis and special symbols) from the recipient's name and address to prevent garbled characters when printing the shipping label; for orders containing only the country code (such as "US"), automatically complete the full country name (such as "United States") according to the pre-configured country code table; verify the zip code format, for example, US zip codes should be 5 digits or 5+4 digits (such as "90210" or "90210-1234"), and mark non-compliant zip codes or truncate them according to preset rules.

[0054] Sub-step S240, Feature Pre-calculation. Traverse all line items of the order and perform the following pre-calculation operations: Accumulate the weight of each item (normalized to grams) to obtain the total order weight, used for calculating the billing weight factor; generate an order-level attribute tag set based on the "attribute tags" (such as "general goods," "pure electric," "special goods," "liquid") in the product profile. For example, if the order contains any item marked "pure electric," then the order-level attribute tags will include "contains pure electric items," for quick determination during rule matching.

[0055] As an example of an implementable form, step S300 in the method of the present invention, when performing rule matching, is specifically configured to include the following sub-steps: Sub-step S310: Rule Loading and Pre-compilation. Upon system startup or when rule configuration changes, the following operations are performed: All rule policies in the "enabled" state are queried from the database and sorted according to priority attributes (numerical values ​​from smallest to largest); an ordered linked list is constructed based on the sorting result, where each node is a rule policy object, and the list order is the matching order; for each rule policy's condition group (logic tree structure), the atomic condition expressions (factor + operator + threshold) are pre-compiled into executable bytecode or an execution tree and stored in the rule policy object. The pre-compilation is implemented by converting atomic conditions into an intermediate representation (IR) recognizable by the expression engine. This IR includes factor identifiers, operator types, and threshold constants. After pre-compilation, runtime execution does not require syntax parsing or type checking of the condition expressions; a Boolean result can be obtained directly upon execution.

[0056] Sub-step S320: Coarse index screening. An inverted index is built using the two highly distinctive attributes of the order: "Destination Country" and "Platform Origin". The data structure of the inverted index is: a composite key of (country code, platform code) as the key, and a list of rule / strategy IDs associated with that composite key as the value.

[0057] When an order to be matched is received, the following operations are performed: The destination country code and platform source code are extracted from the standard order object; a hash lookup is performed in the inverted index using (country code, platform code) as the composite key to quickly locate the list of rule policy IDs (i.e., a subset of rules) related to the country / platform of the order; irrelevant rules policies are directly filtered out. For example, when processing orders shipped to the United States (US), only the subset of rules whose keys in the inverted index contain "US" is traversed, and rules only for Europe (EU) are not traversed, thus significantly reducing the number of rules that need to be evaluated. For general rules without configured country or platform conditions, they are indexed under all composite keys to ensure that general rules are not coarsely filtered out.

[0058] Sub-step S330, Expression Refinement. The standardized standard order object is injected into the expression engine as a context. The expression engine traverses the rule subset obtained after coarse screening in the order of the ordered linked list. For each rule strategy, the following operations are performed: the pre-compiled condition group execution tree is obtained from the rule strategy object; the condition group execution tree is executed with the standard order object as input: for atomic conditions, the corresponding factor value is extracted from the standard order object (if it is a dynamic factor, the calculation function is executed first), and an operator operation is performed with the threshold to obtain a Boolean value; for logical combinations, the Boolean values ​​of the sub-conditions are combined according to AND, OR, and NOT logical combinations; finally, the Boolean result of the entire condition group is obtained.

[0059] Sub-step S340: Short-circuit output. When the condition set of any rule strategy evaluates to true, the traversal of subsequent rule strategies is immediately stopped (i.e., short-circuit mechanism), and that rule strategy is output as the hit result. The short-circuit mechanism ensures that no unnecessary rule calculations are performed after the first matching rule is found, further improving matching efficiency.

[0060] Sub-step S350, Conflict Arbitration. In some business scenarios, multiple rule strategies may simultaneously hit the same order (i.e., non-exclusive rules). This situation is handled through a conflict arbitration mechanism: First, the "exclusive" attribute of each hitting rule is checked. If an exclusive rule exists, it is directly selected, ignoring other hitting rules; if no exclusive rule exists, the comprehensive weight of each hitting rule is calculated according to a preset weighting algorithm. The formula for this weighting algorithm is: Overall weight = Action priority weight × α + Rule priority weight × β Among them, the action priority weight is determined according to the action type configured in the rule (e.g., the priority of the "intercept" action is higher than that of the "allocate logistics" action). The rule priority weight is directly taken from the priority attribute value of the rule (the smaller the value, the higher the weight). α and β are preset coefficients (which can be adjusted according to business needs, with α=β=0.5 by default). The rule with the highest comprehensive weight is selected as the final hit result, and all action instructions in its action group are executed.

[0061] As an example of an implementable form, step S400 in the method of the present invention is specifically configured to execute each action instruction sequentially according to the action group configured in the hit rule strategy, in the order of the serial instruction set: If the action type is "Logistics Channel Allocation", the logistics channel field of the order will be updated to the logistics channel identifier specified in the action parameters, and the order will be pushed to the warehouse system for order processing and shipment. If the action type is "Order Interception", the order status will be changed to "Intercepted", preventing it from entering the subsequent logistics allocation and shipment process, and an alarm notification may be triggered. If the action type is "Abnormal Marking", a specified tag (such as "Manual Review" or "Risk Control Pending") will be added to the order, and the order will be transferred to the manual review queue. If the action type is "Automatic Order Splitting", the original order will be split into multiple sub-orders according to the order splitting rules, and each sub-order will be independently processed for subsequent logistics matching and shipment.

[0062] The method for dynamic matching and automated processing of e-commerce ERP logistics rules provided in this invention can be used to construct a corresponding software program, forming a corresponding e-commerce ERP logistics rule dynamic matching and automated processing system. When running, this software program will execute the aforementioned method for dynamic matching and automated processing of e-commerce ERP logistics rules and store the results in a corresponding storage medium for the processor to retrieve and execute.

[0063] See Figure 2 The resulting e-commerce ERP logistics rule dynamic matching and automated processing system mainly includes the following four core components: rule definition module 100, data preprocessing module 200, rule matching engine 300, and action execution module 400.

[0064] Specifically, the rule definition module 100 in the system is configured to provide a visual rule configuration interface for system administrators to build dynamic rule models based on logistics characteristics. This module manages the definition and registration of factors in the factor layer, the definition and registration of operators in the operator layer, and the configuration and combination of condition groups and action groups in the strategy layer, ultimately generating complete rule strategies and persistently storing them in the rule database.

[0065] The data preprocessing module 200 is configured to obtain multi-source heterogeneous order data from various e-commerce platform interfaces. Through heterogeneous field mapping, unit normalization, address cleaning and completion, feature pre-calculation and other processes, the original order data is converted into standardized order objects with a unified structure and output to the rule matching engine.

[0066] The rule matching engine 300 is configured to load the rule strategies from the rule database into memory and pre-compile them when the system starts. For each order to be matched, it uses an inverted index to coarsely filter and locate a subset of rules, and then uses an expression engine to finely filter and evaluate the subset. If a match is found, a short-circuit mechanism is triggered to stop matching. When multiple rules are matched at the same time, conflict arbitration is performed, and the final matched rule strategy is output.

[0067] The action execution module 400 is configured to execute actions such as logistics channel allocation, order interception, anomaly marking, or automatic order splitting in sequence according to the action group configured in the hit rule strategy output by the rule matching engine.

[0068] The resulting system includes a rule definition module 100 that pre-configures and stores rule strategies; a data preprocessing module 200 that receives raw order data and outputs standard order objects; a rule matching engine 300 that uses the standard order objects as input to perform matching and outputs matching rules; and an action execution module 400 that executes corresponding actions based on the matching rules. The data flow is unidirectional, and each module has clearly defined responsibilities and interfaces.

[0069] Based on an understanding of the overall functions and logical relationships of the components of the above system, the following section provides a more detailed explanation of the specific configuration schemes of each component from a technical implementation perspective.

[0070] As an example of an implementable form, the rule definition module 100 in the system of the present invention is specifically configured to include a factor management submodule 101, an operator management submodule 102, a strategy configuration submodule 103, and a rule persistence submodule 104.

[0071] The factor management submodule 101 is configured to maintain a factor registry. Each factor registration entry includes a factor identifier, factor name, factor type (static / dynamic), data type (numeric / string / boolean / set), and value source (standard order object field path or calculation function reference). When adding a factor, the administrator can register the factor metadata through the interface without modifying the core code.

[0072] The operator management submodule 102 is configured to maintain an operator registry. Each operator registration entry contains an operator identifier, operator name, applicable data type, and function reference for the operation logic. This invention pre-configures comparison operators (EQ, NE, GT, LT, GE, LE) and set operation operators (IN_SUBSET, INTERSECTS), and supports expansion by registering new operators.

[0073] The strategy configuration submodule 103 is configured to provide a graphical rule configuration interface, where administrators can combine conditions (logic tree structure) and actions (serial instruction set) by dragging and dropping and selecting, and configure the priority and exclusive attributes of rules.

[0074] The rule persistence submodule 104 is configured to serialize the configured rule strategy in JSON format and store it in the rule database. At the same time, it listens for rule change events and notifies the rule matching engine to perform hot updates when a rule changes.

[0075] As an example of an implementable form, the data preprocessing module 200 in the system of the present invention is specifically configured to include a platform adapter submodule 201, a field mapping submodule 202, a unit conversion submodule 203, an address processing submodule 204, and a feature pre-calculation submodule 205.

[0076] Among them, the platform adapter submodule 201 is configured to implement an adapter instance for each supported e-commerce platform (Amazon, Shopify, TikTok, eBay, etc.), which is responsible for pulling raw order data from the platform's API interface and converting the data into an intermediate data structure in key-value pair format.

[0077] The field mapping submodule 202 is configured to maintain a field mapping configuration table, mapping platform-specific field names in the intermediate data structure to internal field names of standard order objects. The mapping configuration is stored as an editable configuration file and supports dynamic updates.

[0078] The unit conversion submodule 203 is configured to maintain a unit conversion configuration table, which includes conversion coefficients for various units of measurement, and performs unit normalization conversion of numerical values.

[0079] Address processing submodule 204 is configured to maintain a country code table and a regular expression library for postal code formats, and to perform address cleaning and completion operations.

[0080] The feature pre-computation submodule 205 is configured to traverse order line items, perform weight accumulation and attribute label aggregation, and generate pre-computed features at the order level.

[0081] As an example of an implementable form, the rule matching engine 300 in the system of the present invention is specifically configured to include a rule loading submodule 301, an index building submodule 302, an expression execution submodule 303, and a conflict arbitration submodule 304.

[0082] The rule loading submodule 301 is configured to read all enabled rule policies from the rule database when the system starts, perform pre-compilation, and build an ordered linked list stored in memory. This submodule also subscribes to rule change events and automatically reloads the affected rules when rules are added, deleted, or modified.

[0083] The index building submodule 302 is configured to build an inverted index of the rule policy ID list based on the country and platform conditions in the rule policy, using the (country code, platform code) combination key, and store it in memory.

[0084] The expression execution submodule 303 is configured to implement a lightweight expression evaluator that can accept a standard order object as context, recursively evaluate the precompiled condition group execution tree, and return a boolean result.

[0085] The conflict arbitration submodule 304 is configured to calculate the comprehensive weight based on the weighting algorithm and select the final rule when multiple rules are hit simultaneously.

[0086] As an example of an implementable form, the action execution module 400 in the system of the present invention is specifically configured to include an action instruction parsing submodule 401 and an action executor submodule 402.

[0087] The action instruction parsing submodule 401 is configured to parse the serial instruction set of the action group in the hit rule strategy and convert each action instruction into an executable action task object.

[0088] The action executor submodule 402 is configured to contain multiple action executor instances, with one executor corresponding to each action type: the logistics allocation executor calls the logistics channel update interface of the ERP system; the order interception executor calls the order status management interface; the exception marking executor calls the tag management interface; and the automatic order splitting executor calls the order splitting interface.

[0089] As a further example of an implementable form, the system based on the above scheme is configured to perform the following logical operations: (1) During the rule configuration phase, the administrator selects the required factors from the factor list provided by the factor management submodule 101 and the required operators from the operator list provided by the operator management submodule 102 through the visual interface of the rule definition module 100. In the strategy configuration submodule 103, the administrator combines these to form a logical tree structure of the condition group and a serial instruction set of the action group, configures the priority and exclusive attributes, and then saves the configuration. The rule persistence submodule 104 serializes and stores the rule strategy in the rule database.

[0090] (2) During the system startup phase, the rule loading submodule 301 of the rule matching engine 300 reads all enabled rule policies from the rule database, performs pre-compilation to generate an execution tree for the condition group of each rule, and constructs an ordered linked list according to priority. The index building submodule 302 traverses all rules, extracts the country condition and platform condition, and constructs an inverted index. All data is stored in memory for subsequent matching.

[0091] (3) During the order processing stage, when the original order data is received from the e-commerce platform, the platform adapter submodule 201 of the data preprocessing module 200 pulls the data and converts it into an intermediate format, the field mapping submodule 202 performs field mapping, the unit conversion submodule 203 performs unit normalization, the address processing submodule 204 performs address cleaning and completion, and the feature pre-calculation submodule 205 performs weight accumulation and attribute tag aggregation, and finally outputs a standard order object.

[0092] (4) During the rule matching phase, the rule matching engine 300 receives the standard order object, and the index construction submodule 302 extracts the destination country and platform origin of the order, and quickly locates the rule subset through the inverted index. The expression execution submodule 303 uses the standard order object as the context and traverses the rule subset in the order of the ordered linked list, evaluating the condition group of each rule. Once the condition group of a rule evaluates to true, the short-circuit mechanism is triggered to stop the traversal. If multiple non-exclusive rules are matched at the same time, the conflict arbitration submodule 304 selects the final rule according to the weight algorithm.

[0093] (5) During the action execution phase, the action execution module 400 receives the hit rule strategy, the action instruction parsing submodule 401 parses the serial instruction set of the action group, and the action executor submodule 402 calls the corresponding executor in sequence according to the instruction order to execute the action, and completes the logistics channel allocation, interception, marking or splitting of the order.

[0094] The following specific application examples further illustrate the application and implementation process of the present invention and the technical effects that can be achieved.

[0095] Example 1: Standard Logistics Channel Allocation Scenario Suppose that the following two rule policies have been configured in a cross-border e-commerce ERP system: Rule A (priority 1, exclusive is true) – "US Small Parcel Express Rules": Condition group (logic tree): (Destination country = "US") AND (Order chargeable weight ≤ 450) AND (Order attribute tag is contained in {"General Goods"}) Action group (serial instruction set): [Logistics channel allocation("US_Express_Saver")] Rule B (priority 2, exclusive condition true) – "US General Shipping Rules": Condition group (logic tree): (Destination country = "US") AND (Order billing weight > 450) Action group (serial instruction set): [Logistics channel allocation ("DHL_Global")] Rule C (priority 0, exclusive is true) – "Special Goods Interception Rule": Condition group (logic tree): (Destination country = "US") AND (Intersection of order attribute tags and {"pure electric", "liquid"} is not empty) Action group (serial instruction set): [Order interception(), exception flag("manual review")] After system deployment, an order was received from Amazon, order number 12345, destination country: US, containing two phone cases. The data preprocessing module performed standardization: physical weight was totaled at 200g, volumetric weight was calculated at 180g (assuming small volume), and the billing weight factor was set to the maximum value of 200g; the product profile query showed that the phone cases' attribute tag was "general goods"; the standard order object was generated.

[0096] After receiving a standard order object, the rule matching engine locates the subset of rules (containing rules A, B, and C) with country = US using an inverted index. Following priority (smaller values ​​have higher priority), it first calculates the condition group for rule C: destination country = US matches, but the intersection of the order attribute tag ("general cargo") and {"pure electricity", "liquid") is empty, so the condition group result is false, and rule C is not matched. Next, it calculates the condition group for rule A: destination country = US matches, chargeable weight 200g ≤ 450g matches, and the attribute tag "general cargo" is contained within {"general cargo}, so the condition group result is true, and rule A is matched. Because the exclusive attribute of rule A is true, a short-circuit mechanism is triggered, and the engine stops matching rule B.

[0097] The action execution module receives rule A, parses the logistics channel allocation instruction in the action group, updates the logistics channel of order 12345 to "US_Express_Saver", and pushes the order to the warehouse system for order processing and shipment.

[0098] Example 2: Anomaly Interception Scenario Assume the system is configured with rule D (priority 0, exclusive is true) – "blacklist blocking rule": Condition group (logic tree): Buyer ID exists in {blacklist buyer ID set} Action group (serial instruction set): [Order interception(), exception flag("risk control - blacklist")] When a blacklisted buyer (whose buyer ID is already in the pre-configured blacklist set) places an order on the platform, after the data preprocessing module completes the standardization process, the rule matching engine first calculates the condition group for rule D: extracting the buyer ID from the standard order object, querying the blacklist set, finding a match, and the condition group result is true. Rule D is hit and exclusively true, triggering the short-circuit mechanism, and the engine no longer matches other rules.

[0099] The action execution module executes the following actions sequentially: the order interception action changes the order status to "intercepted," preventing it from entering the subsequent logistics allocation and shipping process; the anomaly marking action marks the order as "risk control - blacklist" and transfers it to the manual review queue. The system simultaneously triggers an alarm notification, reminding operations personnel to pay attention to the abnormal order.

[0100] Example 3: Conflict Arbitration Scenario Suppose the system is configured with the following two non-exclusive rules: Rule E (priority 5, exclusive is false) – "High-value order dedicated line rule": Condition group: (Order amount > 1000) AND (Destination country = "US") Action group: [Logistics Channel Allocation("US_Premium")] Rule F (Priority 3, Exclusivity is false) – "US Standard Shipping Rule": Condition group: (Destination country = "US") Action group: [Logistics Channel Assignment("US_Standard")] When an order worth $1,500 arrives in the US, both Rule E and Rule F's conditions are true, and both rules are triggered simultaneously. Since both rules are non-exclusive, the conflict arbitration mechanism is activated.

[0101] Calculate the overall weight: Rule E's action priority weight ("allocate logistics" is medium priority, so we take 0.5) and rule priority weight (priority 5, take the reciprocal 1 / 5 = 0.2), the overall weight = 0.5 × 0.5 + 0.2 × 0.5 = 0.35. Rule F's action priority weight (also "allocate logistics", so we take 0.5) and rule priority weight (priority 3, take the reciprocal 1 / 3 ≈ 0.333), the overall weight = 0.5 × 0.5 + 0.333 × 0.5 ≈ 0.4165. Rule F has a higher overall weight, so the system selects Rule F as the final result and allocates the order to the "US_Standard" logistics channel.

[0102] Based on the dynamic matching and automated processing scheme for e-commerce ERP logistics rules provided by the present invention, the embodiments of the present invention also provide a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the steps of the above-mentioned dynamic matching and automated processing method for e-commerce ERP logistics rules.

[0103] This invention also provides a processor for running a program, wherein the program executes the steps of the above-described e-commerce ERP logistics rule dynamic matching and automated processing method during runtime.

[0104] This invention also provides a terminal device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. The program code is loaded and executed by the processor to implement the steps of the above-described method for dynamic matching and automated processing of e-commerce ERP logistics rules.

[0105] The present invention also provides a computer program product, which, when executed on a data processing device, is suitable for performing the steps of the above-described e-commerce ERP logistics rule dynamic matching and automated processing method.

[0106] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0107] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0108] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0109] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0110] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for dynamic matching and automated processing of logistics rules in an e-commerce ERP system, characterized in that, Includes the following steps: Rule definition steps: Construct a dynamic rule model based on logistics characteristics. The dynamic rule model includes a factor layer, an operator layer, and a strategy layer. The factor layer is used to define computational factors required for logistics decision-making. The operator layer is used to define set operation operators that perform logical judgments on the factors. The strategy layer is used to decouple the condition group and the action group. Data preprocessing steps: Obtain multi-source heterogeneous order data, perform standardization preprocessing on the multi-source heterogeneous order data, and generate standard order objects; Rule matching steps: Load the configured rule strategy into memory and precompile it; filter and match the rule strategy based on the attribute information of the standard order object; and output the matching rule strategy. Action execution steps: Based on the action group configured in the hit rule strategy, execute at least one of the following actions: logistics channel allocation, order interception, anomaly marking, or automatic order splitting.

2. The method according to claim 1, characterized in that, The computational factors defined in the factor layer include static factors and dynamic computational factors. The static factors include order weight, and the dynamic computational factors include billing weight factor and postal code partition factor. The billing weight factor is used to calculate the billing weight by taking the maximum value of the volumetric weight and physical weight of the order; the postal code partition factor is used to obtain the partition identifier by matching the postal code prefix of the recipient address with the logistics provider's partition table.

3. The method according to claim 1, characterized in that, The set operation operators defined in the operator layer include the inclusion operator and the intersection non-empty operator; the inclusion operator is used to determine whether the set of goods in the order is a subset of the specified set of goods; the intersection non-empty operator is used to determine whether the set of goods in the order has an intersection with the specified set of goods.

4. The method according to claim 1, characterized in that, In the strategy layer, the condition group adopts a logic tree structure configuration, which supports AND, OR, and NOT logical combinations between multiple conditions; the action group adopts a serial instruction set configuration, which supports the sequential execution of multiple actions in a predetermined order.

5. The method according to claim 1, characterized in that, The data preprocessing steps specifically include: Heterogeneous field mapping: Based on the pre-configured field mapping relationship, heterogeneous fields of order data from different e-commerce platforms are uniformly mapped to the internal fields of the standard order object; Unit normalization: Identify the units of measurement in the multi-source heterogeneous order data, and convert the different units of measurement into standard units of measurement according to the pre-configured conversion table; Address cleaning and completion: Perform regular expression matching on the recipient address, remove non-printable characters, and complete the full name of the country based on the country code and verify the postal code format; Feature pre-computation: Traverse the order line items, accumulate the product weights, and generate order-level attribute labels.

6. The method according to claim 1, characterized in that, The rule matching steps specifically include: Rule loading and pre-compilation: Load the enabled rule policies in the database into memory, construct an ordered linked list according to the priority attributes configured in the rule policies, and pre-compile the condition expressions in the rule policies into executable code; Index coarse screening: Based on the country and platform origin attributes of the standard order object, a subset of rules related to the standard order object is quickly located through a pre-built inverted index, and irrelevant rules are filtered out; Expression filtering: The standard order object is injected into the expression engine as a context, the rule subset is traversed, and the expression engine evaluates the condition group of each rule strategy. Short-circuit output: When the evaluation result of the condition group of any of the rule strategies is true, immediately stop the traversal of subsequent rule strategies and output the rule strategy as the hit result.

7. The method according to claim 6, characterized in that, The rule matching step also includes conflict arbitration: when multiple non-exclusive rule strategies are matched at the same time, the action groups of the multiple non-exclusive rule strategies are merged and executed according to a preset weighting algorithm, and the weighting algorithm calculates a comprehensive weight based on action priority and rule priority.

8. The method according to any one of claims 1 to 7, characterized in that, In the action execution steps, the execution action includes at least one of the following: logistics channel allocation action, order interception action, anomaly marking action, and automatic order splitting action; the logistics channel allocation action is used to allocate the order to a designated logistics channel; the order interception action is used to prevent the order from entering the subsequent logistics allocation process; the anomaly marking action is used to mark the order status as an abnormal status; and the automatic order splitting action is used to split the order into multiple sub-orders for separate processing.

9. A dynamic matching and automated processing system for logistics rules in an e-commerce ERP system, characterized in that, include: The rule definition module is configured to construct a dynamic rule model based on logistics characteristics, the dynamic rule model including a factor layer, an operator layer, and a strategy layer; The factor layer is used to define the computational factors required for logistics decision-making, the operator layer is used to define the set operation operators that perform logical judgments on the factors, and the strategy layer is used to decouple the condition group and the action group. The data preprocessing module is configured to acquire multi-source heterogeneous order data, perform standardized preprocessing on the multi-source heterogeneous order data, and generate standard order objects; The rule matching engine is configured to load the configured rule strategies into memory and pre-compile them, filter and match the rule strategies based on the attribute information of the standard order object, and output the matched rule strategies. The action execution module is configured to perform at least one of the following actions based on the action group configured in the hit rule strategy: logistics channel allocation, order interception, anomaly marking, or automatic order splitting.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 8.

Images