An online business real-name verification, signing and settlement integrated system

Abstract

The application discloses an online business real-name verification, signature and settlement integrated system, and relates to the technical field of online business processing. The system comprises the following steps: obtaining a real-name result, a business acceptance record, a contract signature record, a performance record and a settlement request; forming an identity record, an effective contract version identifier and a version settlement record; generating a settlement execution qualification based on a current performance state; forming a qualification invalidation result and a qualification level record when the qualification changes; and releasing or blocking the settlement by a control module according to the result. The system can stably convert the current effective contract version and the corresponding signed obligation content into a settlement release basis, and reduces the risk of disconnection between signature and settlement, mispositioning of contract content and settlement parameters, and continuous execution after the invalidation of old qualification.

Description

Technical Field

[0001] This invention relates to the field of online business processing technology, and more specifically, to an integrated system for online business real-name verification, signing, and settlement. Background Technology

[0002] In the current online business system, although real-name verification, contract signing, and settlement execution have been widely digitized, in actual deployment they are usually still handled independently in the real-name authentication system, electronic signing system, and order or payment settlement system. The Electronic Signature Law requires that electronic signatures be used to identify the signatory's identity and to indicate that the signatory approves the content. This means that, technically, the signing behavior must not only prove who signed, but also which version of the content was signed. However, the current mainstream approach is more to use the signing result as the result of contract archiving or preservation, and then trigger subsequent settlement by order status, payment node, account permissions, or a single settlement request. This results in the signing side forming a contractual fact, while the settlement side consumes a different structure. Parameterization: Once there are supplementary signings, amendments, version replacements, changes in refund conditions, adjustments to revenue sharing conditions, or rollbacks in performance status during the business process, the valid contract version in the signing system and its corresponding obligations often cannot be synchronously converted into a control basis for direct consumption in the settlement system. As a result, the settlement chain may continue to advance along the existing order parameters, forming a chain risk of disconnect between signing and settlement, and misalignment between contract content and settlement parameters. Although existing public solutions have processing paths for connecting signing and payment, intermediary platform supervision, blockchain recording, and conditional transactions, they mainly remain at the level of process integration, evidence solidification, or condition triggering, which is not enough to reliably solve the problem that the current valid signed content cannot continuously constrain settlement release.

[0003] The current technical challenge is how to avoid erroneous releases caused by the separation of contractual facts and settlement parameters, or by the asynchronous release of contract versions and settlement procedures. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, this invention provides an integrated online business real-name verification, signing, and settlement system. This system addresses the problem that in existing online business processes, real-name verification, contract signing, and settlement execution are handled by different systems. This makes it difficult to reliably convert the current valid contract version and its corresponding signed obligations into a release basis that the settlement system can directly identify and continuously verify. Consequently, this leads to problems such as a disconnect between signing and settlement, misalignment between contract content and settlement parameters, and continued execution of settlement actions after the old qualifications have expired.

[0005] To achieve the above objectives, the present invention provides the following technical solution: An integrated online business real-name verification, signing, and settlement system includes: The access module obtains real-name results, business acceptance records, contract signing records, performance records, and settlement requests. Among them, the real-name results include at least the real-name subject identifier and the business document identifier; the business acceptance records include at least the business document identifier and the business subject identifier; the contract signing records include at least the contract identifier, the candidate contract version identifier, the signing status, and the contract signing content; the performance records include at least the business document identifier and the current performance status; and the settlement requests include at least the business document identifier, the requested contract version identifier, and the settlement parameters. The identity verification module reads the business entity identifier from the business acceptance record based on the business document identifier, verifies whether the real-name entity identifier is equal to the business entity identifier or whether it belongs to the authorized operation entity corresponding to the business entity, and generates an identity record containing the real-name entity identifier, business entity identifier and business document identifier when the verification is successful. The version determination module determines the valid contract version identifier based on the contract identifier, candidate contract version identifier, and signing status, and updates the valid contract version identifier when the version status of the candidate contract version identifier corresponding to the valid contract version identifier changes to replacement, re-signing and overwriting, revocation, or invalidation. The settlement content module extracts at least one of the following directly related to settlement from the contract signing content and business acceptance records: amount, payment node, refund conditions, revenue sharing conditions and effective conditions, and generates a version settlement record that corresponds one-to-one with each candidate contract version identifier. The qualification generation module determines whether the current performance status meets the settlement trigger conditions in the version settlement record based on the identity record, the valid contract version identifier, the version settlement record corresponding to the valid contract version identifier, and the current performance status. If the conditions are met, the module generates the settlement execution qualification corresponding to the business document; otherwise, it generates a qualification invalidation result. Upon receiving a settlement request, the control module verifies whether the business document identifier in the settlement request matches the business document identifier in the settlement execution qualification; whether the requested contract version identifier in the settlement request matches the valid contract version identifier in the settlement execution qualification; and whether the settlement parameters in the settlement request match the condition item record corresponding to the version settlement record. Only when all the above verifications are consistent and the settlement execution qualification is valid, a settlement instruction is generated and sent to the payment and settlement system. If there are inconsistencies in the above verifications or the settlement execution qualification is not valid, a settlement blocking result is output. The payment and settlement system executes the settlement request according to the received settlement instruction.

[0006] The technical effects and advantages of this invention are as follows: 1. By using business document identification to connect real-name results, valid contract version identification, version settlement records, performance records, and settlement requests, and using settlement execution qualification as a prerequisite for settlement release, the signing facts, contract version, and settlement parameters are no longer separated. This allows for timely prevention of erroneous settlements when contract versions change, performance changes, or parameters deviate, reducing the risk of erroneous releases caused by asynchronous settlement criteria. 2. Establish a correspondence between each condition item in the version settlement record and each performance item in the performance record according to the condition type, and perform a satisfaction comparison on the condition content and settlement trigger conditions. The system will converge the scattered contract content and performance status into settlement execution qualification. This will enable the system to determine whether the current business meets the settlement conditions in a verifiable manner, and improve the pertinence and consistency of the settlement release basis. 3. After the original settlement execution qualification expires, the current identity record, valid contract version identifier, version settlement record and current performance record are read again, the satisfaction comparison is performed again and the old and new qualification replacement relationship is generated. The system keeps the qualification update synchronized with the change of the basic object; this can prevent the old qualification from continuing to be used as the basis for settlement and ensure that subsequent control is always based on the current valid qualification. 4. Based on the qualification level record, read the settlement processing record corresponding to the historically invalidated qualification, and identify the pending, retry, or generated but not yet settled processing objects as records to be blocked. Then cancel or stop the corresponding settlement instruction, and the system will continue to propagate the qualification failure to the incomplete settlement action. This can inhibit the continued execution of the old qualification derivation link and enhance the closure of failure control. Attached Figure Description

[0007] Figure 1 This is a system block diagram of the present invention. Detailed Implementation

[0008] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0009] In online business, real-name verification, contract signing, and settlement execution are usually handled by different systems. This makes it difficult to reliably transform the current valid contract version and its corresponding signed obligations into a release basis that can be directly identified and continuously verified by the settlement side. When there are changes in contract version, performance status, or settlement parameters, the settlement request may still continue to be executed along the original link, leading to problems such as disconnect between signing and settlement, misalignment between contract content and settlement parameters, and continued execution without completing the settlement action after the old qualification expires. This implementation method builds an integrated processing chain around identity records, valid contract version identifiers, version settlement records, settlement execution qualifications, and qualification level records to achieve linkage control between real-name verification, signing, performance, and settlement in online business. Refer to the instruction manual appendix Figure 1 An integrated online business real-name verification, signing, and settlement system, comprising an access module, an identity verification module, a version verification module, a settlement content module, a qualification generation module, and a control module; Access Module The system retrieves real-name authentication results, business acceptance records, contract signing records, performance records, and settlement requests. Real-name authentication results must include at least the real-name entity identifier and the business document identifier; business acceptance records must include at least the business document identifier and the business entity identifier; contract signing records must include at least the contract identifier, candidate contract version identifier, signing status, and contract signing content; performance records must include at least the business document identifier and the current performance status; and settlement requests must include at least the business document identifier, the requested contract version identifier, and settlement parameters. Specifically, the system first establishes data access connections with the real-name authentication system, business acceptance system, electronic signing system, performance management system, and settlement application portal, and sets the business document identifier as a unified identifier across all record sources. Association keys; When reading real-name authentication results, extract the real-name subject identifier and business document identifier from the data returned by the real-name authentication system. The real-name subject identifier indicates the natural person or operating entity that has completed real-name verification, and the business document identifier indicates the specific business corresponding to the real-name result. When reading business acceptance records, locate the corresponding acceptance entry in the business acceptance system using the business document identifier and extract the business subject identifier. The business subject identifier indicates the business entity registered during the acceptance stage. When reading contract signing records, associate the corresponding signing process using the business document identifier and extract the contract identifier, candidate contract version identifier, signing status, and contract signing content. The contract identifier indicates the same contract subject. The candidate contract version identifier is used to distinguish different signed versions under the main contract object. The signing status indicates whether the candidate contract version identifier is currently in the state of pending signing, signed, revoked, or invalid. The contract signing content is used to carry the original content of subsequent withdrawal amount, payment node, refund conditions, revenue sharing conditions, and effective conditions. When reading the performance record, the corresponding performance item is located in the performance management system by the business document identifier, and the current performance status is extracted. The current performance status indicates whether the business has reached the service activation, node acceptance, refund trigger, or revenue sharing trigger stage. When reading the settlement request, the settlement data initiated this time is received from the settlement application entry, and the business document identifier and request contract version are extracted. This identifier and settlement parameters, the request contract version identifier is used to indicate the contract version referenced in this settlement request, and the settlement parameters are used to indicate the amount, settlement node, refund content or account split content declared in this request; after the above types of data are read, the system merges the real-name result, business acceptance record, contract signing record, performance record and settlement request according to the business document identifier, and writes the real-name subject identifier, business subject identifier, contract identifier, candidate contract version identifier, signing status, contract signing content, current performance status, request contract version identifier and settlement parameters into the corresponding data cache area or processing queue, so that subsequent identity determination, version determination, settlement content generation, qualification generation and control processing can be continuously called;For example, in a scenario where enterprise customers order services online, the system aggregates real-name entity identifiers, business entity identifiers, candidate contract version identifiers, signing status, contract signing content, current performance status, requested contract version identifiers, and payment parameters around the same business document identifier. This data is then grouped into a single processing chain as the input basis for subsequent settlement condition determination.

[0010] Identity verification module The business entity identifier is retrieved from the business acceptance record based on the business document identifier. Specifically, the identity verification module first receives the business document identifiers merged by the access module and writes them into the business acceptance record query conditions. Using the business document identifier as the retrieval condition, it searches for a target record in the business acceptance record that matches the document identifier and has a valid acceptance status. From the target record, it retrieves the business entity identifier and the set of authorized operation entity identifiers. A valid acceptance status means that the business acceptance record has not been withdrawn, has not been voided, and still corresponds to the current business document. When the query result contains only one record that meets the conditions, that record is directly identified as the target record. When the query result contains multiple records that meet the conditions... When the business document is in a valid state, it is sorted according to the time it entered the valid state, and the record that entered the valid state most recently is selected as the target record. The business entity identifier is used to indicate the business entity to which the business document belongs, and the authorized operation entity identifier set is used to indicate the set of operation entities that have been pre-registered by the business entity and are allowed to participate in the current business processing. For example, in the scenario of online procurement services by enterprise customers, the same business document may be submitted, modified and resubmitted successively. The identity determination module first locates the business acceptance record that is still in a valid state according to the business document identifier, and then reads the business entity identifier corresponding to the enterprise and the pre-registered operator entity identifier set from the record for direct use in subsequent entity relationship verification. The system verifies whether the real-name entity identifier is equal to the business entity identifier or whether it belongs to the authorized operating entity corresponding to the business entity. Specifically, the identity verification module first performs a primary key consistency comparison between the real-name entity identifier and the business entity identifier. If the primary key consistency comparison passes, the entity consistency result is directly obtained. The primary key consistency comparison involves mapping the real-name entity identifier and the business entity identifier to the unified entity primary key within the system and then determining whether they are the same to eliminate comparison bias caused by inconsistencies in entity encoding methods across different systems. If the primary key consistency comparison fails, the real-name entity identifier is compared item by item with each entity identifier in the set of authorized operating entity identifiers to obtain an entity consistency result or an authorization matching result. During item-by-item comparison, the comparison can be performed sequentially according to the storage order in the set of authorized operating entity identifiers, or the real-name entity identifier can be compared first. After mapping the identifier to a unified primary key, it is compared item by item with the primary keys corresponding to each entity identifier in the set, as long as the comparison criteria remain consistent. When any comparison passes, an authorization matching result is obtained. When both the primary key consistency comparison and the item-by-item comparison fail, no entity verification pass result is generated, and the business document is marked as entity verification fail. For example, in a scenario where a corporate customer is handled directly by the legal representative, the primary key mapped from the real-name entity identifier and the business entity identifier is the same, and a entity consistency result can be obtained directly. In a scenario where a corporate customer is handled by an authorized agent, the real-name entity identifier and the business entity identifier are usually different. In this case, by comparing item by item with the set of authorized operation entity identifiers, as long as the primary key corresponding to the real-name entity identifier exists in the set, an authorization matching result can be obtained. Upon successful verification, an identity record containing the real-name entity identifier, business entity identifier, and business document identifier is generated. Specifically, upon obtaining a subject consistency result or authorization matching result, the identity determination module writes the real-name entity identifier, business entity identifier, business document identifier, and corresponding matching result into the identity record. If an identity record corresponding to the business document identifier already exists, the original identity record is overwritten or replaced based on the current matching result. During writing, the identity record storage area is first queried using the business document identifier to determine if a corresponding identity record already exists for the current business document. If no corresponding identity record exists, a new identity record is directly generated. If a corresponding identity record already exists, the real-name entity identifier, business entity identifier, and matching result from the original identity record are first read, and then compared with the real-name entity identifier, business entity identifier, and matching result obtained from the current verification. The matching results are compared item by item; when all three items remain unchanged, the original identity record remains valid; when any item changes, the original identity record is overwritten or replaced. Overwriting is applicable when the same identity record primary key is still used but the record content needs to be rewritten, while replacement is applicable when the original identity record is retained and a new identity record is added to take over the current subject relationship. For example, in the scenario where the same business document is first handled by the legal representative of the enterprise and then handled by an authorized agent, if the real-name subject identifier changes but the business subject identifier remains unchanged, the system will update the original identity record to an invalid state and add a new identity record that includes the current real-name subject identifier, business subject identifier, business document identifier, and authorization matching result, so as to ensure that the qualification generation module always reads the currently valid subject correspondence.

[0011] Version determination module The valid contract version identifier is determined based on the contract identifier, candidate contract version identifier, and signing status. Using the contract identifier as a search condition, candidate version records with the same contract identifier are extracted from the contract signing records. From each candidate version record, the candidate contract version identifier, signing status, signing completion time, and version status are read. Specifically, the version determination module first receives the contract signing records output by the access module and writes the contract identifier as a filter condition into the search statement. It then extracts candidate version records with the same contract identifier from the contract signing records. For each extracted candidate version record, the candidate contract version identifier, signing status, signing completion time, and version status are read sequentially. The candidate contract version identifier is used to distinguish different signing versions under the same contract identifier, and the signing status indicates whether the candidate version has been signed. Once the signing is completed, the signing completion time indicates the order in which different candidate versions were signed, and the version status indicates whether the candidate version is currently in a normal, replacement, re-signing overwrite, revoked, or invalid state. When there is only one candidate version record under the same contract identifier, the above fields are read completely before proceeding to the subsequent valid candidate judgment process to ensure that the same execution criteria are used in single-version and multi-version scenarios. For example, in the scenario of enterprise customer online procurement platform services, the initial signing version, supplementary signing version, and replacement signing version may be formed successively under the same contract identifier. The version determination module first extracts all these candidate version records and reads the corresponding candidate contract version identifier, signing status, signing completion time, and version status respectively as the input basis for subsequently determining the valid contract version identifier. Candidate version records with a signing status of "signed and completed" and whose version status is not "replacement," "re-signing and overwriting," "revoked," or "invalid" are identified as valid candidate records. When multiple valid candidate records exist, the target version record is selected based on the order of signing completion time and candidate contract version identifiers. Specifically, after reading the candidate version record fields, the version determination module first checks the signing status of each candidate version record, retaining only those with a signing status of "signed and completed." Then, it checks the version status of these candidate version records, removing those with version statuses of "replacement," "re-signing and overwriting," "revoked," or "invalid," and identifying the remaining records as valid candidate records. When there is only one valid candidate record, it is directly identified as the target version record. When there are multiple valid candidate records, the signing completion time is compared first, prioritizing the record with the later signing completion time as the target version record. If multiple... If the signing completion time of the valid candidate records is the same, the order of the candidate contract version identifiers is compared, and the record corresponding to the candidate contract version identifier with the later order is selected first. The order of the candidate contract version identifiers can be the incremental version number generated by the electronic signing system, the internal sequence code, or the sorting value under the same contract identifier, as long as the system can stably compare the order. For example, in the scenario of re-signing a supplementary agreement, if two records with candidate contract version identifiers V1 and V2 are both in the signing completion state, but the version status of V1 has been marked as overwritten by re-signing, then V1 will not enter the set of valid candidate records, and the module will directly determine the record corresponding to V2 as the target version record. If V2 and V3 are both in the signing completion state and the version status is normal, the record with the later signing completion time is selected first. If the signing completion times are the same, the record corresponding to the candidate contract version identifier with the later order is selected as the target version record. The system updates the valid contract version identifier when the version status of the candidate contract version identifier corresponding to the valid contract version identifier changes to replacement, re-signing overwrite, revocation, or invalidation. It determines the candidate contract version identifier corresponding to the target version record as the valid contract version identifier, and when the version status of the target version record corresponding to the valid contract version identifier changes to replacement, re-signing overwrite, revocation, or invalidation, it re-selects candidate contract version identifiers from the remaining valid candidate records and updates the valid contract version identifier. Specifically, after the target version record is determined, the version determination module writes the candidate contract version identifier corresponding to the target version record into the valid contract version identifier storage area, serving as the basis for the current contract version called by the subsequent settlement content module and qualification generation module. After the valid contract version identifier is determined, the version determination module continuously monitors or periodically reads the version status of the target version record corresponding to the valid contract version identifier. When the version status of the target version record remains normal, the current valid contract version identifier remains unchanged; when the version status of the target version record changes to replacement... When a contract is re-signed, overwritten, revoked, or becomes invalid, it indicates that the current valid contract version identifier can no longer be used as the basis for subsequent settlement. The version determination module then re-extracts all candidate version records using the same contract identifier and, according to the aforementioned valid candidate screening rules and target version selection rules, re-selects candidate contract version identifiers from the remaining valid candidate records, updating the valid contract version identifiers. If no new valid candidate records are found after re-screening, the valid contract version identifier corresponding to that contract identifier is set to a vacant state, and the screening is performed again after a new signed record enters. For example, in a scenario where the original contract version is revoked by both parties and a new version is signed, the version determination module, upon detecting that the target version record corresponding to the original valid contract version identifier has changed to revoked, immediately rescans all candidate version records under the same contract identifier and updates the newly signed candidate contract version identifier with a normal version status to the new valid contract version identifier, ensuring that the subsequent settlement content module and qualification generation module always execute around the currently effective contract version.

[0012] Settlement content module Extract at least one of the following directly related to settlement from the contract signing content and business acceptance records: amount, payment node, refund conditions, account splitting conditions, and effective conditions. Using the contract identifier and candidate contract version identifier as a joint index, read the corresponding contract signing records and business acceptance records. Extract at least one of the following fields from the settlement field area of ​​the contract signing records: amount field, payment node field, refund condition field, account splitting condition field, and effective condition field. Extract the business document identifier and business entity identifier from the business acceptance records. Specifically, the settlement content module first receives the candidate contract version identifier corresponding to the valid contract version identifier output by the version determination module. Using the contract identifier and candidate contract version identifier as joint search conditions, locate the contract signing content corresponding to the candidate contract version identifier in the contract signing records, and locate the business document identifier and business entity identifier corresponding to the business in the business acceptance records. After locating, the settlement content module... The settlement field area is identified in the contract content. This settlement field area can be a structured field area in the contract template, or a field area formed by the electronic signature system after the settlement terms in the contract text are processed into fields before signing. As long as it can reliably read at least one of the following fields: amount field, payment node field, refund condition field, revenue sharing condition field, and effective condition field, it is acceptable. When not all fields are set under a candidate contract version identifier, only the fields that actually exist under that candidate contract version identifier and are directly related to settlement are extracted, without forcibly filling in the missing fields. For example, in an online service procurement scenario, if the contract signing content corresponding to a candidate contract version identifier only stipulates the initial payment amount and initial payment node, then the settlement content module only extracts the amount field and payment node field under that candidate contract version identifier, and at the same time extracts the corresponding business document identifier and business entity identifier from the business acceptance record to provide basic data for the subsequent formation of version settlement records. Generate version settlement records corresponding one-to-one with each candidate contract version identifier; write each extracted field into a condition item record according to its field type, and associate each condition item record with the candidate contract version identifier; specifically, after completing field extraction, the settlement content module first determines the field type for each field, and then writes the field type, field value, and corresponding candidate contract version identifier into the condition item record; where the field type is used to distinguish between amount, payment node, refund conditions, accounting conditions, and effective conditions, and the field value is used to indicate the specific content of the corresponding field under the current candidate contract version identifier; after writing, the settlement content module establishes a one-to-one correspondence between each condition item record and the candidate contract version identifier, so that... The subsequent qualification generation module can read all condition item records corresponding to the candidate contract version identifier. When there are multiple settlement conditions under the same candidate contract version identifier, a condition item record is generated for each settlement condition, and then these condition item records are merged together by the candidate contract version identifier. For example, in the supplementary agreement signing scenario, if the contract signing content corresponding to the candidate contract version identifier stipulates the initial payment amount, the payment node after acceptance, and the refund trigger condition, then the settlement content module generates condition item records corresponding to the amount field, the payment node field, and the refund condition field, and associates the three condition item records together under the candidate contract version identifier. The candidate contract version identifier, business document identifier, business entity identifier, and records of each condition item are written into the version settlement record. When the settlement field area in the contract signing record changes, the corresponding version settlement record is updated or replaced according to the changed field type and field value. Specifically, after the condition item records are formed, the settlement content module writes the candidate contract version identifier, business document identifier, business entity identifier, and records of each condition item belonging to that candidate contract version identifier into the version settlement record, so that the settlement basis under the same candidate contract version identifier is uniformly saved in the form of version settlement records. When a change in the settlement field area in the contract signing record is subsequently detected, the settlement content module first rereads the changed settlement field area, and then generates a new version settlement record according to the changed field type and field value. The system records condition items and compares each condition item in the new condition item record with the condition items in the original version of the settlement record. When the field type remains unchanged but the field value changes, the original version of the settlement record is updated. When the candidate contract version identifier changes, a field type is added, or a field type is deleted, the original version of the settlement record is replaced. For example, in a scenario where the original contract stipulates payment of 50% after acceptance and the supplementary agreement adjusts it to 60% after acceptance, if the candidate contract version identifier remains unchanged and only the amount field value changes, the original version of the settlement record is updated. If a new candidate contract version identifier is formed after re-signing, and a refund condition field is added at the same time, the original version of the settlement record is replaced, so that the subsequent qualification generation module always reads the version of the settlement record that is consistent with the current candidate contract version identifier.

[0013] Qualification generation module Based on the identity record, valid contract version identifier, version settlement record corresponding to the valid contract version identifier, and current performance status, the system determines whether the current performance status meets the settlement trigger conditions in the version settlement record. If it does, it generates settlement execution qualification for the business document; otherwise, it generates qualification invalidation. The system reads the corresponding identity record, valid contract version identifier, version settlement record, and performance record using the business document identifier. It extracts the condition item identifier, condition type, condition content, and settlement trigger condition for each settlement condition from the version settlement record, and the performance item identifier, performance item type, and performance result for each performance item from the performance record. Specifically, the qualification generation module first uses the business document identifier as a unified read key to locate the identity record corresponding to the current business document in the identity record storage area, and locates the valid contract version identifier corresponding to the current business document in the version management storage area. Then, based on the valid contract version identifier, it reads the corresponding version settlement record in the version settlement record storage area, and simultaneously reads the current business document from the performance record storage area. According to the corresponding performance record; after reading the version settlement record, the various settlement conditions recorded therein are broken down into four types of fields: condition item identifier, condition type, condition content, and settlement trigger condition. The condition item identifier is used to uniquely identify a single settlement condition; the condition type is used to distinguish payment node, amount, refund condition, accounting condition, or effective condition; the condition content is used to record the field value of the condition; and the settlement trigger condition is used to record the performance result required when the condition is met. After reading the performance record, the current performance record is broken down into performance item identifier, performance item type, and performance result. The performance item identifier is used to uniquely identify a single performance item; the performance item type is used to indicate the category to which the performance item belongs; and the performance result is used to indicate the current status of the performance item. For example, in the scenario of online procurement services by enterprise customers, the version settlement record can be broken down into the payment node condition item and the amount condition item corresponding to "payment of the first installment after initial acceptance," and the performance record can be broken down into the performance item corresponding to "initial acceptance" and the current acceptance result of the performance item. Each condition item is associated with a corresponding performance item according to its condition type. A satisfaction comparison is then performed on the established performance items and condition items. A qualification result is obtained when all condition items have corresponding performance items and all satisfaction comparisons pass. A qualification failure result and a failed condition item are obtained when any condition item lacks a corresponding performance item or any satisfaction comparison fails. Specifically, the qualification generation module first uses the condition type as the first matching criterion, matching payment node type condition items with the corresponding performance items for payment nodes, refund condition type condition items with refund performance items, account splitting condition type condition items with account splitting performance items, and effective condition type condition items with effective performance items. Then, the business document identifier is used as the second constraint to ensure that the correspondence is established only within the same business document. For performance items and condition items with established correspondences, a satisfaction comparison is performed, simultaneously checking whether the condition content and settlement trigger condition have been fulfilled. The following conditions are considered met: When the performance result meets the settlement trigger condition requirements and the performance item type matches the condition type, the condition item is deemed met; when the performance result does not meet the settlement trigger condition requirements, or the performance item type does not match the condition type, the condition item is deemed unmet; if a condition item does not have a corresponding performance item in the current performance record, it is directly recorded as not having a corresponding performance item; when all condition items have corresponding performance items and are all determined to be met, the qualification result is output; when any condition item does not have a corresponding performance item or there is an unmet condition item, the qualification failure result and the failed condition item are output. The failed condition item must at least record the condition item identifier, condition type, and reason for failure; for example, in the scenario of "payment after first acceptance," if the performance record shows that the acceptance result is passed, the corresponding payment node condition item is determined to be met; if the acceptance result is pending confirmation, the corresponding payment node condition item is determined to be unmet. When a settlement execution qualification with no valid status exists under the business document identifier and a qualification establishment result is obtained, the business document identifier, identity record identifier, valid contract version identifier, version settlement record identifier, and validity status are associated and written into a new settlement execution qualification. When a settlement execution qualification with no valid status exists under the business document identifier and a qualification failure result is obtained, the business document identifier, valid contract version identifier, failed condition item, and invalidation status are associated and written into a qualification failure result. Specifically, after outputting a qualification establishment result or a qualification failure result, the qualification generation module first checks whether a valid settlement execution qualification already exists under the current business document identifier. When no valid settlement execution qualification exists and the current result is a qualification establishment result, a new settlement execution qualification is generated, and the business document identifier is associated and written into a new settlement execution qualification. The system writes the business document identifier, the identity record identifier corresponding to the current identity record, the current valid contract version identifier, the version settlement record identifier corresponding to the current version settlement record, and the validity status into the settlement execution qualification. When there is no settlement execution qualification in a valid state and the current result is a qualification failure result, a settlement execution qualification is not generated, but a qualification failure result is generated, and the business document identifier, valid contract version identifier, failed condition item, and failure status are written into the qualification failure result. Among them, the valid status indicates that the settlement execution qualification can be directly read by the subsequent control module and used as the basis for release, and the failure status indicates that the current business document does not yet meet the release conditions. In this way, when entering the qualification judgment for the first time, the system either generates an available qualification or an unavailable result, and there will be no blank state with no processing output. The system retrieves valid settlement execution qualifications using the business document identifier and extracts the original identity record identifier, original valid contract version identifier, and original version settlement record identifier from these qualifications. Specifically, when a valid settlement execution qualification already exists under the current business document identifier, the qualification generation module does not directly write a new qualification according to the initial generation process. Instead, it first queries the existing qualification storage area using the business document identifier to retrieve the currently valid original settlement execution qualification for that business document. After retrieval, the original identity record identifier, original valid contract version identifier, and original version settlement record identifier are extracted from the original settlement execution qualification as the basis for subsequent change judgments. The original identity record identifier represents the subject relationship basis upon which the original qualification depends, the original valid contract version identifier represents the contract version basis upon which the original qualification depends, and the original version settlement record identifier represents the settlement condition basis upon which the original qualification depends. If no valid original settlement execution qualification is retrieved, the system returns to the initial generation process and does not proceed to subsequent original qualification change judgments. The original identity record identifier, original valid contract version identifier, and original version settlement record identifier are compared with the currently read identity record identifier, valid contract version identifier, and version settlement record identifier to obtain the basic change result. Then, a satisfaction comparison is performed between each performance item corresponding to the current performance record and each condition item in the version settlement record corresponding to the valid contract version identifier to obtain the current condition satisfaction result. Specifically, the qualification generation module first compares the original identity record identifier with the current identity record identifier item by item, then compares the original valid contract version identifier with the current valid contract version identifier item by item, and then compares the original version settlement record identifier with the current version settlement record identifier item by item. When all three sets of identifiers match, the basic change result is "no change"; if any set of identifiers does not match, the basic change result is "change". After completing the basic change judgment, the module recalculates once again based on the version settlement record corresponding to the current valid contract version identifier and the current performance record, according to the aforementioned correspondence rules between condition items and performance items and satisfaction comparison rules, to obtain the current condition satisfaction result. The basic change result indicates whether the qualification-dependent basic object has changed, and the current condition satisfaction result indicates whether the current performance status still meets the settlement trigger conditions in the current version settlement record. If the basic change result is unchanged and the current conditions are met, the original settlement execution qualification remains valid. If the basic change result is changed or the current conditions are not met, the original settlement execution qualification is designated as a pending invalidation qualification, and a qualification change result containing the changed items or failed conditions is generated. Specifically, when the basic change result is unchanged and the current conditions are met, it indicates that the subject relationship, contract version, settlement records, and performance status on which the original settlement execution qualification depends have not changed, affecting settlement release. In this case, the original settlement execution qualification remains valid, and no new qualification object is generated. When the basic change result is changed or the current conditions are not met, it indicates that the original settlement execution qualification remains valid. If the qualification is no longer suitable as the basis for releasing the current business document, the original settlement execution qualification will be determined as a qualification to be invalidated, and a qualification change result will be generated. The qualification change result shall include at least the business document identifier, change item, or failure condition item. The change item is used to record the items that have changed in the original identity record identifier, the original valid contract version identifier, or the original version settlement record identifier. The failure condition item is used to record the settlement conditions that are not currently met. For example, if the original settlement execution qualification has been generated after the first payment conditions corresponding to the original contract version are met, and the valid contract version identifier changes due to the subsequent contract signing, even if the performance result has not changed, the original settlement execution qualification will be transferred to a qualification to be invalidated because the basic change result is a change. After generating the qualification change results, the original qualification identifier, original valid contract version identifier, and original version settlement record identifier are extracted from the qualification to be invalidated. The change items or failed condition items are then extracted from the qualification change results. Specifically, after the original settlement execution qualification is marked as a qualification to be invalidated, the qualification generation module first reads the original qualification identifier, original valid contract version identifier, and original version settlement record identifier from the qualification to be invalidated. Then, it reads the change items or failed condition items generated in the previous step from the qualification change results. The original qualification identifier is used to uniquely identify the original settlement execution qualification that has been replaced or negated. The original valid contract version identifier and the original version settlement record identifier are used to indicate the version basis and settlement condition basis upon which the original qualification depends. The change items or failed condition items are used to indicate the direct reason for the original qualification's invalidation. The purpose of this step is to separate and extract the original qualification object and its reason for invalidation, preparing for the subsequent generation of qualification items to be invalidated. The system associates the business document identifier, original qualification identifier, original valid contract version identifier, original version settlement record identifier, and change or failure condition item to generate qualification items to be invalidated. It then merges all qualification items corresponding to the same business document identifier into a qualification set to be invalidated. Specifically, the qualification generation module writes the current business document identifier, original qualification identifier, original valid contract version identifier, original version settlement record identifier, and change or failure condition item into the same qualification item record to be invalidated. If there is only one qualification item to be invalidated under the same business document identifier, that record is directly used as the qualification set to be invalidated for that business document. If there are multiple qualification items to be invalidated under the same business document identifier, the business document identifier is used as the primary key and the original qualification identifier as the subkey to merge the multiple qualification items to be invalidated, and the failure reasons belonging to the same original settlement execution qualification are centrally saved into the same qualification set to be invalidated. Through this merging process, multiple historical qualification objects and multiple failure reasons that may appear under the same business document can be managed uniformly, facilitating the subsequent formation of new and old qualification replacement relationships. The qualification status of each original settlement execution qualification corresponding to the set of qualifications to be invalidated is updated to invalid and retained as historical invalid qualifications, so that the qualification change result corresponds to the original settlement execution qualification, the original version of the settlement record, and the original business document. Specifically, after the set of qualifications to be invalidated is formed, the qualification generation module updates the qualification status of each original settlement execution qualification corresponding to the set from valid to invalid, while not deleting these original settlement execution qualifications, but continuing to retain them in the qualification storage area as historical invalid qualifications. Here, historical invalid qualifications refer to original settlement execution qualifications whose qualification status has been updated to invalid but are still retained for subsequent blocking processing, identification of replacement between old and new qualifications, and historical tracing. After this status update, the qualification change result is no longer just an independent change description, but can stably correspond to the specific original settlement execution qualification, the original version of the settlement record, and the original business document, thereby ensuring that the subsequent control module can accurately locate the historical qualification link that should be blocked when it needs to block the old qualification derivation action. After generating the set of qualifications to be invalidated, the current identity record, valid contract version identifier, version settlement record corresponding to the valid contract version identifier, and current performance record are reread using the business document identifier. A satisfaction comparison is then performed again on each performance item in the current performance record and each condition item in the version settlement record corresponding to the valid contract version identifier. Specifically, after forming the set of qualifications to be invalidated, the qualification generation module does not directly end the process. Instead, it rereads the current identity record, current valid contract version identifier, current version settlement record, and current performance record again using the business document identifier as the unified read key. The purpose of this rereading is to confirm whether the current business document, under the new subject basis, version basis, and settlement condition basis, has the necessary conditions for re-validation. The system generates settlement execution eligibility conditions. After reading the data, it compares each performance item in the current performance record with each condition item in the current version of the settlement record again, following the rules for establishing the correspondence between the condition items and the performance items and the rules for satisfaction comparison. If the comparison results show that all condition items are satisfied, the system proceeds to the new eligibility generation process. If the comparison results still show that there are unsatisfied condition items, the system retains the set of eligibility items to be invalidated and the historical invalidated eligibility items, and waits for subsequent performance records to change again before re-judging. For example, in a scenario where the original contract version is invalid, the supplementary agreement is effective, and the corresponding performance node has not yet been completed, the system will first form a set of eligibility items to be invalidated, but will not immediately generate new settlement execution eligibility. Instead, it will wait for the new performance conditions to be met before proceeding to the next step. When all satisfaction comparisons pass in a re-execution, the business document identifier, current identity record identifier, valid contract version identifier, version settlement record identifier, and validity status are associated and written into the new settlement execution qualification, and a new qualification identifier is extracted from the new settlement execution qualification. Specifically, when all satisfaction comparisons pass in a re-execution, the qualification generation module generates a new settlement execution qualification and writes the business document identifier, current identity record identifier, current valid contract version identifier, current version settlement record identifier, and validity status into the new settlement execution qualification. After writing, the new qualification identifier is extracted from the new settlement execution qualification as the connection key for establishing the replacement relationship between the old and new qualifications. The new qualification identifier is used to uniquely identify the qualification object re-formed based on the current subject, current version, and current performance conditions, enabling the system to clearly distinguish its succession relationship with the original settlement execution qualification. For example, when a supplementary agreement takes effect and a new payment node has been completed, the system will generate a new settlement execution qualification after all comparisons pass in a re-execution and assign a new qualification identifier to the qualification. The new qualification identifier is associated with each of the original qualification identifiers in the set of qualifications to be expired, generating a new and old qualification replacement relationship. The new settlement execution qualification is determined as a valid settlement execution qualification, and each of the original settlement execution qualifications in the set of qualifications to be expired is determined as a historical expired qualification, forming a qualification level record corresponding to the same business document identifier. Specifically, after obtaining the new qualification identifier, the qualification generation module associates the new qualification identifier with each of the original qualification identifiers in the set of qualifications to be expired, forming a new and old qualification replacement relationship. The new and old qualification replacement relationship records at least the new qualification identifier, the original qualification identifier, and the replacement correspondence between them, indicating which original qualifications have become valid after the current qualification expires. After the replacement relationship is formed, the new qualification identifier is associated with each of the original qualification identifiers in the set of qualifications to be expired. Once a settlement execution qualification is determined to be valid, all original settlement execution qualifications in the set of qualifications to be invalidated will be retained as historical invalid qualifications. The business document identifier, new qualification identifier, original qualification identifier, and the replacement relationship between the old and new qualifications will be written into the qualification level record, thus forming a qualification level chain corresponding to the same business document identifier. For example, when a new payment qualification is generated due to the new contract version and new performance conditions after the original down payment qualification has expired, the system will establish a replacement relationship between the new qualification identifier and the original qualification identifier, and write this relationship along with the business document identifier into the qualification level record. This allows the subsequent control module to only read the new qualification that is currently valid, while still being able to trace why the original qualification expired and which new qualification took over.

[0014] Control module Upon receiving a settlement request, the system verifies whether the business document identifier in the settlement request matches the business document identifier in the settlement execution qualification, whether the requested contract version identifier in the settlement request matches the valid contract version identifier in the settlement execution qualification, and whether the settlement parameters in the settlement request match the condition item record corresponding to the version settlement record. A settlement instruction is generated and sent to the payment settlement system only if all the above verifications are consistent and the settlement execution qualification is valid. If there are inconsistencies in the above verifications or the settlement execution qualification is not valid, a settlement blocking result is output: The payment settlement system executes the settlement request according to the received settlement instruction; using the business document identifier as the retrieval condition, it reads the settlement execution qualification in a valid state, and extracts the business document identifier, valid contract version identifier, and version settlement record identifier from the valid settlement execution qualification, and then reads the corresponding condition item record according to the version settlement record identifier; specifically, after receiving a settlement request, the control module first extracts the business document identifier, requested contract version identifier, and settlement parameters from the settlement request, and uses the business document identifier as... The system uses a search key to locate valid settlement execution qualifications in the settlement execution qualification storage area. If no valid settlement execution qualification is found, the current settlement request is immediately blocked, and subsequent matching steps are not performed. If a valid settlement execution qualification is found, the system extracts the business document identifier, valid contract version identifier, and version settlement record identifier from that qualification. Then, using the version settlement record identifier as an index, the system reads the corresponding condition item record from the version settlement record storage area. Each condition item record includes at least a condition item identifier, condition type, and condition content, serving as the basis for subsequent settlement parameter comparisons. The payment settlement system does not initiate settlement proactively; it only executes the corresponding settlement request after receiving a settlement instruction from the control module. For example, in an online procurement service scenario for enterprise customers, the control module first checks the existence of a valid settlement execution qualification based on the business document identifier in the payment application, and then reads the corresponding payment node condition item and amount condition item based on the version settlement record associated with that qualification, providing a comparison basis for subsequent release judgments. The control module performs document matching by first matching the business document identifier in the settlement request with the business document identifier in the valid settlement execution qualification, then matching the requested contract version identifier in the settlement request with the valid contract version identifier in the valid settlement execution qualification, and finally comparing each settlement parameter in the settlement request with the corresponding condition item in the condition item record to obtain a release result, a blocking result, or a failure item. Specifically, the control module first performs document matching to determine whether the business document identifier in the settlement request is completely consistent with the business document identifier in the settlement execution qualification. If they are inconsistent, it is directly recorded as document matching failure. After document matching is successful, version matching continues to perform version matching to determine whether the requested contract version identifier in the settlement request is consistent with the valid contract version identifier in the settlement execution qualification. If they are inconsistent, it is recorded as version matching failure. After passing the initial screening, the control module further breaks down each settlement parameter in the settlement request by parameter type and compares it with the corresponding condition item in the condition item record. During the comparison, the condition type is used as the basis for matching, and the consistency between the parameter value and the condition content is used as the comparison criterion. If a settlement parameter cannot find a matching condition item in the condition item record, or if a matching condition item is found but the parameter value is inconsistent with the condition content, that item is recorded as a failed item. When document matching, version matching, and all settlement parameter comparisons pass, the release result is output. When any item fails, the blocking result and the failed item are output. For example, in the down payment application scenario, if the requested contract version identifier in the payment application is still the old version, while the valid contract version identifier in the current settlement execution qualification has been updated to the new version, the control module directly determines that the version matching has failed and records this version difference as a failed item. Upon receiving a release result, a settlement instruction is generated based on the settlement request and sent to the payment settlement system. Upon receiving a blocking result, the business document identifier, failed items, and blocking status are associated and written into the settlement blocking result. Specifically, when the control module receives a release result, it generates the corresponding settlement instruction, writes it into the settlement processing record, and sends it to the payment settlement system. When the control module receives a blocking result, it does not generate an executable settlement instruction but instead writes the business document identifier, failed items, and blocking status into the settlement blocking result. Among these, the failed items are used to record the reasons for failure in document matching, version matching, or settlement parameter comparison. For example, in a scenario where the payment amount is inconsistent with the amount condition item in the version settlement record, the control module writes the failed amount comparison into the failed item and directly writes the payment application into the settlement blocking result without sending a settlement instruction to the payment settlement system. The control module reads the settlement processing record corresponding to the historically invalidated qualification from the qualification hierarchy record, and extracts the processing status and settlement instruction identifier from the settlement processing record. Specifically, in addition to processing newly entered settlement requests, the control module continuously monitors the historically invalidated qualifications already formed in the qualification hierarchy record, and reads the settlement processing record corresponding to the historically invalidated qualification from the qualification hierarchy record. The settlement processing record refers to the processing object generated and continuously maintained by the control module for settlement requests, and includes at least a qualification identifier, processing status, and settlement instruction identifier. The qualification identifier indicates which settlement execution qualification the settlement processing record is derived from, and the processing status indicates that the processing record is currently pending. The settlement instruction identifier indicates whether the status is execution, pending retry, generated but not yet settled, completed, or blocked. The control module locates the settlement processing record associated with the historically invalidated qualification through the original qualification identifier in the qualification hierarchy record, and extracts the processing status and settlement instruction identifier from it, providing basic data for subsequent identification of which old actions have not yet been completed. For example, in a scenario where the original payment qualification has expired but its corresponding settlement request has previously generated a settlement instruction, the control module can find the settlement processing record corresponding to the original qualification through the qualification hierarchy record, and further determine whether the old processing record is still in a blocked processing state. The original qualification identifier in the historical invalid qualifications is associated with the qualification identifiers in each settlement processing record. When the processing status is pending execution, pending retry, or generated but not yet settled, the corresponding settlement processing record is identified as a record to be blocked. Specifically, the control module compares the original qualification identifier in the historical invalid qualifications with the qualification identifiers in each settlement processing record item by item. Settlement processing records with matching qualification identifiers are considered as processing objects derived from the historical invalid qualification. Among these successfully associated settlement processing records, their processing status is further checked. When the processing status is pending execution, it indicates that the record has completed verification but has not yet sent a settlement instruction; when the processing status is pending retry, it indicates that the record has completed verification but has not yet sent a settlement instruction. The record shows a previous failed attempt and is currently waiting to be sent again. When the processing status is "generated but not yet credited," it indicates that the settlement instruction has been generated, but the corresponding fund processing result has not yet been written into the settlement result record. The settlement result record is used to record the deduction, refund, or splitting execution result returned by the payment settlement system. The control module uniformly identifies settlement processing records in the above three states as records to be blocked because the settlement actions corresponding to these records have not yet been truly completed and may still continue to be executed. For example, in a scenario where the original payment qualification has expired but the payment instruction has not yet been credited, the settlement processing record corresponding to this payment is identified by the control module as a record to be blocked because the processing status is "generated but not yet credited." The processing status of the record to be blocked is updated to blocked status, and the corresponding settlement instruction identifier is revoked or the sending of the corresponding settlement instruction is stopped, so that the settlement actions derived from the historical invalid qualification that have not yet been completed become invalid synchronously with the historical invalid qualification. Specifically, after identifying the record to be blocked, the control module first updates the processing status of the record to be blocked to blocked status, and then performs different processing based on whether a settlement instruction identifier already exists in the record to be blocked; when a settlement instruction identifier has been generated in the record to be blocked but has not yet been settled, the control module sends a revocation instruction to the settlement processing link, so that the settlement action corresponding to the settlement instruction identifier will no longer be executed; when a settlement instruction identifier has not yet been generated in the record to be blocked .... When a record is in a pending execution or retry state, the control module stops sending subsequent settlement instructions. This process ensures that settlement actions derived from historically invalidated qualifications but not yet completed remain synchronized with the historically invalidated qualification itself, preventing old settlement actions from continuing to be sent to the payment settlement system even after the old qualification has expired. For example, in a scenario where a contract version change causes the original payment qualification to become a historically invalidated qualification, if the processing record corresponding to the original payment is still in a retry state, the control module changes its processing state to a blocked state and stops sending the corresponding payment instruction again, thus ensuring that the system only allows settlement actions consistent with the currently valid qualification to continue execution.

[0015] Working Principle: This invention first links the real-name results, business acceptance records, contract signing records, performance records, and settlement requests, which were originally scattered across different systems, using a single business document identifier. Then, it progressively determines whether the current business truly meets the settlement conditions. The system first confirms the correspondence between the current handler and the business entity, forming an identity record. Next, it filters out the currently valid contract versions from the same contract identifier, forming a valid contract version identifier. Then, it organizes the amounts, payment nodes, refund conditions, revenue sharing conditions, and effective conditions directly related to settlement in this version into a version settlement record. Afterward, the system compares these settlement conditions with the current performance status item by item. Only when all conditions are met is settlement execution qualification generated. If it is found that the identity basis has changed, the contract version has changed, the settlement conditions have changed, or the performance status no longer meets the original conditions, the original qualification is invalidated, and a new qualification is rebuilt as appropriate. Finally, the control module only allows settlement requests that fully match the current valid eligibility to enter the payment settlement system. Requests that do not match will be blocked, and settlement actions derived from the old eligibility but not yet completed will also be stopped, thereby avoiding a disconnect between the contractual fact, the performance status, and the settlement execution.

[0016] For example, in a scenario where enterprise customers purchase services online, the authorized representative first completes real-name verification and submits a business application. The system first confirms whether this representative is indeed the business entity or whether they are a pre-authorized representative of the enterprise. Subsequently, the enterprise signs the contract online. If a new version is subsequently signed, the system automatically identifies which version is currently valid. Next, the system extracts settlement conditions from this valid version, such as "payment of the first installment after initial acceptance." When the enterprise initiates a payment request, the system does not immediately approve it. Instead, it first checks whether the corresponding business document, requested contract version, and payment parameters match the currently valid settlement execution qualification, and also checks whether the performance record has already shown "initial acceptance passed." Only when all these conditions are met does the system send a settlement instruction to the payment and settlement system. If the contract is later changed, or the original payment qualification has expired, the system will not only block new payment requests but also block any pending, retry, or unrecorded settlement actions left by the old qualification. This ensures that the final executed contract and performance result are always the currently valid one.

[0017] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An integrated system for online business real-name verification, signing, and settlement, characterized in that, include: The access module obtains real-name results, business acceptance records, contract signing records, performance records, and settlement requests. Among them, the real-name results include at least the real-name subject identifier and the business document identifier; the business acceptance records include at least the business document identifier and the business subject identifier; the contract signing records include at least the contract identifier, the candidate contract version identifier, the signing status, and the contract signing content; the performance records include at least the business document identifier and the current performance status; and the settlement requests include at least the business document identifier, the requested contract version identifier, and the settlement parameters. The identity verification module reads the business entity identifier from the business acceptance record based on the business document identifier, verifies whether the real-name entity identifier is equal to the business entity identifier or whether it belongs to the authorized operation entity corresponding to the business entity, and generates an identity record containing the real-name entity identifier, business entity identifier and business document identifier when the verification is successful. The version determination module determines the valid contract version identifier based on the contract identifier, candidate contract version identifier, and signing status, and updates the valid contract version identifier when the version status of the candidate contract version identifier corresponding to the valid contract version identifier changes to replacement, re-signing and overwriting, revocation, or invalidation. The settlement content module extracts at least one of the following directly related to settlement from the contract signing content and business acceptance records: amount, payment node, refund conditions, revenue sharing conditions and effective conditions, and generates a version settlement record that corresponds one-to-one with each candidate contract version identifier. The qualification generation module determines whether the current performance status meets the settlement trigger conditions in the version settlement record based on the identity record, the valid contract version identifier, the version settlement record corresponding to the valid contract version identifier, and the current performance status. If the conditions are met, the module generates the settlement execution qualification corresponding to the business document; otherwise, it generates a qualification invalidation result. Upon receiving a settlement request, the control module verifies whether the business document identifier in the settlement request matches the business document identifier in the settlement execution qualification; whether the requested contract version identifier in the settlement request matches the valid contract version identifier in the settlement execution qualification; and whether the settlement parameters in the settlement request match the condition item record corresponding to the version settlement record. Only when all the above verifications are consistent and the settlement execution qualification is valid, a settlement instruction is generated and sent to the payment and settlement system. If there are inconsistencies in the above verifications or the settlement execution qualification is not valid, a settlement blocking result is output. The payment and settlement system executes the settlement request according to the received settlement instruction.

2. The system according to claim 1, characterized in that, In the identity verification module: Using the business document identifier as the search condition, the system searches for target records in the business acceptance records that have the same document identifier and are in a valid acceptance status, and then reads the business entity identifier and the authorized operation entity identifier set from the target record. The real-name entity identifier and the business entity identifier are compared for primary key consistency. If the primary key consistency comparison fails, the real-name entity identifier is compared with each entity identifier in the set of authorized operation entity identifiers to obtain the entity consistency result or the authorization matching result. When a subject consistency result or authorization matching result is obtained, the real-name subject identifier, business subject identifier, business document identifier and the corresponding matching result are written into the identity record. If the identity record corresponding to the business document identifier already exists, the original identity record is overwritten or replaced according to the current matching result.

3. The system according to claim 1, characterized in that, In the version determination module: Using the contract identifier as the search criterion, extract each candidate version record with the same contract identifier from the contract signing records, and read the candidate contract version identifier, signing status, signing completion time and version status from each candidate version record; Candidate version records with a signing status of "signing completed" and whose version status is not "replacement", "re-signing overwrite", "revocation" or "invalidation" are identified as valid candidate records. When there are multiple valid candidate records, the target version record is selected according to the rule of priority of signing completion time and priority of candidate contract version identifier. The candidate contract version identifier corresponding to the target version record is determined as the valid contract version identifier. When the version status of the target version record corresponding to the valid contract version identifier changes to replacement, re-signing and overwriting, revocation or invalidation, a new candidate contract version identifier is selected from the remaining valid candidate records, and the valid contract version identifier is updated.

4. The system according to claim 1, characterized in that, In the settlement content module: Using the contract identifier and candidate contract version identifier as a combined index, read the corresponding contract signing record and business acceptance record, extract at least one of the amount field, payment node field, refund condition field, account splitting condition field and effective condition field from the settlement field area of ​​the contract signing record, and extract the business document identifier and business entity identifier from the business acceptance record; Each extracted field is written into a condition item record according to its field type, and each condition item record is associated with the candidate contract version identifier; Write the candidate contract version identifier, business document identifier, business entity identifier, and each condition item record into the version settlement record. When the settlement field area in the contract signing record changes, update or replace the corresponding version settlement record according to the changed field type and field value.

5. The system according to claim 1, characterized in that, In the qualification generation module: The system reads the corresponding identity record, valid contract version identifier, version settlement record, and performance record based on the business document identifier. It also extracts the condition item identifier, condition type, condition content, and settlement trigger condition corresponding to each settlement condition from the version settlement record, and extracts the performance item identifier, performance item type, and performance result corresponding to each performance item from the performance record. Each condition item is associated with each performance item according to its condition type. A satisfaction comparison is performed on the performance items and condition items that have been associated. When all condition items have corresponding performance items and all satisfaction comparisons are passed, the qualification result is obtained. When any condition item does not have a corresponding performance item or any satisfaction comparison is failed, the qualification result and the failed condition item are obtained. When there is no valid settlement execution qualification for the business document and the qualification is established, the business document identifier, identity record identifier, valid contract version identifier, version settlement record identifier, and valid status are associated and written into the new settlement execution qualification. When there is no valid settlement execution qualification for the business document and the qualification is not established, the business document identifier, valid contract version identifier, failed condition item, and invalid status are associated and written into the qualification invalidation result.

6. The system according to claim 5, characterized in that, In the qualification generation module: Read the original settlement execution qualification that is in a valid state using the business document identifier, and extract the original identity record identifier, the original valid contract version identifier, and the original version settlement record identifier from the original settlement execution qualification; The original identity record identifier, the original valid contract version identifier, and the original version settlement record identifier are compared with the currently read identity record identifier, valid contract version identifier, and version settlement record identifier to obtain the basic change result. Then, the satisfaction comparison is performed between each performance item corresponding to the current performance record and each condition item in the version settlement record corresponding to the valid contract version identifier to obtain the current condition satisfaction result. If the basic change result is unchanged and the current condition is met, the original settlement execution qualification remains valid. If the basic change result is changed or the current condition is not met, the original settlement execution qualification is determined to be invalidated, and a qualification change result containing the changed items or failed condition items is generated.

7. The system according to claim 6, characterized in that, In the qualification generation module: After generating the qualification change results, extract the original qualification identifier, the original valid contract version identifier, and the original version settlement record identifier from the qualification to be invalidated, and extract the change items or failed conditions from the qualification change results; Associate the business document identifier, original qualification identifier, original valid contract version identifier, original version settlement record identifier and change item or failure condition item to generate qualification items to be invalidated, and merge the qualification items to be invalidated corresponding to the same business document identifier into a set of qualification items to be invalidated. Update the qualification status of each original settlement execution qualification corresponding to the set of qualifications to be invalidated to invalid status and retain it as a historical invalid qualification, so that the qualification change result corresponds to the original settlement execution qualification, the original version of settlement record and the original business document.

8. The system according to claim 7, characterized in that, In the qualification generation module: After generating the set of qualifications to be invalidated, the current identity record, valid contract version identifier, version settlement record corresponding to the valid contract version identifier, and current performance record are reread using the business document identifier. Then, a satisfaction comparison is performed again on each performance item in the current performance record and each condition item in the version settlement record corresponding to the valid contract version identifier. When all satisfaction comparisons are passed in the re-execution, the business document identifier, current identity record identifier, valid contract version identifier, version settlement record identifier, and valid status are associated and written into the new settlement execution qualification, and the new qualification identifier is extracted from the new settlement execution qualification; The new qualification identifier is associated with each of the original qualification identifiers in the set of qualifications to be expired, generating a new and old qualification replacement relationship. The new settlement execution qualification is determined as a settlement execution qualification in a valid state, and each of the original settlement execution qualifications in the set of qualifications to be expired is determined as a historical expired qualification, forming a qualification level record corresponding to the same business document identifier.

9. The system according to claim 8, characterized in that, In the control module: Using the business document identifier as the retrieval condition, read the settlement execution qualifications that are in a valid state, and extract the business document identifier, valid contract version identifier, and version settlement record identifier from the settlement execution qualifications that are in a valid state. Then, read the corresponding condition item records according to the version settlement record identifier. The document identifier in the settlement request is matched with the document identifier in the settlement execution qualification that is in a valid state. The contract version identifier in the settlement request is matched with the valid contract version identifier in the settlement execution qualification that is in a valid state. Each settlement parameter in the settlement request is compared with the corresponding condition item in the condition item record to obtain the release result, blocking result and failure item. Upon receiving a release result, a settlement instruction is generated based on the settlement request and sent to the payment and settlement system. Upon receiving a blocking result, the business document identifier, the failed item, and the blocking status are associated and written into the settlement blocking result.

10. The system according to claim 8, characterized in that, In the control module: Read the settlement processing record corresponding to the historically invalidated qualification based on the qualification level record, and extract the processing status and settlement instruction identifier from the settlement processing record; Associate the original qualification identifier in the historical invalid qualifications with the qualification identifier in each settlement processing record. When the processing status is pending execution, pending retry, or generated but not yet settled, the corresponding settlement processing record is identified as a record to be blocked. Update the processing status of the record to be blocked to blocked status, and revoke the corresponding settlement instruction identifier or stop sending the corresponding settlement instruction, so that the settlement actions derived from the historical invalid qualification that have not yet been completed become invalid at the same time as the historical invalid qualification.

Images