Traceable charging method, device, system, electronic device and storage medium
By introducing two data sources and an asynchronous billing thread into the billing system, the problem of inaccurate billing caused by unbilled transactions was solved, enabling accurate traceability billing for each transaction and improving billing efficiency and reconciliation service experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NETSUNION CLEARING CORP
- Filing Date
- 2021-09-22
- Publication Date
- 2026-08-04
AI Technical Summary
In existing technologies, the failure to calculate fees in real time during the transaction process leads to inaccurate fee calculations, affecting the accuracy of the calculations. Furthermore, big data systems are inefficient when reading historical transaction data.
The architecture employs two data sources. Unbilled historical transaction data is sent from the first data source to the second data source, and an asynchronous billing thread is used to bill each transaction separately. Finally, the results are aggregated to achieve accurate traceability and billing.
It improves the accuracy and efficiency of retrospective billing, ensures that the results are consistent with real-time billing, and enhances the reconciliation service experience for trading institutions.
Smart Images
Figure CN115907974B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of online transactions, and in particular to traceability billing methods, devices, systems, electronic devices, and storage media. Background Technology
[0002] As an intermediary, the clearing platform can connect with multiple trading institutions, providing them with services such as transfer and clearing, and charging a certain fee as agreed. When a trading institution connects to the clearing platform, there may be situations where fees cannot be billed in real time during the normal operation of a transaction, thus requiring retroactive billing for unbilled transactions.
[0003] In related technologies, the total amount of all unbilled transactions is often calculated first, and then the transaction fees are calculated based on the total amount. This method is not accurate and affects the accuracy of billing. Summary of the Invention
[0004] This application provides a traceability billing method, apparatus, system, electronic device, and storage medium to more accurately trace and bill transaction fees, etc.
[0005] The embodiments of this application adopt the following technical solutions:
[0006] In a first aspect, embodiments of this application provide a retrospective billing method, executed by a billing server, comprising: sending application information for first transaction data to a first data source, so that the first data source sends the first transaction data to a second data source; the first transaction data is historical transaction data that has not been billed; obtaining multiple second transaction data for retrospective billing from the transaction data stored in the second data source; billing the multiple second transaction data separately to obtain retrospective billing sub-results corresponding to each second transaction data; and summarizing the retrospective billing sub-results to obtain a retrospective billing result.
[0007] In some embodiments, the retrospective billing method further includes: receiving notification information sent by a first data source, the notification information indicating that the first data source has completed the sending operation of the first transaction data; obtaining multiple second transaction data for retrospective billing from the transaction data stored in the second data source includes: sending a retrospective billing request to the second data source according to the notification information, and receiving multiple second transaction data that match the retrospective billing request returned by the second data source.
[0008] In some embodiments, the transaction data sent from the first data source to the second data source is carried by a transaction file; the retrospective billing request includes historical transaction information, which includes one or more of the following: transaction batch identifier, transaction institution identifier, and transaction time; receiving multiple second transaction data records that match the retrospective billing request returned by the second data source includes: receiving a target transaction file returned by the second data source, wherein the target transaction file records the second transaction data that match the historical transaction information.
[0009] In some embodiments, the notification information includes first indication information, which represents the portion of the first transaction data that has been successfully sent to the second data source. Sending a retrospective billing request to the second data source according to the notification information includes: finding the intersection of the second indication information and the first indication information to obtain third indication information corresponding to the second transaction data. The second indication information represents all transaction data required for this retrospective billing. A retrospective billing request is generated according to the third indication information, and the generated retrospective billing request is sent to the second data source.
[0010] In some embodiments, the retrospective billing method further includes: determining, based on third instruction information, the transaction data to which the next request information sent to the first data source is targeted.
[0011] In some embodiments, the notification information includes the storage address of the transaction data in the second data source; sending a retrospective billing request to the second data source according to the notification information includes: generating a transaction data download request corresponding to the storage address as a retrospective billing request; and sending the transaction data download request to the second data source.
[0012] In some embodiments, billing multiple second transaction data separately to obtain traceable billing sub-results corresponding to each second transaction data includes: enabling a first preset number of asynchronous billing threads; enabling each asynchronous billing thread to obtain a second preset number of second transaction data, and billing the obtained second preset number of second transaction data one by one.
[0013] In some embodiments, billing is performed on a per-transaction basis for the second preset number of second transaction data, including: obtaining a billing rule corresponding to the transaction institution identifier in the second transaction data, and using the obtained billing rule to bill the corresponding second transaction data.
[0014] In some embodiments, summarizing the various retrospective billing sub-results to obtain the retrospective billing result includes: netting and summarizing the various retrospective billing sub-results based on one or more of the following: transaction batch, transaction institution, and transaction time, to obtain the retrospective billing result.
[0015] In some embodiments, the first data source is a big data storage system that uses mapping-representation for data reading and writing; the second data source is a distributed file system, and the data interaction between the billing server and the distributed file system is implemented based on the secure file transfer protocol SFTP.
[0016] In some embodiments, the retrospective billing method further includes: saving each retrospective billing sub-result to a billing detail file; and uploading the billing detail file to a second data source so that the billing detail file can be accessed by the transaction institution.
[0017] Secondly, embodiments of this application also provide a traceability billing device, applied to a billing server, for implementing any of the traceability billing methods described above.
[0018] In some embodiments, the retrospective billing device includes: an application unit, configured to send application information for first transaction data to a first data source, so that the first data source sends the first transaction data to a second data source; the first transaction data is unbilled historical transaction data; a transaction data acquisition unit, configured to acquire multiple second transaction data for retrospective billing from the transaction data stored in the second data source; a billing unit, configured to bill the multiple second transaction data separately to obtain retrospective billing sub-results corresponding to each second transaction data; and a summarization unit, configured to summarize the retrospective billing sub-results to obtain a retrospective billing result.
[0019] In some embodiments, the application unit is further configured to receive notification information sent by the first data source, the notification information indicating that the first data source has completed the sending operation of the first transaction data; the transaction data acquisition unit is configured to send a retrospective billing request to the second data source according to the notification information, and receive multiple second transaction data records returned by the second data source that match the retrospective billing request.
[0020] In some embodiments, the transaction data sent from the first data source to the second data source is carried by a transaction file; the retrospective billing request includes historical transaction information, which includes one or more of the following: transaction batch identifier, transaction institution identifier, and transaction time; the transaction data acquisition unit is used to receive the target transaction file returned by the second data source, which records the second transaction data that matches the historical transaction information.
[0021] In some embodiments, the notification information includes first indication information, which represents the portion of the first transaction data that has been successfully sent to the second data source; the transaction data acquisition unit is used to find the intersection of the second indication information and the first indication information to obtain third indication information corresponding to the second transaction data; the second indication information represents all transaction data required for this retrospective billing; a retrospective billing request is generated based on the third indication information, and the generated retrospective billing request is sent to the second data source.
[0022] In some embodiments, the application unit is further configured to determine, based on third instruction information, the transaction data to which the next application information to be sent to the first data source is targeted.
[0023] In some embodiments, the notification information includes the storage address of the transaction data in the second data source; the transaction data acquisition unit is used to generate a transaction data download request corresponding to the storage address as a retrospective billing request; and to send the transaction data download request to the second data source.
[0024] In some embodiments, the billing unit is used to enable a first preset number of asynchronous billing threads; and to enable each asynchronous billing thread to obtain a second preset number of second transaction data, and to bill the obtained second preset number of second transaction data on a transaction-by-transaction basis.
[0025] In some embodiments, the billing unit is configured to obtain billing rules corresponding to the transaction institution identifier in the second transaction data, and to bill the corresponding second transaction data using the obtained billing rules.
[0026] In some embodiments, the aggregation unit is used to net and aggregate the results of each retrospective billing sub-result based on one or more of the following: transaction batch, transaction institution, and transaction time, to obtain the retrospective billing result.
[0027] In some embodiments, the first data source is a big data storage system that uses mapping-representation for data reading and writing; the second data source is a distributed file system, and the data interaction between the billing server and the distributed file system is implemented based on the secure file transfer protocol SFTP.
[0028] In some embodiments, the aggregation unit is further configured to save each traceable billing sub-result to a billing detail file; and upload the billing detail file to a second data source so that the billing detail file can be accessed by the transaction institution.
[0029] Thirdly, embodiments of this application also provide a traceability billing system, including a first data source, a second data source, and a billing server deployed with the traceability billing device described above; the first data source is used to respond to the application information sent by the billing server and send the transaction data targeted by the application information to the second data source; the second data source is used to receive and store the transaction data sent by the first data source, and send multiple transaction data for traceability billing to the billing server.
[0030] Fourthly, embodiments of this application also provide an electronic device, including: a processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the retroactive billing method as described above.
[0031] Fifthly, embodiments of this application also provide a computer-readable storage medium storing one or more programs, which, when executed by an electronic device including multiple applications, cause the electronic device to perform the retroactive billing method as described above.
[0032] The above-mentioned at least one technical solution adopted in the embodiments of this application can achieve the following beneficial effects: it realizes the reasonable storage and reading of large-volume historical transaction data by using two data sources. When retrospectively billing, it no longer calculates the total amount of historical transaction data, but bills each historical transaction separately and then summarizes the results. This makes the retrospective billing result come from each historical transaction data traced back, with finer granularity, which can be consistent with the real-time billing caliber. It also facilitates subsequent reconciliation by transaction institutions and improves the reconciliation service experience of transaction institutions. Attached Figure Description
[0033] 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:
[0034] Figure 1 This is a flowchart illustrating a retrospective billing method in an embodiment of this application;
[0035] Figure 2 This is a schematic diagram of the structure of a traceability billing device in an embodiment of this application;
[0036] Figure 3 This is a schematic diagram of the structure of a traceability billing system according to an embodiment of this application;
[0037] Figure 4 The diagram shown illustrates a retrospective billing process according to one embodiment of this application;
[0038] Figure 5This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0039] 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.
[0040] In existing technology, when retrospectively calculating fees, the total fee is obtained by multiplying the total amount of historical transaction data by the fee rate. When it is necessary to reconcile the fee of a certain transaction, the transaction amount of that transaction is divided by the total transaction amount to obtain a percentage value, and then the percentage value is multiplied by the fee rate to obtain the fee of that transaction.
[0041] However, since the percentage value is usually an approximation, multiplying it by the commission rate may result in a value that deviates from the actual commission for the transaction, making it difficult to be accurate to the millisecond, which can lead to reconciliation failure.
[0042] Therefore, the inventors conceived of a way to avoid this problem: calculating the transaction fee for each transaction by multiplying the original transaction amount by the fee rate. However, a new problem arose: the volume of historical transaction data is enormous, and directly accessing the transaction database would impact real-time trading.
[0043] However, if you access a big data storage system that stores transaction data, the problem is that if you read all the historical transaction data that needs to be traced and billed at once, the computational resources required are huge and the efficiency is low. If you read it in multiple times, you need to read the big data system multiple times. The characteristic of big data systems is that the time consumed is almost the same regardless of the amount of data read. This means that reading in multiple times will occupy too much big data system resources and is also inefficient.
[0044] In summary, the inventors conceived of using an intermediary data source to solve this problem and improve the overall efficiency of traceability and billing.
[0045] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.
[0046] Figure 1 This is a flowchart illustrating a retrospective billing method according to an embodiment of this application. Figure 1 As shown, the retrospective billing method includes:
[0047] Step S110: Send an application message for the first transaction data to the first data source so that the first data source can send the first transaction data to the second data source.
[0048] The first set of transaction data consists of unbilled historical transaction data. In this step, the first data source can retrieve all unbilled historical transaction data for subsequent retrospective billing. Alternatively, the first data source can distribute unbilled historical transaction data tailored to specific needs, such as transaction time, transaction institution, or transaction batch.
[0049] Due to network jitter and other factors between the first and second data sources, the first data source may not be able to send all of the first transaction data to the second data source as expected during the distribution of the first transaction data. Therefore, the data that is actually successfully distributed may be at least a portion of the first transaction data.
[0050] Step S120: Obtain multiple second transaction data entries used for retrospective billing from the transaction data stored in the second data source. In this step, only a portion of the multiple second transaction data entries used for retrospective billing can be read as needed, avoiding excessive data volume read at once, which would consume too many resources and affect efficiency.
[0051] It is understood that the first transaction data sent from the first data source to the second data source, and the second transaction data obtained from the second data source for retrospective billing, are both historical transaction data that has not been billed, such as historical transactions for which no fees have been calculated. The requested first transaction data and the obtained second transaction data can be the same or different. For example, one can first request historical transaction data that has not been billed for a quarter to be sent to the second data source, and then retrieve one month's worth of historical transaction data from the second data source multiple times for retrospective billing.
[0052] Step S130 involves billing multiple second transaction data entries separately, obtaining traceable billing sub-results corresponding to each second transaction data entry. This allows for more precise per-transaction billing, with the traceable billing sub-result for each second transaction data entry accurate to the millisecond.
[0053] Step S140: Summarize the results of each traceability billing sub-result to obtain the traceability billing result.
[0054] visible, Figure 1The method shown utilizes two data sources to achieve reasonable storage and retrieval of large volumes of historical transaction data. When retrospectively billing, it no longer calculates the total amount of historical transaction data, but bills each historical transaction separately and then summarizes the results. This ensures that the retrospective billing results come from each traced historical transaction, resulting in finer granularity. This aligns with the real-time billing standard and facilitates reconciliation for trading institutions, thus improving their reconciliation service experience.
[0055] In some embodiments, the retrospective billing method further includes: receiving notification information sent by a first data source, the notification information indicating that the first data source has completed the sending operation of the first transaction data; obtaining multiple second transaction data for retrospective billing from the transaction data stored in the second data source includes: sending a retrospective billing request to the second data source according to the notification information, and receiving multiple second transaction data that match the retrospective billing request returned by the second data source.
[0056] It should be noted that the completion of the first data source's transmission of the first transaction data does not equate to the first data source having transmitted all of the first transaction data to the second data source. For example, the notification information may also include information on which first transaction data that should have been sent to the second data source failed to be successfully transmitted, so that a new request can be made to the first data source. That is, in some embodiments, the missing first transaction data can be identified based on the notification information, and a transaction data request information corresponding to the missing first transaction data can be sent to the first data source.
[0057] Of course, in addition to recording negative information, such as which first transaction data failed to be sent successfully, the notification information can also record positive information, such as which first transaction data has been sent successfully, in some embodiments.
[0058] In summary, once the notification is received, it can be confirmed that the first transaction data (or at least part of it) has been successfully applied for, and the second transaction data can be obtained from the second data source to continue billing.
[0059] In some embodiments, the transaction data sent from the first data source to the second data source is carried by a transaction file; the retrospective billing request includes historical transaction information, which includes one or more of the following: transaction batch identifier, transaction institution identifier, and transaction time; receiving multiple second transaction data records that match the retrospective billing request returned by the second data source includes: receiving a target transaction file returned by the second data source, wherein the target transaction file records the second transaction data that match the historical transaction information.
[0060] For example, the first data source can generate multiple transaction files according to dimensions such as transaction time, transaction institution, and transaction batch, forming a transaction file set. Specifically, this could be a compressed package containing multiple transaction files, which is then sent to the second data source. The second data source can categorize and save the transaction files, and then, based on the received retrospective billing request, select the transaction files that match the historical transaction information in the retrospective billing request and send them out. Thus, this achieves flexible, convenient, and well-organized transmission of transaction data.
[0061] In some embodiments, the notification information includes first indication information, which represents the portion of the first transaction data that has been successfully sent to the second data source. Sending a retrospective billing request to the second data source according to the notification information includes: finding the intersection of the second indication information and the first indication information to obtain third indication information corresponding to the second transaction data. The second indication information represents all transaction data required for this retrospective billing. A retrospective billing request is generated according to the third indication information, and the generated retrospective billing request is sent to the second data source.
[0062] For example, the first instruction indicates that transaction data A1 to A9000 has been sent to the second data source; while the second instruction indicates that the transaction data required for this retrospective billing is A8500 to A9500. Therefore, the third instruction should indicate that the actual transaction data requested from the second data source is A8500 to A9000, and based on this, a retrospective billing request is generated.
[0063] In some embodiments, the tracing method further includes: determining, based on third instruction information, the transaction data targeted by the next request information sent to the first data source. For example, the next request may be for transaction data A9001 to A9500, or A9001 to AN (N>9500).
[0064] In some embodiments, the notification information includes the storage address of the transaction data in the second data source; sending a retrospective billing request to the second data source according to the notification information includes: generating a transaction data download request corresponding to the storage address as a retrospective billing request; and sending the transaction data download request to the second data source.
[0065] For example, the second data source can save unbilled historical transaction data according to preset storage rules. For instance, if the unbilled historical transaction data of transaction institution A and transaction batch a are stored under the path xxx (IP address)\Transaction institution A\Transaction batch a, then the accessible storage address corresponding to this path can be included in the notification information so that the storage address can be directly accessed for download.
[0066] The first data source can determine the storage address of unbilled historical transaction data in the second data source based on preset storage rules, or the second data source can inform the storage address of unbilled historical transaction data in the second data source.
[0067] In some embodiments, billing multiple second transaction data separately to obtain traceable billing sub-results corresponding to each second transaction data includes: enabling a first preset number of asynchronous billing threads; enabling each asynchronous billing thread to obtain a second preset number of second transaction data, and billing the obtained second preset number of second transaction data one by one.
[0068] Therefore, multi-threading technology can significantly improve the efficiency of traceability billing and the utilization of computing resources.
[0069] For example, given 100,000 second transaction records, 10 asynchronous billing threads are started, with each thread retrieving 10,000 second transaction records. The required second transaction records for each asynchronous billing thread can be pre-defined, or the asynchronous billing thread can select any unused second transaction record after completing the current billing's historical transaction data, and so on.
[0070] In some embodiments, billing is performed on a per-transaction basis for the second preset number of second transaction data, including: obtaining a billing rule corresponding to the transaction institution identifier in the second transaction data, and using the obtained billing rule to bill the corresponding second transaction data.
[0071] In practical applications, different trading institutions may have different billing rules. Therefore, during the retrospective billing process, it is necessary to read the corresponding billing rules based on the trading institution identifier in the second transaction data. Specifically, multiple asynchronous billing threads can each correspond to one trading institution. If the amount of second transaction data of a trading institution is very large, multiple asynchronous billing threads can also be enabled for that trading institution.
[0072] In some embodiments, the retrospective billing method involves summarizing the various retrospective billing sub-results to obtain the retrospective billing result. This includes netting and summarizing the various retrospective billing sub-results based on one or more of the following: transaction batch, transaction institution, and transaction time. For example, transaction batch summarization, daily summarization, or monthly summarization can be performed based on the transaction start time and transaction end time to complete the cumulative summation of historical transaction fees.
[0073] In some embodiments, in the retrospective billing method, the first data source is a big data storage system that uses MapReduce for data reading and writing. MapReduce, also known as MR, is a commonly used processing technique in big data systems. MR has the following characteristics: the time to obtain the result is not closely related to the amount of target data. For example, the time it takes for the first data source to generate transaction files corresponding to 100,000 transaction data points is not significantly different from the time it takes to generate transaction files corresponding to 10,000 transaction data points. Therefore, for this type of big data storage system, all unbilled transaction data can be sent to the second data source in a single application to maximize efficiency.
[0074] In some embodiments, the retrospective billing method further includes: saving each retrospective billing sub-result to a billing detail file; and uploading the billing detail file to a second data source so that the billing detail file can be accessed by the transaction institution.
[0075] Therefore, trading institutions can download billing details files from the second data source as needed and perform detailed reconciliation themselves. Since the billing details files save the results of each traceable billing sub-result, they can be compared one by one with the data of each transaction recorded in the trading institution's internal records, thus improving the reconciliation experience.
[0076] In some embodiments, in the retrospective billing method, the second data source is a distributed file system, and the data interaction between the billing server and the distributed file system is implemented based on the secure file transfer protocol SFTP. Specifically, the second data source can be implemented using technologies such as Dubbo, SFTP, and MySQL. For example, historical transaction data is stored using a MySQL database, the access interface and specific services of the billing server are implemented through Dubbo, and SFTP is used to ensure the reliability of data interaction.
[0077] Specifically, the second data source can use a distributed file system such as Google File System (GFS) and set up an SFTP server to mount transaction files that can be accessed by the billing server.
[0078] Embodiments of this application also provide a traceability billing device, applied in a billing server, for implementing the traceability billing method as described above.
[0079] Specifically, Figure 2 A schematic diagram of a traceability billing device according to an embodiment of this application is shown. Figure 2 As shown, the traceability billing device 200 includes:
[0080] Application unit 210 is used to send application information for the first transaction data to the first data source, so that the first data source sends the first transaction data to the second data source; the first transaction data is historical transaction data that has not been billed.
[0081] The transaction data acquisition unit 220 is used to acquire multiple second transaction data for retrospective billing from the transaction data stored in the second data source; the billing unit 230 is used to bill the multiple second transaction data separately to obtain the retrospective billing sub-results corresponding to each second transaction data; the aggregation unit 240 is used to aggregate the retrospective billing sub-results to obtain the retrospective billing result.
[0082] In some embodiments, the application unit 210 is further configured to receive notification information sent by the first data source, the notification information indicating that the first data source has completed the sending operation of the first transaction data; the transaction data acquisition unit 220 is configured to send a retrospective billing request to the second data source according to the notification information, and receive multiple second transaction data that match the retrospective billing request returned by the second data source.
[0083] In some embodiments, the transaction data sent from the first data source to the second data source is carried by a transaction file; the retrospective billing request includes historical transaction information, which includes one or more of the following: transaction batch identifier, transaction institution identifier, and transaction time; the transaction data acquisition unit 220 is used to receive the target transaction file returned by the second data source, which records the second transaction data that matches the historical transaction information.
[0084] In some embodiments, the notification information includes first indication information, which represents the portion of the first transaction data that has been successfully sent to the second data source; the transaction data acquisition unit 220 is used to find the intersection of the second indication information and the first indication information to obtain third indication information corresponding to the second transaction data; the second indication information represents all transaction data required for this retrospective billing; a retrospective billing request is generated according to the third indication information, and the generated retrospective billing request is sent to the second data source.
[0085] In some embodiments, the application unit 210 is further configured to determine, based on third instruction information, the transaction data to which the next application information sent to the first data source is targeted.
[0086] In some embodiments, the notification information includes the storage address of the transaction data in the second data source; the transaction data acquisition unit 220 is used to generate a transaction data download request corresponding to the storage address as a retrospective billing request; and send the transaction data download request to the second data source.
[0087] In some embodiments, the billing unit 230 is configured to enable a first preset number of asynchronous billing threads; and to enable each asynchronous billing thread to acquire a second preset number of second transaction data, and to bill the acquired second preset number of second transaction data on a transaction-by-transaction basis.
[0088] In some embodiments, the billing unit 230 is configured to obtain a billing rule corresponding to the transaction institution identifier in the second transaction data, and to bill the corresponding second transaction data using the obtained billing rule.
[0089] In some embodiments, the aggregation unit 240 is used to net and aggregate the results of each retrospective billing sub-result based on one or more of the following: transaction batch, transaction institution, and transaction time, to obtain the retrospective billing result.
[0090] In some embodiments, the first data source is a big data storage system that uses mapping-representation for data reading and writing; the second data source is a distributed file system, and the data interaction between the billing server and the distributed file system is implemented based on the secure file transfer protocol SFTP.
[0091] In some embodiments, the aggregation unit 240 is further configured to save each traceable billing sub-result to a billing detail file; and upload the billing detail file to a second data source so that the billing detail file can be accessed by the transaction institution.
[0092] It is understood that the above-mentioned traceability billing device can implement each step of the traceability billing method executed by the billing server in the foregoing embodiments. The relevant explanations of the traceability billing method are applicable to the traceability billing device and will not be repeated here.
[0093] Figure 3 A schematic diagram of the structure of a retrospective billing system according to an embodiment of this application is shown. Figure 3 As shown, the retrospective billing system includes a first data source 310, a second data source 320, and a billing server 330 equipped with the retrospective billing device 200 as described above. The first data source 310 is used to respond to the application information sent by the billing server 330 and send the transaction data targeted by the application information to the second data source 320. The second data source 320 is used to receive and store the transaction data sent by the first data source 310, and to send multiple transaction data for retrospective billing to the billing server 330.
[0094] The following is combined Figure 4 The following is an illustration of a retrospective billing process according to an embodiment of this application.
[0095] First, the billing server confirms the traceability billing task locally, and can perform preprocessing such as parameter verification. Then, it sends transaction data request information to the big data storage system (the first data source). The transaction data request information may include the transaction start time, transaction end time, transaction institution identifier, etc.
[0096] After receiving a transaction data request, the big data storage system verifies the request and generates a corresponding request message, then notifies the billing server that the request has been accepted. The big data storage system consumes this request message, generates transaction files according to transaction batches, packages the transaction files into a transaction file set, sends it to GFS (the second data source), and sends a notification message to the billing server informing them of the request result.
[0097] After GFS decompresses the received transaction file set, it mounts the transaction files to the SFTP server and grants them access permissions that can be accessed by the billing server.
[0098] Upon receiving the notification, the billing server updates the application results, determines which historical transaction data has been sent to GFS, and then downloads the transaction files from the SFTP server based on the transaction batch identifier, transaction institution identifier, etc. Based on the downloaded transaction files, it invokes the asynchronous billing thread to perform traced billing for each transaction, obtaining traced billing sub-results for each historical transaction. These sub-results are saved to a billing details file, which is then uploaded to the SFTP server. The billing server also summarizes the traced billing sub-results to obtain the traced billing result, and performs further archiving, analysis, and other follow-up processing as needed by business requirements.
[0099] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Please refer to it. Figure 5 At 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.
[0100] 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. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 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.
[0101] 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.
[0102] The processor reads the corresponding computer program from non-volatile memory into main memory and then executes it, forming a traceability billing device at the logical level. The processor executes the program stored in memory and specifically performs the following operations:
[0103] Send an application for the first transaction data to the first data source so that the first data source sends the first transaction data to the second data source; the first transaction data is historical transaction data that has not been billed; obtain multiple second transaction data for retrospective billing from the transaction data stored in the second data source; bill the multiple second transaction data separately to obtain retrospective billing sub-results corresponding to each second transaction data; summarize the retrospective billing sub-results to obtain the retrospective billing result.
[0104] The above is as stated in this application. Figure 1The method executed by the traceability billing device disclosed in the illustrated embodiment 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.
[0105] The electronic device can also perform Figure 1 The method for implementing the traceability billing device, and the realization of the traceability billing device in... Figure 2 The functions of the embodiments shown are not described in detail here.
[0106] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform... Figure 1 The method executed by the traceability billing device in the illustrated embodiment is specifically used for the following:
[0107] Send an application for the first transaction data to the first data source so that the first data source sends the first transaction data to the second data source; the first transaction data is historical transaction data that has not been billed; obtain multiple second transaction data for retrospective billing from the transaction data stored in the second data source; bill the multiple second transaction data separately to obtain retrospective billing sub-results corresponding to each second transaction data; summarize the retrospective billing sub-results to obtain the retrospective billing result.
[0108] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0109] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0110] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0111] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0112] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0113] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0114] 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 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.
[0115] 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.
[0116] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0117] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A retrospective billing method, executed by a billing server, wherein, The method includes: Send an application for the first transaction data to the first data source, so that the first data source can send the first transaction data to the second data source; Obtain multiple second transaction records for retrospective billing from the transaction data stored in the second data source; Billing is performed separately on the multiple second transaction data to obtain traceable billing sub-results corresponding to each second transaction data; The results of each traceability billing sub-result are summarized to obtain the traceability billing result; Both the first transaction data and the second transaction data are historical transaction data that have not been charged, and the historical transaction data that has not been charged includes historical transaction data for which no transaction fees have been calculated; The method further includes: receiving notification information sent by the first data source, wherein the notification information indicates that the first data source has completed the sending operation of the first transaction data; The step of obtaining multiple second transaction data entries for retrospective billing from the transaction data stored in the second data source includes: According to the notification information, a retrospective billing request is sent to the second data source, and multiple second transaction data matching the retrospective billing request are received from the second data source. The separate billing of the multiple second transaction data includes: The transaction fee for each transaction is calculated by multiplying the original transaction amount by the transaction fee rate. The notification information includes a first indication, which indicates that a portion of the first transaction data has been successfully sent to the second data source. Sending a retrospective billing request to the second data source based on the notification information includes: The intersection of the second indication information and the first indication information is obtained to obtain the third indication information corresponding to the second transaction data; the second indication information represents: all transaction data required for this retrospective billing. Generate the traceability billing request based on the third instruction information, and send the generated traceability billing request to the second data source; The method further includes: Based on the third instruction information, determine the transaction data to which the next request information sent to the first data source will target.
2. The method as described in claim 1, wherein, The transaction data sent from the first data source to the second data source uses transaction files as the data carrier; The retrospective billing request includes historical transaction information, which includes one or more of the following: transaction batch identifier, transaction institution identifier, and transaction time. The step of receiving multiple second transaction data records that match the retrospective billing request returned by the second data source includes: receiving a target transaction file returned by the second data source, wherein the target transaction file records second transaction data that match the historical transaction information.
3. The method as described in claim 1, wherein, The notification information includes the storage address of the transaction data in the second data source; Sending a retrospective billing request to the second data source based on the notification information includes: Generate a transaction data download request corresponding to the storage address, which serves as the traceability billing request; Send the transaction data download request to the second data source.
4. The method of claim 1, wherein, The step of separately billing the multiple second transaction data to obtain the traceable billing sub-result corresponding to each second transaction data includes: Enable the first preset number of asynchronous billing threads; Each asynchronous billing thread acquires a second preset number of second transaction data, and bills each of the acquired second preset number of second transaction data individually.
5. The method of claim 4, wherein, The step of billing each transaction of the second preset quantity of second transaction data includes: Obtain the billing rules corresponding to the transaction institution identifier in the second transaction data, and use the obtained billing rules to bill the corresponding second transaction data.
6. The method of claim 1, wherein, The process of summarizing the results of each traceability billing sub-result to obtain the traceability billing result includes: Based on one or more of the following factors—transaction batch, transaction institution, and transaction time—the results of each retrospective billing sub-result are netted and summarized to obtain the retrospective billing result.
7. The method of claim 1, wherein, The first data source is a big data storage system that uses mapping-reduction for data reading and writing; The second data source is a distributed file system, and the data interaction between the billing server and the distributed file system is implemented based on the secure file transfer protocol SFTP.
8. The method as described in any one of claims 1 to 7, wherein, The method further includes: Save each traceable billing sub-result to the billing details file; The billing details file is uploaded to the second data source so that the billing details file can be accessed by the transaction institution.
9. A traceability billing device, applied to a billing server, wherein, The traceability billing device is used to implement the traceability billing method according to any one of claims 1 to 8.
10. A traceability billing system, comprising a first data source, a second data source, and a billing server deployed with the traceability billing device as described in claim 9; The first data source is used to respond to the application information sent by the billing server and send the transaction data targeted by the application information to the second data source; The second data source is used to receive and store transaction data sent by the first data source, and to send multiple transaction data for retrospective billing to the billing server.
11. An electronic device, comprising: processor; as well as A memory configured to store computer-executable instructions, which, when executed, cause the processor to perform any of the retroactive billing methods of claims 1 to 8.
12. A computer-readable storage medium storing one or more programs, which, when executed by an electronic device including a plurality of applications, cause the electronic device to perform any of the retroactive billing methods of claims 1 to 8.