Multi-level contract management method and system, electronic equipment and storage medium

Abstract

The invention discloses a multi-level contract management method and system, electronic equipment and a storage medium, and the method comprises the steps: receiving an application of a business contract, and obtaining the customer card accounting information of a current customer; matching a corresponding type of business contract parameter based on the customer card accounting information; generating a current business contract of the current business based on the business contract parameter; the current business contract comprises a client-level business contract and an account-level business contract; if the root-level business contract of the current business in the available state exists, associating the current business contract with superior and subordinate business contracts, and calculating the approval amount of the current business contract and determining business parameters according to the superior and subordinate business contracts; if the root-level business contract of the current business in the available state does not exist, determining business parameters of the current business contract, and setting the current business contract as the root-level business contract; matching the client-level business contract with the account-level business contract; and setting the current business contract as the business contract of the belonging mechanism level.

Description

Technical Field

[0001] This application relates to the field of business information processing, and in particular to a multi-level contract management method and system, electronic device, and storage medium. Background Technology

[0002] For many businesses in the consumer finance industry, the system needs to perform corresponding operations based on the established strategies and information for that business in order to process the business for the customer. For example, in credit card installment business, the system executes according to its corresponding strategies and information to complete the corresponding installment business for the user.

[0003] The current approach to managing strategies and information mainly involves each organization writing corresponding semi-structured scripts and generating corresponding static configuration tables for each product of its launched business, according to its business execution logic. The system then executes the business strategy of that product based on the corresponding semi-structured scripts and static configuration tables, thereby enabling the processing of that product's business.

[0004] However, as customer needs become increasingly diverse, products are becoming more segmented, resulting in a large number of products. Therefore, this approach of writing scripts and configuring information for each product is too cumbersome, inconvenient for timely changes, and the products are independent, making them difficult to manage. Summary of the Invention

[0005] In view of the shortcomings of the prior art, this application provides a multi-level contract management method and system, electronic device and storage medium to solve the problem that the prior art is not convenient for flexible and unified management.

[0006] To achieve the above objectives, this application provides the following technical solution:

[0007] The first aspect of this application provides a multi-level contract management method, including:

[0008] When a business contract application is received, the current customer's card account information is retrieved;

[0009] Match the corresponding type of business contract parameters based on the customer card account information;

[0010] An initial current business contract is generated based on the business contract parameters; wherein, the current business contract includes the current customer-level business contract and the account-level business contract;

[0011] If there is a root-level business contract for the current business that is in an available state, then the current business contract is associated with its superior and subordinate business contracts, and the approval amount of the current business contract and its business parameters are calculated based on its superior and subordinate business contracts.

[0012] If there is no root-level business contract for the current business that is in an available state, determine the business parameters of the current business contract and set the current business contract as the root-level business contract for the current business.

[0013] Match the current customer-level business contract with the account-level business contract;

[0014] Based on the organizational level to which the current business contract belongs, the current business contract is established as a business contract of the corresponding organizational level.

[0015] Optionally, the above-mentioned multi-level contract management method also includes:

[0016] Instantiate the two current business contracts respectively to generate a current contract node corresponding to each current business contract; wherein, the current contract node includes the current technical instance node and the business instance node;

[0017] The two current contract nodes are respectively connected to the contract nodes of the superior business contract in the contract network corresponding to the institution level, and the management and control of the superior contract node are inherited.

[0018] If the current business contract does not belong to the highest level of organization, then the two current contract nodes are connected to the corresponding contract node in the contract network diagram of the highest level of organization, and the management of the contract node of the highest level of organization is inherited.

[0019] Optionally, the above-mentioned multi-level contract management method also includes:

[0020] When a current usage request of a business contract is received, all valid contract nodes of the current user in the contract network are retrieved based on the information in the current usage request.

[0021] Obtain the scenario configuration rules applicable to the current usage request based on the contract adaptation table;

[0022] Based on the scenario configuration rules, scenario matching is performed on each of the retrieved contract nodes to obtain the matching contract nodes;

[0023] Entry and exit contract nodes are determined from each of the matching contract nodes; wherein the entry contract node has no subordinate contract nodes.

[0024] Based on the transaction account matching the current usage request and the contract priority parameter table, the priority of each entry contract node is determined.

[0025] The entry contract nodes are sorted according to priority to obtain the contract candidate queue;

[0026] The contract paths of each entry contract node are checked sequentially according to the contract candidate queue to obtain the final usage result.

[0027] Optionally, in the above-described multi-level contract management method, the step of sequentially checking the contract paths of each entry contract node according to the contract candidate queue to obtain the final usage result includes:

[0028] The contract path of the unchecked entry contract node that is ranked first in the current contract candidate queue is selected as the current target path;

[0029] Starting from the entry contract node of the current target path, each contract node of the current target path is traversed sequentially for inspection; wherein, the usage result of the current target path is obtained by summarizing the inspection results of each contract node;

[0030] If the current target path fails the check, or the spending balance in the spending result of the current target path does not meet the current requirements, then return to the process of selecting the contract path to which the unchecked entry contract node ranks first in the current contract candidate queue belongs as the current target path.

[0031] If the sum of the spending balances in the spending results of each of the checked contract paths meets the current requirement, then the final spending result is generated based on the spending results of each of the checked contract paths.

[0032] If the sum of the withdrawal balances in the withdrawal results of all the contract paths checked does not meet the current requirement, then the withdrawal application will be reported as failed.

[0033] Optionally, in the above-described multi-level contract management method, the step of sequentially traversing each contract node of the current target path, starting from the entry contract node, to perform checks includes:

[0034] Starting from the entry contract node of the current target path, each contract node in the current target path is sequentially traversed as the target contract node;

[0035] If the current type has enabled the account-level control mechanism, then locate the unique account-level business contract instance of the current type under the current transaction account and verify its remaining balance to obtain the current account-level result; wherein, the current type is the type to which the target contract node belongs;

[0036] If the current type has enabled the customer-level control mechanism, then locate the unique customer-level contract instance of the current user's current type and verify its remaining balance to obtain the current customer-level result;

[0037] If the target contract node does not belong to the highest level of organization, then retrieve the instance of the business contract corresponding to the highest level of organization and verify its remaining balance to obtain the current superior result;

[0038] The smaller of the sum of the current account-level result and the current customer-level result, and the current superior result, is determined as the inspection result of the target contract node;

[0039] After checking each contract node of the current target path, the check results of each contract node are summarized to obtain the usage result of the current target path.

[0040] Optionally, the above-mentioned multi-level contract management method also includes:

[0041] When a request to adjust a business contract is received, the request to adjust the business contract is determined.

[0042] Adjust the business contract to be adjusted according to the adjustment target value in the adjustment request, and record the change details;

[0043] In a hierarchical manner, each subordinate business contract of the business contract to be adjusted is addressed sequentially. If the subordinate contract is a business instance, the subordinate contract is adjusted in a coordinated manner, and its change details are recorded, until the subordinate contract is not a business instance or all subordinate business contracts have been adjusted.

[0044] A second aspect of this application provides a multi-level contract management system, including:

[0045] The information acquisition unit is used to acquire the current customer's card account information when a business contract application is received;

[0046] The parameter matching unit is used to match business contract parameters of the corresponding type based on the customer card account information.

[0047] A contract generation unit is used to generate an initial current business contract for the current business based on the business contract parameters; wherein, the current business contract includes the current customer-level business contract and the account-level business contract;

[0048] The first processing unit is used to associate the current business contract with its superior and subordinate business contracts when there is a root-level business contract of the current business that is in an available state, and to calculate the approval amount of the current business contract and determine its business parameters based on its superior and subordinate business contracts.

[0049] The second processing unit is used to determine the business parameters of the current business contract and set the current business contract as the root business contract of the current business when there is no root business contract of the current business that is in an available state.

[0050] A contract matching unit is used to match the current customer-level business contract with the account-level business contract;

[0051] The contract establishment unit is used to establish the current business contract as a business contract of the corresponding institutional level based on the institutional level to which the current business contract belongs.

[0052] Optionally, the aforementioned multi-level contract management system also includes:

[0053] An instantiation unit is used to instantiate the two current business contracts respectively, generating a current contract node corresponding to each current business contract; wherein, the current contract node includes a current technical instance node and a business instance node;

[0054] The first connection unit is used to connect the two current contract nodes to the contract nodes of the superior business contract in the contract network corresponding to the institution level, and to inherit the control of the superior contract node.

[0055] The second connection unit is used to connect the two current contract nodes to the corresponding contract nodes in the contract network diagram of the highest institution level when the current business contract does not belong to the highest institution level, and to inherit the management of the contract nodes of the highest institution level.

[0056] Optionally, the aforementioned multi-level contract management system also includes:

[0057] The retrieval unit is used to retrieve all valid contract nodes of the current user in the contract network based on the information of the current request when a current usage request of a business contract is received.

[0058] The rule acquisition unit is used to acquire the scenario configuration rules applicable to the current usage request based on the contract adaptation table;

[0059] A scenario matching unit is used to perform scenario matching on each of the retrieved contract nodes based on the scenario configuration rules to obtain a matching contract node.

[0060] A node determination unit is used to determine entry and exit contract nodes from each of the matching contract nodes; wherein the entry contract node has no lower-level contract nodes;

[0061] The priority determination unit is used to determine the priority of each entry contract node based on the set identifier matched by the transaction account in the current payment request and the contract priority parameter table.

[0062] A sorting unit is used to sort the various entry contract nodes according to their priority to obtain a contract candidate queue;

[0063] The inspection unit is used to inspect the contract paths of each entry contract node in sequence according to the contract candidate queue to obtain the final usage result.

[0064] Optionally, in the aforementioned multi-level contract management system, the inspection unit includes:

[0065] The selection unit is used to select the contract path of the unchecked entry contract node that is ranked first in the current contract candidate queue as the current target path.

[0066] The path checking unit is used to sequentially traverse each contract node of the current target path, starting from the entry contract node, and check them; wherein the usage result of the current target path is obtained by summarizing the check results of each contract node.

[0067] The return unit is used to return to the execution of the selection unit when the current target path fails the check or the spending balance in the spending result of the current target path does not meet the current requirements.

[0068] The result generation unit is used to generate a final expenditure result based on the expenditure results of each of the checked contract paths when the sum of the expenditure balances in the expenditure results of each of the checked contract paths meets the current requirements.

[0069] The feedback unit is used to report a failure in the payment request when the sum of the payment balances in the payment results of all the contract paths that have been checked does not meet the current requirement.

[0070] Optionally, in the aforementioned multi-level contract management system, the path checking unit includes:

[0071] The traversal unit is used to sequentially traverse each contract node in the current target path as a target contract node, starting from the entry contract node of the current target path.

[0072] The first checking unit is used to locate the unique instance of the account-level business contract of the current type under the current transaction account and verify its remaining balance if the account-level control mechanism of the current type has been enabled, so as to obtain the current account-level result; wherein, the current type is the type to which the target contract node belongs;

[0073] The second checking unit is used to locate the unique customer-level contract instance of the current user's current type and verify its remaining balance if the current type has enabled the customer-level control mechanism, so as to obtain the current customer-level result.

[0074] The third inspection unit is used to retrieve the instance of the business contract at the highest level of the organization and verify its remaining balance if the target contract node does not belong to the highest level of the organization, so as to obtain the current superior result.

[0075] The result selection unit is used to determine the smaller value among the sum of the current account-level result and the current customer-level result and the current superior result as the inspection result of the target contract node.

[0076] The summarization unit is used to summarize the inspection results of each contract node after checking the current target path, so as to obtain the usage result of the current target path.

[0077] Optionally, the aforementioned multi-level contract management system also includes:

[0078] The contract adjustment determination unit is used to determine the business contract to be adjusted when a business contract adjustment request is received.

[0079] The direct adjustment unit is used to adjust the business contract to be adjusted according to the adjustment target value in the adjustment request, and record its change details;

[0080] The linkage adjustment unit is used to sequentially adjust each subordinate business contract of the business contract to be adjusted according to the hierarchy. If the subordinate contract is a business instance, the subordinate contract is adjusted in a linkage manner, and its change details are recorded, until the subordinate contract is not a business instance or all subordinate business contracts have been adjusted.

[0081] A third aspect of this application provides an electronic device, comprising:

[0082] Memory and processor;

[0083] The memory is used to store programs;

[0084] The processor is used to execute the program, which, when executed, is specifically used to implement the multi-level contract management method as described in any of the above.

[0085] The fourth aspect of this application provides a computer storage medium for storing a computer program, which, when executed by a processor, is used to implement the multi-level contract management method as described in any of the preceding claims.

[0086] This application provides a multi-level contract management method. When a business contract application is received, the current customer's card account information is obtained, and the corresponding business contract parameters are matched based on the customer card account information. Then, an initial current business contract is generated based on the business contract parameters. The current business contract includes the current customer-level business contract and the account-level business contract. Therefore, various strategies are managed through business contracts, linked via parameterized configuration, and rules and parameters are decoupled. This parameterized configuration method not only improves the flexibility and maintainability of business strategies. Next, if a root-level business contract for the current business exists and is in an available state, the current business contract is associated with its parent and child business contracts, and the approval amount and business parameters of the current business contract are calculated based on these contracts. If no root-level business contract for the current business exists and is in an available state, the business parameters of the current business contract are determined, the current business contract is established as the root-level business contract for the current business, and the current customer-level and account-level business contracts are matched. Finally, based on the institution level to which the current business contract belongs, it is established as the business contract of that institution level. By constructing a multi-dimensional and multi-level contract network structure between customer level and account level, head office and branch office, and superior and subordinate levels, the business strategy can be flexibly defined and updated, significantly improving the flexibility of business strategy and achieving unified management, which facilitates management. Attached Figure Description

[0087] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0088] Figure 1 A flowchart of a multi-level contract management method is provided for embodiments of this application;

[0089] Figure 2 A flowchart illustrating a method for instantiating a business contract as provided in an embodiment of this application;

[0090] Figure 3 A schematic diagram of a network for an account-level instance and a service-level instance provided in an embodiment of this application;

[0091] Figure 4 A schematic diagram of a network of head office instances and branch instances provided for an embodiment of this application;

[0092] Figure 5 A flowchart illustrating a method for invoked a business contract as provided in an embodiment of this application;

[0093] Figure 6 A flowchart illustrating a method for checking multiple paths, provided in an embodiment of this application;

[0094] Figure 7 A flowchart illustrating a method for inspecting a single path, provided as an embodiment of this application;

[0095] Figure 8 A flowchart illustrating a method for maintaining a business contract as provided in an embodiment of this application;

[0096] Figure 9 A schematic diagram of the architecture of a multi-level contract management system provided for embodiments of this application;

[0097] Figure 10 This is a schematic diagram of the architecture of an electronic device provided in an embodiment of this application. Detailed Implementation

[0098] 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, and 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.

[0099] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0100] This application provides a multi-level contract management method, such as... Figure 1 As shown, it includes:

[0101] S101. When a business contract application is received, obtain the current customer's customer card account information.

[0102] The business contract is a configuration unit used to control parameters in a defined business process. It specifically includes a unique code, configuration parameters, and control measurements. For example, it's a configuration unit used to control parameters such as approval fees, installment periods, approved amounts, and discounts in credit card installment plans. All business strategies in the system are managed in the form of business contracts, facilitating unified management and dynamic configuration.

[0103] By introducing business contracts, business rules and parameters are decoupled, enabling comprehensive coverage of differentiated business needs across various customers, consumption channels, and merchants. Business personnel only need to predefine and configure relevant parameters in the system, such as customer credit rating, transaction amount range, consumption channel identifier, merchant category, and repayment period, to dynamically generate various strategies suitable for specific scenarios. This parameterized configuration approach not only enhances the flexibility and maintainability of business strategies but also significantly shortens the launch and adjustment cycle of new businesses, meeting the demand for personalized and refined pricing in a diversified market.

[0104] Therefore, when generating a business contract that meets the current needs of a customer, a business contract application is initiated. At this time, the customer's customer card account information will be obtained to generate a business contract that conforms to the current user. The customer information is obtained only with the customer's authorization and within a fixed scope.

[0105] It should be noted that the parameters for business contracts can be designed according to the specific business. For example, for credit card installment business, the parameters shown in Table 1 below can be designed.

[0106] The system includes a pre-defined, globally unique business contract code for hierarchical checks and routing decisions in multi-link or single-link scenarios. It supports multiple sets of parallel product codes, with the user's selected product directly impacting subsequent risk control paths and results. For example, it determines the pricing contract type for installment products; such as auto installment products, a customized auto installment pricing contract will be created for the customer. The affiliated institution level parameter distinguishes between different institutions; for example, in a bank, the head office is uniformly instantiated and maintained by the head office, while the branch can be independently issued and adjusted by each branch. The base fee rate issued during the account opening and setup phase provides a baseline for all pricing rules. The approval period is flexibly configurable and adjusts in conjunction with the installment product. The approval fee rate and approval amount represent the fee rate and maximum amount that can be processed for the customer's installment purchase. The upper-level contract number, in the "percentage of upper-level nodes occupied" mode, is responsible for dynamically calculating the available approval amount for lower-level nodes. The contract status parameter can automatically mark expired or exhausted contracts as unavailable and close all lower-level dependencies. The control method can specify three logics: "occupying the upper-level percentage," "occupying the lower-level maximum value," or "summarizing the lower-level nodes," to meet different business needs. When checking the hierarchical parameters to determine disbursement, customer-level, account-level, or two-level collaborative verification is performed. The percentage parameter of the upper-level nodes is used to accurately calculate the amount that can be approved by the child nodes. The discount ratio is used for marketing incentives during the card opening and account creation phase and also follows multi-level verification. Based on the system's front-end hot-reloading and canary release capabilities, operations personnel can add, adjust, or roll back any parameters without interrupting service.

[0107] When a transaction is finalized, the above parameters are integrated into a multi-level rule chain of "lower-level node - higher-level node", "account level - customer level", and "branch level - head office level". This chain sequentially completes activation status detection, list and scenario matching, approval amount verification, fee calculation and discount application, and works in conjunction with external risk control modules to output the final installment interest rate and handling fee. This constructs a highly flexible, maintainable installment pricing system that balances personalized marketing and overall risk control.

[0108] Table 1

[0109]

[0110] S102. Match the corresponding type of business contract parameters based on the customer card account information.

[0111] Specifically, based on the type of business contract that needs to be applied for and the information reflected in the customer card account, the corresponding business contract parameters configured above are matched to facilitate the generation of a business contract that meets the current requirements based on the configured business contract parameters.

[0112] S103. Generate the initial current business contract based on the business contract parameters.

[0113] The current business contracts include current customer-level business contracts and account-level business contracts.

[0114] It should be noted that, in this embodiment, three dimensions enable refined and configurable control over business contracts: First, the vertical linkage between the customer and account levels achieves global control from individual account behavior to the overall customer profile. Second, the hierarchical authorization and strategy inheritance mechanism between various institutions, such as the head office and branches, ensures the uniformity of core pricing strategies and the synergy of regionally differentiated business capabilities. Third, the chain dependency and approval amount occupancy relationship between higher-level and lower-level business contracts allow the business model to be configured from top to bottom and form dynamic linkage control.

[0115] Therefore, when generating business contracts, it is necessary to create both customer-level business contracts and account-level business contracts. Customer-level business contracts are defined at the customer level and are used to globally control business strategies across all accounts under a specific customer. They are typically suitable for high-value customers, customized strategies, or large-scale control logic. Account-level contracts are defined at the account level and only apply to business transactions within that specific account. They are suitable for personalized or scenario-based strategies.

[0116] It should be noted that since different business transactions generate different business contracts, their lifecycle logic also differs. Therefore, it is necessary to generate the initial current business contract for the previous business based on the current business and its contract parameters. For example, for installment payments within a credit limit, the current business contract is generated based on the scenario. For special installment payments, the current business contract is generated based on the installment product.

[0117] S104. Determine if there is a root-level business contract for the current business that is in an available state.

[0118] It should be noted that in this embodiment of the application, the chain dependency and approval amount occupation relationship between the upper-level business contract and the lower-level business contract are taken into consideration. Therefore, it is necessary to determine whether the currently created business contract has a root-level business contract. If a root-level business contract exists, it is determined whether it is in an available state so as to determine whether it has an upper-level business contract that it depends on, so as to perform the corresponding processing.

[0119] If a root-level business contract for the current service exists and is in an available state, then proceed to step S105. If no root-level business contract for the current service exists and is in an available state, then proceed to step S106.

[0120] S105. Associate the current business contract with its superior and subordinate business contracts, and calculate the approval amount of the current business contract and determine its business parameters based on its superior and subordinate business contracts.

[0121] Specifically, the parent and child business contracts are determined and associated based on the type of the current business contract. Then, the approval amount for the current business contract is calculated using the parameters from the parent and child business contracts, i.e., the approval amount for the current business contract is determined based on the relationship between the approval amount and the contract. Other business parameters are then determined, such as the approval fee rate, customer-level discount ratio, and account-level discount ratio.

[0122] S106. Determine the business parameters of the current business contract and set the current business contract as the root-level business contract of the current business.

[0123] Since there is no root-level business contract, the business parameters are calculated directly based on the configuration parameters, such as the approval fee rate, customer-level discount ratio, and account-level discount ratio. Furthermore, the current business contract is set as the root-level business contract for the current business.

[0124] S107. Match the current customer-level business contract with the account-level business contract.

[0125] Since there is no root-level business contract, in order to establish the relationship between the current client-level business contract and the account-level business contract, the current client-level business contract and the account-level business contract are matched.

[0126] S108. Based on the organizational level to which the current business contract belongs, establish the current business contract as a business contract of the organizational level to which it belongs.

[0127] Since business contracts belonging to different organizational levels have clear boundaries in terms of access control, instantiation process and subsequent management, the final business contract needs to be generated according to its organizational level.

[0128] Optionally, in another embodiment of this application, to facilitate the management of various business contracts, a method for instantiating business contracts is provided, such as... Figure 2 As shown, it includes:

[0129] S201. Instantiate the two current business contracts respectively, and generate the current contract node corresponding to each current business contract.

[0130] The current contract node includes the current technical instance node and the business instance node.

[0131] In this embodiment, the business contract is viewed as a distributed network composed of hundreds or even thousands of "parameterized nodes." By attaching metadata such as "installment pricing contract code," "base rate," "MCC category," "merchant black / white list management method," "inspection level," "discount ratio," and "upper-level contract reference" to the nodes, a multi-dimensional directed acyclic graph topology is dynamically constructed at runtime, interwoven with customer-level and account-level, head office and branch, and upper-level and lower-level contracts. This facilitates the subsequent parallel triggering of account-level and customer-level node verification by the graph traversal engine based on the preset "use inspection level" parameter during usage. The available approval amount for each node is recursively calculated through a multi-path calculation strategy. Subsequently, the upper-level backtracking and degradation processing is completed under the protection of concurrency locks and version control mechanisms. Finally, the accurate installment rate is output based on the optimal link.

[0132] Furthermore, based on this, two types of instance roles are further distinguished: "technical instances" and "business instances." The former only handles the inheritance and constraint logic of superior and subordinate contract parameters, while the latter actually participates in the on-site calculation of rates and approval amounts.

[0133] Therefore, account-level business contracts and customer-level business contracts are instantiated as technical instance nodes and business instance nodes, respectively.

[0134] S202. Connect the two current contract nodes to the contract nodes of the superior business contract in the contract network corresponding to their respective institutional levels, and inherit the management and control of the superior contract nodes.

[0135] Specifically, such as Figure 3 As shown, account-level business instances and account-level technical instances are connected to the superior account-level instance in the account-level contract network corresponding to the organization level. Similarly, customer-level business instances and customer-level technical instances are connected to the superior customer-level instance in the customer-level contract network corresponding to the organization level. Furthermore, account-level business instances and customer-level contract instances for the same business contract need to be matched to achieve customer-account level control.

[0136] S203. Determine whether the current business contract belongs to the highest level of organization.

[0137] If the current business contract does not belong to the highest level of organization, then step S204 is executed.

[0138] S204. Connect the two current contract nodes to the corresponding contract nodes in the contract network graph corresponding to the highest institution level, and inherit the control of the contract node of the highest institution level.

[0139] It should be noted that lower-level organizations are subject to the constraints of their superior organizations, therefore... Figure 3Based on the established network, it is also necessary to establish connections with higher-level organizations. For example, such as... Figure 4 As shown, for branch instances, a connection relationship also needs to be established with the head office instance to achieve control between the head office and branches.

[0140] Optionally, the "Approval Source" field in the instance can be used to mount it to the network subgraph of the head office or branch. Subsequently, according to the "Inspection Level" configuration, the graph traversal algorithm triggers customer-level or account-level node verification in parallel, retrieves the associated superior business instance or technical instance, and reads its configured parameterized data. For pricing strategies unique to the branch level, while inheriting the head office template control, the system can also insert customized parameterized subgraphs for the branch, and always maintain the integrity of the reference to superior instances and the consistency of constraints throughout the network. For example, as shown in Table 2 below, a set of corresponding control logic will be formulated for different pricing contract type numbers. By combining it with parameterized pricing contract types, more installment pricing contract products can be expanded, thereby realizing a highly flexible, auditable, and scalable multi-level network architecture installment pricing control scheme.

[0141] Table 2

[0142]

[0143] Optionally, in another embodiment of this application, a method for calling a business contract is provided, which can cover the contract verification and calling process in multi-path scenarios. This method, through a standardized multi-path calling control process, ensures user experience while smoothly replacing the traditional single-path calling mode.

[0144] like Figure 5 As shown, this application appears to attempt to provide a method for using a business contract, including the following steps:

[0145] S501. When a current usage request of a business contract is received, retrieve all valid contract nodes of the current user in the contract network based on the information in the current usage request.

[0146] Specifically, when the system receives a current withdrawal request from a business contract, it first retrieves all valid contract nodes in the contract network for the cardholder based on the application information in the current withdrawal request.

[0147] S502. Obtain the scenario configuration rules applicable to the current usage request based on the contract adaptation table.

[0148] It should be noted that, due to the different product types and transaction scenarios involved in business usage, a dynamically expandable usage strategy matching mechanism is constructed by introducing a parameterized configuration system to facilitate flexible usage. For example, the adaptation table shown in Table 3 can be used for installment payment business. The system quickly identifies the target transaction scenario based on the mask bit, and drives the invocation of usage rules and strategy execution in specific scenarios by leveraging the configurable identifier code and package type mapping structure, thereby achieving flexible control and fine-grained management of the usage process. For example, when the second bit of the applicable scenario mask value for a certain installment pricing contract type is 1, it indicates that the contract needs to enable the scenario verification mechanism based on Merchant Category Code (MCC) during the credit management process. The system first reads the corresponding MCC verification identifier in the contract adaptation table. When the identifier value is 1 (indicating that whitelist verification is enabled), the contract type is only allowed to be applied to MCC categories within the whitelist range. Subsequently, the system retrieves the “Installment Pricing Contract - MCC” type mapping table based on the MCC type identifier configured in the adaptation table, obtains the whitelist of merchant categories corresponding to the contract type, and controls the use of MCCs of merchants involved in the current exchange accordingly.

[0149] Table 3

[0150]

[0151] Therefore, the applicable scenario configuration rules of the exchange for the current payment request can be obtained based on the contract adaptation table.

[0152] S503. Based on the scenario configuration rules, perform scenario matching on each retrieved contract node to obtain the matching contract node.

[0153] S504. Determine the entry and exit contract nodes from each matching contract node.

[0154] Among them, the entry contract node does not have any subordinate contract nodes.

[0155] It should be noted that the embodiments of this application adopt a hierarchical verification process from bottom to top, first account and then customer, and verify from the bottom node to the top level to ensure the stability of the overall contract network. Therefore, matching contract nodes without lower-level nodes are selected as the entry contract nodes of each path.

[0156] S505. Based on the transaction account matching set identifier and contract priority parameter table in the current usage request, determine the priority of each entry contract node.

[0157] During the execution of business contracts, the system controls the order of use for different types of contracts through a priority parameter table, as shown in Table 4 below. This parameter table configures a corresponding priority value for each type of business contract, with a higher value indicating a higher priority. Based on this, to support differentiated needs across transaction scenarios and account dimensions, a priority nesting mechanism is introduced, binding each contract priority to a nesting ID. When executing the execution logic, the system uses transaction elements (such as transaction type, merchant attributes, etc.) and account information as matching criteria to dynamically match the applicable nesting ID, thereby achieving personalized configuration and refined management of business contract priorities and meeting the needs of customized execution paths at the transaction level.

[0158] Table 4

[0159]

[0160] Therefore, for each entry contract node, the system queries the priority value configured in the contract priority parameter table based on the match type ID of the current transaction account, so as to generate a contract candidate queue from high to low priority.

[0161] S506. Sort each entry contract node according to priority to obtain the contract candidate queue.

[0162] S507. Check the contract path of each entry contract node in the contract candidate queue in turn to obtain the final usage result.

[0163] Specifically, the system traverses each contract path sequentially according to priority, using the entry contract node corresponding to the path's starting point as the starting point to enter the single-path verification process for the current path. By checking each path, key parameters such as contract period and fee rate are extracted, the final disbursement result is generated and the actual disbursement is performed, and then the disbursement details are recorded.

[0164] Optionally, in another embodiment of this application, one specific implementation of step S507 is as follows: Figure 6 As shown, it includes:

[0165] S601. Select the contract path of the unchecked entry contract node that is ranked first in the current contract candidate queue as the current target path.

[0166] S602. Starting from the entry contract node of the current target path, traverse each contract node of the current target path in turn for inspection.

[0167] The current target path's usage result is obtained by summarizing the check results of each contract node.

[0168] Optionally, in another embodiment of this application, one specific implementation of step S602 is as follows: Figure 7 As shown, it includes:

[0169] S701. Starting from the entry contract node of the current target path, traverse each contract node in the current target path as the target contract node in turn.

[0170] S702. Determine whether the current type has enabled the account-level control mechanism.

[0171] Specifically, the system first determines whether the account-level control mechanism is enabled for this type based on the contract parameter configuration. If the current type has enabled the account-level control mechanism, then step S703 is executed. If the current type has not enabled the account-level control mechanism, then the verification of the account-level contract is skipped, and step S704 is executed directly.

[0172] S703. Locate the unique instance of the current account-level business contract of the current type under the current transaction account and verify its remaining balance to obtain the current account-level result.

[0173] The current type refers to the type to which the target contract node belongs.

[0174] S704. Determine whether the current type enables the customer-dimensional control mechanism.

[0175] If the current type has account-level control mechanisms enabled, proceed to step S705. If the current type has not enabled account-level control mechanisms, skip to step S706.

[0176] S705. Locate the unique instance of the current user's current type of customer-level contract and verify its remaining balance to obtain the current customer-level result.

[0177] S706. Determine whether the target contract node belongs to the highest level of organization.

[0178] If the target contract node does not belong to the highest level of organization, then proceed to step S707. If the target contract node belongs to the highest level of organization, then skip step 707 and proceed directly to step S708.

[0179] S707. Retrieve the instance of the business contract at the highest level of the corresponding organization and verify its remaining balance to obtain the current superior result.

[0180] S708. The smaller of the sum of the current account-level results and the current client-level results, and the current superior-level results, is determined as the inspection result of the target contract node.

[0181] Specifically, if the account-level control mechanism is not enabled, the current account-level result can be considered zero. If the customer-level control mechanism is not enabled, the current customer-level result can be considered zero. If the target contract node belongs to the highest institution level, the current superior result can be considered zero.

[0182] It should be noted that, in order to ensure that the control logic between upper and lower level contracts remains consistent, the smaller value between the sum of the current account-level result and the current client-level result and the current upper-level result is determined as the inspection result of the target contract node.

[0183] S709. After checking each contract node of the current target path, summarize the check results of each contract node to obtain the usage result of the current target path.

[0184] S603. Determine whether the current target path has failed the check, or whether the spending balance in the spending results of the current target path does not meet the current requirements.

[0185] It should be noted that in practical applications, there may be situations where a high-priority path has insufficient available balance to independently cover the current withdrawal amount. In this case, the system will activate a multi-path combination withdrawal strategy. For example, if a customer intends to withdraw 10,000 yuan, the system will first attempt to match the highest-priority path. If this path can only withdraw a maximum of 7,000 yuan, the system will continue to select the next lower-priority but still available path for supplementary withdrawal. For instance, if this path can still withdraw 20,000 yuan, the system will automatically combine the first two paths, withdrawing 7,000 yuan from the first path and 3,000 yuan from the second path respectively to meet the overall withdrawal requirement. If at least one path successfully passes the contract available balance verification and meets the withdrawal amount requirement, the system will execute the actual withdrawal operation based on the allocated withdrawal amount within each path and register the withdrawal details for all contracts involved in the path. Therefore, if the withdrawal balance in the current target path does not meet the current requirement, the system returns to step S601. If the current spending balance in the current target path's spending results meets the current requirements, proceed to step S604.

[0186] Furthermore, since neither the account-level nor the customer-level control mechanisms are enabled, and it is still at the highest institutional level, the remaining spending balance has not been verified, so the check has failed. Therefore, the detected spending balance does not meet the requirements at this time, so it is necessary to return to step S601.

[0187] If the current target path passes the check and the spending balance in the spending results of the current target path meets the current requirements, it means that the sum of the spending balances in the spending results of all checked contract paths meets the current requirements, so step S604 is executed.

[0188] It should be noted that if all contract paths that have been checked cannot return to step S601 at this time, that is, if the sum of the withdrawal balance in the withdrawal results of each contract path does not meet the current requirements, then the withdrawal application will be reported as failed.

[0189] S604. Generate the final usage result based on the usage results of each contract path that has been checked.

[0190] Optionally, after detecting one or more pricing contracts for disbursement, the system extracts the pricing parameters defined in the contracts, including key information such as the applicable period and approval fee rate, and generates a disbursement plan table in real time based on this as the final disbursement result. For example, the disbursement plan table clearly defines the breakdown of the repayment amount for each period within the entire installment period, including the allocation of principal and handling fees, as well as the disbursement time for each period. Furthermore, if the current disbursement is a multi-path combination, the system will extract the pricing contract parameters corresponding to each path based on the path allocation of the actual disbursement amount and summarize them one by one. By calculating the installment costs for both parts of the amount separately, a structured pricing detail is constructed. Finally, when generating the disbursement plan table, the overall disbursement cost is calculated and displayed uniformly, achieving visualization and transparency of cost calculation.

[0191] Optionally, this application provides a hierarchical and parameterizable method for maintaining business contracts. By introducing a pricing contract network with hierarchical constraints and attribute inheritance relationships, a linked maintenance mechanism for business contracts is achieved. This mechanism not only meets the traditional business requirements for flexible adjustment of business parameters but also supports callers in managing contract status, lifecycle, and other attributes as needed based on specific transaction scenarios or strategy requirements, including but not limited to enabling, disabling, or renewing operations. During this process, the system can perceive the dependencies between contracts and automatically trigger synchronous adjustments to related contracts at different levels, thereby effectively ensuring the consistency of the network structure. Simultaneously, all change operations are recorded traceably, achieving full-process traceability through contract change details, providing a basis for subsequent problem investigation and strategy auditing.

[0192] Specifically, another embodiment of this application provides a method for maintaining business contracts, such as... Figure 8 As shown, it includes:

[0193] S801. When a business contract adjustment request is received, the adjustment request determines the business contract to be adjusted.

[0194] Specifically, when the system receives an adjustment request for a business contract, it parses the message payload sent through the adjustment request and extracts the target level of the adjustment operation, which includes two categories: account-level contracts and client-level contracts.

[0195] S802. Adjust the business contract to be adjusted according to the adjustment target value in the adjustment request, and record the change details.

[0196] Specifically, the system parses and identifies the transaction control dimensions specified in the adjustment request, such as primary and supplementary card relationship, MCC, merchant number, transaction currency, transaction time, and transaction geographical location. The system supports independent control of single variables within each dimension, as well as joint control using multiple dimensions to construct composite conditions. Simultaneously, the system performs legality verification on the specific adjustment target values ​​for each dimension, ensuring compliant execution of adjustment operations under business rules and technical constraints. After parsing the request message, the system uses the account identifier as a key index to retrieve all installment pricing contracts associated with that account. Based on this, the system combines the contract adjustment level, transaction dimension control parameters, and their specific values ​​identified in the submitted message to construct multi-dimensional matching conditions, achieving precise location of the contract to be adjusted within the installment pricing contract network.

[0197] S803. According to the hierarchy, for each subordinate business contract of the business contract to be adjusted, if the subordinate contract is a business instance, the subordinate contract is adjusted in a coordinated manner and its change details are recorded, until the subordinate contract is not a business instance or all subordinate business contracts have been adjusted.

[0198] In the network structure of business contracts, adjustments to contract parameters are updated synchronously through hierarchical relationships. Because some pricing contracts have clear hierarchical relationships, once a parameter change occurs in an upper-level contract, its associated lower-level contracts will automatically update key parameters such as available amount and fee rate according to predetermined logic to ensure overall consistency. For example, if the system configures a cardholder's total available amount in ordinary consumption scenarios to be 10,000 yuan with an annual fee rate of 3%, of which only 50% is allowed for cash withdrawal with an annual withdrawal fee rate 1.5 times the consumption annual fee rate, then the system will establish two related pricing contract nodes: one is the customer-level ordinary consumption contract (IMAP1101), and the other is its subordinate cash withdrawal pricing contract (IMAP2101), the latter's available amount and annual fee rate derived from the former. Once the current entity receives a change request (such as increasing the available amount to 20,000 yuan or raising the annual fee rate to 4%) and completes the update, the system will trigger a chain-like synchronization logic, causing the lower-level cash withdrawal pricing contracts to automatically adjust synchronously according to the agreed ratio, thereby updating to an available amount of 10,000 yuan and an annual fee rate of 6%. This mechanism effectively avoids the consistency risk caused by individual adjustments.

[0199] Furthermore, when making direct adjustments to contracts or adjustments linked between different levels, the system records all contract change details in the order they were made. This detailed registration mechanism provides a complete picture of the entire change path and specific adjustments to the installment pricing contracts under the cardholder's name during each contract maintenance process. This mechanism not only improves the traceability and transparency of contract management but also facilitates rapid problem identification and business retrospective analysis by business personnel in the event of disputes or anomalies.

[0200] This application provides a multi-level contract management method. When a business contract application is received, the method obtains the current customer's card account information and matches the corresponding type of business contract parameters based on the customer card account information. Then, an initial current business contract is generated based on the business contract parameters. The current business contract includes the current customer-level business contract and the account-level business contract. Therefore, various strategies are managed through business contracts, linked via parameterized configuration, and rules and parameters are decoupled. This parameterized configuration method not only improves the flexibility and maintainability of business strategies. Next, if a root-level business contract for the current business exists and is in an available state, the current business contract is associated with its parent and child business contracts, and the approval amount and business parameters of the current business contract are calculated based on these parent and child business contracts. If no root-level business contract for the current business exists and is in an available state, the business parameters of the current business contract are determined, the current business contract is established as the root-level business contract for the current business, and the current customer-level and account-level business contracts are matched. Finally, based on the institution level to which the current business contract belongs, the current business contract is established as the business contract of the corresponding institution level. By constructing a multi-dimensional and multi-level contract network structure between customer level and account level, head office and branch office, and superior and subordinate levels, the business strategy can be flexibly defined and updated, significantly improving the flexibility of business strategy and achieving unified management, which facilitates management.

[0201] Another embodiment of this application provides a multi-level contract management system, such as... Figure 9 As shown, it includes:

[0202] The information acquisition unit 901 is used to acquire the current customer's card account information when a business contract application is received.

[0203] The parameter matching unit 902 is used to match the corresponding type of business contract parameters based on the customer card account information.

[0204] Contract generation unit 903 is used to generate an initial current business contract based on business contract parameters. The current business contract includes the current client-level business contract and the account-level business contract.

[0205] The first processing unit 904 is used to associate the current business contract with its superior and subordinate business contracts when there is a root-level business contract of the current business that is in an available state, and to calculate the approval amount of the current business contract and determine its business parameters based on its superior and subordinate business contracts.

[0206] The second processing unit 905 is used to determine the business parameters of the current business contract and set the current business contract as the root business contract of the current business when there is no root business contract of the current business in an available state.

[0207] Contract matching unit 906 is used to match the current customer-level business contracts and account-level business contracts.

[0208] Contract establishment unit 907 is used to establish the current business contract as a business contract of the corresponding institutional level based on the institutional level to which the current business contract belongs.

[0209] Optionally, in another embodiment of the multi-level contract management system provided in this application, the system further includes:

[0210] The instantiation unit is used to instantiate the two current business contracts respectively, generating a current contract node corresponding to each current business contract. The current contract node includes both the current technical instance node and the business instance node.

[0211] The first connection unit is used to connect the two current contract nodes to the contract nodes of the superior business contract in the contract network corresponding to the institution level, and to inherit the management and control of the superior contract node.

[0212] The second connection unit is used to connect two current contract nodes to the corresponding contract node in the contract network diagram of the highest-level organization when the current business contract does not belong to the highest-level organization, and to inherit the management of the contract node of the highest-level organization.

[0213] Optionally, in another embodiment of the multi-level contract management system provided in this application, the system further includes:

[0214] The retrieval unit is used to retrieve all valid contract nodes of the current user in the contract network based on the information of the current request when a current usage request of a business contract is received.

[0215] The rule acquisition unit is used to obtain the scenario configuration rules applicable to the current usage request based on the contract adaptation table.

[0216] The scenario matching unit is used to perform scenario matching on each retrieved contract node based on scenario configuration rules to obtain the matching contract node.

[0217] The node determination unit is used to determine the entry and exit contract nodes from among the various matching contract nodes. The entry contract node has no subordinate contract nodes.

[0218] The priority determination unit is used to determine the priority of each entry contract node based on the set identifier matched with the transaction account in the current payment request and the contract priority parameter table.

[0219] The sorting unit is used to sort the various entry contract nodes according to their priority to obtain the contract candidate queue.

[0220] The inspection unit is used to check the contract path of each entry contract node in the contract candidate queue in turn to obtain the final usage result.

[0221] Optionally, in another embodiment of the multi-level contract management system provided in this application, the inspection unit includes:

[0222] The selection unit is used to select the contract path of the unchecked entry contract node that is ranked first in the current contract candidate queue as the current target path.

[0223] The path checking unit is used to sequentially traverse each contract node along the current target path, starting from the entry contract node, and check them. The usage result of the current target path is obtained by summing the check results of each contract node.

[0224] The return unit is used to return to the execution selection unit when the current target path fails the check or the spending balance in the spending result of the current target path does not meet the current requirements.

[0225] The result generation unit is used to generate the final expenditure result based on the expenditure results of each checked contract path when the sum of the expenditure balances in the expenditure results of each checked contract path meets the current requirements.

[0226] The feedback unit is used to report a failure of the payment request when the sum of the payment balances in the payment results of all contract paths that have been checked does not meet the current demand.

[0227] Optionally, in another embodiment of the multi-level contract management system provided in this application, the path checking unit includes:

[0228] The traversal unit is used to traverse each contract node in the current target path, starting from the entry contract node, as the target contract node.

[0229] The first checking unit is used to locate the unique instance of the account-level business contract of the current type under the current transaction account and verify its remaining balance if the account-level control mechanism is enabled for the current type, thereby obtaining the current account-level result. Here, the current type is the type to which the target contract node belongs.

[0230] The second checking unit is used to locate the unique customer-level contract instance of the current user's current type and verify its remaining balance if the current type has enabled the customer-level control mechanism, so as to obtain the current customer-level result.

[0231] The third inspection unit is used to retrieve the instance of the business contract at the highest level of the target contract if the target contract node does not belong to the highest level of the organization, and to verify its remaining balance to obtain the current superior result.

[0232] The result selection unit is used to determine the smaller value among the sum of the current account-level result and the current client-level result, and the current superior result, as the inspection result of the target contract node.

[0233] The aggregation unit is used to aggregate the inspection results of each contract node after checking the current target path, and obtain the usage result of the current target path.

[0234] Optionally, in another embodiment of the multi-level contract management system provided in this application, the system further includes:

[0235] The contract adjustment determination unit is used to determine the business contract to be adjusted when a business contract adjustment request is received.

[0236] The direct adjustment unit is used to adjust the business contract to be adjusted according to the adjustment target value in the adjustment request, and record its change details.

[0237] The linkage adjustment unit is used to sequentially adjust each subordinate business contract of the business contract to be adjusted according to the hierarchy. If the subordinate contract is a business instance, the subordinate contract is adjusted in a linkage manner and its change details are recorded until the subordinate contract is not a business instance or all subordinate business contracts have been adjusted.

[0238] It should be noted that the specific working process of each unit provided in the above embodiments of this application can be referred to the implementation process of the corresponding steps in the above method embodiments, and will not be repeated here.

[0239] Another embodiment of this application provides an electronic device, such as... Figure 10 As shown, it includes:

[0240] Memory 1001 and processor 1002.

[0241] The memory 1001 is used to store the program.

[0242] The processor 1002 is used to execute the program stored in the memory 1001. When the program is executed, it is specifically used to implement the multi-level contract management method provided in any of the above embodiments.

[0243] Another embodiment of this application provides a computer storage medium for storing a computer program, which, when executed by a processor, is used to implement the multi-level contract management method provided in any of the above embodiments.

[0244] Computer storage media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0245] Those skilled in the art will further 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 implementation should not be considered beyond the scope of this application.

[0246] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-level contract management method, characterized in that, include: When a business contract application is received, the current customer's card account information is retrieved; Match the corresponding type of business contract parameters based on the customer card account information; An initial current business contract is generated based on the business contract parameters; wherein, the current business contract includes the current customer-level business contract and the account-level business contract; If there is a root-level business contract for the current business that is in an available state, then the current business contract is associated with its superior and subordinate business contracts, and the approval amount of the current business contract and its business parameters are calculated based on its superior and subordinate business contracts. If there is no root-level business contract for the current business that is in an available state, determine the business parameters of the current business contract and set the current business contract as the root-level business contract for the current business. Match the current customer-level business contract with the account-level business contract; Based on the organizational level to which the current business contract belongs, the current business contract is established as a business contract of the corresponding organizational level.

2. The method according to claim 1, characterized in that, Also includes: Instantiate the two current business contracts respectively to generate a current contract node corresponding to each current business contract; wherein, the current contract node includes the current technical instance node and the business instance node; The two current contract nodes are respectively connected to the contract nodes of the superior business contract in the contract network corresponding to the institution level, and the management and control of the superior contract node are inherited. If the current business contract does not belong to the highest level of organization, then the two current contract nodes are connected to the corresponding contract node in the contract network diagram of the highest level of organization, and the management of the contract node of the highest level of organization is inherited.

3. The method according to claim 2, characterized in that, Also includes: When a current usage request of a business contract is received, all valid contract nodes of the current user in the contract network are retrieved based on the information in the current usage request. Obtain the scenario configuration rules applicable to the current usage request based on the contract adaptation table; Based on the scenario configuration rules, scenario matching is performed on each of the retrieved contract nodes to obtain the matching contract nodes; Entry and exit contract nodes are determined from each of the matching contract nodes; wherein the entry contract node has no subordinate contract nodes. Based on the transaction account matching the current usage request and the contract priority parameter table, the priority of each entry contract node is determined. The entry contract nodes are sorted according to priority to obtain the contract candidate queue; The contract paths of each entry contract node are checked sequentially according to the contract candidate queue to obtain the final usage result.

4. The method according to claim 3, characterized in that, The step of sequentially checking the contract paths of each entry contract node according to the contract candidate queue to obtain the final usage result includes: The contract path of the unchecked entry contract node that is ranked first in the current contract candidate queue is selected as the current target path; Starting from the entry contract node of the current target path, each contract node of the current target path is traversed sequentially for inspection; wherein, the usage result of the current target path is obtained by summarizing the inspection results of each contract node; If the current target path fails the check, or the spending balance in the spending result of the current target path does not meet the current requirements, then return to the process of selecting the contract path to which the unchecked entry contract node ranks first in the current contract candidate queue belongs as the current target path. If the sum of the spending balances in the spending results of each of the checked contract paths meets the current requirement, then the final spending result is generated based on the spending results of each of the checked contract paths. If the sum of the withdrawal balances in the withdrawal results of all the contract paths checked does not meet the current requirement, then the withdrawal application will be reported as failed.

5. The method according to claim 4, characterized in that, The step of sequentially traversing each contract node of the current target path, starting from the entry contract node, includes: Starting from the entry contract node of the current target path, each contract node in the current target path is sequentially traversed as the target contract node; If the current type has enabled the account-level control mechanism, then locate the unique account-level business contract instance of the current type under the current transaction account and verify its remaining balance to obtain the current account-level result; wherein, the current type is the type to which the target contract node belongs; If the current type has enabled the customer-level control mechanism, then locate the unique customer-level contract instance of the current user's current type and verify its remaining balance to obtain the current customer-level result; If the target contract node does not belong to the highest level of organization, then retrieve the instance of the business contract corresponding to the highest level of organization and verify its remaining balance to obtain the current superior result; The smaller of the sum of the current account-level result and the current customer-level result, and the current superior result, is determined as the inspection result of the target contract node; After checking each contract node of the current target path, the check results of each contract node are summarized to obtain the usage result of the current target path.

6. The method according to claim 2, characterized in that, Also includes: When a request to adjust a business contract is received, the request to adjust the business contract is determined. Adjust the business contract to be adjusted according to the adjustment target value in the adjustment request, and record the change details; In a hierarchical manner, each subordinate business contract of the business contract to be adjusted is addressed sequentially. If the subordinate contract is a business instance, the subordinate contract is adjusted in a coordinated manner, and its change details are recorded, until the subordinate contract is not a business instance or all subordinate business contracts have been adjusted.

7. A multi-level contract management system, characterized in that, include: The information acquisition unit is used to acquire the current customer's card account information when a business contract application is received; The parameter matching unit is used to match business contract parameters of the corresponding type based on the customer card account information. A contract generation unit is used to generate an initial current business contract for the current business based on the business contract parameters; wherein, the current business contract includes the current customer-level business contract and the account-level business contract; The first processing unit is used to associate the current business contract with its superior and subordinate business contracts when there is a root-level business contract of the current business that is in an available state, and to calculate the approval amount of the current business contract and determine its business parameters based on its superior and subordinate business contracts. The second processing unit is used to determine the business parameters of the current business contract and set the current business contract as the root business contract of the current business when there is no root business contract of the current business that is in an available state. A contract matching unit is used to match the current customer-level business contract with the account-level business contract; The contract establishment unit is used to establish the current business contract as a business contract of the corresponding institutional level based on the institutional level to which the current business contract belongs.

8. The system according to claim 7, characterized in that, Also includes: An instantiation unit is used to instantiate the two current business contracts respectively, generating a current contract node corresponding to each current business contract; wherein, the current contract node includes a current technical instance node and a business instance node; The first connection unit is used to connect the two current contract nodes to the contract nodes of the superior business contract in the contract network corresponding to the institution level, and to inherit the control of the superior contract node. The second connection unit is used to connect the two current contract nodes to the corresponding contract nodes in the contract network diagram of the highest institution level when the current business contract does not belong to the highest institution level, and to inherit the management of the contract nodes of the highest institution level.

9. An electronic device, characterized in that, include: Memory and processor; The memory is used to store programs; The processor is used to execute the program, which, when executed, is specifically used to implement the multi-level contract management method as described in any one of claims 1 to 6.

10. A computer storage medium, characterized in that, Used to store computer programs, which, when executed by a processor, are used to implement the multi-level contract management method as described in any one of claims 1 to 6.

Images