Bill transaction data synchronization method and device, and storage medium

Abstract

The application discloses a kind of bill transaction data synchronization method, device and storage medium, related to data synchronization technical field, discloses bill transaction data synchronization method, comprising: obtaining account information and bill information data;According to the account information, determine the bill transaction data to be synchronized from the bill information data;The data processing is carried out to the bill transaction data to be synchronized, and processing transaction data is obtained;According to the preset business processing strategy, the processing transaction data is synchronized to bill management system, to complete bill transaction data synchronization.It is mainly realized that directional synchronization of cross-system bill transaction data is realized by obtaining account information and bill information data, screening bill transaction data to be synchronized based on account information and carrying out data processing to it, and the technical effects that the problem of bill information data fragmentation is solved, and accurate, adaptive bill transaction data is obtained to complete synchronization in bill management system.

Description

Technical Field

[0001] This application relates to the field of data synchronization technology, and in particular to methods, apparatus and storage media for synchronizing bill transaction data. Background Technology

[0002] When enterprises conduct bill transactions, bill management platforms and corporate online banking are often used simultaneously, with both jointly handling the entire lifecycle of bill issuance, receipt, endorsement, pledging, and discounting. Bill transactions involve a wide variety of types, a large number of participating institutions, and complex transaction steps; any delay in information transmission can affect corporate reconciliation, credit assessment, and overall financial decisions.

[0003] Against this backdrop, traditional technologies typically rely on manual registration or periodic batch queries to synchronize invoice data. This involves iterating through each tenant or account at fixed time intervals and pulling newly added invoices or partial transaction records from external systems in an attempt to maintain data consistency across different platforms. While this approach can alleviate data fragmentation to some extent, its reliance on manual operation or periodic polling easily leads to significant information lag.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device and storage medium for synchronizing bill transaction data, which aims to solve the technical problem that cross-platform bill transaction data cannot be synchronized in a timely and consistent manner, resulting in enterprises being unable to grasp the status of bills in real time.

[0006] To achieve the above objectives, this application proposes a method for synchronizing bill transaction data, the method comprising: Obtain account information and invoice information data; Based on the account information, determine the bill transaction data to be synchronized from the bill information data; The transaction data of the bills to be synchronized is processed to obtain processed transaction data; The processed transaction data is synchronized to the bill management system according to the preset business processing strategy to complete the bill transaction data synchronization.

[0007] In one embodiment, the step of synchronizing the processed transaction data to the bill management system according to a preset business processing strategy to complete the bill transaction data synchronization includes: Based on the processed transaction data, determine the application-type business data and the withdrawal-type business data; The application-type business data and the withdrawal-type business data are processed according to the preset business processing strategy to obtain the processing results, and the processing results are synchronized to the bill management system to complete the synchronization of bill transaction data.

[0008] In one embodiment, the steps of processing the application-type business data and the withdrawal-type business data according to a preset business processing strategy, obtaining processing results, and synchronizing the processing results to the bill management system to complete the bill transaction data synchronization include: The transaction push time information of the application-type business data is determined according to the preset business processing strategy; The application data is sorted according to the transaction push time information to obtain sorted application data; Based on the bill number data, bill range data, bill type data, and bill holder account data of the sorting application data, determine whether there are any processable bills in the sorting application data; When the processable invoice exists in the sorting application data, the information of the processable invoice is updated according to the sorting application data to obtain the updated invoice information; The processing result is obtained based on the transaction information of the updated bill information and the sorting application data, and the processing result is synchronized to the bill management system to complete the synchronization of bill transaction data.

[0009] In one embodiment, the steps of processing the application-type business data and the withdrawal-type business data according to a preset business processing strategy, obtaining processing results, and synchronizing the processing results to the bill management system to complete the bill transaction data synchronization include: Determine whether there is any pending invoice information in the retrieved business data according to the preset business processing strategy; When the pending bill information exists in the withdrawal business data, the pending bill information is updated according to the withdrawal business data to complete the bill transaction data synchronization; If the pending bill information is not present in the withdrawal business data, transaction information is created based on the withdrawal business data; The processing result is determined based on the transaction information or the updated bill information to be synchronized, and the processing result is synchronized to the bill management system to complete the synchronization of bill transaction data.

[0010] In one embodiment, the step of processing the transaction data of the bills to be synchronized to obtain processed transaction data includes: Acquire user mapping relationships and historical bill transaction information data, wherein the user mapping relationships include user mapping relationships between bank system users and bill management system users; The target enterprise's online banking number is determined based on the user mapping relationship; The target bill transaction information data is determined from the bill transaction data to be synchronized based on the target enterprise's online banking number. The transaction data to be processed is determined based on the historical bill transaction information data and the target bill transaction information data.

[0011] In one embodiment, the step of determining the processed transaction data based on the historical bill transaction information data and the target bill transaction information data includes: Determine whether there is duplicate data in the target bill transaction information data based on the historical bill transaction information data; When duplicate data exists in the target bill transaction information data, the duplicate data is deleted to obtain the processed transaction data; If there is no duplicate data in the target bill transaction information data, the target bill transaction information data shall be used as the processing transaction data.

[0012] In one embodiment, after the step of determining the target bill transaction information data in the bill transaction data to be synchronized based on the target enterprise's online banking number, the method further includes: The target bill transaction information data is distributed to obtain the data distribution result; When the data distribution result is successful, the distribution and synchronization of the processed transaction data are completed. When the data distribution result is distribution failure, the target bill transaction information data is distributed according to the preset asynchronous push task to complete the distribution synchronization of the processed transaction data.

[0013] In one embodiment, the step of determining the bill transaction data to be synchronized from the bill information data based on the account information includes: Determine the source identifier of the invoice information data; The current system transaction data is determined based on the source identifier; The current system transaction data is deleted from the bill information data to obtain the transaction data to be processed; The pending transaction data is filtered based on the account information to obtain the bill transaction data to be synchronized.

[0014] In addition, to achieve the above objectives, this application also proposes a bill transaction data synchronization device, which includes: a data acquisition module for acquiring account information and bill information data; The data determination module is used to determine the bill transaction data to be synchronized from the bill information data based on the account information; The data processing module is used to process the transaction data of the bills to be synchronized to obtain processed transaction data; The data synchronization module is used to synchronize the processed transaction data to the bill management system according to the preset business processing strategy, so as to complete the bill transaction data synchronization.

[0015] In addition, to achieve the above objectives, this application also proposes a bill transaction data synchronization device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the bill transaction data synchronization method described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the bill transaction data synchronization method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the bill transaction data synchronization method described above.

[0018] One or more technical solutions proposed in this application have at least the following technical effects: This approach addresses the core problem of data fragmentation between existing bill-related systems, which prevents accurate and effective synchronization of bill transaction data to the bill management system. By first acquiring account and bill information data, then filtering the bill transaction data from the bill information data based on the account information, processing this data to obtain processed transaction data, and finally synchronizing the processed transaction data to the bill management system, this method eliminates redundant data irrelevant to the target account by filtering the data based on account information. Further processing of the filtered data ensures it meets the receiving and usage requirements of the bill management system. Synchronizing the processed data to the bill management system directly establishes a seamless data flow. Compared to existing technologies, this approach achieves targeted and effective synchronization of bill transaction data to the bill management system, ensuring that the bill management system receives bill transaction data that matches the target account and meets usage requirements. Attached Figure Description

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

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

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the method for synchronizing bill transaction data in this application. Figure 2 This is a schematic diagram of the data distribution process provided in Embodiment 1 of the method for synchronizing bill transaction data in this application; Figure 3 This is a schematic diagram of the deduplication process for bill transaction information data provided in Embodiment 1 of the bill transaction data synchronization method of this application; Figure 4 This is a flowchart illustrating Embodiment 2 of the method for synchronizing bill transaction data in this application. Figure 5 This is a business adaptation diagram provided for Embodiment 2 of the method for synchronizing bill transaction data in this application; Figure 6 This is a flowchart of the data processing for synchronizing bill transaction data, provided in Embodiment 2 of the method for synchronizing bill transaction data in this application. Figure 7 A simplified flowchart illustrating the bill transaction data synchronization method provided in Embodiment 2 of this application; Figure 8 This is a schematic diagram of the module structure of the bill transaction data synchronization device according to an embodiment of this application; Figure 9 This is a schematic diagram of the hardware operating environment involved in the bill transaction data synchronization method in this application embodiment.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of this application embodiment is: to obtain account information and bill information data; to determine the bill transaction data to be synchronized from the bill information data based on the account information; to process the bill transaction data to be synchronized to obtain processed transaction data; and to synchronize the processed transaction data to the bill management system according to a preset business processing strategy to complete the synchronization of bill transaction data.

[0026] In this embodiment, for ease of description, the following description will focus on the device for synchronizing bill transaction data.

[0027] Because existing technologies cannot synchronize cross-platform bill transaction data in a timely and consistent manner, leading to enterprises' inability to grasp the real-time status of bills, this application provides a solution. This solution involves first acquiring account and bill information data, then filtering and determining the bill transaction data to be synchronized based on the account information, subsequently processing this data to obtain processed transaction data, and finally synchronizing the processed transaction data to the bill management system. The core problem addressed is the data fragmentation between existing bill-related systems, which prevents accurate and effective synchronization of bill transaction data to the bill management system. By filtering the data to be synchronized based on account information, redundant data irrelevant to the target account can be eliminated. Further processing of the filtered data ensures it is compatible with the bill management system's receiving and usage requirements. Synchronizing the processed data to the bill management system directly establishes a data flow link. Compared to existing technologies, this solution achieves targeted and effective synchronization of bill transaction data to the bill management system, ensuring that the bill management system obtains bill transaction data that matches the target account and meets usage requirements.

[0028] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or a bill transaction data synchronization device capable of performing the above functions. The following description uses a bill transaction data synchronization device as an example to illustrate this embodiment and the subsequent embodiments.

[0029] Based on this, the embodiments of this application provide a method for synchronizing bill transaction data, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the bill transaction data synchronization method of this application.

[0030] In this embodiment, the bill transaction data synchronization method includes steps S10 to S40: Step S10: Obtain account information and invoice information data; It should be noted that the account information is data pushed by the bill management module, which includes the account identifier and account attributes associated with the customer in bill business.

[0031] In addition, the bill information data covers message information of bill business transactions, including data from various bill business transaction scenarios such as receiving a receipt from the Shanghai Commercial Paper Exchange for a bill business application and receiving a response from the counterparty for a bill business application, providing a foundation for the subsequent extraction of valid transaction information.

[0032] Understandably, the bill management module pushes account information to the settlement engine module, while the settlement engine module notifies the real-time consumption bill business transaction message information through Kafka messages, thereby completing the acquisition of account information and bill information data.

[0033] Step S20: Determine the bill transaction data to be synchronized from the bill information data based on the account information; It should be noted that the bill transaction data to be synchronized is the bill business transaction information filtered from the bill information data that needs to be synchronized to the bill management module. This data must meet two conditions: it must match the account information and it must not be a bill transaction processed by the bill management module itself. It is the direct object of subsequent data processing and synchronization operations, ensuring that the synchronized data is only the valid transaction data actually needed by the target customer.

[0034] Understandably, the settlement engine module first filters out bill transactions processed by the bill management module, and then, based on the previously obtained account information, selects bill business transaction information that matches the account information from the bill information data, and determines it as the bill transaction data to be synchronized.

[0035] In one feasible implementation, step S20 may include steps S21 to S24: Step S21: Determine the source identifier of the bill information data; It should be noted that the source identifier is used to distinguish the processing module to which the bill information data belongs. It can clearly identify which system generated each piece of bill information data, providing a basis for subsequent determination of transaction data in specific modules, and ensuring accurate identification of data that does not need to be synchronized and needs to be excluded.

[0036] Understandably, the settlement engine module analyzes each piece of the acquired bill information data, extracts the identifier used to distinguish the processing entity from each piece of data, and uses this identifier to determine the source identifier of the bill information data.

[0037] Step S22: Determine the current system transaction data based on the source identifier; It should be noted that the current system transaction data is bill transaction data generated by the bill management system based on the source identifier. Since this type of data has already been processed within the bill management system, it does not need to be synchronized to the system across entities. Excluding this type of data can avoid the waste of resources caused by duplicate synchronization.

[0038] Understandably, the settlement engine module filters out bill transaction data whose processing entity is the bill management system based on the determined source identifier, and identifies this data as the current system transaction data.

[0039] Step S23: Delete the current system transaction data from the bill information data to obtain the transaction data to be processed; It should be noted that the transaction data to be processed is the remaining transaction data after the settlement engine module deletes the current system transaction data from the transaction information data. It contains potential data that needs to be further filtered and synchronized to the transaction management system, and is the basic dataset for subsequent accurate filtering.

[0040] It is understandable that the settlement engine module removes the confirmed current system transaction data from the bill information data, and the remaining data after removal is the transaction data to be processed.

[0041] Step S24: Filter the transaction data to be processed according to the account information to obtain the bill transaction data to be synchronized.

[0042] It is understandable that the settlement engine module uses the acquired account information to match and filter the transaction data to be processed, retains the data that corresponds to the account information and needs to be synchronized to the bill management system, and determines these retained data as the bill transaction data to be synchronized.

[0043] Step S30: Perform data processing on the transaction data of the bills to be synchronized to obtain processed transaction data; It should be understood that data processing includes data cleaning, data mapping, and data deduplication. Data cleaning removes invalid and redundant content from the transaction data to be synchronized, ensuring data accuracy. Data mapping converts transaction data from various banks into unified interface field values ​​required by the bill management module, based on the mapping relationship between the bank system and the bill management module's user system—that is, the many-to-one mapping relationship between bank customer numbers and corporate online banking numbers in the bill management module. Data deduplication prevents duplicate data from entering the subsequent synchronization process.

[0044] It should be noted that the processed transaction data refers to the bill transaction information data obtained after processing the bill transaction data to be synchronized, which conforms to the interface requirements of the bill management module. This data undergoes data cleaning to remove invalid and redundant content, data mapping to a unified format, and data deduplication to avoid duplicate records, and can be directly used for subsequent synchronization to the bill management module.

[0045] Understandably, the settlement engine module sequentially performs data cleaning, data mapping, and data deduplication operations on the transaction data to be synchronized to complete the data processing and obtain the processed transaction data.

[0046] In one feasible implementation, step S30 may include steps S31 to S34: Step S31: Obtain user mapping relationships and historical bill transaction information data, wherein the user mapping relationships include user mapping relationships between bank system users and bill management system users; It should be noted that the user mapping relationship is a data correspondence used to associate the identities of users in different systems. Specifically, it includes the correspondence between the bank customer number of the bank system user and the corporate online banking number of the bill management system. The correspondence is many-to-one. This relationship is the core basis for determining the corporate user to whom the data belongs, ensuring that the data can be accurately attributed to the corresponding corporate account in the bill management system.

[0047] In addition, bank system users are user entities that are registered and used in the bank's relevant systems. Their identities are uniquely identified by their bank customer numbers, which are exclusive codes assigned to users by the bank system to distinguish different bank users and associate them with the bill transaction data under their names.

[0048] Furthermore, the bill management system is a system that provides enterprises with full lifecycle business functions for bills, covering scenarios such as bill acceptance, endorsement, pledging, and discounting. It is also responsible for receiving synchronized transaction data. The enterprise online banking number is a unique identifier assigned to enterprise users by the system, which is used to associate all bill business data of the enterprise within the system.

[0049] Furthermore, historical bill transaction information data is stored data related to past bill transactions, including details of bill transactions that have been synchronized or processed. This data can be compared with new data to avoid duplicate synchronization or omissions in processing.

[0050] Understandably, the settlement engine module obtains the user mapping relationship between bank system users and bill management system users, and at the same time retrieves the stored historical bill transaction information data.

[0051] Step S32: Determine the target enterprise online banking number based on the user mapping relationship; It should be noted that the target company's online banking number is a unique number corresponding to a specific company user in the bill management system. This number is obtained from the bank's customer number through user mapping and is a key identifier for subsequent screening of target bill transaction information data and distribution data, ensuring that the data can be accurately matched to the corresponding company account in the bill management system.

[0052] Understandably, the settlement engine module, based on the obtained user mapping relationship, maps the bank customer number associated with the bill transaction data to be synchronized to the corporate online banking number in the bill management system, and determines the number as the target corporate online banking number.

[0053] Step S33: Determine the target bill transaction information data in the bill transaction data to be synchronized based on the target enterprise's online banking number; It should be noted that the target bill transaction information data is the part of the bill transaction data to be synchronized that corresponds to the target company's online banking number. That is, the bill transaction data belonging to the company identified by the company's online banking number is the core object for subsequent processing in conjunction with historical data, ensuring that only the transaction data of the corresponding company that needs to be synchronized is processed.

[0054] Understandably, the settlement engine module, based on the determined target enterprise's online banking number, filters out the bill transaction data belonging to the enterprise corresponding to that number from the bill transaction data to be synchronized, and identifies this data as the target bill transaction information data.

[0055] Step S34: Determine the processing transaction data based on the historical bill transaction information data and the target bill transaction information data.

[0056] It should be noted that the processed transaction data is obtained by comparing historical bill transaction information with target bill transaction information. During the processing, duplicate content with historical data will be excluded and missing necessary information will be supplemented. The final result is data with standardized format, accurate content and compliance with the bill management system requirements, which can be directly used for subsequent synchronization operations.

[0057] Understandably, the settlement engine module compares the historical bill transaction information data with the target bill transaction information data, eliminates duplicate data, improves necessary information, and determines the transaction data that meets the requirements for processing.

[0058] In one feasible implementation, after step S33, the process may further include: distributing the target bill transaction information data to obtain a data distribution result; when the data distribution result is successful, completing the distribution synchronization of the processed transaction data; when the data distribution result is a distribution failure, distributing the target bill transaction information data according to a preset asynchronous push task to complete the distribution synchronization of the processed transaction data.

[0059] It should be noted that data distribution is the operation by which the settlement engine module distributes bill transaction information data according to the enterprise online banking number via the Hypertext Transfer Protocol (HTTP). The purpose is to accurately transmit the target bill transaction information data to the bill management system, ensuring that the data can be received and processed by the target system. This is a key step in achieving data synchronization.

[0060] In addition, the data distribution result is the feedback information generated after the data distribution operation. It is divided into two cases: distribution success and distribution failure. This result directly determines whether a backup distribution mechanism needs to be started, and is an important basis for ensuring that the data can eventually be synchronized.

[0061] Furthermore, the preset asynchronous push task is a task pre-set by the settlement engine module to compensate for data distribution. It is triggered when real-time data distribution fails and will re-distribute the target bill transaction information data that was not successfully distributed through timed execution to avoid data synchronization interruption due to real-time distribution failure.

[0062] Furthermore, the process of distributing and synchronizing transaction data involves successfully transmitting the processed bill transaction data to the bill management system and completing the data integration. Once this process is completed, it means that the cross-system bill transaction data synchronization has been achieved, ensuring that the bill management system can obtain accurate transaction data.

[0063] It is understood that the settlement engine module distributes the target bill transaction information data to obtain the data distribution result; if the data distribution result is successful, the distribution synchronization of the processed transaction data is directly completed; if the data distribution result is unsuccessful, the target bill transaction information data is distributed again according to the preset asynchronous push task, thereby completing the distribution synchronization of the processed transaction data.

[0064] Reference Figure 2 , Figure 2 This is a schematic diagram of the data distribution process for the first embodiment of the bill transaction data synchronization method of this application.

[0065] like Figure 2 As shown, the bill business processing is responsible for generating various transaction messages such as issuance, endorsement, and discounting. Information configuration stores business parameters, and account information stores the mapping between the enterprise's online banking number and the bank's customer number. These three together serve as the data source and are transmitted downwards. Account information is first pushed horizontally into the customer information mapping maintenance module of the settlement engine, enabling the settlement engine to grasp the mapping relationship required for filtering by the enterprise's online banking number. Subsequently, the transaction and bill information generated by the bill business processing are sent to Kafka in real time. The settlement engine consumes messages from Kafka and, at the data filtering node, removes transactions initiated by the bill management system itself based on the customer information mapping results, retaining only the parts that need to be synchronized across systems. The filtered data enters the business information mapping processing node, where field conversion, value correction, and deduplication are completed according to the bill management system interface standard to form the target bill transaction information. Then, it enters the bill transaction information distribution and push node, which actively delivers the information to the bill management system via HTTP. If the delivery is successful, the process ends immediately; if it fails, it is transferred to the asynchronous bill transaction push task, which is resent by a scheduled task to ensure eventual data consistency.

[0066] In one feasible implementation, step S34 may include: determining whether there is duplicate data in the target bill transaction information data based on the historical bill transaction information data; if there is duplicate data in the target bill transaction information data, deleting the duplicate data in the target bill transaction information data to obtain processed transaction data; if there is no duplicate data in the target bill transaction information data, using the target bill transaction information data as processed transaction data.

[0067] It should be noted that duplicate data refers to data in the target bill transaction information that is completely identical to the key content of the historical bill transaction information. Key content includes business type, bill package number, bill range, transaction serial number, etc. If this type of data is synchronized repeatedly, it will lead to data redundancy in the bill management system, affecting data accuracy and business processing efficiency.

[0068] In addition, the transaction data is the bill transaction data obtained after deleting duplicate data. It is either the target bill transaction information data after deleting duplicate data, or the target bill transaction information data without duplicates that is directly used. Its core characteristics are no redundancy, compliance with the bill management system's requirement for data uniqueness, and direct use for subsequent distribution and synchronization.

[0069] Understandably, the settlement engine module compares and analyzes the target bill transaction information data against the historical bill transaction information data to determine if there are duplicate data with identical key content. If duplicate data is found, it is deleted, and the remaining data becomes the processed transaction data. If no duplicate data is found, the target bill transaction information data is directly used as the processed transaction data. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the deduplication process for bill transaction information data in the first embodiment of the bill transaction data synchronization method of this application.

[0070] like Figure 3 As shown, the settlement engine node is responsible for data semaphore acquisition. It encapsulates the cleaned and processed transaction data into an HTTP message containing fields such as business type, bill package number, bill range, transaction serial number, and processing status. The message is then sent to the bill management system via HTTP semaphore sending. The bill management system has a corresponding entry point for receiving bill transaction data semaphores. Upon receipt, the system enters the deduplication process, searches historical records, and if no duplicate data exists, writes the semaphore completely to the local database and waits for subsequent asynchronous tasks to retrieve the bank-enterprise direct connection details. If duplicate data exists, it is discarded directly to avoid duplicate updates. This lightweight semaphore achieves second-level reach and idempotent control, reducing network and storage overhead.

[0071] Step S40: Synchronize the processed transaction data to the bill management system according to the preset business processing strategy to complete the bill transaction data synchronization.

[0072] It should be understood that the relevant modules of the bill management system will receive and process the synchronized transaction data. If real-time synchronization fails, it is necessary to send the data through asynchronous tasks to ensure that the data can be completely synchronized to the module.

[0073] It should be noted that the preset business processing strategy is a rule for processing data according to the business transaction dimension, based on the synchronization characteristics of bill business transaction data. The processing logic is set separately for application-type business data and retrieval-type business data in the transaction data. Application-type business data will be sorted by transaction push time and then query the bills that can be processed and update the information. Retrieval-type business data will be checked to see if the bill information to be synchronized exists and then perform update or creation operations accordingly, to ensure that the data processing meets the needs of bill business.

[0074] Furthermore, the bill management system is a system that provides enterprises with full lifecycle business functions for bills, covering scenarios such as bill receipt, endorsement, pledge, and discounting. It is also the target system for processing transaction data synchronization. After receiving synchronized data, it can support the enterprise's subsequent bill business handling and reconciliation operations.

[0075] Understandably, the transaction data is synchronized to the relevant bill management modules by distributing the bill transaction information data via HTTP according to the corporate online banking number. If the real-time distribution operation fails, an asynchronous bill transaction push task is added to compensate for the transaction data by sending it through a timed asynchronous task, and finally the bill transaction data synchronization is completed.

[0076] This embodiment provides a method for synchronizing bill transaction data. By having the settlement engine obtain account information pushed by the bill management system in real time and consume bill transaction messages in Kafka, the method filters out system-owned transactions using source identifiers, accurately selects data to be synchronized based on account information, and then uses cleaning, mapping, deduplication, HTTP distribution, and asynchronous compensation sending techniques to solve the technical problems of delayed synchronization of cross-system bill transaction information, data duplication, large network overhead, and complex processes. This method achieves the beneficial effects of reducing synchronization time from two hours to within fifty seconds, ensuring data consistency and accuracy, and improving system performance.

[0077] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 Step S40 of the bill transaction data synchronization method includes steps S41 to S42: Step S41: Determine the application-type business data and the withdrawal-type business data based on the processed transaction data; It should be noted that application-type business data is the data used to synchronize and update the existing bill information in the bill management system and the corresponding transaction information. The core of processing this type of data is based on the existing bill ledger in the system to ensure that the existing bill information is consistent with the latest transaction status and to avoid business processing errors due to information lag.

[0078] Additionally, the data for repatriation-type business transactions is used to synchronize newly added bill information in the bill management system, as well as the corresponding bill transaction information. The core of processing this type of data is to supplement the missing bill ledgers in the system, ensuring that all involved bills and transaction information can be fully incorporated into the system management to support subsequent business handling needs.

[0079] It is understandable that the settlement engine module distinguishes between application-type business data used to update existing bill information and withdrawal-type business data used to add new bill information, based on the transaction type corresponding to the processed transaction data.

[0080] Step S42: Process the application-type business data and the withdrawal-type business data according to the preset business processing strategy, obtain the processing result, and synchronize the processing result to the bill management system to complete the bill transaction data synchronization.

[0081] It should be noted that the preset business processing strategy is a rule for processing data according to the business transaction dimension, based on the synchronous characteristics of bill business transaction data. For application-type business data, it will first sort by transaction bill package number, bill range, and transaction push time, and then check whether there are any bills that can be processed. If they exist, the bill information will be updated and the transaction information will be added. For withdrawal-type business data, it will be processed independently according to the transaction dimension. The same query conditions will be used to determine whether the bill exists. If it exists, the bill information will be updated. If it does not exist, the bill information and corresponding transaction information will be added.

[0082] Furthermore, the processing result is the final data obtained after processing application-type business data and retrieval-type business data according to preset strategies. This includes updated bill information, newly added bill ledgers and corresponding transaction information. The format and content meet the receiving requirements of the bill management system and are direct data objects for synchronous operations.

[0083] Understandably, according to the preset business processing strategy, corresponding processing operations are performed on the application-type business data and the withdrawal-type business data respectively, to obtain processing results including updated bill information, newly added bill ledgers, and transaction information. These processing results are then synchronized to the bill management system, ultimately completing the synchronization of bill transaction data. (Refer to...) Figure 5 , Figure 5This is a business adaptation diagram of the second embodiment of the bill transaction data synchronization method of this application.

[0084] like Figure 5 As shown, the business adapter module categorizes and adapts invoice transaction data based on its type and status. For existing invoices, the business adapter determines whether to perform an update operation or other adaptation actions based on the invoice's business type and current status. For example, in cases of invoice issuance or receipt, the adapter triggers an update process to synchronize the latest invoice information to the system. For non-existent invoices, the adapter initiates an invoice entry operation, completely recording the new invoice information into the system for subsequent business processing.

[0085] During the synchronization of bill transaction data, the business adapter handles various transaction types, including but not limited to acceptance, endorsement, release of pledge, pledge, withdrawal of pledge, discounting, collection, and payment. Each transaction has its corresponding processing logic and adaptation rules. For example, an acceptance transaction updates the acceptance status of the bill, an endorsement transaction updates the holder information of the bill, and a pledge transaction updates the pledge status of the bill. These transaction processing strategies are preset to ensure that the system can accurately synchronize bill transaction data according to different business scenarios.

[0086] Through the classification and adaptation of business adapters, the synchronization of bill transaction data can efficiently process application-type and withdrawal-type business data. Application-type business data typically involves updating existing bills, while withdrawal-type business data may involve the entry of new bills into the warehousing system or the updating of existing bill information. This classification approach ensures the accuracy and consistency of bill transaction data, while improving system processing efficiency and avoiding business problems caused by data duplication or errors.

[0087] In one feasible implementation, step S42 may include steps A421 to A425: Step A421: Determine the transaction push time information of the application-type business data according to the preset business processing strategy; It should be noted that the transaction push time information is time-related data on when application-type business data is pushed to the processing stage. It includes the specific time when the data is generated and the push is initiated. This information reflects the chronological order of application-type business data and is a core reference to ensure that data is processed in the order in which the business occurs.

[0088] It is understandable that the settlement engine module extracts information used to identify the data push sequence from the application-type business data according to the preset business processing strategy, and determines it as the transaction push time information of the application-type business data.

[0089] Step A422: Sort the application data according to the transaction push time information to obtain sorted application data; It should be noted that the sorted application data is a dataset obtained by sorting application-type business data according to the transaction push time information. Sorting ensures that the application-type business data is arranged in the order of push time, ensuring that the business data pushed first is processed first, which conforms to the time logic of the business process and avoids data association errors caused by disordered processing order.

[0090] It is understandable that the settlement engine module sorts the application-type business data according to the transaction push time information, and obtains the sorted application data after the sorting is completed.

[0091] Step A423: Based on the bill number data, bill range data, bill type data, and bill holder account data of the sorting application data, determine whether there are any processable bills in the sorting application data; It should be noted that the invoice number is a unique identifier for each invoice. Each invoice has a unique invoice number, which allows for precise location of a specific invoice and is one of the core identifiers for checking whether an invoice exists.

[0092] Additionally, the bill range data consists of a range of consecutive bill numbers, which can cover multiple bills in a certain batch or category. This data is used for batch queries to check if bills within this range exist, thus improving query efficiency.

[0093] Furthermore, bill type data identifies the type of bill, including different types such as commercial drafts and bank drafts. The business processing rules for different types of bills differ, and this data ensures that the corresponding type of bill is matched during the query.

[0094] Furthermore, the bill holder account data is coded data that identifies the current holder's account of the bill, which can clearly identify the owner of the bill. By querying this data, it can be ensured that the bill belongs to the correct party. The processable bills are bills that already exist in the bill management system and are in a state where business operations can be carried out. These bills have the basic conditions for updating information.

[0095] Understandably, the settlement engine module extracts the bill number data, bill range data, bill type data, and bill holder account data from the sorting application data, and queries the bill management system based on this data to determine whether there is a corresponding processable bill in the sorting application data.

[0096] Step A424: When the processable invoice exists in the sorting application data, update the information of the processable invoice according to the sorting application data to obtain updated invoice information.

[0097] It should be noted that updating the bill information involves overwriting the original information of the bills that can be processed with the latest content from the sorted application data. The overwritten content includes key information such as bill status and transaction details, ensuring that the bill information in the bill management system is consistent with the actual transaction situation and avoiding information lag from affecting business processing.

[0098] It is understandable that when it is determined that the processable invoice exists in the sorting application data, the settlement engine module updates the original information of the processable invoice based on the latest information in the sorting application data, and finally obtains the updated invoice information.

[0099] Step A425: Obtain the processing result based on the transaction information of the updated bill information and the sorting application data, and synchronize the processing result to the bill management system to complete the bill transaction data synchronization.

[0100] It should be noted that the processing result is the final data obtained by integrating the transaction information of the updated bill information and the sorting application data. This data has a uniform format, complete content, and fully meets the requirements of the bill management system for synchronized data. It is the direct carrier for achieving data synchronization.

[0101] It is understood that the updated bill information is integrated with the transaction information of the sorting application data to form a processing result, and then the processing result is synchronized to the bill management system to finally complete the synchronization of bill transaction data.

[0102] In one feasible implementation, when the processable document is not found in the sorted application data, a task failure message is obtained; It should be noted that the task failure information is a feedback message generated when the query results show that there are no processable invoices in the sorted application data. This information will record the reason for the task failure, namely, the absence of a corresponding processable invoice and the current number of failures, to provide a reference for whether to retry the process in the future, and at the same time terminate the processing flow of this part of the current batch of data.

[0103] It is understandable that if the settlement engine module determines after querying that the processable invoice does not exist in the sorted application data, it will generate task failure information that records the reason for failure and the number of times it failed.

[0104] In one feasible implementation, the step of "obtaining task failure information when no processable invoice exists in the sorting application data" may include: obtaining a preset number of retries; determining the current number of retries based on the task failure information; when the current number of retries is less than or equal to the preset number of retries, returning the step of determining whether a processable invoice exists in the sorting application data based on the invoice number data, invoice range data, invoice type data, and invoice holder account data of the sorting application data; and stopping the current synchronization task when the current number of retries is greater than the preset number of retries.

[0105] It should be noted that the preset number of retries is a pre-set maximum number of times that a failed task can be reprocessed. In this embodiment, the preset number of retries can be set to 5 times. Its purpose is to avoid resource waste caused by infinite retries, and at the same time to provide a clear threshold standard for determining whether to continue retries, ensuring that the retry operation neither misses recoverable failed tasks nor consumes too many resources.

[0106] In addition, the current retry count is the number of times the task has been reprocessed based on the task failure information. This count increases with each retry operation, which can intuitively reflect the progress of the task retry and is a key basis for comparing with the preset retry count to determine subsequent operations.

[0107] Furthermore, the task failure information is generated when there are no processable invoices in the sorted application data. In addition to recording the failure reason "no processable invoices exist", it will also record the number of retries for the current task, providing complete data support for extracting the current number of retries and determining whether to continue retries.

[0108] Understandably, the settlement engine module first obtains the preset number of retries, and then determines the current number of retries based on the task failure information. If the current number of retries is less than or equal to the preset number of retries, it returns the step of determining whether there is a processable bill based on the bill number data, bill range data, bill type data, and bill holder account data of the sorted application data. If the current number of retries is greater than the preset number of retries, the current synchronization task is stopped.

[0109] In one feasible implementation, step S42 may include steps B421 to B424: Step B421: Determine whether there is any pending invoice information in the retrieved business data according to the preset business processing strategy; It should be noted that the preset business processing strategy is a rule for processing data according to the business transaction dimension, based on the synchronization characteristics of bill business transaction data. For withdrawal-type business data, this strategy will clearly define the criteria for determining whether bill information already exists, providing a clear basis for determining whether there is bill information to be synchronized, and ensuring that the processing logic meets the synchronization requirements of bill business.

[0110] Additionally, the pending synchronized bill information refers to bill-related information that may already exist in the bill management system within the data of retrieved business transactions. This includes core information such as bill number, bill type, and holder account. The existence of this information directly determines the subsequent processing method for retrieved business data and is the key to distinguishing between update and creation operations.

[0111] Understandably, the settlement engine module, based on the preset business processing strategy and combined with the core information of the bills in the withdrawal business data, determines whether there is existing bill information to be synchronized in the withdrawal business data.

[0112] Step B422: When the pending invoice information exists in the withdrawal business data, update the pending invoice information according to the withdrawal business data; It should be noted that updating the pending synchronized bill information refers to the operation of overwriting the original bill information with the latest content in the retrieved business data when the pending synchronized bill information already exists in the bill management system. The overwritten content includes key data such as bill status and transaction details, to ensure that the bill information in the bill management system is consistent with the actual transaction situation and to avoid information lag.

[0113] It is understood that if it is determined that the pending invoice information exists in the withdrawal business data, the settlement engine module will update the pending invoice information according to the withdrawal business data.

[0114] Step B423: If the information to be synchronized for the ticket does not exist in the withdrawal business data, create transaction information based on the withdrawal business data; It should be noted that creating transaction information refers to the operation of creating a new bill ledger and corresponding transaction records based on the data of the withdrawn business when there is no bill information to be synchronized in the bill management system. The newly created content includes basic bill information, transaction flow, processing status, etc., to ensure that all bills and transactions involved in withdrawn business can be fully included in the bill management system to support subsequent business handling.

[0115] It is understood that if it is determined that the pending bill information does not exist in the withdrawal business data, the settlement engine module will create transaction information based on the withdrawal business data.

[0116] Step B424: Determine the processing result based on the transaction information or the updated bill information to be synchronized, and synchronize the processing result to the bill management system to complete the bill transaction data synchronization.

[0117] Understandably, the basic data is selected based on whether there is any pending bill information in the withdrawn business data. If new data needs to be created, it is based on the transaction information. If an update is needed, it is based on the updated pending bill information. The data is then integrated to form a processing result, which is then synchronized to the bill management system to finally complete the synchronization of bill transaction data.

[0118] Reference Figure 6 , Figure 6 This is a flowchart of the data processing for synchronizing bill transaction data according to the second embodiment of the bill transaction data synchronization method of this application.

[0119] like Figure 6 As shown, by querying the pending task semaphore, the bill transaction synchronization semaphore table is scanned every 15 seconds to enter the direct connection query to obtain bill transaction information. The complete message is pulled through the bank-enterprise direct connection interface according to the bill package number and transaction serial number to ensure the correct data source. Next, the process enters the time-series processing stage. First, the data is sorted by transaction push time, and then split into two processing paths based on business type: application-type business and retrieval-type business. The application-type business path executes the business processing strategy, first checking if there is a processable invoice. If it exists, the invoice information is updated and transaction information is added. If it does not exist, the failure count is incremented. When the failure count is less than five, the task is re-queued to wait for the next round of retry. If it is more than five, it is terminated directly and the log is recorded. The retrieval-type business path performs invoice deduplication and enters the data into the database. If the invoice already exists, the invoice information is updated and transaction information is added. If it does not exist, the invoice information and transaction information are added directly. The processing results of the two paths are finally summarized in the update and synchronization of invoice transaction task stage. The success or failure status is written back to the semaphore table to complete the update and synchronization of invoice transaction tasks. This avoids duplicate data entry and compresses the original two-hour polling to a second-level completion.

[0120] This embodiment provides a method for synchronizing bill transaction data. It uses a settlement engine to split transaction data into application and withdrawal categories based on transaction type. Application data is sorted by transaction push time and then retrieved for processing based on bill number, range, type, and holder account. Automatic retrying occurs when the number of failures is less than five. Withdrawal data undergoes deduplication before updating or creating new bill ledgers and transaction information. Finally, the processing results are written back to a semaphore table. This method solves the technical problems of missed updates, duplicate entries, lack of retry mechanisms, and low synchronization efficiency caused by differences in business scenarios in cross-system bill transaction data. It achieves the beneficial effects of precise adaptation according to business dimensions, automatic failure compensation, second-level synchronization, and avoidance of data redundancy.

[0121] For example, to help understand the implementation process of the bill transaction data synchronization method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 7 , Figure 7 A simplified flowchart illustrating a method for synchronizing bill transaction data is provided, specifically: The account information push is initiated by the bill management system, which proactively pushes customer account information to the settlement engine. This push action enables the settlement engine to obtain the account-dimensional data necessary for subsequent transaction screening. The second step is that the settlement engine consumes the bill system's Kafka messages in real time, cleaning, deduplicating, and mapping fields of the application, response, receipt, and settlement messages generated by the bill business, retaining only transaction data that is not initiated by the bill management system and conforms to the account dimensions. The third step is real-time incremental data synchronization, which pushes the transaction semaphores selected in the second step back to the bill management system via HTTP within seconds. The semaphores carry the business type, bill package number, bill range, transaction serial number, and processing status, triggering the bill management system to take immediate action. The fourth step is to query the bill transaction details. The bill management system uses the semaphores to call the bank-enterprise direct connection interface to pull the complete transaction details, and then updates or adds bill ledgers and transaction records in the system according to the application or retrieval strategy to complete data synchronization.

[0122] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the method for synchronizing bill transaction data in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0123] This application also provides a device for synchronizing bill transaction data; please refer to [reference needed]. Figure 8 The bill transaction data synchronization device includes: Data acquisition module 10 is used to acquire account information and invoice information data; Data determination module 20 is used to determine the bill transaction data to be synchronized from the bill information data based on the account information; Data processing module 30 is used to process the transaction data of the bills to be synchronized to obtain processed transaction data; The data synchronization module 40 is used to synchronize the processed transaction data to the bill management system according to the preset business processing strategy, so as to complete the bill transaction data synchronization.

[0124] The bill transaction data synchronization device provided in this application, employing the bill transaction data synchronization method described in the above embodiments, can solve the technical problem that cross-platform bill transaction data cannot be synchronized in a timely and consistent manner, resulting in enterprises being unable to grasp the real-time status of bills. Compared with the prior art, the beneficial effects of the bill transaction data synchronization device provided in this application are the same as those of the bill transaction data synchronization method provided in the above embodiments, and other technical features in the bill transaction data synchronization device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0125] In one embodiment, the data synchronization module 40 is further configured to determine application-type business data and withdrawal-type business data based on the processed transaction data; process the application-type business data and the withdrawal-type business data according to a preset business processing strategy to obtain a processing result, and synchronize the processing result to the bill management system to complete the bill transaction data synchronization.

[0126] In one embodiment, the data synchronization module 40 is further configured to: determine the transaction push time information of the application-type business data according to a preset business processing strategy; sort the application-type business data according to the transaction push time information to obtain sorted application data; determine whether there are any processable bills in the sorted application data based on the bill number data, bill range data, bill type data, and bill holder account data of the sorted application data; when there are processable bills in the sorted application data, update the information of the processable bills according to the sorted application data to obtain updated bill information; obtain a processing result based on the updated bill information and the transaction information of the sorted application data, and synchronize the processing result to the bill management system to complete the synchronization of bill transaction data.

[0127] In one embodiment, the data synchronization module 40 is further configured to determine whether there is any bill information to be synchronized in the repatriation business data according to a preset business processing strategy; when the bill information to be synchronized exists in the repatriation business data, update the bill information to be synchronized according to the repatriation business data; when the bill information to be synchronized does not exist in the repatriation business data, create transaction information according to the repatriation business data; determine the processing result according to the transaction information or the updated bill information to be synchronized, and synchronize the processing result to the bill management system to complete the synchronization of bill transaction data.

[0128] In one embodiment, the data processing module 30 is further configured to acquire user mapping relationships and historical bill transaction information data, wherein the user mapping relationships include user mapping relationships between bank system users and bill management system users; determine the target enterprise online banking number based on the user mapping relationships; determine the target bill transaction information data in the bill transaction data to be synchronized based on the target enterprise online banking number; and determine the processing transaction data based on the historical bill transaction information data and the target bill transaction information data.

[0129] In one embodiment, the data processing module 30 is further configured to determine whether there is duplicate data in the target bill transaction information data based on the historical bill transaction information data; if there is duplicate data in the target bill transaction information data, delete the duplicate data in the target bill transaction information data to obtain processed transaction data; if there is no duplicate data in the target bill transaction information data, use the target bill transaction information data as processed transaction data.

[0130] In one embodiment, the data processing module 30 is further configured to distribute the target bill transaction information data to obtain a data distribution result; when the data distribution result is successful, complete the distribution synchronization of the processed transaction data; when the data distribution result is a failure, distribute the target bill transaction information data according to a preset asynchronous push task to complete the distribution synchronization of the processed transaction data.

[0131] In one embodiment, the data determination module 20 is further configured to determine the source identifier of the bill information data; determine the current system transaction data based on the source identifier; delete the current system transaction data from the bill information data to obtain transaction data to be processed; and filter the transaction data to be processed based on the account information to obtain bill transaction data to be synchronized.

[0132] This application provides a bill transaction data synchronization device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the bill transaction data synchronization method in the first embodiment described above.

[0133] The following is for reference. Figure 9The diagram illustrates a structural schematic of a bill transaction data synchronization device suitable for implementing embodiments of this application. The bill transaction data synchronization device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 9 The bill transaction data synchronization device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0134] like Figure 9 As shown, the bill transaction data synchronization device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the bill transaction data synchronization device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the bill transaction data synchronization device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows bill transaction data synchronization devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0135] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0136] The bill transaction data synchronization device provided in this application, employing the bill transaction data synchronization method described in the above embodiments, can solve the technical problem that cross-platform bill transaction data cannot be synchronized in a timely and consistent manner, resulting in enterprises being unable to grasp the real-time status of bills. Compared with the prior art, the beneficial effects of the bill transaction data synchronization device provided in this application are the same as those of the bill transaction data synchronization method provided in the above embodiments, and other technical features in this bill transaction data synchronization device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0137] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0138] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0139] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the bill transaction data synchronization method in the above embodiments.

[0140] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0141] The aforementioned computer-readable storage medium may be included in the bill transaction data synchronization device; or it may exist independently and not be assembled into the bill transaction data synchronization device.

[0142] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the bill transaction data synchronization device, the bill transaction data synchronization device causes the following: to acquire account information and bill information data; to determine the bill transaction data to be synchronized from the bill information data based on the account information; to process the bill transaction data to be synchronized to obtain processed transaction data; and to synchronize the processed transaction data to the bill management system according to a preset business processing strategy, thereby completing the bill transaction data synchronization.

[0143] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0145] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0146] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described bill transaction data synchronization method. This solves the technical problem that cross-platform bill transaction data cannot be synchronized in a timely and consistent manner, leading to enterprises' inability to grasp the real-time status of bills. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the bill transaction data synchronization method provided in the above embodiments, and will not be elaborated upon here.

[0147] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the bill transaction data synchronization method described above.

[0148] The computer program product provided in this application can solve the technical problem that the inability of enterprises to grasp the status of invoices in real time is caused by the failure to synchronize cross-platform invoice transaction data in a timely and consistent manner. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the invoice transaction data synchronization method provided in the above embodiments, and will not be repeated here.

[0149] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for synchronizing bill transaction data, characterized in that, The method includes: Obtain account information and invoice information data; Based on the account information, determine the bill transaction data to be synchronized from the bill information data; The transaction data of the bills to be synchronized is processed to obtain processed transaction data; The processed transaction data is synchronized to the bill management system according to the preset business processing strategy to complete the bill transaction data synchronization.

2. The method as described in claim 1, characterized in that, The step of synchronizing the processed transaction data to the bill management system according to the preset business processing strategy to complete the bill transaction data synchronization includes: Based on the processed transaction data, determine the application-type business data and the withdrawal-type business data; The application-type business data and the withdrawal-type business data are processed according to the preset business processing strategy to obtain the processing results, and the processing results are synchronized to the bill management system to complete the synchronization of bill transaction data.

3. The method as described in claim 2, characterized in that, The steps of processing the application-type business data and the withdrawal-type business data according to the preset business processing strategy, obtaining the processing results, and synchronizing the processing results to the bill management system to complete the bill transaction data synchronization include: The transaction push time information of the application-type business data is determined according to the preset business processing strategy; The application data is sorted according to the transaction push time information to obtain sorted application data; Based on the bill number data, bill range data, bill type data, and bill holder account data of the sorting application data, determine whether there are any processable bills in the sorting application data; When the processable invoice exists in the sorting application data, the information of the processable invoice is updated according to the sorting application data to obtain the updated invoice information; The processing result is obtained based on the transaction information of the updated bill information and the sorting application data, and the processing result is synchronized to the bill management system to complete the synchronization of bill transaction data.

4. The method as described in claim 2, characterized in that, The steps for processing the application-type business data and the withdrawal-type business data according to the preset business processing strategy, obtaining the processing results, and synchronizing the processing results to the bill management system to complete the bill transaction data synchronization include: Determine whether there is any pending invoice information in the retrieved business data according to the preset business processing strategy; When the pending invoice information exists in the repossession business data, the pending invoice information is updated according to the repossession business data; If the pending bill information is not present in the withdrawal business data, transaction information is created based on the withdrawal business data; The processing result is determined based on the transaction information or the updated bill information to be synchronized, and the processing result is synchronized to the bill management system to complete the synchronization of bill transaction data.

5. The method as described in claim 1, characterized in that, The step of processing the transaction data of the bills to be synchronized to obtain processed transaction data includes: Acquire user mapping relationships and historical bill transaction information data, wherein the user mapping relationships include user mapping relationships between bank system users and bill management system users; The target enterprise's online banking number is determined based on the user mapping relationship; The target bill transaction information data is determined from the bill transaction data to be synchronized based on the target enterprise's online banking number. The transaction data to be processed is determined based on the historical bill transaction information data and the target bill transaction information data.

6. The method as described in claim 5, characterized in that, The step of determining the processed transaction data based on the historical bill transaction information data and the target bill transaction information data includes: Determine whether there is duplicate data in the target bill transaction information data based on the historical bill transaction information data; When duplicate data exists in the target bill transaction information data, the duplicate data is deleted to obtain the processed transaction data; If there is no duplicate data in the target bill transaction information data, the target bill transaction information data shall be used as the processing transaction data.

7. The method as described in claim 5, characterized in that, After the step of determining the target bill transaction information data in the bill transaction data to be synchronized based on the target enterprise's online banking number, the method further includes: The target bill transaction information data is distributed to obtain the data distribution result; When the data distribution result is successful, the distribution and synchronization of the processed transaction data are completed. When the data distribution result is distribution failure, the target bill transaction information data is distributed according to the preset asynchronous push task to complete the distribution synchronization of the processed transaction data.

8. The method as described in claim 1, characterized in that, The step of determining the bill transaction data to be synchronized from the bill information data based on the account information includes: Determine the source identifier of the invoice information data; The current system transaction data is determined based on the source identifier; The current system transaction data is deleted from the bill information data to obtain the transaction data to be processed; The pending transaction data is filtered based on the account information to obtain the bill transaction data to be synchronized.

9. A device for synchronizing bill transaction data, characterized in that, The device includes: The data acquisition module is used to acquire account information and invoice information data; The data determination module is used to determine the bill transaction data to be synchronized from the bill information data based on the account information; The data processing module is used to process the transaction data of the bills to be synchronized to obtain processed transaction data; The data synchronization module is used to synchronize the processed transaction data to the bill management system according to the preset business processing strategy, so as to complete the bill transaction data synchronization.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the bill transaction data synchronization method as described in any one of claims 1 to 8.

Images