An intelligent terminal sequential account distribution method and system, storage medium and program product

Abstract

The application belongs to the technical field of intelligent distribution, and discloses a kind of intelligent terminal according to sequence distribution method, system, storage medium and program product, the method includes: when order payment is completed, strategy identification is obtained by inquiring site strategy binding table, distribution order is created and target strategy details are determined;According to the distribution state and refund state of distribution order, combined condition update is executed to determine the execution right of income processing;According to distribution sequence, the distribution amount of corresponding role is determined in turn, the distribution amount is deducted from the remaining amount and distribution details are generated;Distribution details are settled and the corresponding account balance is updated;When order refund occurs, the corresponding distribution order is inquired, and combined condition update is executed based on the refund state to determine the execution right of refund processing;According to the distribution state and settlement state, determine the refund stage, and complete the refund processing based on the refund stage.The application can ensure consistent processing results in the case of concurrent execution of income, settlement and refund.

Description

Technical Field

[0001] This invention relates to the field of intelligent revenue sharing technology, and in particular to an intelligent terminal sequential revenue sharing method, system, storage medium, and program product. Background Technology

[0002] With the large-scale deployment of smart terminals such as food delivery lockers, food lockers, and community storage lockers, the revenue generated during terminal operation, including locker usage fees, overdue fees, and other service income, needs to be distributed among the terminal owner, operator, and site provider. Different parties typically have different revenue calculation methods and order of payment in their operating contracts. Some parties receive revenue according to a percentage of the total revenue, while others receive a predetermined amount, and the specific distribution rules may vary depending on the site, revenue type, and operational phase. Accurately distributing revenue among these parties and ensuring that the distribution results can be settled, refunded, and audited has become a crucial issue in the operation and management of smart terminals.

[0003] Current revenue distribution for smart terminals typically relies on revenue sharing interfaces provided by third-party payment platforms, or the business system directly splits order amounts according to preset roles and ratios. In such systems, participating roles, allocation ratios, and processing flows are usually pre-programmed. Once an order payment is completed, the system calculates the amount for each participant according to the current configuration and directly credits the account. Some systems use message queues to process revenue asynchronously, completing batch settlements through scheduled tasks; in the event of a refund, the amount is returned based on the order revenue record. This approach can handle simple businesses with a small number of roles and unchanging allocation rules over a long period.

[0004] However, existing technologies still have significant shortcomings. First, current systems typically treat all participants as equals when splitting amounts, failing to consider the sequential compensation relationships among them. When order amounts are insufficient, it's impossible to prioritize participants with earlier payment orders, and the minimum monetary unit error generated by proportional calculations lacks a mechanism to handle this in accordance with the compensation order. Second, participant roles and allocation models are usually tied to the calculation program. Adding roles or changing allocation models requires simultaneous modifications to configuration, calculation, and data storage programs, making system expansion difficult. Furthermore, modified accounting rules often immediately override the original rules, meaning orders with earlier payment times but not yet processed may be subject to the modified rules, making it difficult to restore the actual allocation basis applicable at the time of order payment. Third, in asynchronous processing environments, revenue and refund messages may be executed concurrently for the same order. Since existing solutions often rely on long transactions or application-layer locks to control the processing order, lock contention can easily occur with large volumes of business, and issues such as refunded orders being further split and credited amounts not being fully deducted may still arise. Fourth, existing settlement methods usually only allow for a choice between transaction-by-transaction settlement and periodic settlement, making it difficult to balance the timeliness of payment and settlement processing costs. Furthermore, when the old revenue data, which is entirely attributable to a single merchant, coexists with revenue data shared by multiple participants, problems can easily arise where payment entry points, historical order refunds, and account transaction records cannot be linked.

[0005] Therefore, how to flexibly configure participating roles and allocation modes during the operation of smart terminals, accurately allocate order amounts according to the agreed order, and ensure consistent processing results when revenue, settlement, and refund are executed concurrently are urgent problems to be solved. Summary of the Invention

[0006] This invention provides a method, system, storage medium, and program product for sequential revenue sharing in smart terminals to solve the aforementioned problems existing in the prior art.

[0007] According to a first aspect of the present invention, a method for sequential revenue sharing in a smart terminal is provided.

[0008] In one embodiment, the smart terminal sequential revenue sharing method includes: when order payment is completed, obtaining a strategy identifier by querying the site strategy binding table; the strategy identifier is used to create a revenue sharing order and determine the target strategy details; the revenue sharing order includes a revenue sharing status, a settlement status, and a refund status; performing a combined condition update with business status constraints based on the revenue sharing status and refund status of the revenue sharing order to determine the execution right of revenue processing; after obtaining the execution right of revenue processing, determining the revenue sharing amount for the corresponding role according to the revenue sharing mode and revenue sharing value of each target strategy detail in the revenue sharing order, deducting the revenue sharing amount from the remaining amount, and generating revenue sharing details; selecting a target settlement mode according to the merchant configuration, settling the revenue sharing details, and updating the corresponding account balance; when an order is refunded, querying the corresponding revenue sharing order, and performing a combined condition update based on the refund status to determine the execution right of refund processing; determining the refund stage based on the revenue sharing status and settlement status, and determining whether to deduct the corresponding account balance based on the refund stage to complete the refund processing.

[0009] According to a second aspect of the present invention, a smart terminal sequential revenue sharing system is provided.

[0010] In one embodiment, the smart terminal sequential revenue sharing system includes: a strategy acquisition module, used to obtain a strategy identifier by querying a site strategy binding table when an order payment is completed; the strategy identifier is used to create a revenue sharing order and determine the target strategy details; the revenue sharing order includes a revenue sharing status, a settlement status, and a refund status; an authorization determination module, used to perform a combination of conditions with business status constraints to update the order based on the revenue sharing status and refund status, thereby determining the execution right for revenue processing; a sequential revenue sharing module, used to determine the revenue sharing amount for the corresponding role according to the revenue sharing mode and revenue sharing value of each target strategy detail in the order of revenue sharing, deduct the revenue sharing amount from the remaining amount, and generate revenue sharing details; a settlement processing module, used to select a target settlement mode according to the merchant configuration, settle the revenue sharing details, and update the corresponding account balance; and a refund processing module, used to query the corresponding revenue sharing order when an order is refunded, and perform a combination of conditions updates based on the refund status to determine the execution right for refund processing; determine the refund stage based on the revenue sharing status and settlement status, and determine whether to deduct the corresponding account balance based on the refund stage to complete the refund processing.

[0011] According to a third aspect of the present invention, a storage medium is provided.

[0012] In one embodiment, the storage medium is a computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the steps of the above method.

[0013] According to a fourth aspect of the present invention, a computer program product is provided.

[0014] In one embodiment, the computer program product includes a computer program that, when executed by a processor, implements the steps of the method described above.

[0015] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: (1) This invention constructs a matrix-style revenue sharing strategy by means of income type, role type, revenue sharing mode, revenue sharing value and revenue sharing order, so that the participating roles, allocation methods and calculation programs are decoupled from each other; when a new participating role is added, the calculation process can automatically process the new role by adding the corresponding role type and strategy details, without having to set up calculation branches for each type of role; each role obtains the revenue sharing amount from the remaining amount in the order of revenue sharing. When the order amount is insufficient, the role with the earlier order can obtain the agreed amount first. After the remaining amount is exhausted, it will not be allocated to the subsequent roles, thereby avoiding the total amount of allocation exceeding the order amount; when using proportional revenue sharing, the role with the lowest order of proportional revenue sharing takes over the remaining amount and makes up the rounding difference in the order of revenue sharing, so that the sum of the revenue sharing amount of each role is consistent with the total order amount.

[0016] (2) When the revenue sharing strategy changes, the present invention saves historical snapshots and sets corresponding effective dates for the historical snapshots. When the revenue sharing is executed, the applicable strategy version is found based on the order payment time, so that the revenue sharing basis of orders paid on the same date will not be changed due to subsequent strategy modifications. Strategy changes, order payments, revenue sharing details, settlement order numbers and refund flow can be associated through corresponding identifiers. When a refund occurs for a settled order, the reverse processing is completed by generating a negative income record, without deleting or overwriting the original income record. This can restore the complete process of each participant obtaining and returning the amount, and improve the verifiability of the revenue sharing results and the auditability of the fund flow.

[0017] (3) This invention determines the revenue processing right and refund processing right by updating the combined conditions including the accounting status, settlement status and refund status, so that the concurrency control conditions directly correspond to the business status of the order; for the revenue request and refund request that arrive concurrently for the same order, only the processing process that meets the combined conditions can continue to be executed, which can reduce the situation of duplicate accounting, duplicate refunds and the re-entry of refunded orders; business records are written to the database before the message is enqueued, so that unconsumed accounting orders can be discovered and re-triggered through the pending status; revenue messages and refund messages adopt different delay sequences, which can reduce the state conflict caused by the disordered execution of the two types of messages, and the state linkage between settlement orders, accounting details and accounting orders is also conducive to maintaining the consistency of data at each layer.

[0018] (4) The present invention can select real-time settlement or timed aggregated settlement according to the merchant configuration; real-time settlement can quickly update the accounts of each participant after the settlement is completed, and timed aggregated settlement can merge the settlement details according to the role type, account identifier and income type, reducing the number of settlement operations; the payment entry selects the original income processing path or multi-role settlement path according to whether there is a valid strategy binding record at the site. When the strategy details are unavailable, the income can be attributed to the merchant account. When refunding, the corresponding processing method is selected according to whether there is a settlement order. This enables sites that have enabled settlement and sites that have not enabled settlement to run in parallel, reducing the risk of full data migration and shutdown switching during the business system upgrade process.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0021] Figure 1 This is a flowchart illustrating a sequential revenue sharing method for smart terminals according to an exemplary embodiment; Figure 2 This is a detailed implementation diagram of a sequential revenue sharing method for smart terminals, according to an exemplary embodiment. Figure 3 This is a schematic diagram of the hierarchical architecture of a smart terminal sequential revenue sharing system according to an exemplary embodiment. Figure 4 This is a schematic diagram of a smart terminal sequential revenue sharing system according to an exemplary embodiment; Figure 5 This is a schematic diagram of the structure of a computer device according to an exemplary embodiment.

[0022] In the picture: 1. Processor; 2. Internal memory; 3. Network interface; 4. Non-volatile storage medium; 5. Operating system; 6. Computer program; 7. Database; 8. System bus. Detailed Implementation

[0023] The following description and accompanying drawings fully illustrate specific embodiments described herein to enable those skilled in the art to practice them. Some portions and features of certain embodiments may be included in or replace portions and features of other embodiments. The scope of the embodiments herein includes the entire scope of the claims and all available equivalents thereof. The various embodiments described herein are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.

[0024] The modules in the apparatus or system of this application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0025] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0026] Figure 1 An embodiment of a smart terminal sequential revenue sharing method of the present invention is shown.

[0027] In this optional embodiment, the smart terminal sequential revenue sharing method includes: Step S101: When order payment is completed, obtain the strategy identifier by querying the site strategy binding table; the strategy identifier is used to create a revenue sharing order and determine the target strategy details; the revenue sharing order includes revenue sharing status, settlement status, and refund status; Step S102: Execute a combined condition update with business status constraints based on the revenue sharing status and refund status of the revenue sharing order to determine the execution right of revenue processing; Step S103: After obtaining the execution right of revenue processing, perform revenue sharing sequentially according to the revenue sharing order and the details of each target strategy. The model and revenue sharing value determine the revenue sharing amount for the corresponding role, deduct the revenue sharing amount from the remaining amount, and generate revenue sharing details; Step S104: Select the target settlement model according to the merchant configuration, settle the revenue sharing details, and update the corresponding account balance; Step S105: When an order is refunded, query the corresponding revenue sharing order, and perform combined condition updates based on the refund status to determine the execution right of refund processing; After obtaining the execution right of refund processing, determine the refund stage according to the revenue sharing status and settlement status, and determine whether to deduct the corresponding account balance based on the refund stage to complete the refund processing.

[0028] In this optional embodiment, the site policy binding table is used to record the binding relationship between site identifiers and policy identifiers and the corresponding binding status. A single site can have at most one policy identifier in a valid binding state at any given time. The target policy details include revenue type, role type, revenue sharing mode, revenue sharing value, and revenue sharing order, arranged in ascending order. The policy identifier is obtained by querying the site policy binding table, including: when an order payment is completed, querying the site policy binding table based on the site identifier of the site corresponding to the order; if no valid binding record is found, writing the full amount of the order's revenue into the merchant revenue details; if a valid binding record is found, obtaining the policy identifier corresponding to the valid binding record, creating a revenue sharing order, and writing revenue messages after the revenue sharing order is created.

[0029] In this optional embodiment, the target strategy details are configured through a matrix-style revenue sharing strategy model. The matrix-style revenue sharing strategy model includes a main revenue sharing strategy table, a strategy detail table, a strategy change history table, a strategy detail history table, and a site strategy binding table. The main revenue sharing strategy table stores basic information about the revenue sharing strategy. The strategy detail table stores revenue type, role type, revenue sharing mode, revenue sharing value, and revenue sharing order. The strategy change history table and the strategy detail history table store historical snapshots corresponding to different effective dates. The main revenue sharing strategy table establishes a one-to-many relationship with the strategy detail table through a strategy identifier. The site strategy binding table is associated with the main revenue sharing strategy table through a strategy identifier. Each site corresponds to one valid binding record at the same time, and the same revenue sharing strategy can be bound to different sites.

[0030] In this optional embodiment, the matrix-style revenue sharing strategy model expands role types and revenue sharing modes by grouping strategy details. Specifically, it includes: combining the revenue type and revenue sharing mode of each strategy detail to form a grouping key, and dividing strategy details belonging to the same revenue type and the same revenue sharing mode into the same group based on the grouping key; performing role integrity verification on each group to ensure that the group contains all defined role types, specifically including: when the revenue sharing mode is proportional mode, verifying that the sum of the revenue sharing values ​​corresponding to each role in the group is equal to the unit proportion within a preset error range; verifying that the revenue sharing order corresponding to each role in the same group is not repeated and is a continuous positive integer, and verifying that the decimal places of each revenue sharing value do not exceed a preset number of places; when a target strategy detail is determined, querying strategy details with the same revenue type as the order and in an enabled state according to the strategy identifier, and outputting the query results in ascending order of revenue sharing; when a new role type is added, adding the corresponding strategy detail to each group so that the strategy detail corresponding to the new role type enters the query results.

[0031] In this optional embodiment, determining the target strategy details includes: when the revenue sharing strategy is modified, comparing the newly submitted strategy details with the currently effective strategy details in terms of revenue type, role type, revenue sharing mode, revenue sharing value, and revenue sharing order; when at least one field changes, deleting the pending historical snapshots corresponding to the strategy identifier whose effective date is later than the current date, and writing the newly submitted strategy details into the strategy change history table and the strategy detail history table to form a new historical snapshot; setting the effective date of the new historical snapshot to 00:00 on the day following the modification date, and updating the strategy detail table to the newly submitted strategy details; when performing revenue sharing, querying the historical snapshots from the strategy detail history table; querying the historical snapshots based on the date to which the effective date of the strategy identifier belongs and the payment time of the order, and selecting them in descending order of effective date; when the most recent historical snapshot is found, determining the target strategy details based on the most recent historical snapshot; when no corresponding historical snapshot is found, determining the target strategy details based on the current strategy details in the strategy detail table.

[0032] In this optional embodiment, the combined condition update includes revenue processing combined condition update and refund processing combined condition update; the revenue processing combined condition update is an atomic update that uses both the refund status and the split status as update conditions, and modifies the split status according to the update conditions; the refund processing combined condition update is an atomic update that uses the refund status as update conditions, and modifies the refund status according to the update conditions; the split status includes pending split, splitting in progress, splitting completed, and splitting failed; the settlement status includes pending settlement, settlement in progress, settlement completed, and settlement failed; the refund status includes not refunded, refunding in progress, and refunded.

[0033] In this optional embodiment, a combined condition update with business status constraints is performed based on the revenue splitting status and refund status of the revenue splitting order. This includes: when a revenue message is consumed, updating the revenue splitting status to "in progress" with the refund status being "not refunded" and the revenue splitting status being "pending revenue splitting" as update conditions; if the number of records affected by the update meets a preset success condition, the execution right for revenue processing is obtained; otherwise, the current revenue processing is terminated; when a refund request arrives, updating the refund status to "in progress" with the refund status being "not refunded" as update conditions; writing a refund message after a successful update, terminating the current refund processing if the update fails; after revenue processing completes revenue splitting calculation, the refund status is read again; revenue processing continues if the refund status is still "not refunded," and refund processing begins if the refund status is "in progress"; when a refund message is consumed, updating the refund status to "refunded" with the refund status being "in progress" as update conditions, and obtaining the execution right for refund processing after a successful update; wherein each combined condition update is executed by a single atomic update statement in the database, and the result of obtaining the execution right is represented by the number of records affected by the update.

[0034] In this optional embodiment, the revenue sharing mode of the target strategy details includes a proportional mode and a fixed amount mode; wherein, in the proportional mode, the revenue sharing value represents the revenue sharing ratio of the corresponding role relative to the total order amount; in the fixed amount mode, the revenue sharing value represents the agreed amount that the corresponding role should receive; the revenue sharing order is used to determine the priority of the revenue sharing order, the smaller the value of the revenue sharing order, the higher the priority of the corresponding revenue sharing order; the priority of the revenue sharing order is used to determine the order in which each role receives the revenue sharing amount from the current remaining amount; the initial value of the remaining amount is obtained by converting the total order amount of the order into an integer amount expressed in the smallest unit of currency; the revenue sharing details include role type, account identifier, income type, and revenue sharing amount.

[0035] In this optional embodiment, the revenue share for the corresponding role is determined sequentially according to the revenue share mode and revenue share value of each target strategy detail, following the revenue share order: converting the total order amount into an integer amount using a precision conversion factor for the smallest unit of currency; when the revenue share mode for the current target strategy detail is a proportional mode, determining the amount to be allocated based on the product of the total order amount and the revenue share value, rounding down the amount to be allocated to obtain the revenue share for the current role, and recording whether the current role generates a rounding difference; when the current role is the last role in the revenue share order under the proportional mode, determining the current remaining amount as the revenue share for the current role; when the revenue share mode for the current target strategy detail is a fixed amount mode, converting the revenue share value into an integer amount using the smallest unit of currency. The fixed amount is represented, and each role is processed according to the priority of the distribution order from high to low. The smaller value between the fixed amount and the current remaining amount is determined as the distribution amount for the current role. When the current remaining amount is exhausted, the distribution amount for subsequent roles is set to zero, so that roles with higher distribution priority receive the corresponding fixed amount before roles with lower distribution priority. The difference between the total order amount and the sum of the distribution amounts for each role is calculated. According to the priority of the distribution order from high to low, a minimum unit of currency is allocated to each proportional mode role that generates the rounding difference, until the amount difference is cleared to zero, so that proportional mode roles with higher distribution priority receive the minimum unit of currency to make up the rounding difference first.

[0036] In this optional embodiment, the target settlement mode is selected according to the merchant configuration, and the settlement details are settled and the corresponding account balance is updated. This includes: determining whether the target settlement mode for the current settlement order is a real-time settlement mode or a timed aggregated settlement mode based on the settlement mode parameters in the merchant configuration; when the target settlement mode is a real-time settlement mode, generating an independent settlement order number for each settlement detail, writing the settlement order corresponding to the settlement detail into the settlement order table, and writing a settlement message so that the settlement consumer can asynchronously update the corresponding account balance according to each settlement order; when the target settlement mode is a timed aggregated settlement mode, writing the settlement details and keeping the settlement order number of the settlement details empty; querying settlement details with a settlement status of pending settlement and empty settlement order numbers according to a configurable scanning cycle, and forming aggregate groups according to role type, account identifier, and income type; generating a summary settlement order number for each aggregate group, and binding the settlement details belonging to the same aggregate group with the summary settlement order number; the summary settlement order number is used to generate a summary settlement order to merge and settle multiple settlement details corresponding to the same role type, the same account identifier, and the same income type.

[0037] In this optional embodiment, the method for obtaining the aggregated group includes: when the role type is a merchant, reading the merchant identifier from the revenue sharing order and determining the merchant identifier as the account identifier; when the role type is a company, querying the device group data according to the device group serial number corresponding to the order, reading the corresponding company identifier, and determining the company identifier as the account identifier; when the role type is a site, associating site data according to the site policy binding table, reading the corresponding site identifier, and determining the site identifier as the account identifier; writing the determined account identifier and the corresponding account name together with the role type, revenue type, and revenue sharing amount into the revenue sharing details to form an aggregated group based on the written fields.

[0038] In this optional embodiment, a combined condition update is performed based on the refund status to determine the execution right of the refund processing, including: if no revenue-sharing order is found, a negative revenue record for the merchant is generated based on the original revenue record corresponding to the order, and the merchant's account balance is deducted based on the negative revenue record to complete the original refund processing; if a revenue-sharing order is found, the refund stage is determined based on the revenue-sharing status and settlement status, and whether to generate a negative revenue record and whether to deduct the corresponding account balance is selected based on the determined refund stage; when a revenue-sharing order is found, the refund status is updated to "refunding in progress" with the refund status being "not refunded" as the update condition; if the update is successful, a refund message is written; if the update fails, the current refund processing is terminated; when the refund message is consumed, the refund status is updated to "refunded" with the refund status being "refunding in progress" as the update condition; if the update is successful, the execution right of the refund processing is determined, and the refund stage is determined based on the revenue-sharing status and settlement status; if the update fails, the current refund processing is terminated.

[0039] In this optional embodiment, determining the refund stage based on the revenue splitting status and settlement status includes: when the revenue splitting status is "pending splitting" and the settlement status is "pending settlement," it is determined to be the first refund stage, and the refund status is updated to "refunded," without generating a negative income record; when the revenue splitting status is "in progress" and the settlement status is "pending settlement," it is determined to be the second refund stage; revenue processing reads the refund status after the revenue splitting calculation is completed, and stops settlement and transfers to refund processing when the refund status is "in progress," updating the refund status to "refunded," without generating a negative income record; when the revenue splitting status is "completed" and the settlement status is "pending settlement," it is determined to be the third refund stage, and the refund is processed... The status is updated to "Refund Completed" without generating a negative income record. When both the splitting status and settlement status are "Settlement Completed," it is determined to be the fourth refund stage. The splitting details corresponding to each splitting order are queried to obtain the role type, settlement order number, and actual amount received for each role. A negative income record corresponding to the actual amount received is generated for each role to deduct from the corresponding account balance. The transaction identifier of the negative income record is generated based on the original settlement order number and role type to associate the original splitting income with the corresponding refund expenditure. If the splitting status and settlement status do not meet either refund stage, the current status combination is determined to be an abnormal status, and an abnormal handling record is generated.

[0040] It should be noted that this invention provides a method for sequential revenue sharing on smart terminals. It achieves scalable configuration of roles and modes by constructing a matrix-style strategy model containing the revenue sharing order. It utilizes a mechanism that allows policy changes to take effect the following day and a historical snapshot backtracking matching mechanism to manage the policy's time dimension. It employs a hierarchical, progressive amount allocation method based on the revenue sharing order, and a lock-free, end-to-end concurrent security mechanism using multi-field combination conditions to resolve concurrent conflicts between revenue and refunds. It adapts to the settlement needs of different merchants through a dual-mode switching mechanism of real-time settlement and scheduled aggregated settlement. It ensures that revenue sharing messages are not lost through a message reliability guarantee mechanism of write-before-enqueue and differentiated delays. Furthermore, it is supplemented by a four-stage intelligent decision-making process for penetrating refunds and a seamless compatibility mechanism between new and old modes, achieving a complete closed-loop management from policy configuration to revenue sharing calculation and settlement. The specific technical solution is as follows: I. Matrix-based multi-role, multi-mode strategy configuration model based on revenue sharing order: The matrix-style revenue sharing strategy model in this invention refers to a database-level strategy configuration model, falling under the category of relational database table structure design, and does not involve the training process of machine learning or artificial intelligence models. This model achieves flexible configuration and expansion of the strategy through the relationships between multiple database tables and a grouping query mechanism, rather than through training or inference using neural network or other algorithmic models. Those skilled in the art, based on the table structure, field definitions, grouping verification rules, and query process disclosed in this specification, can implement the aforementioned revenue sharing strategy configuration and expansion functions without training any algorithmic models.

[0041] The architecture of this strategy model consists of the following core tables: The main revenue-sharing strategy table stores basic information such as strategy name and status; the strategy details table stores the specific configuration of the strategy, with each record containing five dimensions: revenue type, role type, revenue-sharing mode, revenue-sharing value, and revenue-sharing order; the strategy change history table stores historical snapshots and effective dates of each strategy change; the strategy detail history table stores historical snapshots of each strategy detail change; and the site strategy binding table establishes a one-to-one association between a site and a strategy, meaning that a site can only be bound to one valid strategy at a time, but the same strategy can be bound and used by multiple sites. All these tables are linked through the strategy identifier primary key.

[0042] Specifically, each record in the strategy details table includes five dimensions: income type, role type, revenue sharing mode, revenue sharing value, and revenue sharing order. The revenue sharing order is used to define the order in which the amount is allocated to each role within the same group.

[0043] Specifically, role types refer to the stakeholders participating in revenue sharing. In this system, role types are stored as integer enumeration values, including: 1 for Merchant (terminal owner, the actual owner of the smart cabinet), 2 for Company (operation and management party, the management company responsible for the daily operation and maintenance of the smart cabinet), and 3 for Site (site provider, the venue provider for smart cabinet installation). Adding a new role only requires adding the enumeration value to the code (e.g., 4 for Agent, 5 for Regional Partner), without modifying the core calculation logic.

[0044] Specifically, the strategy details are grouped and managed according to income type and revenue sharing mode, with each group containing revenue sharing configurations for multiple roles. Here, a role's revenue sharing configuration refers to a record in the strategy details table. Each record corresponds to a role's complete revenue sharing rules under a specific income type and revenue sharing mode, consisting of five dimensions: income type and revenue sharing mode determine which group the record belongs to; role type identifies which role the record is configured for; revenue sharing value defines the proportion or fixed amount the role should receive; and revenue sharing order defines the role's allocation order within the group. These five dimensions together constitute a complete revenue sharing configuration record, and none can be omitted. In this invention, the grouping management of income type and revenue sharing mode is implemented through the following specific method and process: The first step is to generate grouping keys. Combine the "Revenue Type" and "Revenue Sharing Mode" fields of each strategy detail record as grouping keys. For example, group "Revenue Type: Grilling Fee" with "Revenue Sharing Mode: Percentage" into one group, "Revenue Type: Grilling Fee" with "Revenue Sharing Mode: Fixed Amount" into another group, and "Revenue Type: Overdue Fee" with "Revenue Sharing Mode: Percentage" into yet another group. The number of grouping keys equals the product of the number of revenue types and the number of revenue sharing modes.

[0045] The second step is to verify the completeness of roles within each group. Each group must contain all defined role types (currently three roles: Merchant, Company, and Site), ensuring that the role configuration within each group is complete.

[0046] The third step is to verify the proportional revenue sharing model. If the revenue sharing model for a group is proportional, then the sum of the revenue sharing values ​​for all roles within that group must equal 1. The verification formula is that the sum of the revenue sharing values ​​for all proportional items must equal 1, with an allowable error range of ±0.0001.

[0047] The fourth step is to verify the uniqueness of the accounting order. The accounting order of each role within the same group must not be repeated and must be consecutive integer values ​​(such as 1, 2, 3).

[0048] Step 5: Verify the accuracy of the revenue split value. The number of decimal places in the revenue split value must not exceed 4.

[0049] Step 6: Grouping and Aggregating Queries. During revenue sharing calculations, first, the revenue type of the current order (gate fee or overdue fee) is obtained. Then, the strategy details for all revenue sharing modes under that revenue type are queried, and processed separately according to the revenue sharing mode. The query statement is: Query all records from the strategy details table whose strategy identifier is equal to the current strategy, whose revenue type is equal to the current order's revenue type, and whose status is enabled, and sort them in ascending order of revenue sharing. This query naturally achieves the grouping and aggregation effect of filtering by revenue type and sorting by revenue sharing order, without requiring additional grouping operations.

[0050] Specifically, the grouping verification rules include: the sum of the revenue sharing values ​​of all roles in the proportional mode is equal to 1, the revenue sharing order within the same group is not repeated, and the number of decimal places in the revenue sharing value does not exceed 4.

[0051] Specifically, this model decouples the number of roles, modes, and revenue sharing order from the core calculation logic through a grouping management mechanism in the details table. That is, when a new role type is added, only the corresponding record needs to be added to the details table and the type value added to the enumeration. The calculation engine automatically adapts to the new grouping dimension through group aggregation, without requiring modification to the revenue sharing calculation code. The specific calculation process for automatically adapting to the new grouping dimension through group aggregation in this invention is as follows: The first step is to expand the enumeration. Add new enumeration values ​​to the code, for example, add a new type value of 4 for the role agent, and update the role type mapping table.

[0052] The second step is to expand the detailed records. In the strategy details table, add a new record for the agent role for each revenue type × revenue sharing mode group. For example, if there were originally 4 groups (2 revenue types × 2 revenue sharing modes), then add 4 new agent detail records, increasing the total number of strategy details from 12 to 16.

[0053] The third step is the automatic adaptation principle. The core logic of the revenue sharing calculation code is as follows: First, query the strategy details (retrieve all records from the strategy details table whose strategy identifier is equal to the current strategy, whose revenue type is equal to the current order revenue type, and whose status is enabled, and sort them in ascending order of revenue sharing). Then, iterate through the query results, allocate the amount in the order of revenue sharing, and finally create a revenue sharing detail record for each role. Since the calculation logic iterates through the query result set rather than hard-coding the processing branches for the three roles, when a record for the agent role is added to the detail table, the query result set will naturally contain 4 records. During the loop iteration, all 4 roles are automatically processed without modifying any calculation code. The versatility of the calculation engine is reflected in the fact that it does not care how many roles there are or what type each role is; it only cares about the triplet of revenue sharing order, revenue sharing mode, and revenue sharing value for each record.

[0054] It should be added that the enumerations in this invention refer to coded fields stored as integer values ​​in the database, whose meanings are defined by constants or enumeration types in the code. Specifically, these include: income type enumerations (1 for grid fee, 2 for overdue fee), role type enumerations (1 for merchant, 2 for company, 3 for site), revenue sharing mode enumerations (1 for percentage, 2 for fixed amount), and a revenue sharing order field where values ​​are consecutive positive integers (e.g., 1, 2, 3…), with smaller values ​​indicating higher priority. Here, 1 represents the first revenue sharing, 2 the second, 3 the third, and so on. These enumeration values ​​are directly stored in database fields, and the type is determined by integer comparison during revenue sharing calculations, resulting in high performance and easy extensibility.

[0055] Specifically, policies establish a one-to-one relationship with websites through the site policy binding table. The site policy binding table acts as a bridge between sites and policies, and its core fields include: site identifier (identifying the specific site), policy identifier (identifying which revenue sharing policy is bound), binding status (1 for bound, 0 for unbound), binding time, and unbinding time. The relationship with the policy details table is as follows: the main policy table establishes a one-to-many relationship with the policy identifiers in the policy details table; the site policy binding table is linked to the main policy table through the policy identifier. A site can only be bound to one valid policy at a time (binding status is 1). During revenue sharing execution, the policy identifier is first retrieved from the binding table using the site identifier, and then the revenue sharing configuration is retrieved from the policy details table using the policy identifier. The binding process is as follows: the operations staff selects the site and policy in the management backend and clicks binding. The system checks whether the site already has a valid binding (binding status is 1). If it does, the status of the old binding is changed to 0 and the unbinding time is recorded. Then, a new record is inserted into the site policy binding table with a binding status of 1 and the binding time being the current time. Orders generated by this site in the future will automatically use the newly bound policy for revenue sharing.

[0056] II. Time-based management mechanism for revenue sharing rules based on the principle of strategy changes taking effect the day after the change and matching with historical snapshots: When a user modifies the details of a revenue-sharing strategy, the system employs a three-stage time-dimensional management approach: change recording, next-day effective date, and retrospective matching. During the change recording stage, the system compares the five fields of the currently effective details with those of the newly submitted details to determine if there have been substantial changes. If changes are found, the new strategy value is written as a historical snapshot to the strategy change history table and the strategy detail history table, with the effective date set to midnight the day after the change date. Simultaneously, all historical records under this strategy that have not yet taken effect (records with effective dates greater than the current date) are deleted to prevent the accumulation of multiple future-effective change records for the same strategy, ensuring that at most one version awaits effective implementation at any given time.

[0057] Specifically, during the next-day effective phase, the strategy change is not actively triggered by a scheduled task, but rather through a passive mechanism that automatically takes effect when the payment date is queried. The specific mechanism is as follows: When a strategy change occurs, the system performs two actions: First, it writes the new strategy value as a historical snapshot into the strategy change history table and the strategy detail history table, setting the effective date to 00:00 on the day following the change date; second, it immediately updates the current strategy detail table with the new value. The current strategy detail table always stores the latest version, while the strategy change history table stores each historical version and its effective date. The system does not have a dedicated scheduled task to activate the new strategy. When an order payment is completed and enters the billing process, the billing engine searches for a matching strategy version in the strategy change history table based on the order's payment time. The query conditions are: the strategy identifier equals the current strategy and the effective date is less than or equal to the order payment date, sorted in descending order by effective date, and the first record is retrieved. If a matching record exists in the history table, the historical snapshot is used; if no matching record exists, the current strategy detail table is used as a fallback. For example, if a user modifies a strategy at 3 PM on July 9th, the effective date is 00:00 on July 10th. After order payment at 6 PM on July 9th, a query of the historical table shows that among records with an effective date less than or equal to July 9th, only the old version history (if any) exists, or there are no matching records (if this is the first change). In this case, the old strategy is used. After order payment at 8 AM on July 10th, a query of the historical table shows that among records with an effective date less than or equal to July 10th, the new version history is matched, therefore the new strategy is used. The core innovation of this mechanism is that the strategy's effectiveness does not rely on a scheduled task actively modifying the data status at midnight the following day. Instead, it is passively triggered during the billing execution phase through a query condition where the effective date is less than or equal to the order payment date, thus achieving a seamless switch. The rule for cleaning up redundant pending versions is as follows: when a strategy changes, the system will delete all historical records under that strategy with an effective date greater than the current date, ensuring that at most one pending version exists at any given time. If a user modifies the strategy twice on the same day, the second modification will delete the pending history generated by the first modification, retaining only the last modification.

[0058] Specifically, during the backtracking and matching phase, when executing the revenue sharing, the system searches the strategy change history table for the most recent historical record whose effective date is less than or equal to the payment date, based on the order payment date. If found, the historical snapshot is used; otherwise, the current strategy details are used. This mechanism achieves precise binding between revenue sharing rules and transaction time, allowing for the reproduction and auditing of revenue sharing rules at any point in time, thus constructing a fully traceable closed loop from strategy changes, historical records, revenue sharing execution to settlement.

[0059] III. Method for allocating remaining funds level by level based on the order of accounting entries: In smart terminal operation contracts, merchants typically enjoy a guaranteed minimum income, which they have priority in receiving; the company collects operation service fees based on the remaining amount after the merchant's allocation; and the site only has the right to allocate the final remaining amount. This hierarchical relationship cannot be achieved through a one-time proportional split, especially when the order amount is insufficient to cover the entire fixed amount. A proportional split would result in all roles receiving an insufficient share, directly violating the contract.

[0060] Unlike existing systems that split all roles equally at once, this invention adopts a method of allocating the remaining amount in a step-by-step manner based on the order of the split, with each role deducting its share from the remaining amount in the order of the split.

[0061] Specifically, the precision conversion factor is a multiplier factor that converts the amount from yuan to fen (cents), with a value of 100. This is determined by the fact that the smallest circulating unit of RMB is the fen, with 1 yuan equal to 100 fen. Multiplying all amounts by 100 and storing and calculating them as integers completely eliminates the precision errors of floating-point arithmetic. The conversion process is as follows: First, input the total order amount in yuan (e.g., 9.99 yuan); second, multiply by the precision conversion factor of 100 to obtain an integer fen value (e.g., 999 fen); third, all subsequent calculations are performed in the integer field of fen; fourth, divide the result by 100 to restore it to yuan. The precision conversion factor is fixed at 100, determined by the smallest unit of RMB, and does not change with business operations.

[0062] First, multiply the total order amount by a precision conversion factor to convert it to integer precision units (cents), and use the entire amount as the initial remaining amount. The proportional mode refers to the revenue share representing the percentage of the total amount that the role should receive, ranging from zero to one. The sum of the revenue shares for all roles in the proportional mode must equal 1. This is suitable for scenarios where revenue is shared according to a contractually agreed-upon ratio, such as 60% for merchants, 25% for companies, and 15% for sites. The fixed amount mode refers to the revenue share representing a fixed amount (unit: yuan) that the role should receive, such as 1.5 yuan for merchants, 0.5 yuan for companies, and 0.3 yuan for sites. Under the fixed amount mode, if the current remaining amount is insufficient to pay the fixed amount for the role, only the remaining amount will be allocated, ensuring that the allocation stops once the amount is exhausted. Subsequent roles will receive zero yuan because their remaining amount is zero. This is suitable for scenarios where each role has a fixed service fee or venue fee agreement. The revenue share mode is a field in the strategy details table. When adding or modifying a strategy, the operations personnel specify the revenue share mode separately for each combination of income type and role type. All roles within the same group must use the same revenue sharing model (i.e., the revenue sharing model in the group key income type plus revenue sharing model must be consistent for all roles within the group). However, different groups can use different revenue sharing models. For example, a percentage-based model can be used for grid fees, while a fixed-amount model can be used for overdue fees. Both models can coexist under the same strategy. Model changes follow the strategy's next-day effective mechanism. That is, after an operations staff member modifies the revenue sharing model for a specific item, the change will take effect at midnight the following day. Orders already paid on that day will still be executed according to the previous model. The system does not automatically switch models; all model selections must be completed by the operations staff in the strategy configuration interface.

[0063] Then, each role is processed sequentially according to the profit-sharing order (1→2→3→…): In proportional mode, the amount due equals the total amount multiplied by the profit-sharing ratio. This amount is rounded down and then deducted from the remaining amount, while recording whether rounding is required; in fixed amount mode, the amount due equals the profit-sharing value. If the amount due is greater than the current remaining amount, only the remaining amount is allocated, stopping allocation when the remaining amount is exhausted. Subsequent roles will also receive zero amount due to zero remaining amount; the last proportional mode role receives all remaining amount directly. After allocation, the difference between the allocated total and the original total is calculated. The difference is then allocated to proportional mode roles that require rounding, one precision unit per role, until it is cleared to zero.

[0064] Specifically, the revenue sharing priority refers to the value of the revenue sharing order field in the strategy details table. This value directly determines the order in which each role participates in the allocation of funds, and also the order in which accuracy error compensation is applied. The priority rules are: the smaller the revenue sharing order value, the higher the priority, meaning it participates in the allocation first; the revenue sharing order within the same group must be unique and consecutive (e.g., 1, 2, 3); during revenue sharing calculation, each role is processed in ascending order of revenue sharing order. The revenue sharing order priority is determined manually by the operations personnel when configuring the revenue sharing strategy, based on the allocation order of the parties agreed upon in the commercial contract. The system does not automatically infer or calculate this. For example, if the contract stipulates that the merchant's guaranteed minimum share has priority, followed by the operations party, and lastly the venue, then in the strategy configuration interface, the merchant's revenue sharing order is set to 1, the company's revenue sharing order is set to 2, and the venue's revenue sharing order is set to 3.

[0065] Specifically, the priority of the revenue sharing order plays a crucial role in both revenue sharing models. In the proportional model, priority determines the order in which precision errors are compensated: due to the rounding down operation, there may be an error of 1 to several cents between the total value allocated proportionally to each role and the original total amount. In this case, based on the revenue sharing order priority from high to low (i.e., the order value from small to large), each role requiring rounding is compensated with one precision unit (i.e., 1 cent) until the error is zero. Roles with higher priority receive compensation first, ensuring that the allocated amount for core roles is not affected by precision loss. In the fixed amount model, priority determines the allocation order when the amount is insufficient: when the total order amount is insufficient to cover the agreed fixed amount for all roles, allocation is done sequentially from high to low priority. Roles with higher priority receive the full agreed amount first, and subsequent roles only receive the remaining amount. Once the remaining amount is exhausted, subsequent roles receive zero. For example, if the total amount is 2 yuan, and the fixed amounts for the three roles are 1.5 yuan for the merchant, 0.5 yuan for the company, and 0.3 yuan for the site, the total is 2.3 yuan, which is greater than 2 yuan. The revenue is distributed in the order of 1, 2, 3: the merchant receives 1.5 yuan (with 0.5 yuan remaining), the company receives 0.5 yuan (with zero yuan remaining), and the site receives zero yuan because it has zero remaining. This priority ensures that the merchant and the company receive the agreed amount, while the site bears the risk of insufficient funds.

[0066] Specifically, the innovation of this invention lies in the deep binding between amount allocation and the order of payment, that is, the first payment recipient deducts from the total amount first, and subsequent recipients deduct from the remaining amount in turn, reflecting the hierarchical progression in the allocation process. For example... Figure 2As shown, the smart terminal sequential revenue sharing method provided in this embodiment includes a revenue sharing calculation process, a settlement execution process, and a refund processing process. In the revenue sharing calculation process, after the order payment is completed, it is first checked whether the site has been bound to a revenue sharing strategy. If a valid strategy exists, the revenue sharing amount for each role is calculated step by step according to the historical strategy version and the revenue sharing order, and the remaining amount is passed on to the subsequent roles. In the settlement execution process, a settlement statement is generated for the revenue sharing result and the corresponding account balance is updated according to the configured real-time settlement mode or timed aggregated settlement mode. In the refund processing process, the refund stage is determined based on the combination result of the revenue sharing status and the settlement status, and the processing logic of direct refund, waiting for income coordination, no settlement required, or generating negative income record is executed respectively to achieve closed-loop management of the entire process of payment, revenue sharing, settlement, and refund.

[0067] IV. A lock-free concurrency security mechanism across the entire connection based on multi-field combination conditions: The system employs database-level multi-field combination condition updates to achieve concurrency safety throughout the entire process of revenue sharing, settlement, and refunds, eliminating the need for a centralized transaction coordinator or distributed locks. Revenue sharing orders simultaneously maintain three status fields: revenue sharing status (0 pending, 1 in progress, 2 completed, 3 failed), settlement status (0 pending settlement, 1 in progress, 2 completed, 3 failed), and refund status (0 not refunded, 1 in progress, 2 refunded). Each stage uses preset combination conditions for concurrency conflict detection, with the specific mechanism as follows: Specifically, the revenue processing flow is as follows: After the revenue message is dequeued from the delayed queue, the revenue splitting consumer first executes a combined condition update. The WHERE condition of the update statement is that both the refund status and the revenue splitting status are 0, updating the revenue splitting status to 1 (in progress). If the number of rows affected by the update is 0, it means that the record has already been marked as refunded by the refund process or has been processed by another revenue consumer, and this process is skipped. If the number of rows affected by the update is 1, it means that this consumer has successfully seized the processing right and continues to execute the subsequent revenue splitting calculation and settlement process. After revenue splitting is completed, the consumer actively checks the refund status of the current record: if the refund status is still 0, the splitting is completed normally; if the refund status has been marked as 1 (in progress), it means that a refund request has arrived during the splitting process, and the refund logic is switched to processing.

[0068] Specifically, the refund processing flow consists of two steps: The first step is refund entry preprocessing. When a refund request arrives, the refund entry service first queries the current status of the order, then executes a combined condition update. The WHERE condition of the update statement is that the refund status equals 0, updating the refund status to 1 (refund in progress). If the number of rows affected by the update is 0, it means the refund status has been modified by other requests, and processing is skipped; if the number of rows affected by the update is 1, it means this refund request has successfully set the refund mark to "refund in progress," and then the refund message is written to a delayed queue (delayed for 60 seconds) for unified processing by the revenue-sharing consumer. The second step is revenue-sharing consumer processing of the refund. After the refund message is dequeued from the delayed queue, the revenue-sharing consumer executes a combined condition update. The WHERE condition of the update statement is that the refund status equals 1, updating the refund status to 2 (refund completed). If the number of rows affected by the update is 0, it means the refund status of the record is not 1, and processing is skipped; if the number of rows affected by the update is 1, it means successful preemption, and the four-stage refund processing logic continues.

[0069] Specifically, the core principle of concurrency mutual exclusion lies in the following: the WHERE condition for revenue processing requires the refund status to be equal to 0, and the WHERE condition for the refund entry also requires the refund status to be equal to 0. Both compete for the mutually exclusive update of the same condition. Therefore, whoever changes the refund status from 0 to its target value first succeeds, and the WHERE condition of the other operation is no longer met, affecting 0 rows. Since a single UPDATE statement in a database is inherently atomic, only one update operation can successfully execute at a time, eliminating the need for application-layer locking or a distributed transaction coordinator. The core innovation of this mechanism lies in the fact that the combined conditions themselves express business constraints. It doesn't simply use optimistic locking, but rather designs multi-field combined conditions with business semantics, naturally binding concurrency conflict detection to business status.

[0070] V. A dual-mode switching mechanism based on real-time settlement and timed aggregated settlement: The system supports two settlement modes, which merchants can switch between via configuration parameters to adapt to different operational scenarios with varying scales and timeliness requirements. In real-time settlement mode, after revenue sharing is completed, a unique settlement order number is immediately generated for each role's revenue sharing details. The settlement order is then inserted into the settlement order table and written to the settlement queue. The settlement consumer asynchronously processes the balance update, making it suitable for merchants with high requirements for timely payment. In scheduled aggregated settlement mode, only revenue sharing details are written after revenue sharing is completed, while the settlement order number field remains empty. A scheduled settlement task scans all merchants' pending revenue sharing details every 5 minutes (configurable), aggregating and grouping the details according to three dimensions: role type, account identifier, and revenue type. Details within the same group share a single aggregated settlement order number.

[0071] Specifically, the account identifier is not part of the strategy configuration, but is dynamically obtained from different data sources based on the role type during revenue sharing execution, and ultimately stored uniformly in the same account identifier field (AccountId) in the revenue sharing details table. The specific retrieval rules are as follows: When the role type is Merchant, the account identifier equals the merchant's own identifier (TenantId), obtained from the Merchant Identifier field of the revenue sharing order; when the role type is Company, the account identifier equals the operating company's identifier (CompanyId), obtained from the Company Identifier field of the Device Group table, with the query condition being the device group serial number; when the role type is Site, the account identifier equals the site's identifier (StationId), obtained from the site strategy binding table associated with the site table. Although the account identifiers for the three roles come from different sources (merchants from the revenue sharing order table, companies from the device group table, and sites from the site table), they are all written into the same account identifier field in the revenue sharing details table, and are uniformly grouped by this field during aggregation settlement, ensuring logical consistency in the aggregation dimension. The account identifier is obtained when the split calculation is completed and the split details are written, and is then determined and stored in the account identifier and account name fields of the split details table. The scheduled settlement task directly reads these two fields from the split details table for aggregation and grouping, without needing to query the external data source again.

[0072] Specifically, the relationship between the five dimensions of the strategy details table and the general strategy details table is as follows: The five dimensions of the strategy details table (income type, role type, revenue sharing mode, revenue sharing value, and revenue sharing order) define who, how, how much money, and the order of revenue sharing, which are abstract rules at the strategy level; while the account identifier defines which specific account the money is allocated to, which is the specific goal of fund disbursement at the execution level. The five dimensions are stored in the strategy details table (platform library), and the account identifier is stored in the revenue sharing details table (tenant library). Together, they constitute a complete link from rule definition to fund disbursement.

[0073] Specifically, this aggregation process uses atomic UPDATE statements in the database to bind settlement order numbers. The mechanism is as follows: A scheduled settlement task scans the revenue details table, finds records with a settlement status of zero (pending settlement) and an empty settlement order number, groups them by three dimensions: role type, account identifier, and income type, and generates a summary settlement order number for each group. Then, an atomic binding update is performed. The WHERE condition of the update statement is that the settlement status equals 0, the settlement order number is empty, and the grouping dimensions match. The SET clause updates the settlement order number to the summary settlement order number. Because a single UPDATE statement in the database is atomic, when multiple scheduled settlement task instances execute concurrently, only the instance that executes the UPDATE first can successfully update the details of the same group (because after the update, the settlement order number is no longer empty, and the WHERE condition of subsequent instances is no longer met), achieving lock-free concurrency safety. Simultaneously, a distributed lock (with a 10-minute expiration time) is used at the task level to prevent multiple instances from repeatedly scanning the same merchant's data. This mechanism balances the timeliness of real-time settlement with the low-frequency advantage of aggregated settlement.

[0074] Specifically, the strategy details table defines the revenue sharing rules, while the revenue sharing details table records the accounting results. The scheduled settlement is based solely on the fixed role types, account identifiers, and income types in the revenue sharing details table, thereby achieving logical decoupling and consistency assurance between rule definition and execution.

[0075] VI. Anomaly Handling Mechanism Based on Four-Stage Intelligent Decision-Making for Penetrating Refunds: When a refund occurs, the system divides the refund scenario into four stages based on the current accounting and settlement status of the accounting order. The accounting status has four possible values ​​(0 Pending Accounting, 1 Accounting in Progress, 2 Accounting Completed, 3 Accounting Failed), and the settlement status has four possible values ​​(0 Pending Settlement, 1 Settlement in Progress, 2 Settlement Completed, 3 Settlement Failed), resulting in a total of sixteen possible state combinations. This invention maps four valid combinations to four processing stages, and considers the remaining combinations as abnormal states. The specific division rules and judgment methods are as follows: The first step is to query the main table of the split order based on the split order identifier to obtain the current split order status and settlement status.

[0076] The second step is to determine the current stage according to the following rules: 1) If the revenue sharing status is zero (pending revenue sharing) and the settlement status is zero (pending settlement), it is classified as Stage 1. In this stage, the order has been recorded as a revenue sharing order but has not yet been processed by the revenue sharing consumer. The refund can be marked as completed directly without generating a negative income record or performing any settlement operations.

[0077] 2) If the revenue sharing status is 1 (in progress) and the settlement status is 0 (pending settlement), it is classified as Phase Two. In this phase, the revenue sharing consumer is performing revenue sharing calculations. The refund entry point first marks the refund status as 1 (refund in progress) and then writes the refund message to a delayed queue. After the revenue sharing calculation is completed but before updating the revenue sharing status to complete, the revenue sharing consumer actively checks the refund status field: if the refund status is still 0, it normally updates the revenue sharing status to complete and continues the settlement process; if the refund status is 1, it indicates that a refund request is pending processing. In this case, the revenue sharing status is not updated to complete, and the refund processing logic is directly switched, i.e., the current status combination is re-determined and the corresponding refund processing is executed (at this time, the status combination is still in progress and pending settlement, processed according to Phase Two, and directly marked as refund complete). This mechanism ensures that the revenue process and the refund process can be correctly coordinated within the revenue sharing time window.

[0078] 3) If the revenue sharing status is 2 (revenue sharing completed) and the settlement status is zero (pending settlement), it is classified as Phase Three. In this phase, revenue sharing calculation has been completed and revenue sharing details have been written, but settlement has not yet been executed. Refunds can be marked as refunds completed directly; there is no need to generate negative income records because the account balances of each role have not actually increased, and there is no balance to be deducted.

[0079] 4) If both the splitting status and settlement status are 2 (splitting completed) and 2 (settlement completed), it is classified as Stage Four. In this stage, both splitting and settlement are complete, and the account balances of each role have actually increased. Refunds require a reverse process: query the original splitting details to obtain the settlement information for each role (role type, settlement order number, actual amount received), iterate through each role to generate a corresponding negative income record, and deduct the corresponding account balance. The transaction number for the negative income record is generated based on the original settlement order number (e.g., REFUND_original settlement order number_role type), ensuring that the refund and original income can be traced through the transaction number.

[0080] The third step involves logging the following combinations of states as abnormal and requiring manual intervention: Split status is zero but settlement status is non-zero (state machine violation: settlement is impossible before splitting); split status is 1 but settlement status is non-zero (splitting is not yet complete and settlement is impossible); split status is 3, indicating splitting failure (the reason for splitting failure needs to be investigated before deciding on the refund processing method); settlement status is 1, indicating settlement in progress (refunds need to be processed after settlement is completed or fails); settlement status is 3, indicating settlement failure (refunds need to be processed after retrying settlement or confirming failure).

[0081] Specifically, the core innovation of this mechanism lies in the fact that refunds are not simply full refunds, but rather refined based on the stage of the order in the revenue sharing and settlement chain: stages one and three do not require generating negative income (because the funds have not yet been actually received), and only stage four requires generating negative income and deducting from the balance. Settled refunds are processed by generating negative income records rather than deleting the original records, ensuring the complete traceability of fund flows. That is, every positive and negative income before and after the refund has an independent record, and the complete fund trajectory can be reconstructed through the transaction number.

[0082] VII. A seamless compatibility mechanism between the old and new models based on entry point diversion, no-strategy fallback, and refund rollback: The system employs three compatibility strategies to achieve a smooth migration from the old model (all revenue goes to the merchant) to the new model (multi-role revenue sharing). The selection of these three compatibility strategies is a step-by-step, automated decision-making process, with the specific decision-making flow as follows: The first step is entry point routing judgment. At the payment callback entry point, the system determines the processing path based on whether the order's site has been bound to a revenue sharing policy. The specific logic is as follows: When the payment callback arrives, the system queries the site policy binding table based on the device group identifier in the order to determine if the site has been bound to a valid revenue sharing policy. If the site policy binding table does not contain a valid binding record for the site (binding status is 1), it means the site has not yet enabled revenue sharing mode, and the original entry path is followed: the full amount of revenue is directly written to the merchant revenue details table, bypassing the revenue sharing engine, and the behavior is completely consistent with before the upgrade. If the site policy binding table contains a valid binding record for the site, it means the site has enabled revenue sharing mode, and the revenue sharing engine entry is used: a revenue sharing order is created and the multi-role revenue sharing process begins. This judgment is based on an objective data existence check: whether a valid binding record for the corresponding site exists in the site policy binding table; if it exists, it is enabled; if not, it is not enabled. This judgment logic does not rely on any subjective classification, and the result is definite and verifiable.

[0083] The second step is the no-strategy fallback decision. When a site with the revenue-sharing mode enabled enters the revenue-sharing engine, the system retrieves the revenue-sharing strategy identifier from the site's strategy binding table and then queries the strategy details table to obtain the specific revenue-sharing configuration. If the strategy details table does not contain any valid detail records for that strategy (status: enabled), the no-strategy fallback strategy is triggered, meaning the revenue-sharing engine automatically allocates all amounts to the merchant role (role type 1), behaving exactly the same as when the revenue-sharing mode is not enabled. If the strategy details table contains valid records, the normal multi-role revenue-sharing process is executed according to the strategy details. It should be noted that the group integrity verification described in Section 3.1 occurs during the strategy saving phase, ensuring complete configuration upon submission; however, this fallback strategy covers runtime scenarios. The strategy passes the integrity verification upon saving, but subsequent operational operations (such as manually disabling all details or deactivating the strategy) may result in no valid details being found during revenue-sharing execution. In addition, this fallback is also triggered when a strategy is newly created but the details have not yet been submitted and saved. This mechanism ensures that regardless of the reason why the strategy details are unavailable, the system will not make a mistake but will gracefully degrade to the old mode behavior.

[0084] The third step is refund rollback determination. When a refund request arrives, the system searches for the original revenue record in the revenue-sharing order table: if a corresponding record is found, it means that the order has been processed by the revenue-sharing engine and will be processed according to the four-stage refund logic of the revenue-sharing engine; if no record is found, it means that the order is historical data generated when the revenue-sharing mode was not enabled, triggering the refund rollback strategy, that is, rolling back to the old mode's refund logic, directly writing negative revenue records and deducting from the merchant's balance.

[0085] It's important to note that in the above three steps, the system does not maintain any classification tags indicating whether a merchant is new or old. All judgments are based on objective data: whether the site is bound to a strategy, whether the strategy has details, and whether the original record exists in the revenue-sharing order table. The entry point diversion strategy allows two processing paths to coexist: sites bound to a strategy use the revenue-sharing engine, while unbound sites use the original path. Different sites under the same merchant can be in different states, achieving a gradual migration at the site level. The no-strategy fallback strategy ensures that the system automatically downgrades when the strategy configuration is incomplete. The refund rollback strategy automatically processes refund requests from historical data. The synergy of these three compatibility strategies allows the new and old systems to coexist for a long time, achieving a smooth upgrade with zero downtime and zero risk. The selection of the above three strategies is entirely based on the existence of objective records in the database, without involving any manual classification or subjective judgment. They are verifiable and repeatable, and those skilled in the art can directly use this logic to achieve seamless compatibility between the new and old systems.

[0086] 8. Message reliability guarantee mechanism based on write-then-enqueue and differentiated delay: The system employs a double-insurance architecture—writing to the database first and then enqueuing—to ensure no revenue sharing messages are lost. During payment callbacks, a revenue sharing order record is first created in the tenant database (initially with a state of 0 awaiting revenue sharing), and the database's auto-incrementing primary key is used as the revenue sharing order identifier. Then, the revenue sharing message is written to a delayed queue in an in-memory cache database. The core innovation of this mechanism lies in the database record serving as a persistent credential for the message. Even if a delayed queue message is lost due to factors such as a database restart or network anomalies, a record with a state of 0 awaiting revenue sharing still exists in the database. Recovery can be manually triggered via the re-revenue sharing function in the management backend, achieving discoverability and recoverability of lost messages. Furthermore, the system uses a differentiated delay strategy based on business semantics: revenue messages are enqueued after a 30-second delay, and refund messages are enqueued after a 60-second delay. The refund delay is twice that of the revenue delay, ensuring that revenue processing completes before refund processing under normal timing. When a refund is executed, revenue has already completed revenue sharing calculations, avoiding concurrent state conflicts between refunds and revenues. After settlement is completed, the system performs multi-level status linkage updates: the settlement consumer updates the settlement order status (until settlement is completed), the associated sub-account details status (until settlement is completed), and checks whether all role details under the sub-account order have been settled and then updates the sub-account order settlement status (until settlement is completed), ensuring the consistency of the status between the main table and the details table. Through the unidirectional flow constraint of the state machine, data splitting caused by partial settlement success is avoided.

[0087] Figure 3 and Figure 4 An embodiment of a smart terminal sequential revenue sharing system of the present invention is shown.

[0088] In this alternative embodiment, such as Figure 3 As shown, the intelligent terminal sequential revenue sharing system includes an entry layer, a strategy configuration layer, a revenue sharing engine layer, and a data persistence layer. The entry layer includes a strategy acquisition module 201; the revenue sharing engine layer includes a permission determination module 202, a sequential revenue sharing module 203, a settlement processing module 204, and a refund processing module 205. Specifically, the entry layer receives payment callback requests and determines the processing path based on the site strategy binding; the strategy configuration layer stores the main revenue sharing strategy table, the strategy detail table, and historical strategy data, providing a configuration basis for revenue sharing rule matching; the revenue sharing engine layer executes revenue sharing status control, sequential amount allocation, settlement processing, and refund stage judgment according to the target strategy; the data persistence layer stores business data such as site strategy binding data, revenue sharing orders, revenue sharing details, and settlement orders; the entry layer determines the processing path based on the strategy configuration provided by the strategy configuration layer and hands over the pending business to the revenue sharing engine layer for execution, while the revenue sharing engine layer reads or updates the business data in the data persistence layer during the processing. The system can also achieve compatibility degradation, which is used to perform corresponding rollback processing when the site is not bound to a valid policy, no valid policy details are found, or no corresponding revenue-sharing order is found when a refund is requested.

[0089] In this alternative embodiment, such as Figure 4 As shown, the strategy acquisition module 201 is used to obtain the strategy identifier by querying the site strategy binding table when the order payment is completed; the strategy identifier is used to create a revenue-sharing order and determine the target strategy details; the revenue-sharing order includes revenue-sharing status, settlement status, and refund status; the permission determination module 202 is used to perform combined condition updates with business status constraints based on the revenue-sharing status and refund status of the revenue-sharing order to determine the execution right of revenue processing; the sequential revenue-sharing module 203 is used to, after obtaining the execution right of revenue processing, sequentially determine the revenue-sharing mode and revenue-sharing value according to the revenue-sharing order of each target strategy detail. The system determines the revenue share for the corresponding role, deducts the revenue share from the remaining amount, and generates revenue share details. The settlement processing module 204 is used to select the target settlement mode according to the merchant configuration, settle the revenue share details, and update the corresponding account balance. The refund processing module 205 is used to query the corresponding revenue share order when an order is refunded, and perform combined condition updates based on the refund status to determine the execution right of refund processing. After obtaining the execution right of refund processing, the system determines the refund stage based on the revenue share status and settlement status, and determines whether to deduct the corresponding account balance based on the refund stage to complete the refund processing.

[0090] In addition, the present invention also provides a computer device, including a memory and a processor 1, wherein the memory stores a computer program 6, and the processor 1 executes the computer program 6 to implement the steps in the above method embodiments.

[0091] In one embodiment, the computer device may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor 1, a memory, and a network interface 3 connected via a system bus 8. The processor 1 provides computing and control capabilities. The memory includes a non-volatile storage medium 4 and internal memory 2. The non-volatile storage medium 4 stores an operating system 5, a computer program 6, and a database 7. The internal memory 2 provides an environment for the operation of the operating system 5 and the computer program 6 stored in the non-volatile storage medium 4. The database 7 stores static and dynamic data. The network interface 3 communicates with external terminals via a network. When the computer program 6 is executed by the processor 1, it implements the steps described in the above method embodiment.

[0092] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0093] In addition, the present invention also provides a storage medium, which is a computer-readable storage medium, on which a computer program 6 is stored, and when the computer program 6 is executed by the processor 1, it implements the steps in the above method embodiments.

[0094] In addition, the present invention also provides a computer program product, which includes a computer program 6, which, when executed by a processor 1, implements the steps in the above method embodiments.

[0095] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by computer program instructions controlling related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0096] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.

Claims

1. A method for sequential revenue sharing in smart terminals, characterized in that, include: When an order payment is completed, the strategy identifier is obtained by querying the site strategy binding table; the strategy identifier is used to create a split order and determine the target strategy details; the split order includes split status, settlement status and refund status; Based on the revenue splitting status and refund status of the order, a combined condition update with business status constraints is performed to determine the execution right for revenue processing; After obtaining the execution right to process the revenue, the revenue share of the corresponding role is determined in the order of revenue sharing according to the revenue sharing mode and revenue sharing value of each target strategy detail. The revenue sharing amount is deducted from the remaining amount, and revenue sharing details are generated. Select the target settlement mode according to the merchant's configuration, settle the aforementioned revenue sharing details, and update the corresponding account balance; When an order is refunded, the corresponding split order is queried, and the combined condition update is performed based on the refund status to determine the execution right of the refund processing; the refund stage is determined according to the split status and settlement status, and it is determined whether to deduct the corresponding account balance based on the refund stage to complete the refund processing.

2. The method for sequential revenue sharing in a smart terminal according to claim 1, characterized in that, The site policy binding table is used to record the binding relationship between site identifiers and policy identifiers and the corresponding binding status. At any given time, a single site may have at most one policy identifier that is in a valid binding status. The target strategy details include income type, role type, revenue sharing mode, revenue sharing value, and revenue sharing order, and are arranged in ascending order according to the revenue sharing order; The step of obtaining the policy identifier by querying the site policy binding table includes: When the order payment is completed, the site policy binding table is queried according to the site identifier of the site corresponding to the order; If no valid binding record is found, the full amount of the order's revenue will be written into the merchant's revenue details. When a valid binding record is found, the strategy identifier corresponding to the valid binding record is obtained, a revenue sharing order is created, and a revenue message is written after the revenue sharing order is created.

3. The method for sequential revenue sharing in a smart terminal according to claim 1, characterized in that, The target strategy details are configured through a matrix-style revenue sharing strategy model; The matrix-style revenue sharing strategy model includes a revenue sharing strategy master table, a strategy detail table, a strategy change history table, a strategy detail history table, and the site strategy binding table. The main table for revenue sharing strategies stores basic information about the revenue sharing strategies; the detailed table for strategies stores income type, role type, revenue sharing mode, revenue sharing value, and revenue sharing order; and the history table for strategy changes and the history table for detailed strategies store historical snapshots corresponding to different effective dates. The revenue sharing strategy master table establishes a one-to-many relationship with the strategy details table through the strategy identifier; the site strategy binding table is associated with the revenue sharing strategy master table through the strategy identifier; the same site corresponds to one valid binding record at the same time, and the same revenue sharing strategy is allowed to be bound by different sites.

4. The method for sequential revenue sharing in a smart terminal according to claim 3, characterized in that, The matrix-style revenue sharing strategy model expands role types and revenue sharing modes by grouping and managing the strategy details, specifically including: The revenue type and revenue sharing mode of each strategy detail are combined to form a grouping key, and strategy details belonging to the same revenue type and the same revenue sharing mode are divided into the same group based on the grouping key; Perform a role integrity check on each group to ensure that the group contains all defined role types; When the target strategy details are determined, based on the strategy identifier, query the strategy details that have the same revenue type as the order and are in the enabled state, and output the query results in ascending order according to the revenue sharing order; When a new role type is added, corresponding strategy details are added to each group so that the strategy details corresponding to the new role type are included in the query results.

5. The method for sequential revenue sharing in a smart terminal according to claim 3, characterized in that, The details of the target strategy include: When the revenue sharing strategy is modified, the newly submitted strategy details are compared with the revenue type, role type, revenue sharing mode, revenue sharing value, and revenue sharing order of the currently effective strategy details. If at least one field changes, the pending historical snapshots corresponding to the strategy identifier with effective dates later than the current date are deleted, and the newly submitted strategy details are written into the strategy change history table and the strategy details history table to form a new historical snapshot. Set the effective date of the new historical snapshot to 00:00 on the day following the modification date, and update the policy details table to the newly submitted policy details; When executing the revenue split, query the historical snapshot from the strategy details history table; When the most recent historical snapshot is found, the target policy details are determined based on the most recent historical snapshot; when no corresponding historical snapshot is found, the target policy details are determined based on the current policy details in the policy details table.

6. The method for sequential revenue sharing in a smart terminal according to claim 1, characterized in that, The combined condition update includes revenue processing combined condition update and refund processing combined condition update; The revenue processing combination condition update is to use both the refund status and the revenue split status as update conditions, and to modify the atomic update of the revenue split status according to the update conditions; The refund processing combined condition update is an atomic update that uses the refund status as the update condition and modifies the refund status according to the update condition; The revenue sharing status includes pending revenue sharing, revenue sharing in progress, revenue sharing completed, and revenue sharing failed; the settlement status includes pending settlement, settlement in progress, settlement completed, and settlement failed; the refund status includes not refunded, refund in progress, and refunded.

7. The method for sequential revenue sharing in a smart terminal according to claim 6, characterized in that, Based on the revenue splitting order's revenue splitting status and refund status, perform a combined condition update with business status constraints, including: When a revenue message is consumed, the revenue status is updated to "in progress" based on the conditions that the refund status is "not refunded" and the revenue sharing status is "pending revenue sharing". When a refund request arrives, the refund status is updated to "refunding in progress" based on the condition that the refund status is "not refunded". A refund message is written after the update is successful, and the refund process is terminated if the update fails. After the revenue processing is completed and the revenue calculation is finished, the refund status is read again; if the refund status is still "not refunded", the revenue processing continues; if the refund status is "refund in progress", the refund processing will begin. When the refund message is consumed, the refund status is updated to "refunded" using the refund status as the update condition, and the right to execute the refund processing is obtained after the update is successful.

8. The method for sequential revenue sharing in a smart terminal according to claim 1, characterized in that, The revenue sharing modes of the target strategy details include a proportional mode and a fixed amount mode; wherein, in the proportional mode, the revenue sharing value represents the revenue sharing ratio of the corresponding role relative to the total order amount; and in the fixed amount mode, the revenue sharing value represents the agreed amount that the corresponding role should receive. The order of revenue sharing is used to determine the priority of revenue sharing. The smaller the value of the order of revenue sharing, the higher the priority of the corresponding revenue sharing. The priority of revenue sharing is used to determine the order in which each role receives the revenue sharing amount from the current remaining amount. The initial value of the remaining amount is obtained by converting the total order amount of the order into an integer amount expressed in the smallest unit of currency; The revenue sharing details include role type, account identifier, income type, and revenue sharing amount.

9. The method for sequential revenue sharing in a smart terminal according to claim 8, characterized in that, The revenue share for each role is determined sequentially based on the revenue sharing model and revenue share value of each target strategy detail, including: The total order amount is converted to the integer amount using the precision conversion factor of the smallest unit of currency. When the revenue sharing mode in the current target strategy details is the proportional mode, the amount to be allocated is determined by multiplying the total order amount by the revenue sharing value. The amount to be allocated is rounded down to obtain the revenue sharing amount for the current role, and it is recorded whether the current role generates a rounding difference. When the current role is the last role in the revenue sharing order under the proportional mode, the current remaining amount is determined as the revenue sharing amount for the current role. When the revenue sharing mode in the current target strategy details is a fixed amount mode, the revenue sharing value is converted into a fixed amount expressed in the smallest unit of the currency, and each role is processed from high to low according to the revenue sharing priority. The smaller value between the fixed amount and the current remaining amount is determined as the revenue sharing amount for the current role. When the current remaining amount is fully allocated, the revenue sharing amount for subsequent roles is determined to be zero.

10. A method for sequential revenue sharing in a smart terminal according to claim 8, characterized in that, Based on the merchant's configuration, select the target settlement mode, settle the aforementioned revenue sharing details, and update the corresponding account balance, including: Based on the settlement mode parameters in the merchant configuration, the target settlement mode for the current split order is determined to be either real-time settlement mode or timed aggregated settlement mode; When the target settlement mode is real-time settlement mode, an independent settlement order number is generated for each sub-detail, the settlement order corresponding to the sub-detail is written into the settlement order table, and a settlement message is written. When the target settlement mode is the timed aggregated settlement mode, write the sub-account details and keep the settlement order number of the sub-account details empty; query the sub-account details with the settlement status pending settlement and the settlement order number empty according to the configurable scanning cycle, and form aggregated groups according to the role type, the account identifier and the income type; A summary settlement number is generated for each aggregation group, and the sub-account details belonging to the same aggregation group are bound to the summary settlement number.

11. A method for sequential revenue sharing in a smart terminal according to claim 10, characterized in that, The methods for obtaining the aggregated groups include: When the role type is a merchant, the merchant identifier is read from the revenue sharing order and the merchant identifier is identified as the account identifier; When the role type is a company, query the device group data according to the device group serial number corresponding to the order, read the corresponding company identifier, and determine the company identifier as the account identifier; When the role type is a site, the site data is associated with the site policy binding table, the corresponding site identifier is read, and the site identifier is determined as the account identifier; The determined account identifier and corresponding account name, along with the role type, income type, and revenue share amount, are written into the revenue share details to form the aggregated group based on the written fields.

12. The method for sequential revenue sharing in a smart terminal according to claim 1, characterized in that, The combined condition update is performed based on the refund status to determine the right to execute the refund processing, including: If the order is not found, a negative revenue record for the merchant is generated based on the original revenue record corresponding to the order, and the merchant's account balance is deducted based on the negative revenue record to complete the original refund process. If the revenue-sharing order is found, the refund stage is determined based on the revenue-sharing status and the settlement status, and the system selects whether to generate a negative income record and whether to deduct the corresponding account balance based on the determined refund stage. When the order for splitting payments is found, the refund status is updated to "refunding in progress" based on the condition that the refund status is "not refunded". When a refund message is consumed, the refund status is updated to "refunded" using the refund status as the update condition. If the update is successful, the execution right to process the refund is determined, and the refund stage is determined based on the accounting status and the settlement status.

13. The method for sequential revenue sharing in a smart terminal according to claim 12, characterized in that, The refund stage is determined based on the aforementioned revenue sharing and settlement status, including: When the revenue sharing status is pending revenue sharing and the settlement status is pending settlement, it is determined to be the first refund stage, and the refund status is updated to refunded without generating a negative income record. When the revenue splitting status is in progress and the settlement status is pending settlement, it is determined to be the second refund stage; the revenue processing reads the refund status after the revenue splitting calculation is completed, and stops the settlement and transfers to the refund processing when the refund status is in progress, updates the refund status to refunded, and does not generate a negative income record; When the revenue sharing status is "revenue sharing completed" and the settlement status is "pending settlement", it is determined to be the third refund stage, and the refund status is updated to "refunded" without generating a negative income record; When the splitting status is splitting completed and the settlement status is settlement completed, it is determined to be the fourth refund stage. The splitting details corresponding to the splitting order are queried, and negative income records corresponding to the actual amount received are generated for each role to deduct the corresponding account balance. If the revenue sharing status and the settlement status do not meet either of the refund stages, the current status combination is determined as an abnormal status, and an abnormal handling record is generated.

14. A smart terminal sequential revenue sharing system, characterized in that, include: The strategy acquisition module is used to obtain the strategy identifier by querying the site strategy binding table when the order payment is completed; the strategy identifier is used to create a split order and determine the target strategy details; the split order includes split status, settlement status and refund status; The permission determination module is used to perform a combination of condition updates with business status constraints based on the revenue splitting status and refund status of the revenue splitting order, so as to determine the execution right of revenue processing; The sequential revenue sharing module is used to determine the revenue sharing amount for the corresponding role according to the revenue sharing mode and revenue sharing value of each target strategy detail after obtaining the execution right of revenue processing, deduct the revenue sharing amount from the remaining amount, and generate revenue sharing details. The settlement processing module is used to select the target settlement mode according to the merchant's configuration, settle the settlement details and update the corresponding account balance; The refund processing module is used to query the corresponding split order when an order is refunded, and to perform the combined condition update based on the refund status to determine the execution right of the refund processing; to determine the refund stage based on the split status and settlement status, and to determine whether to deduct the corresponding account balance based on the refund stage to complete the refund processing.

15. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.

Images