Tourist route distribution commission calculation method, system and device and medium

Abstract

A calculation method, system, medium and device of tourist route distribution commission relate to the technical field of data processing, and the method comprises the following steps: in response to a calculation request of the tourist route distribution commission, obtaining distributor information, tourist route information and sales data corresponding to the calculation request; constructing a rule engine for commission calculation; calling and executing a commission calculation rule based on the rule engine; and determining a commission result corresponding to each piece of sales data, the commission result including a commission amount, and returning each commission result to each distributor. Through adoption of the scheme, tourist route distribution commission business rules are classified and defined, and a core framework of a rule system is clarified; a rule data model is constructed, and data support is provided for efficient execution of a rule engine; the defined business rules are managed and maintained, so that the accuracy and timeliness of the rules are guaranteed, and the rule engine is ensured to have stable computing power and good maintainability.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a method, system, device and medium for calculating a tourism route distribution commission. BACKGROUND

[0002] In the tourism route distribution business scenario of a tourism Internet system, the commission calculation link needs to rely on complex business rules to carry out operations. Such business rules are frequently changed due to the influence of multi-dimensional factors, including the differences of tourism routes, the differences of distributor levels, and the development of promotion activities. The traditional commission calculation mode has been difficult to adapt to the above-mentioned dynamic changes in business requirements.

[0003] In the prior art, the commission calculation of the tourism route distribution business is realized by using a hard coding mode, that is, by directly writing the commission calculation rules into the system program code, so that the rules are tightly coupled with the code, and the hard-coded rule logic is directly called during system operation to complete the commission calculation.

[0004] However, since the commission calculation rules are embedded in the code by hard coding, even a small adjustment of the rules requires a full-process operation of developing and modifying the code, which cannot quickly respond to the immediate change requirements of the business rules, resulting in high rule iteration cost and low efficiency. Moreover, when the number of commission calculation rules stored in the system is large, the rule logic is completely hidden in the code, and business analysts cannot directly view and understand the rule content. If a business analyst proposes a rule change requirement, he or she cannot independently complete the rule adjustment and must rely on the intervention of the developer to modify the code, which increases the cross-role collaboration cost and is prone to rule implementation errors due to communication bias. SUMMARY

[0005] The present application provides a method, system, device and medium for calculating a tourism route distribution commission, to solve the problem of high iteration, understanding and collaboration cost in the prior art.

[0006] In a first aspect, the present application provides a method for calculating a tourism route distribution commission, the method comprising: In response to a calculation request for a tourism route distribution commission, obtaining distributor information, tourism route information and sales data corresponding to the calculation request; constructing a rule engine for commission calculation; based on the rule engine, calling and executing the commission calculation rules; determining the commission results corresponding to each sales data, the commission results including the commission amount, and returning each commission result to each distributor.

[0007] By adopting the technical scheme, the commission calculation request initiated by the distributor is quickly responded, the distributor information, the travel route information and the sales data corresponding to the request are accurately obtained, the commission calculation rules are called and executed based on the rule engine, the commission results containing the commission amounts corresponding to the sales data are determined and returned to the distributor, the problem of high iteration cost and inflexible response to business changes caused by the close coupling of the commission calculation rules and the code in the prior art is effectively solved, the efficiency and accuracy of the commission calculation are significantly improved, and the standardization and scalability of the commission calculation process are guaranteed.

[0008] In a specific implementable scheme, the construction of the rule engine includes: classifying and defining the business rules of the travel route distribution commission; constructing a rule data model; managing and maintaining the defined business rules.

[0009] By adopting the technical scheme, the business rules of the travel route distribution commission are classified and defined, the core framework of the rule system is clarified, the rule data model is constructed to provide data support for efficient execution of the rule engine, the management and maintenance of the defined business rules are performed to guarantee the accuracy and timeliness of the rules and avoid the confusion caused by the lack of system in the construction of the rule engine in the prior art, and the rule engine has stable calculation capability and good maintainability, thereby laying a foundation for flexible iteration of subsequent commission calculation rules.

[0010] In a specific implementable scheme, the business rules of the travel route distribution commission are classified and defined, including: collecting the commission rule requirements in combination with the distributor level, the travel route type, the sales region and the sales season, classifying the business rules according to the grouping logic and setting unique identifiers and descriptions; defining branch conditions, basic calculation rules and customized calculation rules for each type of rule.

[0011] By adopting the technical scheme, the commission rule requirements are accurately collected around the multi-dimensional scenarios of the travel route distribution business, the business rules are sorted into an ordered system according to the grouping logic and are given unique identifiers and descriptions, the rules are quickly positioned and managed, the branch conditions, the basic calculation rules and the customized calculation rules of each type of rule are clarified, the rules can accurately adapt to different business scenarios and have no logic conflicts, the problems of business rule confusion, poor scene adaptability and easy rule conflicts in the prior art are solved, and the adaptability and flexibility of the rules to business changes are significantly improved.

[0012] In a specific implementable scheme, the defined business rules are managed and maintained, including: establishing a visual rule management mechanism and a rule review mechanism; Establish a rule storage structure and implement rule version control; The rules were tested, verified, and optimized using both simulated and actual sales data.

[0013] By adopting the above technical solutions, a visual rule management mechanism is established to lower the operational threshold for business personnel, and a rule review mechanism is used to ensure the accuracy of rule configuration. The rule storage structure and version control function ensure that rule data is stored securely and historical changes are traceable, avoiding rule loss or tampering. Through dual testing and verification with simulated data and actual sales data, rule logic deviations can be identified and optimized in a timely manner, solving the problems of rule management relying on developers, version confusion, and difficulty in ensuring accuracy in existing technologies. This significantly reduces rule maintenance costs and improves rule maintenance efficiency and reliability.

[0014] In a specific feasible implementation, the rule data model includes: Data objects include distributor information, tour route information, and sales data; The rule logic structure includes conditional branching logic, execution logic, and the smallest unit within the rule; The result includes the commission amount, the basis for commission calculation, and the applicable rule number for the commission.

[0015] By adopting the above technical solution, the data objects include distributor information, travel route information, and sales data, ensuring that the rule engine can efficiently obtain complete business data during calculation; the rule logic structure clearly defines the logical path of rule execution, supporting accurate calculation of rules with varying complexity; the result object records the commission amount, calculation basis, and applicable rule number, enabling traceability of commission calculation results, solving the problems of data dispersion, ambiguous rule execution logic, and untraceable results in existing technologies, and providing core support for the accuracy and auditability of commission calculation.

[0016] In a specific feasible implementation, based on the rules engine, commission calculation rules are invoked and executed, including: Based on distributor information, tour route information, and sales data, determine the corresponding rule type and load the rule configuration file for that rule type; The calculation request is validated, and an algorithm matching the rule configuration file is obtained from the preset algorithm library. The commission is calculated based on the algorithm and sales data.

[0017] By adopting the above technical solution, the appropriate rule type is accurately located based on business data, and the latest valid rule configuration file of the target type is loaded to ensure that the rule used for calculation is the currently effective version. By verifying the legality of calculation requests, illegal data or incomplete requests are filtered out to avoid invalid calculations. Algorithms that are compatible with the rule configuration file are matched from the preset algorithm library, and commission calculation is completed in combination with sales data. This ensures that the calculation logic is highly consistent with the rule requirements, solves the calculation error problems caused by blind rule calls, missing request verification, and mismatch between algorithms and rules in existing technologies, and significantly improves the accuracy and reliability of commission calculation.

[0018] In one specific feasible implementation, it includes: Generate multi-dimensional business reports based on commission results; The commission results are analyzed, and the results are used to adjust the travel route distribution business. Establish an auditing mechanism to monitor and record the application of commission results.

[0019] By adopting the above technical solutions, multi-dimensional business reports generated based on commission results provide intuitive operational data support for business managers; in-depth analysis of commission results can uncover business patterns and provide a basis for adjusting strategies in the tourism route distribution business; the established audit mechanism can monitor the application of commission results in real time, promptly detect and handle data anomalies or business violations, and solve the problems of existing technologies where commission results are only used for settlement, cannot be used to support business operations, and lack monitoring in the application process, thereby maximizing the value of commission results and ensuring the compliance and sustainable optimization of the tourism route distribution business.

[0020] A second aspect of this application provides a system for calculating commissions for the distribution of travel routes, the system comprising: The request processing module is used to respond to the calculation request for travel route distribution commission and obtain the distributor information, travel route information and sales data corresponding to the calculation request. The rules module is used to build a rules engine for commission calculation, classify and define business rules for travel route distribution commissions, build rule data models, and manage and maintain the defined business rules. The execution module is used to call and execute commission calculation rules based on the rule engine. It determines the corresponding rule type and loads the rule configuration file according to distributor information, travel route information and sales data. It also verifies the calculation request and matches the algorithm to calculate the commission. The output module is used to determine the commission results corresponding to each sales data point and return the commission results to each distributor.

[0021] A third aspect of this application provides an electronic device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0022] A fourth aspect of this application provides a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps described above.

[0023] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. This application enables flexible configuration and efficient iteration of commission calculation rules. By building a rule engine for commission calculation, it classifies and defines the rules for tourism route distribution commission business, constructs and manages the rule data model, and maintains them. Business personnel can independently complete the configuration, update and verification of rules without the need for developers to modify the code. This effectively solves the problems of high iteration costs and slow response to business changes caused by the tight coupling between commission calculation rules and code in existing technologies, and greatly improves the efficiency of rule iteration and the speed of business adaptation.

[0024] 2. This application significantly reduces the maintenance cost of commission calculation rules. By separating the commission calculation rules from the system code, when the rules need to be changed due to the business scenario of tourism route distribution, only the rule configuration file needs to be modified. There is no need to perform the entire process of development, testing, and deployment. This avoids the problems of cumbersome and costly maintenance operations under the traditional hard-coding method and reduces the investment of maintenance manpower and time.

[0025] 3. This application enhances the system's adaptability and scalability to changes in the tourism route distribution business. The rule engine supports multiple rule recording methods and multi-dimensional business scenario adaptation. The rule data model can comprehensively carry distributor information, tourism route information, and sales data, and supports dynamic loading and hot updating of rules. It can quickly adapt to business dynamics such as differences in tourism routes, changes in distributor levels, and the implementation of promotional activities, ensuring that the system can continue to operate stably without large-scale reconstruction when the business scale expands or the scenario changes, and has strong flexibility and scalability. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of a method for calculating commission for the distribution of travel routes provided in an embodiment of this application; Figure 2 This is a schematic diagram of a rule engine module provided in an embodiment of this application; Figure 3 This is a schematic diagram of a tourism route distribution commission calculation system module provided in an embodiment of this application. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0028] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0029] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0030] Please refer to Figure 1 This paper presents a flowchart illustrating a method for calculating commissions for tourism route distribution. This method can be implemented using a computer program, a microcontroller, or a tourism route distribution commission calculation system. The computer program can be integrated into a computer device or run as a standalone application. Specifically, the method includes steps S100 to S400, as follows: S100. In response to the calculation request for the travel route distribution commission, obtain the distributor information, travel route information and sales data corresponding to the calculation request; In this embodiment of the application, the request for calculating the commission of the tour route distribution refers to an electronic request initiated by a distributor to the tour route distribution commission calculation system (hereinafter referred to as the system) after the distributor generates a sales transaction based on the tour route it distributes, in order to obtain the commission corresponding to the sales transaction.

[0031] In some embodiments, a calculation request includes a request header, a request body, and a request footer. The request header includes a request ID, initiation time, and distributor identifier; the request body includes distributor information associated with the sales activity, travel route information, and sales data; and the request footer contains a data verification code. Calculation requests are triggered in real-time after a single sale is completed, and in batches after a summary of daily sales.

[0032] In this embodiment of the application, the distributor information is used to identify the distributor's identity and cooperation level, including distributor number, distributor level, etc.

[0033] In this embodiment of the application, the tourism route information is used to distinguish the characteristics of different tourism routes, including route number, route name, route type, etc.

[0034] In this embodiment of the application, sales data records key indicators of tourism route sales behavior, including sales revenue, sales volume, and sales time.

[0035] In some embodiments, the system receives a request from a distributor to calculate the commission for a travel route distribution through a preset request receiving interface. The system performs a preliminary validity check on the request, including whether the request ID is unique to avoid duplicate requests; whether the data verification code is consistent with the system's preset verification rules to prevent data tampering; and whether the request was initiated within the system's service hours to avoid requests outside of service hours.

[0036] If the initial verification fails, the system returns a message to the distributor containing the error code and the reason for the error. If the initial verification passes, the system parses the data in the request body and extracts the distributor information, tour route information, and sales data corresponding to the calculation request.

[0037] When retrieving distributor information, the system reads the distributor identifier field from the request body and queries the system's distributor information database based on this identifier field to obtain complete distributor information. Distributor information includes distributor ID, distributor level, distributor's region, and distributor's cooperation permissions.

[0038] When retrieving tour route information, the system reads the route identifier field from the request body, associates it with the tour route database of the tour route distribution commission calculation system, and obtains complete tour route information. Tour route information includes route number, route name, route type, route popularity coefficient, and route cost price.

[0039] When extracting sales data, the system reads the sales data fields from the request body. The sales data fields include sales amount, sales volume, sales time, sales order number, and purchasing user group.

[0040] In some embodiments, the evaluation criteria for distributor levels can be set as follows: Level 1 distributors must have sales of RMB 5 million or more in the past 12 months and a cooperation period of 2 years or more; Level 2 distributors must have sales of RMB 2 million or more but less than RMB 5 million in the past 12 months; and Level 3 distributors must have sales of less than RMB 2 million in the past 12 months.

[0041] S200, Build a rules engine for commission calculation; In this embodiment of the application, the rule engine is the core service module of the system used to parse, call, and execute the rules for calculating commissions for tourism route distribution. This module has full-process capabilities for rule configuration, rule storage, rule matching, rule execution, and result output. It supports the decoupling of rules and code and can achieve rule iteration through configuration updates without modifying the underlying system code.

[0042] refer to Figure 2 Based on the above embodiments, as another optional embodiment, the construction of the rule engine includes: S201. Classify and define the business rules for the distribution commission of the aforementioned tourism routes; Based on the above embodiments, as another optional embodiment, the business rules for travel route distribution commissions are classified and defined, including: S2011. Based on the commission collection rules requirements of distributor level, travel route type, sales region and sales season, classify the business rules according to the grouping logic and set unique identifiers and descriptions. In some embodiments, the system collects commission rule requirements based on multi-dimensional scenarios, categorizes business rules according to grouping logic, and assigns unique identifiers and descriptions. A multi-role collaborative requirement collection mechanism is established, collecting requirements from distributors, finance, and technical personnel through preset modules. The system extracts keywords from the requirements and categorizes and labels them according to requirement type and priority. Requirement types include regular and special requirements, and priorities include high, medium, and low, forming a requirement list.

[0043] Based on the requirements list, the system categorizes business rules using a multi-dimensional cross-grouping logic. These grouping dimensions include distributor, tour route, and time. The distributor dimension is divided by distributor level and region; the tour route dimension by route type and popularity coefficient; and the time dimension by season and holidays. The grouping logic includes: a main group based on core dimensions (distributor level and route type); and subgroups based on auxiliary dimensions (region and season).

[0044] The system assigns a unique identifier and a detailed description to each subgroup. The unique identifier uses a format of main group code and subgroup code. The detailed description includes the applicable scenarios for the subgroup, the core requirements contained in the subgroup, and the business restrictions associated with the subgroup. Among them, the applicable scenarios for the subgroup are used to clarify the business scope corresponding to the subgroup; the core requirements contained in the subgroup are used to clarify the business requirements that the subgroup must meet; and the business restrictions associated with the subgroup are used to clarify the applicable boundaries of the subgroup.

[0045] In some embodiments, high-priority demand can be set as sales of popular domestic travel routes (popularity coefficient greater than or equal to 1.1) by first-level distributors during peak season, and the commission rate for high-priority demand is increased to 7%; medium-priority demand can be set as sales of outbound travel routes by second-level distributors during off-season, and the commission rate for medium-priority demand remains at 5%; low-priority demand can be set as sales of adventure travel routes by third-level distributors, and the commission rate for low-priority demand can fluctuate by plus or minus 0.5%.

[0046] S2012. For each type of rule, define branch conditions, basic calculation rules, and customized calculation rules.

[0047] In some embodiments, the system defines branch conditions, basic calculation rules, and customized calculation rules for each rule subgroup divided in S2011, ensuring that the rules cover both regular and special scenarios and that there are no logical conflicts.

[0048] When defining branching conditions, the system defines multi-dimensional branching conditions based on the applicable scenarios of rule subgroups. Dimensions include sales data, distributors, and travel routes. The sales data dimension includes sales revenue, sales volume, and sales time; the distributor dimension includes distributor level, region, and cooperation permissions; and the travel route dimension includes route type, popularity coefficient, and cost price. Conditions for each dimension are set using fields, operators, and thresholds. The system supports logical combinations of multiple conditions, including AND, OR, and NOT operations, and assigns priority weights to each condition.

[0049] When defining basic calculation rules, the system defines them based on the typical scenarios of the rule subgroups. These basic calculation rules include the basic commission amount, sales revenue, and a basic coefficient. The basic commission amount is obtained by multiplying the sales revenue and the basic coefficient. Specifically, the basic commission amount is the commission the distributor can earn calculated according to the typical scenario; the sales revenue is the transaction amount corresponding to the sale of the tour package; and the basic coefficient is a fixed percentage coefficient determined based on the requirements of the rule subgroups. The system sets a result verification threshold for the basic calculation rules to ensure that the commission remains within a reasonable cost range. If the calculated basic commission amount exceeds this threshold, the basic calculation rule triggers an anomaly flag, awaiting manual review.

[0050] When defining customized calculation rules, the system defines them for specific scenarios within a rule subgroup. These specific scenarios include high-traffic routes, excess sales volume, and holiday sales. Customized calculation rules include a customized commission amount, a base commission amount, a dynamic adjustment coefficient, and an excess reward item. The customized commission amount is obtained by multiplying the base commission amount and the dynamic adjustment coefficient, plus the excess reward item. Specifically, the customized commission amount is the distributor's commission calculated for the specific scenario, the base commission amount is the commission amount calculated for the regular scenario, the dynamic adjustment coefficient is the product of multiple dimension coefficients, including route popularity coefficient and holiday coefficient, and the excess reward item is the reward amount corresponding to the portion exceeding the sales threshold. The system sets trigger conditions for customized calculation rules; the customized calculation rules are executed only when the trigger conditions are met; otherwise, the base calculation rules are executed.

[0051] S202, Construct a rule-based data model; Based on the above embodiments, as another optional embodiment, the rule data model includes: Data objects include the aforementioned distributor information, tour route information, and sales data; The rule logic structure includes conditional branching logic, execution logic, and the smallest unit within the rule; The result object includes the commission amount, the basis for commission calculation, and the applicable commission rule number.

[0052] In this embodiment, the rule data model is a structured data framework that supports the operation of the rule engine. This model is used to achieve integrated functions of data integration, logic definition, and result delivery, ensuring that the rule engine can efficiently acquire data, execute logic, and output results. The rule data model includes three sub-models: data objects, rule logic structures, and result objects.

[0053] When constructing data objects, the system integrates distributor information, travel route information, and sales data acquired by S100, establishing a mapping relationship between data objects, fields, and rule conditions. This ensures that the rule engine can quickly extract the fields required for rule calculation from the data objects. The data object's field settings include distributor information fields, travel route information fields, and sales data fields.

[0054] In some embodiments, the distributor information field includes distributor ID, distributor level, region, cooperation permissions, and historical cooperation duration. The distributor ID is a character type with a length of 10; the distributor level is an enumeration type, with values ​​of Level 1, Level 2, and Level 3; the region is an enumeration type, with values ​​of East China, North China, South China, Southwest China, Northwest China, and Northeast China; the cooperation permissions are an enumeration type, with values ​​of regular permissions and special permissions; and the historical cooperation duration is a numeric type, in months. The historical cooperation duration field is used in subsequent rule iterations to add exclusive reward rules for existing distributors, improving model scalability.

[0055] In some embodiments, the tour route information field includes route number, route name, route type, route popularity coefficient, route cost price, and route validity period. The route number is a character type with a length of 10; the route name is a character type with a length of 50; the route type is an enumeration type, with values ​​including domestic tour, outbound tour, local tour, and adventure tour; the route popularity coefficient is a numerical type, rounded to two decimal places; the route cost price is a numerical type, in yuan; and the route validity period is a date type, including the start date and end date. The route validity period field is used to determine whether the sales period is within the route's available sales range, avoiding commission calculations for expired routes.

[0056] In some embodiments, sales data fields include sales order number, sales time, sales amount, sales volume, customer group, and payment status. The sales order number is a character type with a length of 20; the sales time is a date and time type, accurate to the minute; the sales amount is a numeric type, in yuan; the sales volume is a numeric type, in units of orders; the customer group is an enumeration type, with values ​​for family customers, young customers, elderly customers, and business customers; the payment status is an enumeration type, with values ​​for paid, unpaid, in the process of being refunded, and refunded. The payment status field is used to filter unpaid and refunded sales data, performing commission calculations only on paid sales data to avoid invalid calculations.

[0057] Furthermore, the system establishes a dynamic mapping table between data object fields and rule condition fields. This table records the rule condition field name, data object field name, data type, and conversion rule. For example, the distributor level in the rule condition field corresponds to the distributor level in the data object field; both are enumerated types, and the conversion rule is direct mapping. Similarly, the peak season sales time in the rule condition field corresponds to the sales time in the data object field; both are date types, and the conversion rule determines whether the sales time falls within a preset peak season period. If so, it is mapped to the peak season; otherwise, it is mapped to the off-season. When rule condition fields are added or modified, the system updates the mapping table without altering the data object structure, thus improving model flexibility.

[0058] In some embodiments, the rule logic structure includes conditional branching logic, execution logic, and the smallest unit within the rule.

[0059] When constructing conditional branching logic, the system adopts a decision tree structure. The root node of the decision tree is the rule subgroup identifier, the first-level branches are the core conditions, including distributor level and line type; the second-level branches are the auxiliary conditions, including sales time and sales amount; the leaf nodes of the decision tree are the rule triggering results, including executing basic calculation rules, executing customized calculation rules, and not triggering rules; the system supports visual editing of the decision tree, and users can adjust the branch order by dragging and dropping nodes, for example, adjusting the line popularity coefficient from the second-level branch to the first-level branch to adapt to the business's need to prioritize line popularity.

[0060] When constructing the execution logic, the system adopts a modular design, breaking it down into a data preprocessing module, a calculation module, and a result verification module. The data preprocessing module cleanses and converts the extracted business data, including removing data with negative sales figures and converting sales time to seasonal enumeration values. The calculation module loads formulas from basic or customized calculation rules and substitutes them into the preprocessed data to perform calculations. The result verification module performs compliance and consistency checks on the calculation results. Compliance checks determine if the results exceed cost control limits, and consistency checks verify the consistency of multiple calculations for the same sales order number. If the checks pass, the result is entered into the result object; otherwise, exception handling is triggered.

[0061] When constructing the smallest unit within a rule, the system defines a rule unit as the smallest unit within a rule. Each rule unit corresponds to an independent calculation logic, such as adjusting the route popularity coefficient, calculating holiday rewards, and calculating excess sales rewards. Rule units support plug-and-play functionality; business personnel can select the required units from the rule unit library of the travel route distribution commission calculation system and combine them into complete execution logic without rewriting the calculation code. The rule unit library includes customer-defined units, regular expression units, and structured query units. Customer-defined units allow business personnel to define their own logic through a low-code platform; regular expression units are used for simple numerical calculations; and structured query units are used for querying external data. These three types of units meet the execution logic requirements of varying complexity.

[0062] When constructing the result object, the system carries the commission calculation results and full-process traceability information to ensure that the results are searchable and traceable. The fields of the result object include basic result fields, traceability information fields, and detailed information fields.

[0063] In some embodiments, the basic result fields include result ID, commission amount, commission calculation status, and calculation time. The result ID is a character type with a length of 32, a unique identifier generated by the system; the commission amount is a numeric type, in yuan, with two decimal places, distinguishing between basic commission amount and customized commission amount; the commission calculation status is an enumeration type, with values ​​including calculation successful, calculation failed, verification error, and pending review; the calculation time is a date and time type, accurate to the second.

[0064] In some embodiments, the traceability information field includes an applicable rule subgroup identifier, an applicable rule number, a data source identifier, a calculation algorithm identifier, and an operator identifier. The applicable rule subgroup identifier is a character type and is associated with the rule subgroup identifier in step S2011; the applicable rule number is a character type; the data source identifier is a character type and is associated with the sales order number in step S100; the calculation algorithm identifier is a character type and is associated with the algorithm number in the preset algorithm library; the operator identifier is a character type, with the value set to "system automatic" when the calculation is successful and the value set to the operator's account during manual review.

[0065] In some embodiments, the detailed information field includes basic calculation details, dynamic adjustment details, and excess reward details. The detailed information field is described in natural language to facilitate business personnel and distributors to understand the calculation process.

[0066] Furthermore, the system sets up data association indexes for result objects, including result ID, sales order number, and rule subgroup identifier. These indexes allow for quick retrieval of all calculation results for a specific sales order number and all calculation records for a specific rule subgroup, improving result query efficiency. Simultaneously, result objects are associated with the system's log system. Every status change of a result object is recorded in the log system, including changes from successful calculation to pending review, and from pending review to successful calculation. The log system records the change time, reason for change, and operator, enabling full lifecycle traceability.

[0067] S203. Manage and maintain the defined business rules.

[0068] Based on the above embodiments, as another optional embodiment, the management and maintenance of defined business rules includes: S2031. Establish a visual rule management mechanism and a rule review mechanism; In some embodiments, the system develops a low-code visual rule management interface, allowing business personnel to complete the addition, modification, query, and deletion of rules without writing code.

[0069] During the rule addition process, business users select a rule subgroup on the interface, click the "Add Rule" button, and the system loads the branch condition template and calculation rule template for that subgroup. Business users can then select the branch condition from the drop-down menu, enter the calculation rule parameters, and select the rule cell to view the rule's logical expression.

[0070] During rule modification, business users can query the rules that need to be modified. The interface displays all current configurations of the rule, including conditions, parameters, and units, and supports partial modifications. After modification, the system compares the rules before and after the modification and indicates the range of calculation results that may be affected by the modification.

[0071] During rule query operations, the system provides multi-condition query functionality. Business personnel can query rules by rule subgroup identifier, rule number, rule status, and creation time. Rule status includes effective, ineffective, and invalid. Query results are displayed in list format, including the rule's core configuration, effective time, and usage count. The usage count refers to the number of calculations triggered by the rule. Clicking on a list item allows viewing the rule's detailed configuration and historical change records.

[0072] In some embodiments, the system establishes a multi-level rule review mechanism. The addition, modification, and invalidation of rules must go through a review process before they can take effect. The review process includes business review, technical review, and financial review.

[0073] The business review is performed by the business department module. The review content includes whether the rule meets the business requirements, whether the rule logic conflicts with other rules, and whether the rule priority is reasonable. If the review is passed, it is submitted to the technical department module for review. If it fails, it is returned to the business personnel under the business department.

[0074] Technical review is performed by the technical department module. The review content includes whether the rule configuration conforms to the technical specifications, whether there are performance risks in the rule execution, and whether the rule data is available. Technical specifications include whether the parameter format is correct and whether the rule units are compatible. Performance risks include whether complex conditions lead to excessive calculation time. Data acquisition difficulty includes whether the rule condition fields exist in the data object. If the review is successful, it is submitted to the finance department module for review. If it fails, it is returned to the business personnel and technical optimization suggestions are provided.

[0075] Financial review is performed by the finance department module. The review includes whether the commission amount calculated by the rules is within the cost control range and whether the rules comply with tax compliance requirements. If the review is passed, the rule status changes to pending effect and will automatically take effect after the effective time is set. If the review is not passed, it is returned to the business personnel and financial adjustment suggestions are provided.

[0076] S2032. Establish a rule storage structure and implement rule version control; In some embodiments, the system designs a distributed rule storage structure, employing a hybrid storage architecture of master-slave database and distributed file library to ensure the security, high availability, and scalability of rule data. The master database uses a relational database cluster to store the structured data of the rules, including rule subgroup identifiers, branch conditions, calculation parameters, review status, and effective time. The slave database synchronizes data with the master database in real time for read / write separation; the master database handles write operations, and the slave database handles read operations, improving storage performance. The distributed file library stores the unstructured data of the rules, including rule configuration files, visual configuration templates, and rule review attachments, supporting large file storage and multi-node backup to prevent data loss.

[0077] Furthermore, the system encrypts the stored rule data. Structured data is encrypted at the field level, and the encryption key is managed centrally by the system's key management module and changed according to a preset replacement cycle. Unstructured data is encrypted at the file level. An encrypted file is generated when uploaded to the distributed file library, and user permissions must be verified and decryption performed during download to ensure that the rule data is not accessed by unauthorized personnel.

[0078] Furthermore, the system establishes role-based access permissions for rule data, with roles including business personnel, auditors, administrators, and distributors. Business personnel can only view, add, and modify rules for their respective business departments. Auditors can only view and audit all rules, but cannot modify them. Administrators can view and modify all rules and configure access permissions. Distributors can only view the descriptions of rule subgroups relevant to themselves, but cannot view specific parameters. Different roles, after logging in with their accounts, can only access rule data within their authorized scope, preventing data leaks.

[0079] In some embodiments, the system establishes a rule version control and difference comparison mechanism. Each addition or modification of a rule generates a new version, with the version number in the format of major version number, minor version number, and revision number. When a version is generated, the version description, creation time, creator, and associated historical version number are recorded.

[0080] Furthermore, the system provides a version difference comparison tool, which allows users to compare the differences in rule branching conditions, calculation parameters, and rule units across different versions. When an error occurs in a new rule version, such as a calculation result deviation or logical conflict, administrators can initiate a version rollback operation. By selecting the target version to roll back to, the system will restore the rule configuration to the target version's state and generate a rollback log, which includes the rollback time, reason for rollback, and operator. Simultaneously, the system marks the results calculated using the new rule before the rollback. This marking serves to prompt business personnel to re-execute the calculation to ensure result accuracy.

[0081] S2033. Test, verify and optimize the rules using simulated data and actual sales data respectively.

[0082] In this embodiment of the application, simulated data refers to virtual sales data generated by the system based on business scenarios. This data is used to initially verify the correctness of the rule logic and avoid errors caused by directly applying the rules to actual business.

[0083] In this embodiment of the application, actual sales data refers to real sales data obtained by the system from the tourism route distribution business, which is used to further verify the applicability of the rules in actual business scenarios.

[0084] In some embodiments, the system substitutes simulated data and actual sales data into predefined rules to calculate commissions, and compares the results calculated using simulated data with those calculated using actual sales data. If the results are consistent, it means the predefined rules are correct; if there are discrepancies, the reasons are analyzed and the rules are optimized until they meet business requirements.

[0085] S300. Based on the rule engine, call and execute the commission calculation rule; Based on the above embodiments, as another optional embodiment, based on the rule engine, the commission calculation rules are invoked and executed, including: S301. Based on the distributor information, tour route information, and sales data, determine the corresponding rule type and load the rule configuration file for the rule type; In this embodiment of the application, the rule type refers to the rule group that is adapted to the current sales scenario. This rule group corresponds one-to-one with the rule groups divided in step S2011. The system determines the rule type corresponding to the current scenario by analyzing the distributor level in the distributor information, the route type in the travel route information, and the sales time and sales region in the sales data.

[0086] In this embodiment, the rule configuration file stores all rule logic and parameters for the target rule type, including rule branching conditions, calculation methods, reward thresholds, etc. The system loads the valid version of the rule configuration file corresponding to the target rule type to ensure that the currently effective rule is used for calculation.

[0087] S302. Verify the calculation request, obtain an algorithm that matches the rule configuration file from the preset algorithm library, and calculate the commission based on the algorithm and the sales data.

[0088] In some embodiments, the system selects an appropriate algorithm from a preset algorithm library based on the logical complexity of the rule configuration file. For example, for a rule configuration file with multiple conditions, a multi-condition exact matching algorithm is selected, and then the sales data is substituted into the algorithm and the calculation logic in the rule configuration file to complete the commission calculation.

[0089] S400. Determine the commission result corresponding to each of the sales data, the commission result including the commission amount, and return each of the commission results to each distributor.

[0090] In this embodiment of the application, the commission result refers to a collection including the commission amount and related traceability information. In addition to the commission amount, it may also include information such as the commission calculation basis and the commission applicable rule number defined in the result object in S202.

[0091] In some embodiments, the system will determine the corresponding commission result for each piece of sales data obtained by S100, and then send the commission result to the corresponding distributor through synchronous return of interface or asynchronous push of message queue, so as to ensure that the distributor can obtain the commission information corresponding to its own sales behavior in a timely manner.

[0092] Based on the above embodiments, as another optional embodiment, the method further includes: S401. Generate a multi-dimensional business report based on the commission results; In this embodiment, multi-dimensional business reports refer to reports formed by integrating commission result data from different business dimensions, including distributor dimensions, travel route dimensions, and time dimensions. The report format can be tables, bar charts, line charts, etc., facilitating business managers to intuitively view business data. The system integrates the commission results of all distributors according to each business dimension at preset time intervals (such as daily or monthly) to generate corresponding business reports, providing data support for business management.

[0093] S402. Analyze the commission results, and use the analysis results to adjust the tourism route distribution business; In this embodiment of the application, the analysis of commission results refers to the system using data mining technology to extract business patterns and trends from the commission results, such as analyzing the commission contribution rate of travel routes, the sales capabilities of distributors, and the commission change trends in different seasons.

[0094] In some embodiments, the analysis results are output to business and management personnel in the form of reports, enabling them to adjust travel route distribution strategies based on the analysis results. For example, they may increase the promotion of routes with high commission contribution rates or upgrade the cooperation level of high-quality distributors to improve business efficiency and market competitiveness.

[0095] S403. Establish an auditing mechanism to monitor and record the application of the commission results.

[0096] In this embodiment, the audit mechanism refers to the system tracking the application of commission results in subsequent business processes in real time, recording the operation time, operator, operation content, and corresponding commission result information for each stage. These subsequent business processes include commission settlement, report generation, and business adjustments. Simultaneously, the audit mechanism monitors for anomalies during the application process, such as commission settlement failures or report data deviations. If an anomaly is detected, an early warning notification is triggered to ensure timely handling of the anomaly and guarantee the compliance and data accuracy of the tourism route distribution business.

[0097] refer to Figure 3 Based on the above embodiments, as another optional embodiment, this application embodiment may further include a system for calculating travel route distribution commissions, the system comprising: The request processing module is used to respond to the calculation request for travel route distribution commission and obtain the distributor information, travel route information and sales data corresponding to the calculation request. The rules module is used to build a rules engine for commission calculation, classify and define business rules for travel route distribution commissions, build rule data models, and manage and maintain the defined business rules. The execution module is used to call and execute commission calculation rules based on the rule engine, determine the corresponding rule type and load the rule configuration file according to distributor information, travel route information and sales data, verify the calculation request and match the algorithm to calculate the commission; The output module is used to determine the commission result corresponding to each sales data point and return the commission result to each distributor.

[0098] In some embodiments, the rules module includes a rule classification and definition module, a rule data model construction module, and a rule management and maintenance module. The rule classification and definition module is used to classify and define the business rules for travel route distribution commissions; the rule data model construction module is used to construct the rule data model; and the rule management and maintenance module is used to manage and maintain the defined business rules.

[0099] In some embodiments, the execution module includes a rule invocation module and a rule execution module. The rule invocation module is used to invoke and execute commission calculation rules based on the rule engine, determine the corresponding rule type based on distributor information, travel route information, and sales data, and load the rule configuration file; the rule execution module is used to verify the calculation request and match the algorithm to calculate the commission.

[0100] In some embodiments, the output module includes a result feedback module and a result application module. The result feedback module is used to determine the commission result corresponding to each sales data point and return the commission result to each distributor; the result application module is used to generate multi-dimensional business reports based on the commission result, analyze the commission result to adjust the travel route distribution business, and establish an audit mechanism to monitor and record the application of the commission result.

[0101] In some embodiments, the system further includes a departmental approval module for approving the addition, modification, and invalidation of rules. This departmental approval module includes modules for business departments, technology departments, and finance departments.

[0102] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0103] Based on the above embodiments, as another optional embodiment, the present application embodiment may further include a computer storage medium, which may store multiple instructions adapted for loading by a processor and executing a method of the above embodiments. For the specific execution process, please refer to the detailed description of the above embodiments, which will not be repeated here.

[0104] Based on the above embodiments, as another optional embodiment, this application embodiment may further include an electronic device. The electronic device may include: at least one processor, at least one communication bus, a user interface, at least one network interface, and a memory.

[0105] The communication bus is used to enable communication between these components.

[0106] The user interface may include a display screen and a camera. Optional user interfaces may also include standard wired interfaces and wireless interfaces.

[0107] The network interface may include standard wired interfaces and wireless interfaces (such as Wi-Fi interfaces).

[0108] The processor may include one or more processing cores. It connects to various parts of the server via various interfaces and lines, executing instructions, programs, code sets, or instruction sets stored in memory, and accessing data stored in memory to perform various server functions and process data. Optionally, the processor may be implemented using at least one of the following hardware forms: Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor.

[0109] The memory may include random access memory (RAM) or read-only memory. Optionally, the memory may include a non-transitory computer-readable storage medium. The memory can be used to store instructions, programs, code, code sets, or instruction sets. The memory may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor. As a computer storage medium, the memory may include an operating system, a network communication module, a user interface module, and an application program of one method.

[0110] In electronic devices, the user interface is primarily used to provide an input interface for users and to acquire user input data; while the processor can be used to call an application program stored in memory that represents a method. When executed by one or more processors, this causes the electronic device to perform one or more methods as described in the above embodiments. It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps can be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0111] 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 in other embodiments.

[0112] In the various embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0113] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0114] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0115] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0116] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will readily conceive of those skilled in the art upon consideration of the specification and the disclosure of practical truths.

[0117] This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for calculating commission on the distribution of travel routes, characterized in that, The method includes: In response to the request to calculate the commission for the tour package distribution, obtain the distributor information, tour package information and sales data corresponding to the calculation request; Build a rules engine for commission calculation; Based on the rule engine, the commission calculation rules are invoked and executed; Determine the commission result corresponding to each of the aforementioned sales data, the commission result including the commission amount, and return each of the aforementioned commission results to each distributor.

2. The method for calculating commission on travel route distribution according to claim 1, characterized in that, The construction of the rule engine includes: The business rules for the distribution commission of the aforementioned travel routes are classified and defined; Build a rule-based data model; Manage and maintain the defined business rules.

3. The method for calculating commission on tourism route distribution according to claim 2, characterized in that, The classification and definition of the business rules for the distribution commission of the aforementioned travel routes include: Based on the commission collection rules requirements of distributor level, tour route type, sales region and sales season, classify the business rules according to grouping logic and set unique identifiers and descriptions; For each type of rule, define branch conditions, basic calculation rules, and customized calculation rules.

4. The method for calculating commission on travel route distribution according to claim 3, characterized in that, The management and maintenance of the defined business rules includes: Establish a visual rule management mechanism and a rule review mechanism; Establish a rule storage structure and implement rule version control; The rules were tested, verified, and optimized using both simulated and actual sales data.

5. The method for calculating commission on travel route distribution according to claim 4, characterized in that, The rule data model includes: Data objects include the aforementioned distributor information, tour route information, and sales data; The rule logic structure includes conditional branching logic, execution logic, and the smallest unit within the rule; The result object includes the commission amount, the basis for commission calculation, and the applicable commission rule number.

6. The method for calculating commission on travel route distribution according to claim 1, characterized in that, The step of invoking and executing commission calculation rules based on the rule engine includes: Based on the distributor information, tour route information, and sales data, determine the corresponding rule type and load the rule configuration file for that rule type; The calculation request is verified, and an algorithm matching the rule configuration file is obtained from a preset algorithm library. The commission is calculated based on the algorithm and the sales data.

7. The method for calculating commission on travel route distribution according to claim 1, characterized in that, include: Generate multi-dimensional business reports based on the commission results; The commission results are analyzed, and the results are used to adjust the travel route distribution business. Establish an auditing mechanism to monitor and record the application of the commission results.

8. A system for calculating commissions for the distribution of travel routes, characterized in that, The system includes: The request processing module is used to respond to the calculation request for travel route distribution commission and obtain the distributor information, travel route information and sales data corresponding to the calculation request. The rules module is used to build a rules engine for commission calculation, classify and define business rules for travel route distribution commissions, build rule data models, and manage and maintain the defined business rules. The execution module is used to call and execute commission calculation rules based on the rule engine, determine the corresponding rule type and load the rule configuration file according to distributor information, travel route information and sales data, verify the calculation request and match the algorithm to calculate the commission; The output module is used to determine the commission result corresponding to each sales data point and return the commission result to each distributor.

9. An electronic device, characterized in that, It includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted to be loaded by a processor and executed as described in any one of claims 1-7.

Images