A logistic offer condition formula separation and declarative pipeline method and apparatus

Abstract

The application relates to the technical field of logistics quotation, in particular to a logistics quotation condition formula separation and declarative pipeline method and equipment, wherein the method comprises the following steps: constructing a quotation context, loading condition, formula, action separated effective rule objects, performing static verification on a declarative quotation stage list, sequentially executing each stage, completing rule determination and action execution in a rule processing stage, synchronously generating a full-link audit track, and outputting a quotation result. The application can realize decoupling of logistics quotation rules and codes, improve controllability of process arrangement and traceability of the quotation process, and reduce operation and maintenance costs.

Description

Technical Field

[0001] This application relates to the field of logistics pricing technology, and in particular to a method and device for separating logistics pricing condition formulas and declarative pipelines. Background Technology

[0002] The cross-border logistics quotation process needs to simultaneously handle various business rules and fee items, such as basic freight, billing re-adjustment, remote area surcharge, address surcharge, product surcharge, discounts, rejection judgment, transfer to manual review, last-mile delivery fee and explanatory items. It is the core calculation link in the logistics business system, and its configuration flexibility, execution stability and result traceability directly affect operational efficiency and customer experience.

[0003] The current mainstream implementation in the industry usually involves hard-coding the pricing rules into the business code, or distributing different types of rules across multiple data tables and independent processing functions; the execution order and branching logic of the entire pricing process are also fixed within the business functions, and the stage transition is achieved through the order of code calls.

[0004] This implementation method has three technical drawbacks: First, the rules and code are tightly coupled, and adding or adjusting rules requires modifying the code and redeploying, resulting in high iteration costs, opaque execution logic, and difficulty in testing and troubleshooting. Second, the rules have limited expressive power, with most only supporting simple conditions and fixed amounts, making it difficult to flexibly adapt to the complex cost calculation logic in logistics scenarios. Furthermore, different types of rules are modeled in a decentralized manner, leading to inconsistent auditing and debugging standards. Third, the quotation process is rigidly arranged, and adding execution stages or adjusting early termination logic can easily introduce regression defects, resulting in insufficient process scalability and controllability.

[0005] Therefore, based on the above problems, the existing technology still needs to be improved. Summary of the Invention

[0006] The purpose of this application is to provide a method and device for separating logistics quotation condition formulas and declarative pipelines, which aims to solve the technical problems of high coupling degree of logistics quotation rules, insufficient expressive ability, and rigid process arrangement that are prone to defects in the prior art.

[0007] The purpose of this application is to provide a method and equipment for separating logistics quotation conditions formulas and declarative pipelines, including: Receive a logistics quotation request, and construct a quotation context based on the logistics quotation request to carry the entire process request data, intermediate calculation results and process status markers; Load the valid rule object for the current pricing scenario. The valid rule object adopts a structure that separates conditions, formulas, and actions, and contains independently configured condition expressions, formula expressions, and rule actions. Obtain a pre-defined list of declarative pricing stages, wherein each pricing stage in the list pre-declares dependencies, field read / write ranges, and skip rules, and the list of declarative pricing stages includes a rule processing stage; perform pipeline static validation on the list of declarative pricing stages. After the pipeline static verification is passed, each pricing stage is executed sequentially according to the preset stage order. Before each pricing stage is executed, it is determined whether to skip it based on its own declared skip rules and the process status flag in the pricing context. If it is not skipped, the fields within the declared range in the pricing context are read to complete the stage calculation, and the stage execution result is written back to the pricing context. When the execution reaches the rule processing stage, the valid rule objects are traversed according to priority. First, the condition expression is evaluated based on the quotation context field to determine whether the rule is hit. If the rule is hit, the formula expression is executed according to the type of the rule action and the cost result is written to the quotation context, or the corresponding process status flag is written to the quotation context. During the execution process of each pricing stage and the execution process of each valid rule object in the rule processing stage, execution information and field change data of the pricing context are recorded synchronously to generate a full-link audit trail; Extract the final cost data and process status data accumulated after the entire process is executed from the quotation context, and output the logistics quotation result by combining the full-link audit trajectory.

[0008] By adopting the above technical solution, a unified, globally circulating quotation context is established as the sole data carrier. Original parameters of the quotation request, intermediate calculated values ​​at each stage, and process start / stop markers are stored uniformly. Each quotation stage and rule interacts only through this carrier, eliminating data coupling issues caused by the dispersed transmission of multiple variables and ensuring clear data flow logic throughout the entire process. Effective rule objects are split into a three-part structure with independent conditions, formulas, and actions. Each module can be independently configured and modified, allowing rule iteration without modifying the underlying code. This solves the problems of high coupling and long deployment cycles associated with hard-coded rules. The split structure allows for the expansion of diverse computational logic, adapting to complex logistics billing scenarios. A declarative quotation stage pipeline architecture is adopted, with external configurations for stage dependencies, read / write permissions, and skip rules. Before execution, static pipeline checks proactively intercept process errors such as circular dependencies and missing stages, mitigating the risk of online failures after adjustments to fixed processes. Each stage has built-in read / write boundaries and automatic skip logic, skipping redundant calculations when rejection or manual review markers are present, accelerating quotation response speed. By setting up a separate rule processing stage, all rules are executed uniformly according to priority, standardizing three types of business logic: cost calculation, process interruption, and information annotation. This reduces the maintenance burden caused by the decentralized development of multiple rule types. A complete two-level (generation stage and rule-level) end-to-end audit trail fully records data changes and calculation processes. In case of billing anomalies or pricing disputes, problems can be quickly traced and located, reducing after-sales and troubleshooting costs. This solution simultaneously addresses the shortcomings of existing technologies, such as rule coupling, weak expressive power, and rigid processes, improving the configurability and operational stability of the quotation system, and reducing R&D and operational maintenance costs.

[0009] In one possible implementation of this application, the conditional expression in the valid rule object is used to complete the rule hit judgment based on the field data in the quotation context, supporting logical combination operations, field comparison operations, string matching operations, and field existence judgments; the formula expression is used to complete the cost calculation based on the business fields in the quotation context, supporting amount boundary constraints and numerical normalization processing; the rule actions are divided into cost adjustment type, process control type, and information annotation type, corresponding to three types of execution behaviors: cost detail writing, process status mark update, and audit information annotation, respectively.

[0010] By adopting the above technical solution, and relying on a unified three-layer structure to standardize the modeling of all logistics business rules, the rich computing power can cover multi-dimensional address, cargo attribute determination, and various tiered billing, amount capping and minimum guarantee calculation needs. The three types of rule actions are fully adapted to all logistics quotation business scenarios such as price increase, discount, interception review, and remarks. There is no need to develop independent processing logic for each type of rule. The unified rule model reduces the maintenance costs of configuration, debugging and auditing.

[0011] In one possible implementation, this application further includes a rule compilation step before loading a valid rule object for the current pricing scenario: Compile readable conditional and formula text into structured conditional and formula expressions; Extract all fields belonging to the pricing context referenced in the conditional expression and the formula expression to generate a variable dependency set; Perform multi-dimensional compliance checks on the compiled structured rules, and once the checks pass, form a valid rule object that can be loaded in subsequent steps.

[0012] By adopting the above technical solution, the rule text that is readable by the operation side is transformed into a structured expression that can be parsed by the program. Field dependencies are extracted in advance and syntax and field permission compliance checks are completed. Syntax errors and illegal field references can be intercepted in advance during the rule configuration stage to avoid runtime errors. At the same time, the generated variable dependency set can be used for rule impact scope analysis, improving rule management and online operation stability.

[0013] In one possible implementation of this application, the pipeline static verification specifically includes: Verify that the identifier information of each pricing stage in the declarative pricing stage list is unique; Verify that all dependent pricing stages exist for the dependencies declared in each pricing stage; A stage dependency graph is constructed based on the dependencies declared at each pricing stage to detect and block circular dependencies.

[0014] By adopting the above technical solutions, multi-level process verification is completed before the pipeline is officially executed, logical defects such as stage duplication, missing dependencies, and circular dependencies are detected in advance, configuration errors can be found without running the quotation process, process execution anomalies are avoided from the source, and the reliability of declarative pipeline operation is improved.

[0015] In one possible implementation of this application, during the execution of each bidding stage, field data in the bidding context is read only within the field read / write scope declared by itself, and execution results are written to the bidding context only within the field read / write scope declared by itself; when the process status flag in the bidding context satisfies the skip rule declared by the current bidding stage, the calculation and execution process of the current bidding stage is skipped directly.

[0016] By adopting the above technical solution, the data access boundaries of each stage are divided by field read and write range constraints, reducing data interference between stages; at the same time, the automatic skipping of stages is realized by relying on process status markers, eliminating meaningless calculation logic, thereby reducing process coupling and improving the overall execution efficiency of quotation.

[0017] In one possible implementation of this application, the specific logic executed according to the type of rule action after a rule is matched is as follows: If the rule action is a fee adjustment type, then the formula expression is executed to calculate the corresponding fee result, and the fee result is written into the fee details of the quotation context; If the rule action is a process control type, then write the corresponding process status flag and trigger reason to the quotation context, and stop the execution of the subsequent quotation stage according to the stop processing flag carried by the valid rule object; If the rule action is an information annotation type, then the annotation information is written to the quotation context and is not included in the final cost data aggregation calculation.

[0018] By adopting the above technical solution, the rules for different business needs are divided into differentiated execution logics. A single rule model can uniformly handle three types of scenarios: cost increase / decrease, process interception, and remarks recording. There is no need to develop separate processing branches for each type of business, and the unified execution logic reduces the workload of system development and later maintenance.

[0019] In one possible implementation of this application, the end-to-end audit trajectory includes stage-level audit information and rule-level audit information; the stage-level audit information records the execution time, skipping reasons, abnormal information, and key field changes of the quotation context before and after execution for each quotation stage; the rule-level audit information records the condition judgment results, formula calculation process, action execution results, and hit reasons for each valid rule object in the rule processing stage.

[0020] By adopting the above technical solution, a two-level hierarchical audit record system is established to fully retain the stage operation status and individual rule calculation details of the entire quotation process. When the quotation result is abnormal, the entire calculation process can be traced back layer by layer, saving the cost of manual reproduction and calculation, and improving the efficiency of problem investigation and customer complaint verification.

[0021] The second objective of this application is to provide a logistics quotation condition formula separation and declarative pipeline system, which includes: Context building module: Used to receive logistics quotation requests and build a quotation context based on the logistics quotation requests to carry the entire process request data, intermediate calculation results and process status markers; Rule loading module: Used to load valid rule objects for the current pricing scenario. The valid rule objects adopt a structure that separates conditions, formulas, and actions, and contain independently configured condition expressions, formula expressions, and rule actions. Pipeline validation module: used to obtain a preset list of declarative pricing stages, each pricing stage in the list of declarative pricing stages predeclares dependencies, field read / write ranges and skip rules, and the list of declarative pricing stages includes a rule processing stage, and performs pipeline static validation on the list of declarative pricing stages; Phase execution module: After the pipeline static verification passes, it executes each quotation phase in a preset phase order. Before each quotation phase is executed, it determines whether to skip based on its own declared skip rules and the process status flag in the quotation context. If it does not skip, it reads the fields within the declared range in the quotation context to complete the phase calculation and writes the phase execution result back to the quotation context. Rule processing module: When the execution reaches the rule processing stage, it traverses the valid rule objects according to priority, first evaluates the condition expression based on the quotation context field to determine whether the rule is hit, and if the rule is hit, executes the formula expression according to the type of the rule action and writes the cost result into the quotation context, or writes the corresponding process status flag into the quotation context; Audit logging module: used to synchronously record execution information and field change data of the quotation context during the execution process of each quotation stage and during the execution of each valid rule object in the rule processing stage, and generate a full-link audit trail; The results output module is used to extract the final cost data and process status data accumulated after the entire process is executed from the quotation context, and output the logistics quotation result in combination with the full-link audit trajectory.

[0022] By adopting the above technical solution, a unified, globally circulating quotation context is established as the sole data carrier. Original parameters of the quotation request, intermediate calculated values ​​at each stage, and process start / stop markers are stored uniformly. Each quotation stage and rule interacts only through this carrier, eliminating data coupling issues caused by the dispersed transmission of multiple variables and ensuring clear data flow logic throughout the entire process. Effective rule objects are split into a three-part structure with independent conditions, formulas, and actions. Each module can be independently configured and modified, allowing rule iteration without modifying the underlying code. This solves the problems of high coupling and long deployment cycles associated with hard-coded rules. The split structure allows for the expansion of diverse computational logic, adapting to complex logistics billing scenarios. A declarative quotation stage pipeline architecture is adopted, with external configurations for stage dependencies, read / write permissions, and skip rules. Before execution, static pipeline checks proactively intercept process errors such as circular dependencies and missing stages, mitigating the risk of online failures after adjustments to fixed processes. Each stage has built-in read / write boundaries and automatic skip logic, skipping redundant calculations when rejection or manual review markers are present, accelerating quotation response speed. By setting up a separate rule processing stage, all rules are executed uniformly according to priority, standardizing three types of business logic: cost calculation, process interruption, and information annotation. This reduces the maintenance burden caused by the decentralized development of multiple rule types. A complete two-level (generation stage and rule-level) end-to-end audit trail fully records data changes and calculation processes. In case of billing anomalies or pricing disputes, problems can be quickly traced and located, reducing after-sales and troubleshooting costs. This solution simultaneously addresses the shortcomings of existing technologies, such as rule coupling, weak expressive power, and rigid processes, improving the configurability and operational stability of the quotation system, and reducing R&D and operational maintenance costs.

[0023] The third objective of this application is to provide a logistics quotation condition formula separation and declarative pipeline device, which includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed by the above-mentioned logistics quotation condition formula separation and declarative pipeline method.

[0024] The fourth objective of this application is to provide a storage medium.

[0025] The above-mentioned objective four of this application is achieved through the following technical solution: a storage medium, wherein a computer program is stored that can be loaded by a processor and executed by the above-mentioned logistics quotation condition formula separation and declarative pipeline method.

[0026] In summary, this application includes at least one of the following beneficial technical effects: 1. A unified global quotation context is established as the sole data carrier. Original parameters of the quotation request, intermediate calculated values ​​at each stage, and process start / stop markers are stored uniformly. Each quotation stage and rule interacts only through this carrier, eliminating data coupling issues caused by the dispersed transmission of multiple variables and ensuring clear data flow logic throughout the entire process. Effective rule objects are split into a three-part structure with independent conditions, formulas, and actions. Each module can be independently configured and modified, allowing rule iteration without modifying the underlying code. This solves the problems of high coupling and long deployment cycles associated with hard-coded rules. The split structure allows for the expansion of diverse computational logic, adapting to complex logistics billing scenarios. A declarative quotation stage pipeline architecture is adopted, with external configurations for stage dependencies, read / write permissions, and skip rules. Before execution, static pipeline checks proactively intercept process errors such as circular dependencies and missing stages, mitigating the risk of online failures after adjustments to fixed processes. Each stage has built-in read / write boundaries and automatic skip logic, skipping redundant calculations when rejection or manual review markers are present, accelerating quotation response speed. By setting up a separate rule processing stage, all rules are executed uniformly according to priority, standardizing three types of business logic: cost calculation, process interruption, and information annotation. This reduces the maintenance burden caused by the decentralized development of multiple rule types. A complete two-level (generation stage and rule-level) end-to-end audit trail fully records data changes and calculation processes. In case of billing anomalies or pricing disputes, problems can be quickly traced and located, reducing after-sales and troubleshooting costs. This solution simultaneously addresses the shortcomings of existing technologies, such as rule coupling, weak expressive power, and rigid processes, improving the configurability and operational stability of the quotation system, and reducing R&D and operational maintenance costs.

[0027] 2. Based on a unified three-layer structure, all logistics business rules are standardized and modeled. The rich computing power can cover multi-dimensional address, cargo attribute determination, and various tiered billing, amount capping and minimum guarantee calculation needs. The three types of rule actions are fully adapted to all logistics quotation business scenarios such as price increase, discount, interception review, and remarks. Various rules do not need to be developed separately with independent processing logic. The unified rule model reduces the maintenance costs of configuration, debugging and auditing. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a logistics quotation condition formula separation and declarative pipeline method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the virtual structure of a logistics quotation condition formula separation and declarative pipeline system provided in an embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0031] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0032] This application provides a method for separating logistics quotation condition formulas and declarative pipelines, referring to... Figure 1 The main process of the method is described as follows: S1: Receive a logistics quotation request and construct a quotation context based on the logistics quotation request to carry the entire process request data, intermediate calculation results and process status markers; The quotation context serves as the sole unified data storage carrier throughout the entire quotation process, acting as a global data sharing pool. It isolates the direct variable transfer between execution steps, allowing all stages and rules to read and write only the fields within this carrier. It uniformly aggregates three types of data: the user's original order request data, intermediate calculation results from each stage, and process status markers controlling the flow. All data read / write operations in the entire quotation process are performed around this carrier, avoiding data corruption and severe coupling issues caused by scattered parameter passing between multiple functions. For example, when the system receives a customer's logistics quotation request, requesting original business fields such as destination postal code, actual cargo weight, outer box dimensions, product category, shipping channel, and recipient country, the system automatically initializes a blank quotation context, writing all the aforementioned original request fields into the context to complete the initialization. Subsequent stage calculations and rule determinations can directly read the field data within the context.

[0033] S2: Load the valid rule object for the current pricing scenario. The valid rule object adopts a structure that separates conditions, formulas, and actions, and contains mutually independently configured condition expressions, formula expressions, and rule actions. The effective rule object is a standardized rule entity that has been compiled and verified for compliance and can be directly executed by the engine. It abandons the traditional approach of coupling judgment logic, calculation logic, and execution behavior into a single code block, instead splitting it into three independently editable and adjustable modules. Operations personnel can modify billing conditions, calculation formulas, and execution actions separately without requiring code modification and service restarts by the development team, thus adapting to the high-frequency rule updates required by logistics operations. For example, regarding the remote address surcharge rule for European and American channels, operations personnel can separately configure conditional expressions to determine the recipient's postal code range, separately configure formula expressions to set tiered pricing standards, and separately configure fee adjustment rule actions. These three elements combine to form a complete effective rule object. The system then filters and matches all rules corresponding to the scenario based on the current quoted shipping channel and destination country, loading them uniformly into memory for subsequent calls.

[0034] S3: Obtain a preset list of declarative pricing stages. Each pricing stage in the list predeclares dependencies, field read / write ranges, and skip rules. The list of declarative pricing stages also includes a rule processing stage. Perform pipeline static validation on the list of declarative pricing stages. The declarative pricing stage list breaks down the complete pricing process into multiple configurable, independent execution units. All preconditions, data access permissions, and dependencies for each stage are externally configured, not embedded in the code. Static pipeline validation is performed before the process officially runs, proactively identifying configuration defects and preventing issues like process freezes and data read errors during runtime. The rule processing stage serves as a dedicated unit for uniformly executing all billing rules, centrally aggregating all rule calculation logic. For example, the preset pricing stage list includes multiple stages: request normalization, billing recalculation, partition matching, rule processing, and result aggregation. Each stage pre-marks its dependent preconditions, readable and writable fields, and trigger skip states. The system performs static validation to verify that all stage IDs are unique, all dependent stages exist, and there are no circular dependencies. Only after successful validation is the stage execution process allowed to proceed.

[0035] S4: After the pipeline static verification is passed, each quotation stage is executed sequentially according to the preset stage order. Before each quotation stage is executed, it is determined whether to skip it based on its own declared skip rules and the process status flag in the quotation context. If it is not skipped, the fields within the declared range in the quotation context are read to complete the stage calculation, and the stage execution result is written back to the quotation context. Each pricing stage strictly follows a sequential execution logic. Before execution, it reads the generated process status flags within the context and matches them against its own preset skip rules. If the conditions are met, it skips all calculations in this stage, reducing invalid computations. Simultaneously, each stage can only operate on fields within its declared read / write scope and cannot overstep its authority to read or modify data specific to other stages, thus isolating data interference between stages. For example, when a "goods prohibited from shipment and rejected" status flag exists in the context, subsequent billing stages such as billing recalculation and partition matching match their own skip rules and skip directly. If no skip is triggered, the billing recalculation stage only reads the length, width, height, and actual weight fields within the context, calculates the volumetric weight and billing weight, and only writes the calculation results to the billing weight field within the context, without modifying other business data.

[0036] S5: When the execution reaches the rule processing stage, the valid rule objects are traversed according to priority. First, the condition expression is evaluated based on the quotation context field to determine whether the rule is hit. If the rule is hit, the formula expression is executed according to the type of the rule action and the cost result is written to the quotation context, or the corresponding process status flag is written to the quotation context. The rule processing stage is a dedicated stage that uniformly handles all business rule calculations. It iterates through all valid rule objects one by one according to the pre-set operational priority. First, it parses the conditional expressions and matches them with context fields to determine if a match has occurred. Upon a match, it differentiates between three types of rule actions and executes differentiated logic, uniformly completing cost calculation, process control, and information labeling functions. For example, in the rule processing stage, the system iterates through surcharge, discount, and interception rules in order of priority. For the oversized item interception rule, if the conditional expression determines that the longest side of the item is greater than 1.2 meters, a match is found, and a process control action is executed, writing a "transfer to manual review" status flag to the context. For the remote area surcharge rule, after a successful conditional match, the formula is executed to calculate the surcharge, and the cost details are written to the quotation context.

[0037] S6: During the execution process of each pricing stage and the execution process of each valid rule object in the rule processing stage, synchronously record the execution information and the field change data of the pricing context to generate a full-link audit trail; The system collects operational data in real time at each stage of the bidding process, including the start and end points, as well as at each rule determination and calculation completion point. It synchronously records the stage's operational status, rule calculation details, and changes in context fields, integrating these data to form a complete and tamper-proof audit trail that fully reconstructs the entire bidding calculation process. For example, the system records the execution time of each stage, whether a skip was triggered, billing overlap before and after execution, destination partitioning, and other key field values. For each rule, it records the judgment results of each condition, the step-by-step calculation values ​​of the formula, and the final execution action. All records are uniformly integrated into a complete audit trail for that bidding process.

[0038] S7: Extract the final cost data and process status data accumulated after the entire process is executed from the quotation context, and output the logistics quotation result in combination with the full-link audit trajectory.

[0039] After all stages and rule-based calculations, the quotation context has collected complete result data, including all cost details, total amount, and process control markers. The standardized data accumulated within the context is directly extracted and output along with the audit trail. The quotation result not only includes the price value but also comes with complete calculation traceability documentation. For example, the system extracts basic freight, various surcharges, and discount amounts from the context to obtain the final total price. It also extracts process status markers such as "transferred to manual processing" and "rejection," returning the total price, status information, and complete audit trail to the front end. Customers or operations personnel can view the calculation source of each cost at any time.

[0040] Specifically, in some possible embodiments, in the effective rule object, the conditional expression is used to complete the rule hit judgment based on the field data in the quotation context, supporting logical combination operations, field comparison operations, string matching operations, and field existence judgments; the formula expression is used to complete the cost calculation based on the business fields in the quotation context, supporting amount boundary constraints and numerical normalization processing; the rule actions are divided into cost adjustment type, process control type, and information annotation type, corresponding to three types of execution behaviors: cost detail writing, process status mark update, and audit information annotation, respectively.

[0041] Traditional logistics pricing rules often employ fixed judgment logic and single-amount assignment, failing to simultaneously implement multi-condition overlay judgments, character-matched billing, and capped / minimum amount processing. Different functional types of rules require separate development of independent processing code, resulting in high system maintenance costs. This embodiment breaks down rules into three independent modules: conditions, formulas, and actions. Conditional expressions cover multi-dimensional logical judgment requirements, formula expressions adapt to various tiered and capped / minimum amount billing scenarios, and the three types of rule actions fully cover all logistics business scenarios, including surcharges, discounts, interception audits, and business remarks. For example, in the Southeast Asia channel remote area surcharge rule, the conditional expression uses logical combination operations to simultaneously match the recipient country, postal code prefix, and cargo weight; the formula expression calculates the surcharge based on weight tiers and sets a minimum charge amount; and the rule action is a fee adjustment type, automatically writing the calculated fee into the fee details of the pricing context.

[0042] Specifically, in some possible embodiments, a rule compilation step is included before loading the valid rule object for the current pricing scenario: Compile readable conditional and formula text into structured conditional and formula expressions; Extract all fields belonging to the pricing context referenced in the conditional expression and the formula expression to generate a variable dependency set; Perform multi-dimensional compliance checks on the compiled structured rules, and once the checks pass, form a valid rule object that can be loaded in subsequent steps.

[0043] Traditional solutions directly parse plain text rules entered from the front end, only exposing syntax errors and illegal field references at runtime. This easily leads to online quotation failures and cannot quickly identify which business fields a single rule modifies or reads. This embodiment adds a compilation process before rule loading, converting the natural language rule text easily readable by operations personnel into structured expressions that the engine can parse. It simultaneously captures all context fields referenced by the rule to generate a dependency set, and then uniformly performs compliance checks on syntax, field permissions, and numerical ranges, proactively intercepting various configuration defects. After successful verification, a stable and executable valid rule object is generated. For example, if operations personnel enter the rule text "Destination country = USA and billable weight > 30kg, surcharge = billable weight * 5, minimum 100 yuan", the compilation phase first parses and generates structured judgment logic and calculation formulas, extracts the dependency fields destination country and billable weight, and after verifying the existence of fields and the syntax of the formulas, outputs a valid rule object that can be directly loaded and run.

[0044] Specifically, in some possible embodiments, the pipeline static verification specifically includes: Verify that the identifier information of each pricing stage in the declarative pricing stage list is unique; Verify that all dependent pricing stages exist for the dependencies declared in each pricing stage; A stage dependency graph is constructed based on the dependencies declared at each pricing stage to detect and block circular dependencies.

[0045] Traditional hard-coded processes lack pre-verification mechanisms. Adding or modifying a pricing stage can easily lead to hidden faults such as duplicate stage IDs, missing prerequisite stages, and infinite loops caused by inter-stage dependencies. These problems are only discovered when a real pricing request is initiated, directly impacting the normal operation of online pricing services. This embodiment performs three layers of static verification before pipeline startup. First, it ensures that all pricing stage identifiers are unique to avoid execution conflicts. Second, it verifies the existence of prerequisite stages that each stage depends on. Finally, it generates a complete directed graph based on dependency relationships to accurately identify circular dependency configurations. All non-compliant configurations can be directly intercepted during the configuration saving stage, without needing to reproduce the fault through a real pricing request. For example, if an operator adds a "terminal surcharge calculation stage" and declares a dependency on the "billing recalculation stage," the system verifies that the billing recalculation stage exists and has no circular references, and that the stage identifier does not duplicate existing stages; the pipeline static verification passes. However, if a circular relationship exists where stage A depends on stage B, and stage B depends on stage A, the verification process will directly throw an exception and block the pipeline saving.

[0046] Specifically, in some possible embodiments, during the execution of each pricing stage, field data in the pricing context is read only within the field read / write scope declared by itself, and execution results are written to the pricing context only within the field read / write scope declared by itself; when the process status flag in the pricing context meets the skip rule declared by the current pricing stage, the calculation and execution process of the current pricing stage is skipped directly.

[0047] In traditional pricing processes, each execution unit can read and write all business data without restriction. The boundaries of data operations between stages are blurred, and a modification to a single field can have uncontrollable effects on the entire process. Furthermore, there is no automatic skip mechanism; even if goods are deemed unacceptable or the shipping channel is deemed unsuitable, the system will still execute all billing logic, generating a large amount of invalid calculations and slowing down pricing response speed. This embodiment defines a dedicated field read / write range for each pricing stage, strictly limiting stages to operating only authorized fields, isolating data operation behaviors at each stage, and reducing process coupling. Simultaneously, it relies on process status markers within the pricing context to match preset skip rules for each stage. When the conditions are met, the current stage's calculation is directly terminated, reducing computational power consumption and improving pricing processing efficiency. For example, when the pricing context writes the "prohibited goods rejected" process status marker, the basic freight calculation stage matches its own configured skip rules, directly skipping calculation steps such as weight conversion and zoned pricing. The chargeable weight conversion stage only allows reading the length, width, and height of the goods and the actual weight fields, and can only write the chargeable weight and volumetric weight fields, unable to modify other business fields such as destination and shipping channel.

[0048] Specifically, in some possible embodiments, the specific logic executed after a rule is matched, based on the type of the rule action, is as follows: If the rule action is a fee adjustment type, then the formula expression is executed to calculate the corresponding fee result, and the fee result is written into the fee details of the quotation context; If the rule action is a process control type, then write the corresponding process status flag and trigger reason to the quotation context, and stop the execution of the subsequent quotation stage according to the stop processing flag carried by the valid rule object; If the rule action is an information annotation type, then the annotation information is written to the quotation context and is not included in the final cost data aggregation calculation.

[0049] Traditional solutions involve writing separate branches for three types of business rules: fee increases / decreases, process interception, and remarks / annotations. This results in fragmented code logic, difficulty in unified management, and the need to modify multiple execution logics simultaneously when adding new business rules, leading to low iteration efficiency. This embodiment divides rule actions into three standardized processing logics. A single rule engine can uniformly handle all logistics pricing business scenarios, eliminating the need to develop separate execution branches for different business types. For example, the long cargo interception rule matches process control actions, adds a manual review flag upon successful matching, and terminates the subsequent billing stage; the multi-item discount rule matches fee adjustment actions, calculates the discount amount, and writes it into the fee details; the battery product notification rule matches information annotation actions, retaining only remarks and not participating in the total price calculation.

[0050] Specifically, in some possible embodiments, the end-to-end audit trajectory includes stage-level audit information and rule-level audit information; the stage-level audit information records the execution time, skipping reasons, abnormal information, and key field changes of the quotation context before and after execution for each quotation stage; the rule-level audit information records the condition judgment results, formula calculation process, action execution results, and hit reasons for each valid rule object in the rule processing stage.

[0051] Traditional pricing systems only output the final total price, leaving the entire calculation process a black box. When price disputes or billing anomalies occur, operations personnel must meticulously check all business configurations, including channels, surcharges, and discounts, and reproduce the entire calculation process to pinpoint the problem. This process is time-consuming for after-sales verification and troubleshooting. This embodiment employs a two-tiered audit logging mechanism, retaining both the overall operational log for the pricing phase and detailed calculation logs for individual rules. It comprehensively records every step of context field changes, judgment processes, and execution results. When customer complaints or billing discrepancies arise, the audit trail can be used to trace the source layer by layer, significantly reducing manual verification and location costs. For example, when a customer reports an error in the calculation of the remote area surcharge, rule-level audit information can be retrieved to view the matching fields of the corresponding surcharge rule, the step-by-step calculation values ​​of the formula, and the final amount written into the details. Simultaneously, by combining this with stage-level audit to view the pre-calculation results such as weight and destination, the point at which the billing discrepancy occurred can be quickly identified.

[0052] Another embodiment of this application provides a logistics quotation condition formula separation and declarative pipeline system, wherein, see reference Figure 2 A logistics pricing condition formula separation and declarative pipeline system, comprising: Context building module 100: Used to receive logistics quotation requests and build a quotation context based on the logistics quotation requests to carry the full-process request data, intermediate calculation results and process status markers; Rule loading module 200: Used to load valid rule objects under the current quotation scenario. The valid rule objects adopt a structure that separates conditions, formulas, and actions, and contain mutually independently configured condition expressions, formula expressions, and rule actions. Pipeline verification module 300: used to obtain a preset list of declarative quotation stages, wherein each quotation stage in the list of declarative quotation stages predeclares dependencies, field read / write ranges and skip rules, and the list of declarative quotation stages includes a rule processing stage, and performs pipeline static verification on the list of declarative quotation stages; Phase execution module 400: After the pipeline static verification passes, it executes each quotation phase in a preset phase order. Before each quotation phase is executed, it determines whether to skip based on its own declared skip rules and the process status flag in the quotation context. If it does not skip, it reads the fields within the declared range in the quotation context to complete the phase calculation and writes the phase execution result back to the quotation context. Rule processing module 500: When the execution reaches the rule processing stage, it traverses the valid rule objects according to priority, first evaluates the condition expression based on the quotation context field to determine whether the rule is hit, and if the rule is hit, executes the formula expression according to the type of the rule action and writes the cost result into the quotation context, or writes the corresponding process status flag into the quotation context; Audit logging module 600: used to synchronously record execution information and field change data of the quotation context during the execution process of each quotation stage and during the execution process of each valid rule object in the rule processing stage, and generate a full-link audit trail; Result output module 700: used to extract the final cost data and process status data accumulated after the entire process is executed from the quotation context, and output the logistics quotation result in combination with the full-link audit trajectory.

[0053] This embodiment provides a logistics quotation condition formula separation and declarative pipeline system. Due to the functions of each module and the logical connections between them, it can realize the steps of the aforementioned embodiments. Therefore, it can achieve the same technical effect as the aforementioned embodiments. For the principle analysis, please refer to the relevant description of the steps of the aforementioned logistics quotation condition formula separation and declarative pipeline method, which will not be repeated here.

[0054] This application embodiment also provides a logistics quotation condition formula separation and declarative pipeline device, including a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described above for a logistics quotation condition formula separation and declarative pipeline method.

[0055] This application embodiment also provides a storage medium storing a computer program capable of being loaded by a processor and executing the above-described logistics quotation condition formula separation and declarative pipeline method.

[0056] The storage medium provided in this embodiment can achieve the same technical effect as the aforementioned embodiments because the computer program therein, after being loaded and run on the processor, will implement the various steps of the aforementioned embodiments. For the principle analysis, please refer to the relevant description of the aforementioned method steps, which will not be repeated here.

[0057] The storage medium includes, for example, various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0058] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0059] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0060] Furthermore, features defined by the terms "first" and "second" may explicitly or implicitly include at least one of those features. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., and unless otherwise explicitly specified, is used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0061] Therefore, any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0062] The embodiments described in this specific implementation are preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for separating logistics quotation condition formulas and a declarative pipeline, characterized in that, include: Receive a logistics quotation request, and construct a quotation context based on the logistics quotation request to carry the entire process request data, intermediate calculation results and process status markers; Load the valid rule object for the current pricing scenario. The valid rule object adopts a structure that separates conditions, formulas, and actions, and contains independently configured condition expressions, formula expressions, and rule actions. Obtain a pre-defined list of declarative pricing stages, wherein each pricing stage in the list pre-declares dependencies, field read / write ranges, and skip rules, and the list of declarative pricing stages includes a rule processing stage; perform pipeline static validation on the list of declarative pricing stages. After the pipeline static verification is passed, each pricing stage is executed sequentially according to the preset stage order. Before each pricing stage is executed, it is determined whether to skip it based on its own declared skip rules and the process status flag in the pricing context. If it is not skipped, the fields within the declared range in the pricing context are read to complete the stage calculation, and the stage execution result is written back to the pricing context. When the execution reaches the rule processing stage, the valid rule objects are traversed according to priority. First, the condition expression is evaluated based on the quotation context field to determine whether the rule is hit. If the rule is hit, the formula expression is executed according to the type of the rule action and the cost result is written to the quotation context, or the corresponding process status flag is written to the quotation context. During the execution process of each pricing stage and the execution process of each valid rule object in the rule processing stage, execution information and field change data of the pricing context are recorded synchronously to generate a full-link audit trail; Extract the final cost data and process status data accumulated after the entire process is executed from the quotation context, and output the logistics quotation result by combining the full-link audit trajectory.

2. The logistics quotation rule engine and declarative pipeline execution method with conditional formula separation as described in claim 1, characterized in that, In the valid rule object, the conditional expression is used to complete the rule hit judgment based on the field data in the quotation context, and supports logical combination operation, field comparison operation, string matching operation and field existence judgment; the formula expression is used to complete the cost calculation based on the business fields in the quotation context, and supports amount boundary constraints and numerical normalization processing; the rule actions are divided into cost adjustment type, process control type and information annotation type, which correspond to three types of execution behaviors: cost detail writing, process status mark update and audit information annotation, respectively.

3. The logistics quotation rule engine and declarative pipeline execution method with conditional formula separation as described in claim 1, characterized in that, Before loading the valid rule object for the current pricing scenario, a rule compilation step is also included: Compile readable conditional and formula text into structured conditional and formula expressions; Extract all fields belonging to the pricing context referenced in the conditional expression and the formula expression to generate a variable dependency set; Perform multi-dimensional compliance checks on the compiled structured rules, and once the checks pass, form a valid rule object that can be loaded in subsequent steps.

4. The logistics quotation rule engine and declarative pipeline execution method with conditional formula separation as described in claim 1, characterized in that, The static pipeline verification specifically includes: Verify that the identifier information of each pricing stage in the declarative pricing stage list is unique; Verify that all dependent pricing stages exist for the dependencies declared in each pricing stage; A stage dependency graph is constructed based on the dependencies declared at each pricing stage to detect and block circular dependencies.

5. The logistics quotation rule engine and declarative pipeline execution method with conditional formula separation as described in claim 1, characterized in that, During the execution of each pricing stage, field data in the pricing context is read only within the field read / write scope declared by itself, and execution results are written to the pricing context only within the field read / write scope declared by itself; when the process status flag in the pricing context meets the skip rule declared for the current pricing stage, the calculation and execution process of the current pricing stage is skipped directly.

6. The logistics quotation rule engine and declarative pipeline execution method with conditional formula separation as described in claim 1, characterized in that, Once a rule is matched, the specific logic executed according to the type of the rule action is as follows: If the rule action is a fee adjustment type, then the formula expression is executed to calculate the corresponding fee result, and the fee result is written into the fee details of the quotation context; If the rule action is a process control type, then write the corresponding process status flag and trigger reason to the quotation context, and stop the execution of the subsequent quotation stage according to the stop processing flag carried by the valid rule object; If the rule action is an information annotation type, then the annotation information is written to the quotation context and is not included in the final cost data aggregation calculation.

7. The logistics quotation rule engine and declarative pipeline execution method with conditional formula separation as described in claim 1, characterized in that, The full-link audit trail includes stage-level audit information and rule-level audit information; the stage-level audit information records the execution time, skipping reasons, abnormal information, and key field changes in the bidding context before and after execution for each bidding stage; the rule-level audit information records the condition judgment results, formula calculation process, action execution results, and hit reasons for each valid rule object in the rule processing stage.

8. A logistics quotation condition formula separation and declarative pipeline system, characterized in that, include: Context building module: Used to receive logistics quotation requests and build a quotation context based on the logistics quotation requests to carry the entire process request data, intermediate calculation results and process status markers; Rule loading module: Used to load valid rule objects for the current pricing scenario. The valid rule objects adopt a structure that separates conditions, formulas, and actions, and contain independently configured condition expressions, formula expressions, and rule actions. Pipeline validation module: used to obtain a preset list of declarative pricing stages, each pricing stage in the list of declarative pricing stages predeclares dependencies, field read / write ranges and skip rules, and the list of declarative pricing stages includes a rule processing stage, and performs pipeline static validation on the list of declarative pricing stages; Phase execution module: After the pipeline static verification passes, it executes each quotation phase in a preset phase order. Before each quotation phase is executed, it determines whether to skip based on its own declared skip rules and the process status flag in the quotation context. If it does not skip, it reads the fields within the declared range in the quotation context to complete the phase calculation and writes the phase execution result back to the quotation context. Rule processing module: When the execution reaches the rule processing stage, it traverses the valid rule objects according to priority, first evaluates the condition expression based on the quotation context field to determine whether the rule is hit, and if the rule is hit, executes the formula expression according to the type of the rule action and writes the cost result into the quotation context, or writes the corresponding process status flag into the quotation context; Audit logging module: used to synchronously record execution information and field change data of the quotation context during the execution process of each quotation stage and during the execution of each valid rule object in the rule processing stage, and generate a full-link audit trail; The results output module is used to extract the final cost data and process status data accumulated after the entire process is executed from the quotation context, and output the logistics quotation result in combination with the full-link audit trajectory.

9. A logistics quotation condition formula separation and declarative pipeline equipment, characterized in that, include: A memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any one of claims 1-7, a method for separating and declaratively pipelined logistics pricing conditions.

10. A storage medium, characterized in that, The computer program is stored and can be loaded by a processor and executed as described in any one of claims 1-7, which is a method for separating logistics pricing condition formulas and declarative pipelines.

Images