An integral full-life cycle management method, device, equipment and storage medium
Patent Information
- Application Number
- CN202610998087.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-06
- Publication Date
- 2026-10-27
AI Technical Summary
[0003]然而,现有方案在多租户全生命周期管控场景下仍存在以下缺陷:第一,缺乏多级账户体系以及积分全生命周期状态机,导致积分在预冻结、异常解冻、申诉返还等环节容易出现重复扣减、冻结未解冻等资金风险;第二,差异化定价规则与积分状态流转相互脱节,无法在冻结、扣减、返还等不同状态节点中动态确定实际应变更的积分数额,难以实现按租户等级、模型类型及扣减优先级的一致计费;第三,缺少与状态流转操作绑定的全链路不可篡改流水记录,无法满足企业对每一笔积分来源、去向及变更原因的完整追溯与合规审计要求
本申请的技术方案通过先搭建包括租户级账户及归属于其的子账户的多租户积分账户体系,实现了多租户积分的归口管理与隔离,从根本上规避了无分层账户导致的管控混乱;通过定义全生命周期状态及标准化流转规则;通过定义全生命周期状态及标准化流转规则,规范了积分在不同状态节点的变更逻辑,避免了重复扣减、冻结滞留等资金风险;并在积分流转过程中嵌入差异化扣减规则,使计费逻辑跟随积分状态同步执行,解决定价规则与流转脱节、计费标准不统一的问题;最后绑定生成全链路流水记录,确保每笔积分变动可追溯、不可篡改,完全满足企业合规审计与财务对账要求。
Smart Images

Figure CN122989201A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of AI service billing, and in particular to a method, apparatus, device and storage medium for full lifecycle management of points. Background Technology
[0002] Currently, AI content generation platforms have basic capabilities for points management and differentiated pricing, such as setting different unit prices for different tenants, different functional nodes, or different AI models, and recording simple points recharge and deduction logs.
[0003] However, existing solutions still have the following shortcomings in multi-tenant full lifecycle management scenarios: First, the lack of a multi-level account system and a full lifecycle state machine for points makes it easy for points to be deducted repeatedly or frozen without being unfrozen during pre-freezing, abnormal unfreezing, and appeal return stages, resulting in financial risks. Second, the differentiated pricing rules are disconnected from the point status flow, making it impossible to dynamically determine the actual amount of points to be changed at different status nodes such as freezing, deduction, and return, making it difficult to achieve consistent billing based on tenant level, model type, and deduction priority. Third, the lack of a full-link immutable transaction record bound to the status flow operation makes it impossible to meet the enterprise's requirements for complete traceability and compliance audit of the source, destination, and reason for change of each point. Summary of the Invention
[0004] This application provides a method, device, equipment, and storage medium for full lifecycle management of points. By deeply coupling differentiated deduction rules with state transitions and binding them to generate full-link log records, it achieves refined, consistent management and complete traceability of points in multi-tenant scenarios.
[0005] Firstly, this application provides a method for full lifecycle management of points, comprising: constructing a multi-tenant points account system, wherein the multi-tenant points account system includes at least a tenant-level account and sub-accounts belonging to the tenant-level account; defining a full lifecycle state set of points and state transition rules between multiple core states in the full lifecycle state set; responding to a points operation request initiated by a target account, performing a validity check on the points operation request; if the validity check passes, performing a points state transition operation on the points to be operated corresponding to the points operation request in the target account according to the state transition rules, and determining the actual changed points in the points state transition operation according to a preset differentiated deduction rule; and generating a points transaction record corresponding to the points state transition operation based on the actual changed points and the points state transition result.
[0006] In one possible implementation, the validity verification of the points operation request specifically includes: obtaining the available points corresponding to the target account, and determining whether the available points are less than the points to be operated corresponding to the points operation request; obtaining the tenant's cumulative points consumption value and a preset tenant cumulative points consumption limit corresponding to the target account, and determining whether the sum of the tenant's cumulative points consumption value and the points to be operated exceeds the tenant's cumulative points consumption limit; determining whether the target account is the sub-account, and if so, obtaining the sub-account's used points amount in the current period and a preset single-period points usage limit, and determining whether the sum of the points to be operated and the used points amount is greater than the single-period points usage limit; if the available points are less than the points to be operated corresponding to the points operation request, the sum of the tenant's cumulative points consumption value and the points to be operated exceeds the tenant's cumulative points consumption limit, or when the target account is the sub-account, the sum of the points to be operated and the used points amount is greater than the single-period points usage limit, then the validity verification fails; otherwise, the validity verification passes.
[0007] In one possible implementation, the full lifecycle state set includes at least an available state, a frozen state, a consumed state, and a returned state; the flow rules include: when the points operation request is an operation request requiring pre-deduction, the points to be operated are changed from the available state to the frozen state; when the service corresponding to the operation request requiring pre-deduction is successfully completed, the points to be operated are changed from the frozen state to the consumed state; when the service corresponding to the operation request requiring pre-deduction fails or is canceled, the points to be operated are rolled back from the frozen state to the available state; when the points operation request is an immediate consumption request, the points to be operated are directly changed from the available state to the consumed state; when the points operation request is a valid returned state, the points to be operated are changed from the consumed state to the returned state, and the points amount corresponding to the points to be operated are restored to the available points of the target account.
[0008] In one possible implementation, the step of performing a points state transition operation on the points to be operated corresponding to the points operation request in the target account according to the state transition rules specifically includes: determining the corresponding pre-change state and post-change state from the transition rules according to the operation type of the points operation request; determining whether the current core state of the points to be operated is consistent with the pre-change state; if consistent, changing the state of the points to be operated to the post-change state; if inconsistent, refusing to execute the points state transition operation and returning an error message.
[0009] In one possible implementation, determining the actual changed points according to a preset differentiated deduction rule in the points status transition operation specifically includes: obtaining the pricing factor corresponding to the points operation request, wherein the pricing factor includes at least the tenant level corresponding to the target account; querying the differentiated deduction rule according to the pricing factor to determine the points deduction parameter corresponding to the points operation request; and calculating the actual changed points according to the points to be operated corresponding to the points operation request and the points deduction parameter.
[0010] In one possible implementation, the preset differentiated deduction rule further includes an account-level deduction priority rule; after determining the actual changed points according to the preset differentiated deduction rule in the points status transition operation, the method further includes: if the target account is a sub-account, then based on the account-level deduction priority rule, deducting the actual changed points from the sub-account and / or the tenant-level account to which the sub-account belongs; if the target account is a tenant-level account, then deducting the actual changed points only from the tenant-level account; wherein, the account-level deduction priority rule includes at least one of the following: deducting from the sub-account first, and when the available points corresponding to the sub-account are insufficient, deducting from the tenant-level account to which the sub-account belongs; deducting from the tenant-level account first, without occupying the available points of the sub-account; deducting only from the sub-account, and when the available points of the sub-account are insufficient, intercepting the points operation request.
[0011] In one possible implementation, the method for full lifecycle management of points provided in this application further includes: responding to a recharge request initiated by the tenant-level account, adding the points amount corresponding to the recharge amount to the available points corresponding to the tenant-level account, and generating a recharge transaction record; responding to an allocation request initiated by the tenant-level account, allocating the available points in the tenant-level account to the available points of the sub-account belonging to the tenant-level account, and generating an allocation transaction record; and responding to a recycling request initiated by the tenant-level account, recycling unused available points in the sub-account belonging to the tenant-level account to the available points of the tenant-level account, and generating a recycling transaction record.
[0012] Secondly, this application provides a full lifecycle management device for points, comprising: a multi-tenant points account system construction module, a rule definition module, a points operation request response module, an operation execution module, and a points transaction record generation module; wherein, the multi-tenant points account system construction module is used to construct a multi-tenant points account system, the multi-tenant points account system including at least a tenant-level account and sub-accounts belonging to the tenant-level account; the rule definition module is used to define a full lifecycle state set of points and state transition rules between multiple core states in the full lifecycle state set; the points operation request response module is used to respond to a points operation request initiated by a target account and perform a validity check on the points operation request; the operation execution module is used to, if the validity check passes, perform a points state transition operation on the points to be operated corresponding to the points operation request in the target account according to the state transition rules, and determine the actual changed points according to a preset differentiated deduction rule in the points state transition operation; the points transaction record generation module is used to generate a points transaction record corresponding to the points state transition operation based on the actual changed points and the points state transition result.
[0013] Thirdly, embodiments of this application also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.
[0014] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.
[0015] This application provides a method, apparatus, device, and storage medium for the full lifecycle management of integration, which has the following advantages compared with the prior art: The technical solution of this application first establishes a multi-tenant points account system, including tenant-level accounts and their subordinate sub-accounts, to achieve centralized management and isolation of multi-tenant points, fundamentally avoiding the control chaos caused by untiered accounts; by defining the full lifecycle status and standardized flow rules, it standardizes the change logic of points at different status nodes, avoiding financial risks such as duplicate deductions and frozen retention; and by embedding differentiated deduction rules in the points flow process, it ensures that the billing logic is executed synchronously with the points status, solving the problems of pricing rules being disconnected from the flow and inconsistent billing standards; finally, it binds and generates a full-link transaction record to ensure that every points change is traceable and tamper-proof, fully meeting the requirements of enterprise compliance audit and financial reconciliation. Attached Figure Description
[0016] 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.
[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.
[0018] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.
[0019] Figure 1 This is a flowchart illustrating one embodiment of the full lifecycle management method for points provided in this application; Figure 2 This is a schematic diagram of the structure of one embodiment of the points-based full lifecycle management device provided in this application; Figure 3 This is a schematic diagram of the structure of a computer device provided in this application. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0021] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.
[0022] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.
[0023] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0024] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0025] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]." Example 1, see Figure 1 , Figure 1 This is a flowchart illustrating one embodiment of the full lifecycle management method for points provided in this application, as shown below. Figure 1 As shown, the method includes steps 101-105, as detailed below: Step 101: Construct a multi-tenant points account system, which includes at least tenant-level accounts and sub-accounts belonging to the tenant-level accounts.
[0026] In one embodiment, the multi-tenant points account system adopts a two-level subordinate architecture of tenant-level accounts and sub-accounts. The system is built from three parts: account hierarchical architecture, tenant data isolation, and hierarchical permission control, which meets the business needs of unified recharge for tenants and decentralized use of sub-accounts.
[0027] Specifically, regarding the hierarchical account structure: First, a two-tiered account architecture is established. A unique tenant-level account is created for each enterprise tenant. The tenant-level account serves as the unified management carrier for tenant points assets, handling top-level operations such as points top-up, points allocation, points redemption, and global budget configuration. All users under a tenant correspond to independent sub-accounts. All sub-accounts are bound to the unique identifier of their respective tenant-level accounts, forming a subordinate relationship. Sub-accounts can only consume the points quota allocated by the administrator and do not have the ability to independently top up or modify global deduction rules. The hierarchical division distinguishes the management entity and the user entity of points assets.
[0028] Specifically, regarding tenant data isolation: a tenant account isolation mechanism is established to achieve physical isolation storage of all points account data under different tenants. The system attaches a unique tenant identifier as an isolation index to each account balance, points transaction history, allocation record, and budget configuration data. Data of the same tenant-level account and all its subordinate sub-accounts are aggregated into an independent data partition. Before the system executes any points operation such as recharge, allocation, deduction, or query, it forcibly verifies the unique tenant identifier carried in the request. If the identifier does not match, the operation is directly blocked, eliminating the risk of cross-tenant reading and tampering of points data and misappropriation of other tenants' points assets, and ensuring the independent security of each tenant's points assets in a multi-tenant scenario.
[0029] Specifically, regarding tiered access control: a three-tiered role-based access control mechanism is implemented to enhance the control capabilities of the two-tiered account system. Differentiated operational permissions are set for tenant-level accounts and sub-accounts to achieve separation of rights and responsibilities. The tenant super administrator holds all operational permissions for the tenant-level account, including topping up the tenant-level account, allocating points to sub-accounts, reclaiming unused points from sub-accounts, configuring differentiated deduction rules, querying the points flow of all tenant accounts, and setting the overall points budget for the tenant. The tenant financial administrator only has the permissions to view points flow and export reconciliation reports, but no permissions to allocate points, reclaim points, or adjust deduction rules, adapting to enterprise financial reconciliation and auditing scenarios. Ordinary sub-account users can only view their own sub-account's points balance and personal points flow, and can only consume points allocated to their own sub-accounts to call the AI generation function, and cannot access the points data of tenant-level accounts or other sub-accounts. Based on the three supporting designs of two-tiered accounts, tenant data isolation, and tiered access control, a multi-tenant points account system adapted to AI generation business is fully constructed.
[0030] Specifically, the system also includes account-level limit control capabilities, allowing administrators to independently configure the total monthly points usage limit and the single-purchase points limit for each sub-account. When a sub-account initiates a points consumption operation, the system automatically checks whether the points to be consumed and the total points already consumed by the sub-account in the current month exceed the monthly limit, and also checks whether the points to be consumed in a single transaction exceed the single-purchase limit. Once either limit is exceeded, the system automatically intercepts the points operation request and prompts that the limit has been exceeded, helping enterprises to finely manage the scale of employees' daily points usage and prevent a single employee from unrestrainedly consuming the tenant's overall points assets.
[0031] Step 102: Define the full lifecycle state set of the integral and the state transition rules between multiple core states in the full lifecycle state set.
[0032] In one embodiment, the full lifecycle state set includes at least an available state, a frozen state, a consumed state, and a returned state.
[0033] Specifically, the available status refers to the idle state of the points, which can be used normally by the account holder. Points in this state can be used for consumption scenarios such as submitting AI-generated tasks, calling AI functions, or initiating customized service work orders.
[0034] Specifically, a frozen state refers to an intermediate state in which points are temporarily locked due to a user's submission of an operation request that requires pre-deduction. During the frozen period, points cannot be used for any other purpose until subsequent consumption or unfreezing operations are triggered.
[0035] Specifically, the "consumption status" refers to one of the final states where the points have been deducted and included in the platform's revenue, indicating that the points have been actually used.
[0036] Specifically, the "return status" refers to the recovery status where consumed points are returned to the original account's available balance for a specific reason.
[0037] In one embodiment, the full lifecycle state set also includes archived states.
[0038] Specifically, the archived status indicates that the corresponding points transaction record has been reconciled and verified, and has reached the preset retention period. The data is locked and cannot be modified; it can only be queried.
[0039] Specifically, the available state, frozen state, consumed state, and returned state are the core states in the points transfer process, while the archived state serves as the final state for the closed-loop points transfer. All points within an account will belong to a unique state, and any single point can only hold a single state.
[0040] In one embodiment, the flow rule includes: when the points operation request is an operation request that requires pre-deduction, the points to be operated are changed from the available state to the frozen state.
[0041] Specifically, when a user submits an AI-generated task or customized service work order that requires pre-deduction, the system recognizes the operation request as an operation request that requires pre-deduction. At this time, the points to be operated are changed from an available state to a frozen state, and the corresponding points amount is locked from the available balance of the account to ensure that the points are not misappropriated during the task execution.
[0042] In one embodiment, the flow rule includes: when the service corresponding to the operation request that requires pre-deduction is successfully completed, the pending operation points are changed from the frozen state to the consumed state.
[0043] Specifically, when the service corresponding to the pre-deduction request is successfully completed, the content compliance verification is passed, or the work order is accepted, the system will change the frozen points from frozen to consumed, completing the final deduction of the points.
[0044] In one embodiment, the flow rule includes: when the service corresponding to the operation request that requires pre-deduction fails or is canceled, the points to be operated are rolled back from the frozen state to the available state.
[0045] Specifically, when a task fails to execute, content compliance verification fails, work order is canceled, or acceptance fails, the system will restore the frozen points from the frozen state to the usable state, unfreeze them, and return them to the original account, ensuring that the user's points assets are not damaged due to abnormal processes.
[0046] In one embodiment, the flow rule includes: when the points operation request is an immediate consumption request, the points to be operated are directly changed from the available state to the consumed state.
[0047] Specifically, when a user calls an instant AI function that does not require pre-freezing, the system recognizes the operation request as an instant consumption request and directly changes the points to be operated from the available state to the consumed state, skipping the freezing intermediate step, in order to meet the needs of business scenarios with lightweight, low amount or high real-time requirements.
[0048] In one embodiment, the flow rule includes: when the points operation request is a valid return request, changing the points to be operated from the consumed state to the return state, and restoring the points amount corresponding to the points to be operated to the available points of the target account.
[0049] Specifically, when a user's appeal is successful, content is generated abnormally, or invalid consumption is confirmed to be caused by a platform malfunction, the system responds to a valid return request, changes the pending points from the consumption status to the return status, and restores the corresponding points amount to the target account's available points, thereby realizing the ability to retrospectively correct points.
[0050] In one embodiment, the circulation rules include: when the transaction records corresponding to the points are properly recorded and reconciled, and the transaction records exceed the preset retention period, the points records that are in the consumption or return state are changed to the archived state.
[0051] Specifically, after the system completes the accounting and reconciliation of points transactions and verifies that there are no abnormalities, it continuously records the storage time of the transaction data. When the storage time exceeds the preset retention period, it automatically switches the points records corresponding to the consumption and return status to the archived status. After archiving, the corresponding transaction data cannot be modified or deleted, and only query operations are supported, which meets the long-term financial reconciliation and compliance audit storage needs of enterprises.
[0052] In one embodiment, a database transaction guarantee mechanism is provided for all integral state transition operations, serving as the underlying execution constraint for all state transitions.
[0053] Specifically, any cross-state change operation of points is encapsulated as an independent database transaction with atomicity constraints. All associated operations such as account balance updates, points status marking, and transaction record writing must be executed successfully in sync before the transaction can be committed and take effect. If any part of the process is interrupted, the transaction will be rolled back, and the account balance, points status, and transaction records will be restored to the original data before the operation, thus preventing financial risks such as inconsistent points status, abnormal account balances, and missing transaction records caused by partial execution.
[0054] Step 103: In response to the points operation request initiated by the target account, perform a validity check on the points operation request.
[0055] In one embodiment, the points operation request is a consumable points operation request, which is a request initiated by the user to use AI-generated related services and will result in actual points consumption, such as pre-paid AI task requests, instant AI call requests, and points refund requests. This type of request includes three scenarios: first, pre-paid AI task requests, which correspond to operations requiring pre-freezing of points, i.e., users submitting AI generation tasks or initiating customized service work orders; second, instant AI call requests, which correspond to instant consumption operations that do not require pre-freezing, i.e., instant calls to lightweight AI functions or small-amount AI content; and third, points refund requests, which involve refunding consumed points due to platform failures, abnormal content generation, or successful user appeals. Before processing this type of request, the system must sequentially verify the account's available points, the tenant's overall budget, and the sub-account's periodic usage limit; if any dimension exceeds the limit, the operation will be directly blocked.
[0056] In one embodiment, the available points corresponding to the target account are obtained, and it is determined whether the available points are less than the points to be operated corresponding to the points operation request; the cumulative points consumption value of the tenant corresponding to the target account and the preset upper limit of the cumulative points consumption value of the tenant are obtained, and it is determined whether the sum of the cumulative points consumption value of the tenant and the points to be operated exceeds the upper limit of the cumulative points consumption value of the tenant; it is determined whether the target account is the sub-account, and if so, the used points amount of the sub-account in the current period and the preset upper limit of points usage in a single period are obtained, and it is determined whether the sum of the points to be operated and the used points amount is greater than the upper limit of points usage in a single period; if the available points are less than the points to be operated corresponding to the points operation request, the sum of the cumulative points consumption value of the tenant and the points to be operated exceeds the upper limit of the cumulative points consumption value of the tenant, or when the target account is the sub-account, the sum of the points to be operated and the used points amount is greater than the upper limit of points usage in a single period, then the legality check is determined to fail; otherwise, the legality check is determined to pass.
[0057] Specifically, the system first performs multi-dimensional legitimacy checks on the target account initiating the points operation request to ensure that the points consumption operation does not exceed the limits of the account's available balance, the tenant's overall budget, and the sub-account's individual quota. This verification process includes at least three dimensions: available points verification, tenant-level budget verification, and sub-account-level quota verification. If any dimension fails verification, the points operation request is blocked and not executed.
[0058] Specifically, the system reads the target account's real-time available points, extracts the points to be processed for the points operation request, and compares the available points with the points to be processed to determine if the available points are less than the points to be processed. If the available points are less than the points to be processed, this constitutes a basis for determining that the validity check has failed, thus avoiding the risk of deducting points due to account overdraft. The system also returns a message indicating insufficient points balance, guiding the user to recharge or contact the administrator for points allocation.
[0059] Specifically, the system retrieves the cumulative points consumption value of the tenant belonging to the target account, as well as the pre-configured cumulative points consumption limit for the tenant by the tenant administrator. This limit can be customized on a monthly, quarterly, or annual basis. The system then adds the tenant's cumulative points consumption value to the points to be processed and checks if the sum exceeds the tenant's cumulative points consumption limit. If the sum exceeds the budget limit, the validity check fails, the operation request is blocked, and a budget overrun warning is sent to the tenant administrator. This layer of verification is used to control the overall AI generation business cost of the tenant, preventing multiple sub-accounts from dispersing consumption and causing the overall points consumption of the tenant to exceed the limit.
[0060] Specifically, the system first determines the type of the target account initiating the operation. If the target account is a sub-account, it reads the sub-account's used points limit for the current period and the tenant's preset single-period points usage limit. The system then sums the points to be processed with the sub-account's used points limit and checks if the sum exceeds the single-period points usage limit. If the sum exceeds the limit, the validity check fails, the operation request is blocked, and the sub-account's available points for the current period are indicated as insufficient. This controls the points consumption of a single sub-account within the statistical period. If the target account is the tenant's main account, the single-period limit verification process for this sub-account is skipped; because tenant-level accounts do not have a single-period usage limit, their consumption is only constrained by the tenant's total available points and the tenant-level budget limit.
[0061] Specifically, if the available points are less than the points to be processed, or the sum of the tenant's accumulated points consumption and the points to be processed exceeds the tenant's accumulated points consumption limit, or when the target account is a sub-account, the sum of the points to be processed and the used points exceeds the single-cycle points usage limit, any of these conditions will result in the validity check failing. The points operation request will be blocked, and no points status change will be performed. Only when all the above verification conditions are met can the validity check be considered passed, allowing the system to proceed to the subsequent points status transition stage. Through this layered and progressive verification mechanism, the system constructs a security defense line for points consumption from three dimensions: account level, tenant level, and sub-account level, effectively preventing the risks of overspending and budget overruns.
[0062] Specifically, in addition to the three-tiered quota budget verification, the system has built-in abnormal operation interception and detection rules as an additional pre-verification item to prevent the loss of points assets caused by account theft and malicious data fraud.
[0063] Specifically, the abnormal operation interception and detection rules cover three types of risk scenarios: high-frequency continuous point consumption within a short period of time, point consumption initiated by logging in from an unfamiliar device in a different location, and large-amount point consumption in a single transaction that far exceeds the account's historical normal consumption range. When the system identifies any of the above abnormal operations, it automatically triggers a two-factor authentication process; if the user fails the two-factor authentication, it directly intercepts the current point operation request, blocking the abnormal point deduction behavior and avoiding the risk of point loss caused by account theft from the source.
[0064] Step 104: If the legality verification passes, then perform a points status transition operation on the points to be operated corresponding to the points operation request in the target account according to the status transition rules, and determine the actual changed points in the points status transition operation according to the preset differentiated deduction rules.
[0065] In one embodiment, a points state transition operation is performed on the points to be operated corresponding to the points operation request in the target account according to the state transition rules. Specifically, this includes: determining the corresponding pre-change state and post-change state from the transition rules according to the operation type of the points operation request; determining whether the current core state of the points to be operated is consistent with the pre-change state; if consistent, changing the state of the points to be operated to the post-change state; if inconsistent, refusing to execute the points state transition operation and returning an error message.
[0066] Specifically, the system determines the pre-change and post-change states of the current operation based on the operation type of the points operation request, matching the pre-change and post-change states from preset state transition rules. Combined with the platform's deduction, unfreezing, and instant deduction processes, the state mapping relationships for various operation types are as follows: For pre-deduction AI task requests, the pre-change state is available, and the post-change state is frozen; for task completion and acceptance deductions, the pre-change state is frozen, and the post-change state is consumed; for task failures or work order cancellations / unfreezings, the pre-change state is frozen, and the post-change state is available; for instant AI call requests, the pre-change state is available, and the post-change state is consumed; for points return requests, the pre-change state is consumed, and the post-change state is returned. Relying on the fixed mapping relationship between operation types and transition rules, the system can quickly determine the legal points state change path.
[0067] Specifically, before executing a points status change, the system enforces a pre-change status consistency check. The system reads the current status of the points to be operated and compares it with the pre-change status obtained from the flow rules. If they are consistent, it means the points meet the pre-change conditions, and the system executes the status change, updating the current status of the points to be operated to the changed status and simultaneously adjusting the account's available points balance: when changing from an available status to a frozen status, the account's available points are deducted; when changing from a frozen status to a consumed status, the formal deduction is completed; and when changing from a frozen status back to an available status, the account's available points are restored. If the current points status is inconsistent with the pre-change status, it is determined to be an illegal flow, and the system refuses to execute this points status flow operation and returns a status mismatch error message to the calling client to avoid points data corruption caused by illegal cross-state operations; for example, if the points to be operated are currently in a frozen state, and a pre-deduction AI task request is initiated again, the verification will fail and it will be directly blocked.
[0068] Specifically, all points status transition operations rely on the atomic execution of database transactions. A single transaction synchronously completes status consistency verification, updates the core points status, adjusts the available points balance in the account, and writes the corresponding points transaction records. If any step fails, the entire transaction is rolled back, and the points status and account balance are fully restored to the original data before the operation, avoiding discrepancies between the records and the actual situation caused by partial execution. The entire process follows a closed-loop control logic based on matching transition rules according to operation type, verifying the current points status, and atomically executing changes, standardizing all status transitions throughout the points lifecycle, and ensuring the accuracy and completeness of points data from the bottom up.
[0069] In one embodiment, determining the actual changed points based on a preset differentiated deduction rule in the points status transition operation specifically includes: obtaining the pricing factor corresponding to the points operation request, wherein the pricing factor includes at least the tenant level corresponding to the target account; querying the differentiated deduction rule based on the pricing factor to determine the points deduction parameter corresponding to the points operation request; and calculating the actual changed points based on the points to be operated corresponding to the points operation request and the points deduction parameter.
[0070] Specifically, during the points status transition process, the system needs to calculate the actual change points based on the tenant's pre-configured differentiated deduction rules. This distinguishes the points deduction standards for different tenants and different business scenarios, avoiding the problem of insufficient control flexibility caused by a uniform deduction standard for all businesses. The entire calculation process consists of three steps: reading pricing factors, matching differentiated deduction rules, and calculating the actual change points based on the points to be operated. All pricing factors and deduction rules are bound and isolated to tenant identifiers, ensuring that data between multiple tenants does not interfere with each other.
[0071] Specifically, pricing factors are key variables affecting points deduction calculations. These include at least the tenant level of the target account, such as premium partner tenant or regular tenant. Furthermore, depending on the business scenario, they can be expanded to include business type (e.g., text generation, image generation, video generation), AI model specifications (e.g., basic model, high-definition model, professional model), and the time period of the call, among other diverse factors. The system automatically extracts these pricing factors from the context of the points operation request, providing a basis for subsequent differentiated deduction rule matching.
[0072] Specifically, the system uses the acquired pricing factors as search criteria to query the pre-stored set of differentiated deduction rules and match the points deduction parameters that are suitable for the current tenant level and business scenario. These points deduction parameters can be in the form of discount coefficients, fixed deduction ratios, tiered deduction thresholds, etc. Different tenant levels correspond to different deduction parameters, thereby achieving differentiated points deduction at different levels.
[0073] Preferably, the differentiated deduction rules use multi-dimensional pricing factors as matching keys, storing the point unit price and deduction coefficient corresponding to different tenant levels, different business types, different AI model specifications, and different call periods. The system uses the actual pricing factor combination obtained in the steps as the query condition, and performs exact matching or priority matching in the differentiated deduction rule table. If a match is found, the corresponding point unit price and deduction coefficient are extracted as the point deduction parameters for this calculation; if no match is found, it falls back to the system's default point deduction parameters, ensuring that reasonable point deduction parameters are available in any scenario.
[0074] Specifically, the system extracts the value of the points to be operated corresponding to this points operation request, and performs calculations in combination with the points deduction parameters obtained in the previous step to finally calculate the actual points that need to be changed in this status transition. Subsequently, the system will use the actual points change as the basis to perform account balance adjustment and points status switching, and write it into the corresponding points transaction record. The transaction record synchronously records the pricing factor, points deduction parameters, and actual points change, which is convenient for tenants to reconcile and verify accounts.
[0075] Specifically, when system administrators add or adjust deduction rules, they can first configure the rules to apply only to specified tenants or sub-accounts. The rules can then be fully deployed after verification within a gray-scale testing phase. During the gray-scale testing phase, the system dynamically selects between the new and old rules for calculating deduction parameters based on the gray-scale identifier of the requesting tenant or account. This ensures a smooth transition during rule changes and avoids widespread risks to points funds due to incorrect rule configuration. Through the complete process of obtaining pricing factors, matching deduction rules, determining deduction parameters, and calculating actual changed points, the system achieves flexible, precise, and secure differentiated points deduction capabilities, fully adapting to the differentiated operational and pricing needs of different customers in a multi-tenant model.
[0076] In one embodiment, the preset differentiated deduction rules also include account-level deduction priority rules.
[0077] In one embodiment, after determining the actual changed points according to the preset differentiated deduction rules in the points status transition operation, the method further includes: if the target account is a sub-account, then deducting the actual changed points from the sub-account and / or the tenant-level account to which the sub-account belongs, based on the account-level deduction priority rules; if the target account is a tenant-level account, then deducting the actual changed points only from the tenant-level account.
[0078] In one embodiment, the account-level deduction priority rule includes at least one of the following: deducting from the sub-account first, and deducting from the tenant-level account to which the sub-account belongs only when the available points corresponding to the sub-account are insufficient; deducting from the tenant-level account first, without occupying the available points of the sub-account; deducting only from the sub-account, and blocking the points operation request when the available points of the sub-account are insufficient.
[0079] Specifically, the preset differentiated deduction rules include not only tiered deduction rules based on pricing factors and matching points deduction parameters, but also account-level deduction priority rules. These rules are used to regulate the source of actual change points deduction in scenarios with a two-tier account system of tenant master account and subordinate sub-accounts. They clarify the deduction order and logic between sub-accounts and their respective tenant-level accounts, thereby adapting to the differentiated needs of different enterprise customers for points consumption strategies.
[0080] Specifically, after the system calculates the actual change points based on the pricing factor and the points to be processed, it identifies the target account type corresponding to the current operation and then retrieves the account-level deduction priority rules to execute the points deduction operation. If the target account for this operation is a sub-account, the actual change points calculated above will be deducted according to the pre-selected account-level deduction priority rules of the tenant, either solely from the sub-account, solely from the tenant-level account, or a combination of sub-account first and then tenant-level account. If the target account is a tenant-level account, there is no multi-level account deduction scenario, and the actual change points can only be deducted directly from within that tenant-level account.
[0081] Specifically, the account-level deduction priority rules offer several optional configuration modes, allowing tenants to choose at least one deduction logic based on their management needs. The first is a sub-account-first, then tenant master account mode, which prioritizes consuming available points within the sub-account. When the sub-account's available points are insufficient to cover the actual change points, the difference is automatically deducted from the tenant-level account to which the sub-account belongs. The second is a tenant master account-first mode, which directly deducts the actual change points from the tenant-level account without consuming any available points in the sub-account itself. The third is a sub-account-only deduction mode, where all consumption is limited to using only the sub-account's own points. If the sub-account's available points are less than the actual change points, the system directly intercepts the point operation request and does not initiate a fallback deduction from the tenant master account. Different sub-accounts can be configured with independent deduction priority rules, and all rules are bound and isolated to the tenant identifier. The deduction logic between different tenants and different sub-accounts does not interfere with each other, adapting to the needs of multi-tenant hierarchical point management.
[0082] Specifically, through the flexible configuration of the aforementioned account-level deduction priority rules, the system achieves refined control over the source of points deductions within a multi-tenant two-tier account architecture. Tenant administrators can select appropriate deduction priority strategies for tenants based on their own enterprise management strategies, financial accounting methods, and business continuity requirements, and adjust them at any time during operation. Simultaneously, the deduction priority rules and status transition operations are executed atomically within the same database transaction, ensuring the consistency and integrity of priority selection, points deduction, balance updates, and transaction records, providing enterprise customers with flexible, secure, and auditable points consumption control capabilities.
[0083] Step 105: Based on the actual changes in points and the results of point status transitions, generate point flow records corresponding to the point status transition operations.
[0084] In one embodiment, after the points status transition is completed and the actual changed points are deducted according to the account priority rules, the system synchronously generates a points transaction record corresponding to the points status transition operation. Each points change behavior generates a single transaction record independently. The transaction record is used to retain full-link operation information for tenant reconciliation, business traceability and compliance audit.
[0085] In one embodiment, each points transaction record contains complete field information, including at least: transaction number, tenant unique identifier, target account ID, operation type, points balance before operation, actual points changed in this transaction, points balance after operation, associated business ID, operator identifier, operation timestamp, operation IP address, and remarks. The balance before operation, the actual points changed, and the balance after operation satisfy a strict reconciliation relationship: the balance after operation is the sum of the balance before operation and the actual points changed, providing a data foundation for subsequent reconciliation and verification.
[0086] In one embodiment, the integrated transaction records are persistently stored after generation, and the system implements an immutable and undeletable protection mechanism for archived transaction records. All transaction records only support append-only writing; transaction data already written to disk is not allowed to be modified or physically deleted in any form, ensuring the originality and authenticity of the transaction data. For historical transaction records exceeding the preset retention period, the system automatically transfers them to the archive storage area. Archived transaction data still supports read-only queries, but also maintains the constraints of being immutable and undeletable. This design fully meets the stringent requirements of enterprise financial reconciliation, information security compliance, and tax audits regarding the originality and integrity of data.
[0087] In one embodiment, based on transaction records, the system provides multi-dimensional query and export capabilities. Tenant super administrators and financial administrators can perform combined queries by time range, operation type, target account ID, business type, transaction number, etc., to quickly locate all points transfer details within a specific time period. The system also supports exporting query results into standard report formats, facilitating monthly and quarterly reconciliation by financial personnel. Sub-account users can only query and export transaction records limited to their own accounts; they do not have permission to view transaction data for tenant-level accounts or other sub-accounts, adhering to the principle of least privilege.
[0088] Specifically, the system automatically generates tenant-level reconciliation reports daily to verify the consistency between the total recharge amount, total consumption amount, total frozen amount, total refund amount, and available account balance, ensuring that the accounts match the actual balance. Once an anomaly is detected in the reconciliation, the system automatically pushes an alarm notification to the tenant's financial administrator to promptly expose potential discrepancies in funds.
[0089] Specifically, the system also possesses full-scenario intelligent early warning notification capabilities. It can be configured with multiple risk trigger conditions, and when these conditions are met, it automatically pushes warning messages to tenant super administrators and financial administrators via SMS, WeChat, and email. Warning coverage scenarios include: the tenant's total available points balance falling below the administrator's preset security threshold; the tenant's cumulative points consumption reaching the budget warning line; a single large-amount points consumption transaction; the system identifying abnormal points operations from other locations or at high frequencies; and data discrepancies appearing during daily reconciliation verification. Through the aforementioned end-to-end transaction recording, automatic reconciliation, and multi-dimensional intelligent early warning mechanisms, the system provides a robust, traceable, auditable, and proactively risk-alerting data infrastructure for the secure operation of multi-tenant points assets.
[0090] In one embodiment, in response to a recharge request initiated by the tenant-level account, the points corresponding to the recharge amount are added to the available points of the tenant-level account, and a recharge transaction record is generated.
[0091] Specifically, once the points account system is established, the system responds to recharge requests initiated by tenant-level accounts and executes the points recharge process. This recharge operation can only be initiated by the tenant super administrator at the tenant-level account level; ordinary sub-accounts do not have independent recharge permissions, ensuring the uniformity and security of the points asset recharge portal from the source. The tenant super administrator submits a recharge request through the recharge portal provided by the system, and the request must include at least the tenant's unique identifier, the recharge amount, and payment channel information.
[0092] Specifically, upon receiving a recharge request, the system first performs pre-verification. The system verifies whether the requesting user has the necessary super administrator privileges for the tenant; if not, the operation is rejected. It also verifies the validity of the tenant's unique identifier to ensure the target tenant's account is in a normal and usable state. Finally, it verifies whether the recharge amount is within a reasonable and permissible range, such as being greater than zero but not exceeding the single recharge limit. Once all pre-verifications pass, the system guides the user to the corresponding payment channel to complete the actual payment process. Payment channels can include, but are not limited to, mainstream payment methods such as bank transfer, Alipay, WeChat Pay, and UnionPay. The system and payment channels communicate via standard interfaces to create payment orders, asynchronously receive user payment results, and verify signatures.
[0093] Specifically, after a successful payment, the system triggers a points increase operation based on the payment callback result. The system converts the recharge amount into a corresponding points amount according to a preset exchange rate, and then adds this points amount to the available points balance of the target tenant-level account. The newly added points are marked as available by default and can be immediately allocated to sub-accounts by the tenant administrator or directly consumed by the tenant-level account. The points balance update operation is executed within a database transaction to ensure atomicity between account balance changes and subsequent transaction record generation.
[0094] Specifically, in the final stage of the recharge process, the system automatically generates a recharge transaction record. This record includes: a globally unique transaction number, a unique tenant identifier, the target tenant-level account ID, an operation type marked as recharge, the available points balance before the operation, the actual number of points added during the recharge, the available points balance after the operation, the associated payment order number, the recharge channel identifier, the operator, the operation timestamp, and remarks. Once generated, the recharge transaction record cannot be modified or deleted, serving as the core voucher for subsequent financial reconciliation and auditing. Simultaneously, the system sends a successful recharge notification to the tenant administrator via SMS, WeChat Work, or email, informing them of the recharge amount, the number of points credited, and the current total available balance in the tenant's account, thus completing the closed-loop management of the recharge process.
[0095] In one embodiment, in response to an allocation request initiated by the tenant-level account, the available points in the tenant-level account are allocated to the available points of the sub-account belonging to the tenant-level account, and an allocation log record is generated.
[0096] Specifically, after the points recharge process is completed, the system responds to the allocation request initiated by the tenant-level account, distributing the available points in the tenant-level account to the available points of the sub-accounts belonging to that tenant-level account. This allocation operation can only be initiated by the tenant super administrator at the tenant-level account level; ordinary sub-accounts do not have the ability to independently apply for or operate the allocation, thus ensuring centralized control over points allocation permissions. The tenant super administrator submits the allocation request through the allocation portal provided by the system, and the request must include at least the tenant's unique identifier, the target sub-account ID, and the number of points to be allocated.
[0097] Specifically, upon receiving an allocation request, the system first performs strict pre-verification. The system verifies whether the requesting user has the necessary super administrator privileges for the tenant; if not, the operation is rejected outright. It also verifies whether the target sub-account belongs to the current tenant-level account, ensuring that the allocation operation does not cross tenant boundaries. Furthermore, it verifies whether the number of points to be allocated is a positive integer and does not exceed the tenant-level account's currently available points balance. If the tenant-level account has insufficient points, the system directly intercepts the allocation request and prompts an insufficient balance, guiding the administrator to top up their account before proceeding with the allocation operation. If any of the above verifications fails, the allocation request is terminated and not executed.
[0098] Specifically, after all pre-verification checks pass, the system atomically executes the points allocation operation within a database transaction. The system reduces the available points in the tenant-level account by the number of points to be allocated, while simultaneously increasing the available points in the target sub-account by the corresponding number of points. The point balance changes for both accounts are completed within the same transaction, ensuring that the reduction in the tenant-level account and the increase in the sub-account are strictly equal and take effect synchronously, preventing the creation or loss of points due to partial execution success. The allocated points are then marked as available in the sub-account, and the sub-account user can immediately use this amount to invoke the AI-generated points function.
[0099] Specifically, after the allocation operation is completed, the system automatically generates an allocation log record. This log record includes: a globally unique serial number, a unique tenant identifier, a tenant-level account ID, a target sub-account ID, an operation type marked as allocation, the tenant-level account's available balance before the operation, the number of points transferred out in this allocation, the tenant-level account's available balance after the operation, the sub-account's available balance before the operation, the sub-account's available balance after the operation, the operator, the operation timestamp, and remarks. By simultaneously recording the balance changes of both the allocation and sub-accounts, this log record fully reflects the entire trajectory of points flowing from the tenant-level account to the sub-account.
[0100] In one embodiment, in response to a recycling request initiated by the tenant-level account, unused available points in the sub-account belonging to the tenant-level account are recycled to the available points of the tenant-level account, and a recycling log record is generated.
[0101] Specifically, after the points allocation process is completed, the system also supports tenant-level accounts initiating recycling requests. This allows unused available points from sub-accounts belonging to that tenant-level account to be recycled back to the tenant-level account's available points, enabling flexible allocation and centralized management of points. This recycling operation can only be initiated by the tenant super administrator at the tenant-level account level. Ordinary sub-accounts do not have the authority to recycle points themselves or return them to the tenant-level account, ensuring unified control and operational security of the points recycling entry point. The tenant super administrator submits a recycling request through the recycling entry point provided by the system, and the request must include at least the tenant's unique identifier, the target sub-account ID, and the number of points to be recycled.
[0102] Specifically, upon receiving a recycling request, the system first performs strict pre-verification. The system verifies whether the requesting operator has the necessary super administrator privileges for the tenant; if not, the operation is rejected outright. It also verifies whether the target sub-account belongs to the current tenant-level account to ensure that the recycling operation is not executed across tenants. Finally, it verifies whether the number of points to be recycled is a positive integer and does not exceed the target sub-account's current available points balance. If the sub-account's available points are insufficient to cover the number to be recycled, the system directly intercepts the recycling request and prompts the administrator with a message indicating insufficient available points, guiding them to adjust the recycling quantity. If any of the above verifications fails, the recycling request is terminated and not executed.
[0103] Specifically, after all pre-verification checks pass, the system atomically executes the points redemption operation within a database transaction. The system reduces the available points of the target sub-account by the number of points to be redeemed, while simultaneously increasing the corresponding points amount in the available points of its parent tenant-level account. The point balance changes for both accounts are completed within the same transaction, ensuring that the reduction in points for the sub-account and the increase in points for the tenant-level account are strictly equal and take effect synchronously, preventing the creation or loss of points due to partial execution success. The redeemed points are restored to a usable state in the tenant-level account and can be redistributed to other sub-accounts by the tenant administrator or directly consumed by the tenant-level account, achieving dynamic allocation and efficient utilization of the tenant's overall points assets.
[0104] Specifically, after the recycling operation is completed, the system automatically generates a recycling transaction record. This record includes: a globally unique transaction number, a unique tenant identifier, a tenant-level account ID, a target sub-account ID, an operation type marked as recycling, the sub-account's available balance before the operation, the number of points transferred out in this recycling, the sub-account's available balance after the operation, the tenant-level account's available balance before the operation, the tenant-level account's available balance after the operation, the operator, the operation timestamp, and remarks. By simultaneously recording the balance changes of both the recycling and sub-accounts, this transaction record fully reflects the entire trajectory of points flowing back from the sub-account to the tenant-level account, forming a complete credential chain of bidirectional point transfer between the two levels of accounts together with the allocation transaction record. At the same time, the system can push recycling completion notifications to tenant administrators and sub-account users via SMS, WeChat Work, or email, informing them of the number of points recycled and the current available balances of both accounts, forming a closed-loop management of the recycling process.
[0105] Example 2, see Figure 2 , Figure 2 This is a schematic diagram of an embodiment of a points lifecycle management device provided in this application. Corresponding to the above-described points lifecycle management method, this application also provides a points lifecycle management device. This points lifecycle management device includes modules for executing the above-described points lifecycle management method, and can be configured in terminals such as desktop computers, tablets, and laptops. Specifically, the points lifecycle management device includes a multi-tenant points account system construction module, a rule definition module, a points operation request response module, an operation execution module, and a points transaction record generation module. The multi-tenant points account system construction module 201 is used to construct a multi-tenant points account system, which includes at least a tenant-level account and sub-accounts belonging to the tenant-level account.
[0106] The rule definition module 202 is used to define the full life cycle state set of the integral and the state transition rules between multiple core states in the full life cycle state set.
[0107] The points operation request response module 203 is used to respond to a points operation request initiated by the target account and to perform a validity check on the points operation request.
[0108] The operation execution module 204 is used to perform a points status transition operation on the points to be operated corresponding to the points operation request in the target account according to the status transition rules if the legality verification passes, and to determine the actual changed points in the points status transition operation according to the preset differentiated deduction rules.
[0109] The integral log generation module 205 is used to generate an integral log corresponding to the integral state transition operation based on the actual change of integral and the integral state transition result.
[0110] In one embodiment, the points operation request response module 203 is used to perform a legality check on the points operation request, specifically including: obtaining the available points corresponding to the target account, and determining whether the available points are less than the points to be operated corresponding to the points operation request; obtaining the tenant's cumulative points consumption value and a preset tenant cumulative points consumption limit corresponding to the target account, and determining whether the sum of the tenant's cumulative points consumption value and the points to be operated exceeds the tenant's cumulative points consumption limit; determining whether the target account is the sub-account, and if so, obtaining the sub-account's used points amount in the current period and a preset single-period points usage limit, and determining whether the sum of the points to be operated and the used points amount is greater than the single-period points usage limit; if the available points are less than the points to be operated corresponding to the points operation request, the sum of the tenant's cumulative points consumption value and the points to be operated exceeds the tenant's cumulative points consumption limit, or when the target account is the sub-account, the sum of the points to be operated and the used points amount is greater than the single-period points usage limit, then the legality check fails; otherwise, the legality check passes.
[0111] In one embodiment, the full lifecycle state set includes at least an available state, a frozen state, a consumed state, and a returned state; In one embodiment, the flow rules include: when the points operation request is an operation request that requires pre-deduction, changing the points to be operated from the available state to the frozen state; when the service corresponding to the operation request that requires pre-deduction is successfully completed, changing the points to be operated from the frozen state to the consumed state; when the service corresponding to the operation request that requires pre-deduction fails or is canceled, reverting the points to be operated from the frozen state to the available state; when the points operation request is an immediate consumption request, directly changing the points to be operated from the available state to the consumed state; when the points operation request is a valid return request, changing the points to be operated from the consumed state to the return state, and restoring the points amount corresponding to the points to be operated to the available points of the target account.
[0112] In one embodiment, the operation execution module 204 is used to perform a points status transition operation on the points to be operated corresponding to the points operation request in the target account according to the status transition rules. Specifically, it includes: determining the corresponding pre-change status and post-change status from the transition rules according to the operation type of the points operation request; determining whether the current core status of the points to be operated is consistent with the pre-change status; if consistent, changing the status of the points to be operated to the post-change status; if inconsistent, refusing to execute the points status transition operation and returning an error message.
[0113] In one embodiment, the operation execution module 204 is used to determine the actual changed points according to a preset differentiated deduction rule in the points status transition operation. Specifically, it includes: obtaining the pricing factor corresponding to the points operation request, wherein the pricing factor includes at least the tenant level corresponding to the target account; querying the differentiated deduction rule according to the pricing factor to determine the points deduction parameter corresponding to the points operation request; and calculating the actual changed points according to the points to be operated corresponding to the points operation request and the points deduction parameter.
[0114] In one embodiment, the preset differentiated deduction rules also include account-level deduction priority rules.
[0115] In one embodiment, the operation execution module 204 is configured to, after determining the actual changed points according to a preset differentiated deduction rule in the points status transition operation, further be configured to: if the target account is a sub-account, deduct the actual changed points from the sub-account and / or the tenant-level account to which the sub-account belongs, based on the account-level deduction priority rule; if the target account is a tenant-level account, deduct the actual changed points only from the tenant-level account; wherein the account-level deduction priority rule includes at least one of the following: deducting from the sub-account first, and deducting from the tenant-level account to which the sub-account belongs only when the available points corresponding to the sub-account are insufficient; deducting from the tenant-level account first, without occupying the available points of the sub-account; deducting only from the sub-account, and intercepting the points operation request when the available points of the sub-account are insufficient.
[0116] In one embodiment, the points lifecycle management device provided in this application further includes: a recharge operation execution module, an allocation operation execution module, and a recycling operation execution module; wherein, the recharge operation execution module is used to respond to a recharge request initiated by the tenant-level account, add the points corresponding to the recharge amount to the available points of the tenant-level account, and generate a recharge transaction record; the allocation operation execution module is used to respond to an allocation request initiated by the tenant-level account, allocate the available points in the tenant-level account to the available points of the sub-account belonging to the tenant-level account, and generate an allocation transaction record; the recycling operation execution module is used to respond to a recycling request initiated by the tenant-level account, recycle unused available points in the sub-account belonging to the tenant-level account to the available points of the tenant-level account, and generate a recycling transaction record.
[0117] The aforementioned integral lifecycle management device can implement the integral lifecycle management method of the above method embodiments. The options in the above method embodiments are also applicable to this embodiment, and will not be detailed here.
[0118] like Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of a computer device provided in this application; it includes a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112 and the memory 113 communicate with each other through the communication bus 114, and the memory 113 is used to store computer programs.
[0119] In one embodiment of this application, when the processor 111 executes the program stored in the memory 113, it implements the full lifecycle management method of the integral provided in any of the foregoing method embodiments.
[0120] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.
[0121] Therefore, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the full lifecycle management method for integrals as provided in any of the foregoing method embodiments.
[0122] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.
[0123] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.
[0124] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.
[0125] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0126] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.
[0127] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0128] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Since these modifications and variations fall within the scope of the claims and their equivalents, this application also intends to include these modifications and variations.
[0129] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for full lifecycle management of points, characterized in that, include: Construct a multi-tenant points account system, wherein the multi-tenant points account system includes at least a tenant-level account and sub-accounts belonging to the tenant-level account; Define the set of states for the entire lifecycle of the integral and the rules for state transitions between multiple core states in the set of states for the entire lifecycle; In response to a points operation request initiated by the target account, the validity of the points operation request is verified. If the legality verification passes, then the points status transition operation is performed on the points to be operated corresponding to the points operation request in the target account according to the status transition rule, and the actual changed points are determined according to the preset differentiated deduction rule in the points status transition operation. Based on the actual changes in points and the results of point status transitions, a point flow record corresponding to the point status transition operation is generated.
2. The method according to claim 1, characterized in that, The legality verification of the points operation request specifically includes: Obtain the available points corresponding to the target account, and determine whether the available points are less than the points to be operated corresponding to the points operation request; Obtain the cumulative points consumption value of the tenant corresponding to the target account and the preset upper limit of the cumulative points consumption value of the tenant, and determine whether the sum of the cumulative points consumption value of the tenant and the points to be operated exceeds the upper limit of the cumulative points consumption value of the tenant. Determine whether the target account is the sub-account. If so, obtain the sub-account's used points amount in the current period and the preset single-period points usage limit, and determine whether the sum of the points to be operated and the used points amount is greater than the single-period points usage limit. If the available points are less than the points to be operated corresponding to the points operation request, the sum of the tenant's accumulated points consumption value and the points to be operated exceeds the tenant's accumulated points consumption limit, or when the target account is the sub-account, the sum of the points to be operated and the used points amount is greater than the single-cycle points usage limit, then the legality check is determined to fail; otherwise, the legality check is determined to pass.
3. The method according to claim 1, characterized in that, The full lifecycle state set includes at least the available state, frozen state, consumed state, and returned state; The circulation rules include: When the points operation request is an operation request that requires pre-deduction, the points to be operated will be changed from the available state to the frozen state; When the service corresponding to the operation request that requires pre-deduction is successfully completed, the pending points will be changed from the frozen state to the consumed state. When the service corresponding to the operation request that requires pre-deduction fails or is canceled, the points to be operated will be rolled back from the frozen state to the available state. When the points operation request is an immediate consumption request, the points to be operated will be changed directly from the available state to the consumed state. When the points operation request is a valid return request, the points to be operated are changed from the consumed state to the return state, and the points amount corresponding to the points to be operated are restored to the available points of the target account.
4. The method according to claim 1, characterized in that, The step of performing a points status transition operation on the points to be operated corresponding to the points operation request in the target account according to the status transition rules specifically includes: Based on the operation type of the points operation request, determine the corresponding pre-change state and post-change state from the flow rules; Determine whether the current core state of the integral to be operated is consistent with the state before the change; If they match, the state of the integral to be operated on is changed to the changed state; If there is a discrepancy, the integral state transition operation will be refused and an error message will be returned.
5. The method according to claim 1, characterized in that, The determination of the actual changed points in the points status transition operation according to the preset differential deduction rules specifically includes: Obtain the pricing factor corresponding to the points operation request, wherein the pricing factor includes at least the tenant level corresponding to the target account; Based on the pricing factor, query the differentiated deduction rule to determine the points deduction parameters corresponding to the points operation request; The actual changed points are calculated based on the points to be operated corresponding to the points operation request and the points deduction parameters.
6. The method according to claim 5, characterized in that, The preset differentiated deduction rules also include account-level deduction priority rules; After determining the actual changed points according to the preset differential deduction rules in the points status transition operation, the process further includes: If the target account is a sub-account, the actual change points are deducted from the sub-account and / or the tenant-level account to which the sub-account belongs, based on the account-level deduction priority rule. If the target account is a tenant-level account, the actual change points will only be deducted from the tenant-level account; The account-level deduction priority rules include at least one of the following: The deduction is first made from the sub-account, and when the available points corresponding to the sub-account are insufficient, the deduction is then made from the tenant-level account to which the sub-account belongs. The points will be deducted first from the tenant-level account and will not affect the available points of the sub-account. Deduct points only from the sub-account; if the sub-account has insufficient available points, block the points operation request.
7. The method according to claim 1, characterized in that, Also includes: In response to a recharge request initiated by the tenant-level account, the points corresponding to the recharge amount are added to the available points of the tenant-level account, and a recharge transaction record is generated. In response to the allocation request initiated by the tenant-level account, the available points in the tenant-level account are allocated to the available points of the sub-account belonging to the tenant-level account, and an allocation log record is generated. In response to a recycling request initiated by the tenant-level account, unused available points in the sub-account belonging to the tenant-level account are recycled to the available points of the tenant-level account, and a recycling transaction record is generated.
8. A life-cycle management device for integration, characterized in that, include: The system includes a multi-tenant points account system construction module, a rule definition module, a points operation request and response module, an operation execution module, and a points transaction record generation module. The multi-tenant points account system construction module is used to construct a multi-tenant points account system, which includes at least a tenant-level account and sub-accounts belonging to the tenant-level account. The rule definition module is used to define the full life cycle state set of the integral and the state transition rules between multiple core states in the full life cycle state set. The points operation request response module is used to respond to a points operation request initiated by the target account and to perform a validity check on the points operation request. The operation execution module is used to perform a points status transition operation on the points to be operated corresponding to the points operation request in the target account according to the status transition rules if the legality verification passes, and to determine the actual changed points in the points status transition operation according to the preset differentiated deduction rules. The integral log generation module is used to generate an integral log corresponding to the integral state transition operation based on the actual change of integral and the integral state transition result.
9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-7.