Transaction data processing method and apparatus, electronic device, and storage medium

Abstract

The application discloses a transaction data processing method and device, electronic equipment and storage medium. The method comprises the following steps: acquiring and aggregating the reconciliation files of the plurality of first application systems to obtain a target reconciliation file, each first application system having a corresponding second application system, the reconciliation file including the first transaction data recorded by the first application system between the corresponding second application system within a specified period; updating the transaction log of the transaction processing system based on the second transaction data recorded by the plurality of second application systems within the specified period, the transaction log including the third transaction data recorded by the transaction processing system between the plurality of first application systems and the plurality of second application systems within the specified period; and performing reconciliation processing on the third transaction data in the updated transaction log based on the target reconciliation file to obtain a reconciliation result.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a transaction data processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] To achieve real-time transactions, transactions between different business parties are typically processed through a transaction processing system that acts as an intermediary platform. To ensure the consistency and accuracy of transaction data, the transaction processing system needs to reconcile accounts between the transacting parties.

[0003] In many business scenarios, some business parties may set up multiple application systems. For example, a first business party might deploy multiple first application systems, each serving users in different regions. To better facilitate transactions with the first business party, a second business party might also set up multiple second application systems, each used to transact with one first application system. Correspondingly, the transaction processing system would employ a split-reconciliation approach to reconcile the transactions between the two parties. For instance, each time the transaction processing system receives a reconciliation file from a first application system, it immediately reads the transaction data between that first application system and its corresponding second application system from the transaction log and uses the reconciliation file to reconcile the read transaction data.

[0004] However, when using a point-to-point reconciliation method, if the user initiating the transaction is located in a different location than the transaction processing location—for example, the first business party is the settlement party and the second business party is the receiving party—and a user in location A applies to transact in location B, the transaction processing system will request the second application system in location B to process the transaction and return the processing result to the first application system in location A for settlement. In this case, the reconciliation file sent by the first application system in location B will not contain this transaction, leading to an incorrect reversal of the transaction data recorded in the transaction log. Similarly, if the first application system sends multiple reconciliation files—such as sending a normal reconciliation file the first time and an abnormal file the second time, or vice versa—some transaction data may also be incorrectly reversed, requiring subsequent manual processing by relevant business personnel. As business volume increases, the number of incorrectly reversed transactions also increases, leading to more frequent manual interventions, resulting in decreased reconciliation accuracy and efficiency, and wasted human resources. Summary of the Invention

[0005] The purpose of this application is to provide a transaction data processing method, apparatus, electronic device, and storage medium to solve the problems of low reconciliation efficiency, low accuracy, and waste of human resources caused by erroneous transaction reversals in related technologies.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] In a first aspect, embodiments of this application provide a transaction data processing method, including:

[0008] The reconciliation files of the multiple first application systems are obtained and aggregated to obtain the target reconciliation file. Each first application system has a corresponding second application system. The reconciliation file includes the first transaction data between the first application system and the corresponding second application system within a specified time period, as recorded by the first application system.

[0009] Based on the second transaction data recorded by each of the plurality of second application systems within the specified time period, the transaction log of the transaction processing system is updated. The transaction log includes the third transaction data recorded by the transaction processing system between the plurality of first application systems and the plurality of second application systems within the specified time period.

[0010] Based on the target reconciliation file, the third transaction data in the updated transaction log is reconciled to obtain the reconciliation result.

[0011] Secondly, embodiments of this application provide a transaction data processing apparatus, comprising:

[0012] The acquisition unit is used to acquire the reconciliation files of the multiple first application systems and perform summary processing to obtain the target reconciliation file. Each first application system has a corresponding second application system. The reconciliation file includes the first transaction data between the first application system and the corresponding second application system recorded within a specified time period.

[0013] An update unit is used to update the transaction log of the transaction processing system based on the second transaction data recorded by each of the plurality of second application systems within the specified time period. The transaction log includes the third transaction data recorded by the transaction processing system between the plurality of first application systems and the plurality of second application systems within the specified time period.

[0014] The reconciliation unit is used to perform reconciliation processing on the third transaction data in the updated transaction log based on the target reconciliation file, and obtain the reconciliation result.

[0015] Thirdly, embodiments of this application provide an electronic device, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method as described in the first aspect.

[0016] Fourthly, embodiments of this application provide a readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method described in the first aspect.

[0017] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0018] Since the second application system is the final party executing the transaction processing, the third transaction data in the second application system is authentic and reliable. Based on the second transaction data from multiple second application systems, the transaction log of the transaction processing system is updated to obtain the updated transaction log. That is, the second business party first unifies its internal transaction data, which serves as a preliminary correction of the third transaction data in the transaction log and can initially ensure the validity of the third transaction data in the transaction log. Based on this, the updated transaction log is then reconciled according to the target reconciliation file to obtain the reconciliation result. The target reconciliation file is obtained by aggregating the reconciliation files of multiple first application systems. Because the third transaction log in the transaction log has undergone internal reconciliation, and the reconciliation files of multiple first application systems have been aggregated together, transaction data where the user's place of origin and the transaction processing location are inconsistent during the original separate reconciliation will not be incorrectly reversed. Furthermore, if a first application system sends multiple reconciliation files, it will not perform multiple reconciliations based on those files, thus preventing some transaction data from being incorrectly reversed. Therefore, the method adopted in this application embodiment can reduce the number of incorrectly reversed transaction data, thereby reducing the number of manual interventions, improving the accuracy and efficiency of reconciliation, and avoiding waste of human resources. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 A flowchart illustrating a transaction data processing method provided in one embodiment of this application;

[0021] Figure 2 A schematic diagram illustrating the correspondence between the first application systems and the second application systems provided in the embodiments of this application;

[0022] Figure 3 This is a schematic diagram of the transaction data processing flow of the transaction data processing system provided in the embodiments of this application;

[0023] Figure 4A schematic diagram illustrating the process of updating transaction logs based on second transaction data in a transaction data processing system provided in this application embodiment;

[0024] Figure 5 A schematic diagram illustrating the process of reconciliation processing based on the target reconciliation file and the updated transaction log in the transaction data processing system provided in this application embodiment;

[0025] Figure 6 A schematic diagram of the structure of a transaction data processing apparatus provided in one embodiment of this application;

[0026] Figure 7 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] The terms "first," "second," etc., used in this specification and claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in sequences other than those illustrated or described herein. Furthermore, in this specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0029] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0030] See Figure 1 The following is a flowchart illustrating a transaction data processing method according to an embodiment of this application. This method is applied to a transaction processing system and may include the following steps:

[0031] S102, obtain the reconciliation files of multiple first application systems and perform summary processing to obtain the target reconciliation file.

[0032] The system comprises several parts: a first application system (set up by the first business party), and a second application system (set up by the second business party). Each first application system performs different processing, for example, different first application systems provide services to users in different regions. Each first application system has a corresponding second application system, which is set up by the second business party. Transactions between multiple first application systems and multiple second application systems are conducted through a transaction processing system. The reconciliation file includes the first transaction data recorded by the respective first application system between itself and its corresponding second application system within a specified time period.

[0033] In practical applications, the first transaction data recorded by the first application system within a specified time period between itself and the corresponding second application system can be the first transaction data within a day or the first transaction data within a month. That is, the specified time period can be set according to actual reconciliation needs. This application embodiment does not specifically limit this, and this content will not be repeated in other embodiments of this application. For example, if end-of-day reconciliation is to be achieved, then the specified time period can be the period between the current day's reconciliation deadline and the previous day's reconciliation deadline; if monthly reconciliation is to be achieved, then the specified time period can be the period between the current month's reconciliation deadline and the previous month's reconciliation deadline, and so on.

[0034] This example illustrates the correspondence between the first and second application systems and the reconciliation files of each first application system. It should not be construed as limiting the methods of the embodiments in this application. Example 1: (e.g.) Figure 2 The diagram shown illustrates the structural relationship between the various first application systems and the various second application systems provided in this application embodiment. It includes multiple first application systems ①, ②, ③, ④, and ⑤ set up by the first business party; second application systems A, B, C, D, and E set up by the second business party corresponding to each of the first application systems; and reconciliation files for each first application system, namely Reconciliation File 1, Reconciliation File 2, Reconciliation File 3, Reconciliation File 4, and Reconciliation File 5. Taking Reconciliation File 1 as an example, Reconciliation File 1 includes the first transaction data recorded by the first application system ① within a specified time period between it and the corresponding second application system A. It should be understood that... Figure 2 The double-headed arrows are used to indicate the correspondence between the first and second application systems and have no other special meaning.

[0035] During the transaction process, each first application system, each second application system, and the transaction system record the transaction data generated during the transaction. To distinguish the transaction data recorded by each of the first application systems, second application systems, and the transaction processing system, in this embodiment, the transaction data recorded by each first application system within a specified time period between itself and its corresponding second application system is recorded as first transaction data; the transaction data recorded by multiple second application systems within the specified time period is recorded as second transaction data; and the transaction data recorded by the transaction processing system between the multiple first application systems and the multiple second application systems within the specified time period is recorded as third transaction data. This content is the same in this embodiment and the remaining embodiments, and will not be repeated hereafter. The transaction processing system, acting as an intermediary platform between the first business party and the second business party, is used to conduct transactions between multiple first application systems of the first business party and multiple second application systems of the second business party.

[0036] As an optional implementation, step S102 above may include the following steps:

[0037] S121, retrieve the reconciliation files of each first application system from the designated server.

[0038] S122, for each first application system, if multiple reconciliation files of the first application system are obtained from the designated server, the non-empty reconciliation file closest to the reconciliation deadline is taken as the valid reconciliation file of the first application system; or, if no reconciliation file of the first application system is obtained from the designated server, a retrieval request is sent to the first application system, which is used to request the first application system to send its own reconciliation file to the designated server.

[0039] The reconciliation deadline refers to the agreed-upon deadline by the first business party and the second business party for all first application systems to send their respective reconciliation files to the designated server. The designated server is a server pre-selected by the first business party and the second business party to store the reconciliation files sent by each of the multiple first application systems.

[0040] This example illustrates the validity of reconciliation files in this application embodiment and should not be construed as limiting the method of this application embodiment. Example 2: Assume the reconciliation deadline is 15:00. A non-empty reconciliation file A sent by the first application system at 13:30 has been obtained from the designated server. Then, a reconciliation file B sent by the first application system at 14:00 is obtained from the designated server. If reconciliation file B is non-empty, it is considered a valid reconciliation file for the first application system. If reconciliation file B is empty, reconciliation file A is considered a valid reconciliation file for the first application system. If a reconciliation file sent by the first application system is obtained again before the reconciliation deadline of 15:00, the valid reconciliation file for the first application system is determined in the same way.

[0041] In this embodiment, the first application system may send a reconciliation file and then immediately retrieve the reconciliation file from the designated server. Alternatively, it may retrieve the file from the designated server a short time after sending it. Similarly, the non-empty reconciliation file closest to the reconciliation deadline is considered the valid reconciliation file of the first application system. This embodiment does not impose any specific limitations on this.

[0042] For each first application system, the process begins when the reconciliation file can be obtained from the designated server. If the reconciliation file for the first application system cannot be obtained from the designated server, a retrieval request is sent to the first application system. The retrieval request is used to request the first application system to send its own reconciliation file to the designated server. If the reconciliation file for the first application system has not been obtained by the reconciliation deadline, relevant business personnel can be requested to manually process the process to obtain the reconciliation file for the first application system.

[0043] This application embodiment obtains reconciliation files from multiple first application systems, ensuring the validity of each first application system's reconciliation file, which is then used for subsequent summary processing. This ensures the completeness and accuracy of the obtained target reconciliation files and avoids erroneous reversal problems caused by the first application system abnormally sending empty reconciliation files or sending multiple reconciliation files.

[0044] Optionally, after obtaining the reconciliation files of each first application system from the designated server, the following steps may be included: for each first application system, if a valid reconciliation file of the first application system is obtained from the designated server and the file status corresponding to the first application system is in the default state, then the file status is changed to the target state.

[0045] If a valid reconciliation file for the first application system is obtained from the specified server, and the file status corresponding to the first application system is the target status, then this valid reconciliation file replaces the previously obtained valid reconciliation file that is most recent to this acquisition. The file status corresponding to the first application system indicates whether a valid reconciliation file for that first application system has been obtained; the default status indicates that no valid reconciliation file has been obtained, and the target status indicates that a valid reconciliation file has been obtained.

[0046] If, by the reconciliation deadline, the file status corresponding to the first application system is still in the default state, then relevant business personnel should be requested to manually process it to obtain a valid reconciliation file for that first application system.

[0047] Through the embodiments of this application, it is ensured that a valid reconciliation file of each first application system is obtained, and then the obtained valid reconciliation files are summarized and processed to obtain the target reconciliation file, thereby ensuring the integrity and accuracy of the target reconciliation file.

[0048] Optionally, after obtaining the reconciliation files of each first application system from the designated server, the process may further include the following steps: decrypting the obtained reconciliation files and storing them in a designated path; after all the reconciliation files of each first application system have been decrypted, reading the first transaction data from the decrypted reconciliation files in the designated path and writing it into the database table of the transaction processing system to form the target reconciliation file. Specifically, the decryption of the obtained reconciliation files is performed according to an encryption algorithm pre-agreed upon by the first and second business parties. The first application system encrypts the reconciliation files and sends them to the designated server, and the transaction processing system decrypts the obtained reconciliation files according to the decryption algorithm of the first business party. The designated path is a specified path used to store the decrypted reconciliation files.

[0049] The above embodiments are used to ensure the security of the reconciliation file and the first transaction data in the reconciliation file, and to improve transmission efficiency.

[0050] Optionally, before retrieving the reconciliation files of each first application system from the designated server, the following steps may be included: each first application system sends its own reconciliation file to the designated server for storage using a specified method, and after successful transmission, sends a reconciliation notification to the transaction processing system. The reconciliation notification carries the storage path information of the sent reconciliation file on the designated server and the unique identifier information of the sent reconciliation file. After receiving the reconciliation notification, the communication interface of the transaction processing system can retrieve the reconciliation file from the designated server using the specified method based on the storage path information and unique identifier information in the reconciliation notification. The specified method is a file transfer method agreed upon in advance by the first and second business parties, such as File Transfer Protocol (FTP) or SSS File Transfer Protocol (SFTP). This embodiment of the application does not specifically limit this method.

[0051] It should be understood that, in this embodiment of the application, not all first application systems send a reconciliation notification after successfully sending the reconciliation file, but any first application system sends a reconciliation notification after successfully sending the reconciliation file; if the same first application system sends the reconciliation file multiple times, a reconciliation notification will also be sent to the transaction processing system after each successful sending.

[0052] The above embodiments ensure that reconciliation files sent by each first application system can be obtained from the designated server, laying a solid foundation for subsequent data processing.

[0053] S104, based on the second transaction data recorded by each of the multiple second application systems within a specified time period, update the transaction log of the transaction processing system.

[0054] The transaction log includes third transaction data recorded by the transaction processing system between multiple first application systems and multiple second application systems within a specified time period. The third transaction data in the transaction log is updated based on the second transaction data in the multiple second application systems.

[0055] As an optional implementation, step S104 may include the following steps: aggregating the second transaction data recorded by multiple second application systems within a specified time period to obtain a transaction dataset; obtaining the difference information between the transaction dataset and the transaction log; and updating the transaction log based on the difference information.

[0056] The transaction dataset includes second transaction data read from multiple second application systems and recorded by each of these systems within a specified time period. By comparing the second transaction data in the transaction dataset with the third transaction data in the transaction log, discrepancy information between the two can be obtained. This discrepancy information includes at least one first transaction data group and at least one second transaction data group; wherein the first transaction data group includes second and third transaction data belonging to the same transaction but with different transaction states; and the second transaction data group includes second and third transaction data belonging to the same transaction and with the same transaction state.

[0057] It should be understood that the difference information between the transaction dataset and the transaction log in this application embodiment refers to the difference information between the second transaction data in the transaction dataset and the third transaction data in the transaction log; the difference information may be missing transaction data, inconsistent transaction status, inconsistent transaction data, etc.

[0058] Optionally, updating the transaction log based on the discrepancy information may include the following steps: For each first transaction data group, if the transaction status of the second transaction data in the first transaction data group is valid and the transaction status of the third transaction data is invalid, then the second transaction data in the first transaction data group is inserted into the transaction log, and the first reconciliation status of the inserted second transaction data is marked as valid in the transaction log; or,

[0059] For each first transaction data group, if the transaction status of the second transaction data in the first transaction data group is invalid and the transaction status of the third transaction data is valid, then the first reconciliation status of the third transaction data in the first transaction data group is marked as void in the transaction log; or,

[0060] For each second transaction data group, if the transaction status of both the second and third transaction data in the second transaction data group is valid, then the transaction amount of the third transaction data is updated in the transaction log based on the second transaction data, and the first reconciliation status of the third transaction data is marked as effective in the transaction log.

[0061] In this context, transaction data with a valid transaction status corresponds to successful and existing transaction data; transaction data with an invalid transaction status corresponds to failed or non-existent transaction data. Other embodiments of this application will not repeat this content. The first reconciliation status of the third transaction data in the transaction log is based on the second transaction data in multiple second application systems, and is a preliminary determination of the validity of the third transaction data. The first reconciliation status includes at least one of the following: effective, void, etc. In practical applications, to further distinguish between different effective and void statuses, the effective status can be further subdivided into effective and updated transaction amount, effective but no valid transaction found, and the void status can be subdivided into void and no valid transaction found, etc.

[0062] In practical applications, the transaction data in multiple second application systems should be consistent with that in the transaction processing system. However, due to reasons such as system crashes, data loss, accidental deletion, and system errors, the transaction data recorded by the second application systems and the transaction processing system may be inconsistent, which in turn leads to inconsistencies between the second transaction data in the transaction dataset and the third transaction data in the transaction log.

[0063] Based on this, the third transaction data in the transaction log is updated through the embodiments of this application, including at least one of the following update operations: inserting second transaction data into the transaction log, updating the transaction amount of the third transaction data, and retaining a backup of the third transaction data. After any of the above update operations are completed, the first reconciliation status of each third transaction data is marked in the transaction log, and the transaction status is updated. This determines the third transaction data that may be effective and the third transaction data that may be invalid, thereby improving the accuracy of the third transaction data in the transaction processing system. In this way, the accuracy of reconciliation can be further improved in subsequent reconciliation.

[0064] This example illustrates the process of updating transaction logs based on difference information in the transaction data processing method provided in this application, and should not be construed as limiting the method of this application. Example 3: Assume that the second transaction data in the transaction dataset is as shown in Table 1, including: successful second transaction data A, B, and E; failed second transaction data C, D, and F; and non-existent second transaction data G and H; the third transaction data in the transaction log is as shown in Table 2, including: successful third transaction data a, c, and g; failed third transaction data b, d, and h; and non-existent third transaction data e and f; the transaction status of successful and existing transaction data in Table 1 or Table 2 is valid, and the transaction status of failed or non-existent transaction data is invalid.

[0065] It should be understood that transaction data in Table 1 or Table 2 that does not indicate whether the transaction was successful or failed is non-existent. In this example, to more clearly illustrate the update process, non-existent transaction data is also symbolically marked in the tables. For example, the second transaction data G and the second transaction data H do not exist in Table 1, and the third transaction data e and the third transaction data f do not exist in Table 2. In practical applications, these data would not be recorded. This will not be repeated in other embodiments of this application.

[0066] For each transaction data group, if transaction data group (A, a) belongs to the first transaction data group, and the transaction status of the second transaction data A and the third transaction data a is the same and both are valid, then the transaction amount of the third transaction data a is updated based on the second transaction data A, the reconciliation status is marked as effective and the transaction amount is updated.

[0067] Transaction data group (B, b) belongs to the second transaction data group. The transaction states of second transaction data B and third transaction data b are different, with second transaction data B being valid and third transaction data b being invalid. Therefore, second transaction data B is inserted into the transaction log table, and its transaction state is marked as valid, and its reconciliation status is marked as effective and no valid transaction was found. Transaction data group (C, c) belongs to the second transaction data group. The transaction states of second transaction data C and third transaction data c are different, with second transaction data C being invalid and third transaction data c being valid. Therefore, third transaction data c is retained in the transaction log, and its reconciliation status is marked as void and no valid transaction was found. Transaction data group (D, d) belongs to the first transaction data group. The transaction states of second transaction data D and third transaction data d are the same and both are invalid. Therefore, third transaction data d is retained in the transaction log. Transaction data group (E, e) belongs to the second transaction data group. If transaction data group (F, f) belongs to the first transaction data group, and transaction data group (G, g) belongs to the second transaction data group, and transaction data group (G, g) belongs to the second transaction data group, and transaction data group (H, h) belongs to the first transaction data group, and transaction data group (H, h) belongs to the first transaction data group, and transaction data group (H, h) belongs to the first transaction data group, and transaction data group (H, h) belongs to the first transaction data group, and transaction data group (H, f) belongs to the first transaction data group, and transaction data group (F, f) belongs to the first transaction data group, and transaction data group (F, f) belongs to the first transaction data group, and transaction data group (F, f) belongs to the second ...

[0068] It should be understood that this example and the tables involved are for the purpose of more clearly illustrating the process of updating the third transaction data in the transaction log, and should not be construed as a limitation on the method of the embodiments of this application. The following embodiments will not repeat this content.

[0069] Table 1 Transaction Dataset

[0070] Second transaction data Transaction successful / Transaction failed Transaction status A Transaction successful efficient B Transaction successful efficient C Transaction failed invalid D Transaction failed invalid E Transaction successful efficient F Transaction failed invalid G invalid H invalid

[0071] Table 2 Transaction Log

[0072] Third transaction data Transaction successful / Transaction failed Transaction status a Transaction successful efficient b Transaction failed invalid c Transaction successful efficient d Transaction failed invalid e invalid f invalid g Transaction successful efficient h Transaction failed invalid

[0073] Table 3 Updated Transaction Log (1)

[0074] Third transaction data Transaction successful / Transaction failed Transaction status First reconciliation status a success efficient Effective and updated transaction amount b fail invalid B success efficient Effective but no valid transactions found c success efficient Invalid and no valid transaction found d fail invalid e invalid E success efficient Effective but no valid transactions found f invalid g success efficient Invalid and no valid transaction found h fail invalid

[0075] As another embodiment of this application, after updating the transaction log based on the difference information, the transaction data processing method provided in this application embodiment may further include the following steps: querying the third transaction data of failed transactions in the updated transaction log and the second transaction data of failed transactions in the transaction dataset, deleting the third transaction data record of failed transactions from the transaction log, and deleting the second transaction data of failed transactions from the transaction dataset.

[0076] Combining the transaction dataset shown in Table 1 of Example 3 above and the updated transaction log (1) shown in Table 3, after the method steps of this application embodiment, the second transaction data in the updated transaction dataset shown in Table 4 and the updated transaction log (2) shown in Table 5 are obtained.

[0077] Through the embodiments of this application, after the reconciliation is completed, the second transaction data in multiple second application systems can be reversed according to the updated log table to ensure the consistency of transaction data in multiple first application systems of the first business party and multiple second application systems of the second business party.

[0078] Table 4 Updated Transaction Dataset

[0079] Second transaction data Transaction successful / Transaction failed Transaction status A Transaction successful efficient B Transaction successful efficient E Transaction successful efficient

[0080] Table 5 Updated Transaction Log (2)

[0081] Third transaction data Transaction successful / Transaction failed Transaction status First reconciliation status a success efficient Effective and updated transaction amount B success efficient Effective but no valid transactions found c success efficient Invalid and no valid transaction found E success efficient Effective but no valid transactions found g success efficient Invalid and no valid transaction found

[0082] S106, Based on the target reconciliation file, perform reconciliation processing on the third transaction data in the updated transaction log to obtain the reconciliation result.

[0083] As can be seen from the above embodiments, the target reconciliation file includes first transaction data between multiple first application systems and their corresponding second application systems within a specified time period. Based on the first transaction data in the target reconciliation file, reconciliation processing is performed on the third transaction data in the updated transaction log. The second transaction status of the third transaction data is marked in the updated transaction log, and this second transaction status record is the reconciliation result. Specifically, the second reconciliation status of the third transaction data in the transaction log is based on the first transaction data in the target reconciliation file. The validity of the third transaction data in the updated transaction log is determined by comparing the first transaction data in the target reconciliation file with the third transaction data. The second reconciliation status record includes at least one of the following: reconciliation successful, transaction amount inconsistent, transaction parties not corresponding, transaction amount inconsistent and transaction parties not corresponding, no valid transaction data found, pending reversal, etc.

[0084] In this embodiment, based on second transaction data from multiple second application systems, the transaction log of the transaction processing system is updated to obtain an updated transaction log. Specifically, the second business party first unifies its internal transaction data to preliminarily determine the validity of the third transaction data in the transaction log. Based on this, the updated transaction log is then reconciled according to the target reconciliation file to obtain the reconciliation result. The target reconciliation file is obtained by aggregating the reconciliation files from multiple first application systems. Therefore, in the original separate reconciliation process, transaction data where the user's origin and the transaction processing location are inconsistent will not be incorrectly reversed. Furthermore, if a first application system sends multiple reconciliation files, multiple reconciliations will not be performed based on those files, preventing incorrect reconciliation of some transaction data. Thus, the method employed in this embodiment can reduce the number of incorrectly reversed transaction data, thereby reducing the number of manual interventions, improving the accuracy and efficiency of reconciliation, and avoiding waste of human resources.

[0085] As an optional implementation, step S106 above may include the following steps:

[0086] S161, based on the target reconciliation file and the updated transaction log, obtain at least one third transaction data group and at least one fourth transaction data group; wherein, the third transaction data group includes first transaction data and third transaction data belonging to the same transaction and having the same transaction status, and the fourth transaction data group includes first transaction data and third transaction data belonging to the same transaction but having different transaction statuses.

[0087] S162, for each third transaction data group, if the transaction status of the first transaction data and the third transaction data in the third transaction data group is the same and both are valid, then compare the transaction amount and application system information of the first transaction data and the third transaction data, and record the second reconciliation status of the third transaction data in the transaction log.

[0088] S163, for each fourth transaction data group, based on the respective transaction status of the first and third transaction data in the fourth transaction data group, record the second reconciliation status of the third transaction data in the transaction log.

[0089] S164, based on the second reconciliation status of each third transaction data in the transaction log, generate the reconciliation result.

[0090] The application system information includes information about the first application system to which the first transaction data belongs and information about the second application system to which the third transaction data belongs.

[0091] Based on the target reconciliation file and the updated transaction log, this application embodiment obtains at least one third transaction data group and at least one fourth transaction data group. The method of this application embodiment is used to update each third transaction data in the updated transaction log to obtain and record the second reconciliation status of each third transaction data, thereby obtaining the reconciliation result.

[0092] Optionally, S162 may include the following steps: if the transaction amounts of the first transaction data and the third transaction data in the third transaction data group are consistent, and the first application system to which the first transaction data belongs corresponds to the second application system to which the third transaction data belongs, then the second reconciliation status of the third transaction data is marked as reconciliation successful in the transaction log; or, if the transaction amounts of the first transaction data and the third transaction data in the third transaction data group are inconsistent, then the second reconciliation status of the third transaction data is marked as transaction amount inconsistency in the transaction log; or, if the first application system to which the first transaction data belongs in the third transaction data group does not correspond to the second application system to which the third transaction data belongs, then the second reconciliation status of the third transaction data is marked as transaction parties not corresponding in the transaction log.

[0093] In this embodiment, when the transaction statuses of the first and third transaction data in the third transaction data group are the same and valid, the first and third transaction data are compared, and a second reconciliation status for the third transaction data is marked in the transaction log based on the comparison result. Here, the comparison of the first and third transaction data can include comparing transaction amounts and application system information, or other information such as the transaction times of the first and third transaction data. In this embodiment, relevant information can be compared according to the needs of the first and second business parties. After comparing each piece of information, the corresponding information is inserted at the second reconciliation status to facilitate subsequent processing of transaction data in multiple first or second application systems based on the reconciliation statuses of the third transaction data in the transaction log, ensuring consistency of transaction data in both application systems. If the transaction amounts are different, further verification by both business parties is required; if the transactions do not correspond, both business parties need to negotiate an adjustment to determine the performance attribution of the transaction, and so on.

[0094] By summarizing the reconciliation files of each first-use system to obtain the target reconciliation file, and then combining it with the method of the embodiments of this application, the number of times transaction data is incorrectly reversed due to the inconsistency between the user's place of origin and the transaction processing location during separate reconciliation can be reduced, thereby improving the accuracy and efficiency of reconciliation.

[0095] Optionally, S163 may include the following steps: if the transaction status of the first transaction data in the fourth transaction data group is valid and the transaction status of the third transaction data is invalid, then insert the first transaction data into the transaction log and mark the second reconciliation status of the inserted first transaction data in the transaction log as "no valid transaction data found"; or, if the transaction status of the first transaction data in the fourth transaction data group is invalid and the transaction status of the third transaction data is valid, then mark the second reconciliation status of the third transaction data in the transaction log as "to be reversed", and call the reconciliation interface to send a reconciliation request to the second application system to which the third transaction data belongs, the reconciliation request being used to request the reconciliation of the third transaction data.

[0096] Specifically, the "reversal" mechanism is a remedial measure taken when a user terminal in the second application system set up by the second business party believes that a transaction may have failed. This means that a transaction has been marked as successful in the second application system and on the client terminal, but the corresponding first application system set up by the second business party has not responded, and there is no record of the transaction in the first application system (i.e., a timeout occurred in the first application system). Therefore, it is uncertain whether the transaction was successfully completed in the corresponding first application system. To ensure the user's interests, a request is resent to the corresponding first application system to cancel the transaction record. If the transaction was successfully completed in the first application system, the first application system rolls back the transaction and re-enters the transaction data. Otherwise, the first application system will not record the transaction data. Then, the second application system will process the second transaction data in each second application system according to the reversal processing result returned by the first application system. If the reversal processing result is a transaction failure, the transaction will be removed from the second application system, identified as a failed transaction, and a new record will be inserted into the transaction log as: "Transaction failed in the first application system". If the reversal processing result is a successful transaction, a new record will be inserted into the transaction log as: "Transaction successful in the first application system". If the first reversal status of the transaction is void, it needs to be recorded in the second application system. The above content is for better understanding of the meaning of reversal and the series of operations that may occur after reversal, and should not be construed as limiting the method of the embodiments of this application.

[0097] Through the embodiments of this application, the validity of each third transaction data in the updated transaction log is further confirmed. Subsequently, each second application system performs relevant processing based on the updated transaction log to ensure the consistency of transaction data between the two business parties. Assuming that first transaction data is inserted into the transaction log, the second application system needs to supplement the first transaction data according to the updated transaction log to ensure the consistency of transaction data between the two business parties.

[0098] Here, combining Example 3 above and the updated transaction log (2) shown in Table 5, we take an example to illustrate the process in Embodiments 6, 7, and 8 above, which involves obtaining at least one third transaction data group and at least one fourth transaction data group based on the target reconciliation file and the updated transaction log, and determining the second reconciliation status of the third transaction data in the updated transaction log for the first and third transaction data in each third or fourth transaction data group. Example 4:

[0099] Assume that the first transaction data in the target reconciliation file obtained by summarizing is as shown in Table 6, including successful second transaction data I, second transaction data III, second transaction data IV, second transaction data V and second transaction data VIII; as well as failed first transaction data II and first transaction data VII, and non-existent first transaction data VI; in Table 6, the transaction status of successful and existing first transaction data is valid, and the transaction status of failed or non-existent first transaction data is invalid.

[0100] It should be understood that in practical applications, the target reconciliation file obtained in this application embodiment does not contain records of failed transactions or records of non-existent transactions. Before reversing, the first application system will not record any transaction records of failed transactions within a specified period. In this example, this part of the first transaction data is displayed in order to facilitate the explanation of the process of obtaining the reconciliation results. At the same time, in order to further clarify the process of obtaining the reconciliation results, the non-existent transaction data in the updated transaction log (2) shown in Table 5 is also symbolically displayed in this example, as shown in the updated transaction log (3) in Table 7.

[0101] For each transaction data group, transaction data group (I, a) belongs to the third transaction data group. The transaction statuses of first transaction data I and third transaction data a are the same and both are valid. It is necessary to compare the transaction amounts and application system information of first transaction data I and third transaction data a. Assuming the transaction amounts are the same and the first application system to which first transaction data I belongs corresponds to the second application system to which third transaction data a belongs, then the second reconciliation status of third transaction data a is marked as reconciliation successful in the transaction log. Transaction data group (II, B) also belongs to the third transaction data group. The transaction statuses of first transaction data II and third transaction data B are... If both transaction data sets are in the same and valid state, it is necessary to compare the transaction amounts and application system information of the first transaction data II and the third transaction data B. Assuming the transaction amounts are different, and the first application system to which the first transaction data II belongs corresponds to the second application system to which the third transaction data B belongs, then the second reconciliation status of the third transaction data B will be marked as having different transaction amounts in the transaction log. Transaction data group (III, c) belongs to the third transaction data group. The transaction states of the first transaction data III and the third transaction data c are the same and both valid. It is necessary to compare the transaction amounts and application system information of the first transaction data III and the third transaction data c. Assuming the transaction amounts are the same, and the first application system to which the first transaction data III belongs does not correspond to the second application system to which the third transaction data c belongs, then in the transaction log, the second reconciliation status of the third transaction data c is marked as "the transactions of both parties do not correspond"; if transaction data group (IV, d) belongs to the fourth transaction data group, the transaction status of the first transaction data IV is valid, and the transaction status of the third transaction data d is invalid, then the first transaction data IV is inserted into the transaction log, the second reconciliation status is marked as "no valid transaction found", and the transaction status is marked as valid; if transaction data group (V, E) belongs to the third transaction data group, and the first transaction data V and the third transaction data d... The three transaction data E have the same transaction status and are all valid. It is necessary to compare the transaction amount and application system information of the first transaction data V and the third transaction data E. Assuming that the transaction amounts are different and the first application system to which the first transaction data V belongs does not correspond to the second application system to which the third transaction data E belongs, the second reconciliation status of the third transaction data c will be marked in the transaction log as inconsistent transaction amounts and the transactions of the two parties do not correspond. Transaction data group (VI, f) belongs to the third transaction data group. The transaction status of the first transaction data V and the third transaction data E are the same and are both invalid. Therefore, the third transaction data f will be temporarily retained in the transaction log.Transaction data group (VII, g) belongs to the fourth transaction data group. The transaction status of the first transaction data VII is invalid, and the transaction status of the third transaction data g is valid. Therefore, the second reconciliation status of the third transaction data g is marked as pending reversal in the transaction log, and the reversal interface is called to send a reversal request to the second application system to which the third transaction data g belongs. The reversal request is used to request the reversal of the third transaction data g. Transaction data group (VIII, h) belongs to the fourth transaction data group. The transaction status of the first transaction data VIII is valid, and the transaction status of the third transaction data h is invalid. Therefore, the first transaction data VIII is inserted into the transaction log, the second reconciliation status is marked as no valid transaction found, and the transaction status is marked as valid. After the above steps, the updated transaction log (4) is obtained, as shown in Table 8. Further, the third transaction data that indicates non-existence is removed from the table, as shown in Table 9, the updated transaction log (5).

[0102] Table 6 Target Reconciliation Documents

[0103] First Transaction Data Transaction successful / Transaction failed Transaction status I Transaction successful efficient II Transaction successful efficient III Transaction successful efficient IV Transaction successful efficient V Transaction successful efficient VI invalid VII Transaction failed invalid VIII Transaction successful efficient

[0104] Table 7 Updated Transaction Log (3)

[0105] Third transaction data Transaction successful / Transaction failed Transaction status First reconciliation status a success efficient Effective and updated transaction amount B success efficient Effective but no valid transactions found c success efficient Invalid and no valid transaction found d invalid E success efficient Effective but no valid transactions found f invalid g success efficient Invalid and no valid transaction found h invalid

[0106] Table 8 Updated Transaction Log (4)

[0107]

[0108] Table 9 Updated Transaction Log (5)

[0109] Optionally, after the above-mentioned reconciliation processing of the third transaction data in the updated transaction log based on the target reconciliation file and obtaining the reconciliation result, the following steps are also included: exporting the second reconciliation status of the third transaction data in the updated transaction log to obtain a reconciliation result report.

[0110] The reconciliation result report includes a record of the second reconciliation status of the third transaction data in the updated transaction log. This reconciliation result report is sent to each of the first application systems of the first business party. Each first application system processes the received reconciliation result report accordingly and returns the processing result to the transaction processing system. Based on the returned processing result, the transaction processing system ultimately determines the reconciliation status of the third transaction data in the transaction log and processes the transaction data in the second application system accordingly to ensure the consistency of transaction data between the first and second business parties.

[0111] Here, combining Examples 3 and 4 above, we will use an example to illustrate how to export the second reconciliation status of each third transaction data in the updated transaction log shown in Table 9 to obtain a reconciliation result report. Example 5: Assume that the first transaction data in the first application system ① is I, the first transaction data in the first application system ② is II, the first transaction data in the first application system ③ is III, the first transaction data in the first application system ④ is IV and VIII, the first transaction data in the first application system ⑤ is V, and the first transaction data in the first application system ⑥ is VII. After the second business party exports the second status of each third transaction data in the updated log, it obtains a reconciliation result report, as shown in the reconciliation result report (1) in Table 10, or...

[0112] Assume that the first transaction data in the first application system ① are I and II, the first transaction data in the first application system ② are III and IV, the first transaction data in the first application system ③ are VII and VIII, and the first transaction data in the first application system ④ is V. After the second business party exports the second status of each third transaction data in the updated log, it obtains the reconciliation result report, as shown in Table 11 (2).

[0113] It should be understood that the first transaction data VI is transaction data that does not exist in the first application system. At the same time, there is no corresponding data in the second application system and the transaction application system. Therefore, there is no record in the final result report. As for the first transaction data VII, as explained above, it is transaction data of failed transactions in the first application system. There will be no corresponding data record before the reversal. It is only symbolically displayed to illustrate the process of data processing in the transaction processing system by the method provided in this application embodiment. After the reversal process, the data record of this part will be improved according to the specific situation to ensure the consistency of transaction data in the first application system and the second application system.

[0114] It should be understood that the reconciliation result report shown in Example 5 is only intended to illustrate the more important information in the reconciliation result report. As for other information and report formats, they can be set according to actual needs, and this application does not impose specific limitations on them. For example, if the reconciliation result of the first transaction data in the first application system ④ in Table 10 is "no valid transaction found", then in actual application, it is not necessary to display the first transaction data IV and VIII one by one in the reconciliation result report. It is sufficient to directly display that the reconciliation result is "no valid transaction found".

[0115] It should be understood that after the second business party generates the reconciliation result report, it can send the report as shown in Table 10 or Table 11 to each first application system, or send the corresponding reconciliation result report on a per-first-application-system basis, that is, split Table 10 or Table 11 into several tables and send them to the corresponding first application system on a per-first-application-system basis.

[0116] Table 10 Reconciliation Results Report (1)

[0117]

[0118] Table 11 Reconciliation Results Report (2)

[0119]

[0120]

[0121] The following describes the transaction data processing method provided in this application embodiment using a practical application scenario. This scenario involves end-of-day reconciliation between a bank and an insurance company. In this scenario, the bank is the first business party, the insurance company is the second business party, and the bank-insurance interconnection system is the transaction processing system.

[0122] Among them, the Bank-Insurance Link System is an intermediary platform for insurance companies and banks to connect their application systems via dedicated lines and transmit data in real time. It provides bank customers with a business system for handling transactions such as policy underwriting and policy maintenance. The Bank-Insurance Link System includes insurance application, policy cancellation, inquiry, and partial policy maintenance services. By leveraging the extensive and stable personal customer resources of banks through their vast branch networks, it is one of the important business channels for insurance companies.

[0123] A bank has multiple branches, and each branch's application system constitutes a primary application system. Similarly, an insurance company has multiple branches, and each branch's application system constitutes a secondary application system. Primary and secondary application systems located in the same area conduct insurance transactions through the bank-insurance linkage system. For example, when the bank-insurance linkage system responds to an insurance application request from a salesperson for a customer in a specific location, the customer fills out the application information in the primary application system and submits it to the branch's secondary application system via the bank-insurance linkage system. The secondary application system then sends the corresponding underwriting results and payment information to the branch's primary application system, which in turn notifies the customer of the actual premium amount. After payment, the primary application system sends payment success data to the bank-insurance linkage system, which then calls the secondary application system to issue the policy and sends the electronic policy to the customer's email address. At the end of the day, after reconciliation, the bank transfers the day's premium to the insurance company's collection account opened at the corresponding branch, thus completing one insurance application transaction. During the transaction, the first application system, the bank-insurance system, and the second application system involved in the transaction will all record the transaction data, such as the policy number, policy information, policy amount, and transaction status.

[0124] Because discrepancies may arise between insurance companies and banks in daily transactions due to network or system issues, banks are required to initiate end-of-day reconciliation transactions after each transaction is completed through the Bank-Insurance Link system. This reconciliation process involves the Bank-Insurance Link system using the daily reconciliation file provided by the bank to reconcile the transaction data recorded in the system with its own records, automatically correcting any discrepancies. If the discrepancies cannot be automatically corrected, the Bank-Insurance Link system records a reconciliation failure and requests manual processing from relevant personnel.

[0125] In the traditional split-reconciliation model, each time the bank-insurance system receives a reconciliation file from a first application system, it immediately reads the transaction data between the first application system and the corresponding second application system within the same day from the transaction log, and reconciles the read transaction data according to the reconciliation file.

[0126] However, when using a point-to-point reconciliation method, if the user's bank card issuance location differs from the insurance policy's location—for example, the bank acts as the settlement party and the insurance company as the receiving party—and a user who opened a bank account at a Beijing branch but purchased insurance at an insurance branch in Shanghai, the bank-insurance system will request the Shanghai insurance branch's second application system to process the policy and return the processing result to the Beijing bank branch's first application system for settlement. Consequently, the reconciliation file sent by the Shanghai bank branch's first application system will lack the relevant information and records for that policy, leading to an incorrect reversal of the policy data recorded in the transaction log. Furthermore, if the bank's first application system sends multiple reconciliation files—for example, sending a normal file the first time followed by an abnormal file, or vice versa—some transaction data may also be incorrectly reversed, requiring subsequent manual processing by relevant personnel. As business volume increases, the number of incorrectly reversed transactions also increases, leading to more frequent manual interventions, resulting in decreased reconciliation accuracy and efficiency, and wasted human resources.

[0127] To address the aforementioned issues and for the specific application scenarios described above, such as... Figure 3 As shown, the transaction data processing system provided in this application embodiment includes the following steps:

[0128] First, a provincial banking institution generates its daily reconciliation file and sends it to a designated server for storage. The file includes the first transaction data recorded by the institution's first application system and the second application system of the provincial insurance branch for that day. Then, a reconciliation notification is sent to the Yinbaotong system. Upon receiving the notification, the Yinbaotong system retrieves and decrypts the reconciliation file, storing it in a designated path. Next, it checks whether all provincial banking institutions' reconciliation files have been obtained. If not, it sends a request to the first application system of the provincial banking institution that did not receive the file, requesting that system send the file. Once the reconciliation notification is received, the system retrieves the file from that provincial banking institution. If all reconciliation files have been received, the system reads them from the designated path and writes them to the Yinbaotong database table, obtaining the target reconciliation file. Simultaneously, the system reads the second transaction data recorded by each provincial insurance branch's second application system database for the day. Based on this second transaction data, it updates the transaction log of the bank-insurance linkage system. The transaction log includes the third transaction data recorded by the bank-insurance linkage system for the day between the first application system of each provincial banking institution and the second application system of each provincial insurance branch. Then, it reads the target reconciliation file and the updated transaction log from the bank-insurance linkage system database. Based on the target reconciliation file and the updated transaction log, it performs reconciliation processing to obtain the reconciliation results.

[0129] Specifically, such as Figure 4 As shown, the transaction data processing system provided in this application updates the transaction log based on the second transaction data, including:

[0130] First, the third and second transaction data are retrieved from the transaction logs of the Bank-Insurance Link system database and the second application system databases of the insurance branches in each province. The second and third transaction data are compared. If both the second and third transaction data belong to the same transaction and their respective transaction statuses are valid, the second transaction data is used, and the transaction amount of the third transaction data in the transaction log is updated. The first reconciliation status is marked as effective, and the transaction amount is updated. Alternatively, if the second transaction data belongs to the same transaction and its transaction status is valid, but the third transaction data is invalid, the second transaction data is inserted into the transaction log, and the transaction log is updated accordingly. The transaction status of the second transaction data is marked as valid, and the first reconciliation status is marked as effective and no valid transaction is found. Alternatively, if the transaction data of the second transaction data belonging to the same transaction is invalid, and the third transaction data is valid, then the third transaction data is retained in the transaction log, and the first reconciliation status of the third transaction data is marked as invalid and no valid transaction is found. At the same time, the failed third transaction data in the transaction log and the failed second transaction data in the second application system database of each provincial insurance branch are queried and deleted from the transaction log and each second application system. Based on the above steps, the updated transaction log table is obtained.

[0131] like Figure 5 As shown, the transaction data processing system provided in this application performs reconciliation processing based on the target reconciliation file and the updated transaction log, including:

[0132] First, the third transaction data and the first transaction data are read from the updated transaction logs and target reconciliation file in the Yinbaotong system database, respectively. The transaction status of the first and second transaction data is compared. If the transaction status of the first and third transaction data belonging to the same transaction is valid, the transaction amount and application system information are further compared. If the transaction amounts are consistent and the application systems correspond, the second reconciliation status of the third transaction data is marked as reconciliation successful. If the transaction amounts are inconsistent but the application systems correspond, the second reconciliation status of the third transaction data is marked as transaction amount inconsistency. If the transaction amounts are consistent but the application systems do not correspond, the second reconciliation status of the third transaction data is marked as transaction amount inconsistency. Correspondingly, the second reconciliation status of the third transaction data is marked as "the two parties do not correspond." If the transaction amounts are inconsistent and the application systems do not correspond, the second reconciliation status of the third transaction data is marked as "the transaction amounts are inconsistent and the two parties do not correspond." Alternatively, if the transaction status of the first transaction data belonging to the same transaction is valid and the third transaction data is invalid, the first transaction data is inserted into the transaction log, and the second reconciliation status is marked as "no valid transaction found." Alternatively, if the transaction status of the first transaction data belonging to the same transaction is invalid and the third transaction data is valid, the reversal interface is called to mark the second reconciliation status of the third transaction data as "pending reversal." Based on the above steps, the reconciliation result is obtained according to the second reconciliation status of the third transaction data in the updated transaction log.

[0133] Understandably, after daily reconciliation, banks transfer the day's premiums to the insurance company's branch office's collection account at the corresponding branch. The primary application systems of various banking institutions may encounter the following situation: a policy purchased at a branch in region A may appear in the reconciliation file for region B. This could be because the customer's bank card was opened in region B, and therefore the actual premium was transferred to the bank's collection account in region B. Consequently, the reconciliation file for the branch in region A will lack the policy. Furthermore, the existing segmented reconciliation method can lead to region A mistakenly deeming the policy invalid and incorrectly reversing it, resulting in region B having an extra premium in its account even though the policy did not exist.

[0134] However, when using the reconciliation processing method described in this application, because the policy was found in the reconciliation file of the branch in region B, the second reconciliation status of the policy will be marked as a mismatch between the two parties. Subsequently, it is necessary to adjust the excess premium in the account of the branch in region B to ensure that the transaction data of the insurance company and the bank are consistent.

[0135] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0136] This application also provides a transaction data processing apparatus. Please refer to [link to relevant documentation]. Figure 6 The diagram below illustrates the structure of a transaction data processing apparatus 600 according to an embodiment of this application. The apparatus 600 may include:

[0137] The acquisition unit 610 is used to acquire the reconciliation files of the multiple first application systems and perform summary processing to obtain the target reconciliation file. Each first application system has a corresponding second application system. The reconciliation file includes the first transaction data between the first application system and the corresponding second application system recorded within a specified time period.

[0138] The update unit 620 is used to update the transaction log of the transaction processing system based on the second transaction data recorded by each of the plurality of second application systems within the specified time period. The transaction log includes the third transaction data recorded by the transaction processing system between the plurality of first application systems and the plurality of second application systems within the specified time period.

[0139] The reconciliation unit 630 is used to perform reconciliation processing on the third transaction data in the updated transaction log based on the target reconciliation file, and obtain the reconciliation result.

[0140] Optionally, when the acquisition unit 610 acquires and summarizes the reconciliation files of the plurality of first application systems to obtain the target reconciliation file, it may perform the following steps: acquire the reconciliation files of each first application system from a designated server; for each first application system, if multiple reconciliation files of the first application system are acquired from the designated server, the non-empty reconciliation file closest to the reconciliation deadline is taken as the valid reconciliation file of the first application system; or, if the reconciliation file of the first application system is not acquired from the designated server, an acquisition request is sent to the first application system, the acquisition request being used to request the first application system to send its own reconciliation file to the designated server.

[0141] Optionally, when updating the transaction log of the transaction processing system based on the second transaction data recorded by each of the plurality of second application systems within the specified time period, the updating unit 620 may perform the following steps: summarizing the second transaction data recorded by each of the plurality of second application systems within the specified time period to obtain a transaction dataset; obtaining the difference information between the transaction dataset and the transaction log; updating the transaction log based on the difference information; wherein the difference information includes: at least one first transaction data group and at least one second transaction data group, wherein the first transaction data group includes second transaction data and third transaction data belonging to the same transaction but with different transaction states, and the second transaction data group includes second transaction data and third transaction data belonging to the same transaction and with the same transaction state.

[0142] Optionally, when updating the transaction log based on the difference information, the updating unit 620 may perform the following steps: For each first transaction data group, if the transaction status of the second transaction data in the first transaction data group is valid and the transaction status of the third transaction data is invalid, then the second transaction data in the first transaction data group is inserted into the transaction log, and the first reconciliation status of the inserted second transaction data is marked as effective in the transaction log; or, for each first transaction data group, if the transaction status of the second transaction data in the first transaction data group is invalid and the transaction status of the third transaction data is valid, then the first reconciliation status of the third transaction data in the first transaction data group is marked as invalid in the transaction log; or, for each second transaction data group, if the transaction status of both the second and third transaction data in the second transaction data group is valid, then the transaction amount of the third transaction data is updated in the transaction log based on the second transaction data, and the first reconciliation status of the third transaction data is marked as effective in the transaction log.

[0143] The device 600 further includes:

[0144] The query unit is used by the update unit 620 to perform the following steps after updating the transaction log based on the difference information: querying the third transaction data of failed transactions in the updated transaction log and the second transaction data of failed transactions in the transaction dataset, deleting the third transaction data record of failed transactions from the transaction log, and deleting the second transaction data of failed transactions from the transaction dataset.

[0145] Optionally, when the reconciliation unit 630 performs reconciliation processing on the third transaction data in the updated transaction log based on the target reconciliation file to obtain a reconciliation result, it may perform the following steps: Based on the target reconciliation file and the updated transaction log, obtain at least one third transaction data group and at least one fourth transaction data group. The third transaction data group includes first transaction data and third transaction data belonging to the same transaction and having the same transaction status. The fourth transaction data group includes first transaction data and third transaction data belonging to the same transaction but having different transaction statuses. For each third transaction data group, if the transaction status of the first transaction data and the third transaction data in the third transaction data group are both valid, compare the transaction amount and application system information of the first transaction data and the third transaction data, and record the second reconciliation status of the third transaction data in the transaction log. For each fourth transaction data group, based on the transaction status of the first transaction data and the third transaction data in the fourth transaction data group, record the second reconciliation status of the third transaction data in the transaction log. Based on the second reconciliation status of each third transaction data in the transaction log, generate a reconciliation result.

[0146] Optionally, when the reconciliation unit 630 compares the transaction amounts and application system information of the first and third transaction data in the third transaction data group and records the second reconciliation status of the third transaction data in the transaction log if both the transaction statuses of the first and third transaction data in the third transaction data group are valid, the following steps may be performed: If the transaction amounts of the first and third transaction data in the third transaction data group are consistent, and the first application system to which the first transaction data belongs corresponds to the second application system to which the third transaction data belongs, then the second reconciliation status of the third transaction data is marked as reconciliation successful in the transaction log; or, if the transaction amounts of the first and third transaction data in the third transaction data group are inconsistent, then the second reconciliation status of the third transaction data is marked as inconsistent transaction amounts in the transaction log; or, if the first application system to which the first transaction data belongs in the third transaction data group does not correspond to the second application system to which the third transaction data belongs, then the second reconciliation status of the third transaction data is marked as the two parties do not correspond in the transaction log.

[0147] Optionally, when the reconciliation unit 630 records the second reconciliation status of the third transaction data in the transaction log based on the respective transaction statuses of the first and third transaction data in the fourth transaction data group, it may perform the following steps: if the transaction status of the first transaction data in the fourth transaction data group is valid and the transaction status of the third transaction data is invalid, then the first transaction data is inserted into the transaction log, and the second reconciliation status of the inserted first transaction data is marked as "no valid transaction data found" in the transaction log; or, if the transaction status of the first transaction data in the fourth transaction data group is invalid and the transaction status of the third transaction data is valid, then the second reconciliation status of the third transaction data is marked as "pending reversal" in the transaction log, and the reversal interface is called to send a reversal request to the second application system to which the third transaction data belongs, the reversal request being used to request the reversal of the third transaction data.

[0148] Obviously, the transaction data processing apparatus provided in this application embodiment can serve as... Figure 1 The entity executing the transaction data processing method shown, for example Figure 1 In the transaction data processing method shown, step S102 can be performed by... Figure 6 The acquisition unit 610 in the transaction data processing device shown executes step S104, which can be performed by... Figure 6 The update unit 620 in the transaction data processing device shown executes step S106, which can be performed by... Figure 6 The reconciliation unit 630 in the transaction data processing device shown is executed.

[0149] According to another embodiment of this application, a general-purpose computing device, such as a computer, including processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), can run an application capable of performing tasks such as... Figure 1 The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 6 The transaction data processing apparatus shown herein, and the transaction data processing method for implementing the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, and may be transferred to and run in an electronic device via such a medium.

[0150] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Please refer to it. Figure 7At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0151] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0152] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0153] The processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming a transaction data processing device at the logical level. The processor executes the program stored in memory and specifically performs the following operations: It acquires and summarizes the reconciliation files of each of the plurality of first application systems to obtain a target reconciliation file. Each first application system has a corresponding second application system. The reconciliation file includes first transaction data recorded by the first application system within a specified time period between itself and its corresponding second application system. Based on the second transaction data recorded by each of the plurality of second application systems within the specified time period, it updates the transaction log of the transaction processing system. The transaction log includes third transaction data recorded by the transaction processing system between the plurality of first application systems and the plurality of second application systems within the specified time period. Based on the target reconciliation file, it performs reconciliation processing on the third transaction data in the updated transaction log to obtain a reconciliation result.

[0154] The above is as stated in this application. Figure 6The method executed by the transaction data processing apparatus disclosed in the illustrated embodiments can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0155] The electronic device can also perform Figure 1 The method, and implement the transaction data processing device in Figure 6 The functions of the embodiments shown will not be repeated here. Of course, in addition to software implementation, the electronic device of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0156] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform... Figure 1The method of the illustrated embodiment is specifically used to perform the following operations: obtaining reconciliation files of each of the plurality of first application systems and performing summary processing to obtain a target reconciliation file, each first application system having a corresponding second application system, the reconciliation file including first transaction data recorded by the first application system within a specified time period between the first application system and the corresponding second application system; updating the transaction log of the transaction processing system based on the second transaction data recorded by each of the plurality of second application systems within the specified time period, the transaction log including third transaction data recorded by the transaction processing system between the plurality of first application systems and the plurality of second application systems within the specified time period; and performing reconciliation processing on the third transaction data in the updated transaction log based on the target reconciliation file to obtain a reconciliation result.

[0157] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0158] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

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

[0160] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0161] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A method for processing transaction data, characterized in that, The method, applied to a transaction processing system for facilitating transactions between multiple first application systems of a first business party and multiple second application systems of a second business party, includes: The reconciliation files of the multiple first application systems are obtained and aggregated to obtain the target reconciliation file. Each first application system has a corresponding second application system. The reconciliation file includes the first transaction data between the first application system and the corresponding second application system within a specified time period, as recorded by the first application system. Based on the second transaction data recorded by each of the plurality of second application systems within the specified time period, the transaction log of the transaction processing system is updated. The transaction log includes the third transaction data recorded by the transaction processing system between the plurality of first application systems and the plurality of second application systems within the specified time period. Based on the target reconciliation file, the third transaction data in the updated transaction log is reconciled to obtain the reconciliation result.

2. The method according to claim 1, characterized in that, The step of obtaining and summarizing the reconciliation files of the multiple first application systems to obtain the target reconciliation file includes: Retrieve reconciliation files from the designated server for each primary application system; For each first application system, if multiple reconciliation files for the first application system are obtained from the designated server, then the non-empty reconciliation file closest to the reconciliation deadline is taken as the valid reconciliation file for the first application system; or, If the reconciliation file of the first application system is not obtained from the designated server, a retrieval request is sent to the first application system, which requests the first application system to send its reconciliation file to the designated server.

3. The method according to claim 1, characterized in that, The step of updating the transaction log of the transaction processing system based on the second transaction data recorded by each of the multiple second application systems within the specified time period includes: The transaction dataset is obtained by aggregating the second transaction data recorded by each of the multiple second application systems within the specified time period; Obtain the difference information between the transaction dataset and the transaction log; The transaction log is updated based on the discrepancy information.

4. The method according to claim 3, characterized in that, The difference information includes: at least one first transaction data group and at least one second transaction data group, wherein the first transaction data group includes second transaction data and third transaction data belonging to the same transaction but with different transaction states, and the second transaction data group includes second transaction data and third transaction data belonging to the same transaction but with the same transaction state; The step of updating the transaction log based on the difference information includes: For each first transaction data group, if the transaction status of the second transaction data in the first transaction data group is valid and the transaction status of the third transaction data is invalid, then the second transaction data in the first transaction data group is inserted into the transaction log, and the first reconciliation status of the inserted second transaction data is marked as valid in the transaction log; or, For each first transaction data group, if the transaction status of the second transaction data in the first transaction data group is invalid and the transaction status of the third transaction data is valid, then the first reconciliation status of the third transaction data in the first transaction data group is marked as void in the transaction log; or, For each second transaction data group, if the transaction status of both the second transaction data and the third transaction data in the second transaction data group is valid, then the transaction amount of the third transaction data is updated in the transaction log based on the second transaction data, and the first reconciliation status of the third transaction data is marked as effective in the transaction log.

5. The method according to claim 3, characterized in that, After updating the transaction log based on the difference information, the method further includes: Query the updated transaction log for the third failed transaction data and the transaction dataset for the second failed transaction data, delete the third failed transaction data record from the transaction log, and delete the second failed transaction data record from the transaction dataset.

6. The method according to claim 1, characterized in that, The reconciliation process, based on the target reconciliation file, involves reconciling the third transaction data in the updated transaction log to obtain the reconciliation result, including: Based on the target reconciliation file and the updated transaction log, at least one third transaction data group and at least one fourth transaction data group are obtained. The third transaction data group includes first transaction data and third transaction data belonging to the same transaction and having the same transaction status. The fourth transaction data group includes first transaction data and third transaction data belonging to the same transaction but having different transaction statuses. For each third transaction data group, if the transaction status of both the first transaction data and the third transaction data in the third transaction data group is valid, then the transaction amount and application system information of the first transaction data and the third transaction data are compared, and the second reconciliation status of the third transaction data is recorded in the transaction log. For each fourth transaction data group, based on the respective transaction status of the first and third transaction data in the fourth transaction data group, the second reconciliation status of the third transaction data is recorded in the transaction log; Based on the second reconciliation status of each third transaction data in the transaction log, a reconciliation result is generated.

7. The method according to claim 6, characterized in that, If the transaction status of both the first and third transaction data in the third transaction data group is valid, then the transaction amounts and application system information of the first and third transaction data are compared, and the second reconciliation status of the third transaction data is recorded in the transaction log, including: If the transaction amounts of the first transaction data and the third transaction data in the third transaction data group are consistent, and the first application system to which the first transaction data belongs corresponds to the second application system to which the third transaction data belongs, then the second reconciliation status of the third transaction data is marked as reconciliation successful in the transaction log; or, If the transaction amounts of the first and third transaction data in the third transaction data group are inconsistent, then the second reconciliation status of the third transaction data is marked as inconsistent transaction amount in the transaction log; or, If the first application system to which the first transaction data in the third transaction data group belongs does not correspond to the second application system to which the third transaction data belongs, then the second reconciliation status of the third transaction data is marked as "the two parties do not correspond" in the transaction log.

8. The method according to claim 6, characterized in that, The step of recording the second reconciliation status of the third transaction data in the transaction log based on the respective transaction statuses of the first and third transaction data in the fourth transaction data group includes: If the transaction status of the first transaction data in the fourth transaction data group is valid and the transaction status of the third transaction data is invalid, then the first transaction data is inserted into the transaction log, and the second reconciliation status of the inserted first transaction data is marked as "no valid transaction data found" in the transaction log; or, If the transaction status of the first transaction data in the fourth transaction data group is invalid and the transaction status of the third transaction data is valid, then the second reconciliation status of the third transaction data is marked as pending reversal in the transaction log, and the reversal interface is called to send a reversal request to the second application system to which the third transaction data belongs. The reversal request is used to request the reversal of the third transaction data.

9. A transaction data processing device, characterized in that, include: The acquisition unit is used to acquire and summarize the reconciliation files of multiple first application systems to obtain a target reconciliation file. Each first application system has a corresponding second application system. The reconciliation file includes first transaction data between the first application system and the corresponding second application system recorded within a specified time period. An update unit is used to update the transaction log of the transaction processing system based on the second transaction data recorded by each of the plurality of second application systems within the specified time period. The transaction log includes the third transaction data recorded by the transaction processing system between the plurality of first application systems and the plurality of second application systems within the specified time period. The reconciliation unit is used to reconcile the third transaction data in the updated transaction log based on the target reconciliation file to obtain the reconciliation result.

10. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 8.

Images