Call record reconciliation method and device, electronic equipment and computer storage medium

Abstract

The application relates to the technical field of communication services, and provides a bill reconciliation method and device, an electronic device and a computer storage medium, the method comprising the following steps: processing the traffic bills of a user obtained through a bill preprocessing program, and outputting the to-be-merged bills of the user; performing statistical storage on the to-be-merged bills through a statistical program, and obtaining pre-merging statistical data of the user; processing target merging bills meeting the traffic threshold and the time threshold of the user in the to-be-merged bills through a dynamic merging program, and outputting final merging bills; determining post-merging statistical data and a price list data of the user based on the final merging bills, and performing bill reconciliation based on a preset dimension in combination with the pre-merging statistical data, the final merging bills and the price list data. The bill reconciliation method provided in the application combines the traffic threshold, the time threshold and the preset dimension, realizes full-process auditing of the traffic bills, improves the accuracy of the audited merging bills and reduces the operation risk.

Description

Technical Field

[0001] This application relates to the field of communication service technology, and in particular to a call detail record (CDR) reconciliation method, apparatus, electronic device, and computer storage medium. Background Technology

[0002] With the increasing prevalence of data usage in the mobile communications industry, various apps on users' mobile devices are running in the background with minimal data usage, leading to a surge in the number of data-intensive call records (CDRs). Processing these numerous fragmented CDRs requires significant system resources, placing a growing burden on the system. The current method involves storing CDRs to be merged in a Redis cluster. When a certain amount of data usage is reached, multiple CDRs are merged into a single CDR, which is then used as the final CDR for batch pricing. However, the large number of fragmented CDRs on the network side can easily cause CDR accumulation during processing, leading to pricing delays, low accuracy in auditing merged CDRs, and increased operational risks. Summary of the Invention

[0003] This application provides a call detail record (CDR) reconciliation method, apparatus, electronic device, and computer storage medium, aiming to improve the accuracy of auditing consolidated CDRs and reduce operational risks.

[0004] Firstly, this application provides a method for reconciling call detail records (CDRs), including:

[0005] The obtained user traffic call records are processed by the call record preprocessing program, and the user's call records to be merged are output.

[0006] The statistical procedures are used to collect and store the call details to be merged, thereby obtaining the user's pre-merging statistical data.

[0007] The dynamic call detail record (CDR) merging program processes the target CDRs that meet the user's traffic threshold and time threshold, and outputs the final merged CDR.

[0008] Based on the final merged call detail records (CDRs), the user's post-merger statistical data and pricing list data are determined. CDR reconciliation is then performed based on preset dimensions, combining the pre-merger statistical data, the final merged CDRs, and the pricing list data.

[0009] In one embodiment, the target merged call detail records (CDRs) are processed by a dynamic merge procedure to output the final merged CDRs, including:

[0010] Identify the billing event call records in the target merged call records, and sort the billing event call records according to the Redis node number and key;

[0011] Determine the call detail record (CDR) labels for the sorted billing event CDRs, and merge the CDRs with the same CDR labels to obtain the sorted target billing event CDRs.

[0012] If the lock key-value pair of the sorted target billing event call detail record is the lock value pair of this process, then the sorted target billing event call detail record and the local billing event call detail record are determined as the final merged call detail record.

[0013] The process of reconciling call detail records (CDRs) based on preset dimensions, combined with the pre-merging statistical data, the final merged CDRs, and the approved pricing list data, includes:

[0014] The user's uplink and downlink traffic are statistically analyzed based on the time dimension to obtain the user's first statistical report data;

[0015] Call detail records (CDRs) are reconciled based on the data from the first statistical report, the statistical data before the call detail record merging, the final merged CDRs, and the approved pricing list data.

[0016] The process of reconciling call detail records (CDRs) based on preset dimensions, combined with the pre-merging statistical data, the final merged CDRs, and the approved pricing list data, includes:

[0017] The uplink and downlink traffic of the user are statistically analyzed based on the user information dimensions to obtain the user's second statistical report data;

[0018] Call detail records (CDRs) are reconciled based on the data from the second statistical report, combined with the statistical data before the merging, the final merged CDRs, and the approved pricing list data.

[0019] The statistical data and pricing list data for the user after merging the call detail records (CDRs) based on the final merged CDRs include:

[0020] The merged call detail records (CDRs) are statistically entered into the database through an input statistics program to obtain the merged statistical data for the user.

[0021] The final merged call detail records (CDRs) are processed through a pricing process to obtain the user's pricing list data.

[0022] After determining the sorted target billing event call detail records (CDRs) and local billing event CDRs as the final merged CDRs, the process further includes:

[0023] The final merged call detail records (CDRs) are submitted to a Redis transaction, and the CDR deduplication identifier with the Redis node number and keyword is deleted.

[0024] After determining the sorted target billing event call detail records (CDRs) and local billing event CDRs as the final merged CDRs, the process further includes:

[0025] Store the final merged call detail records to a backup directory file.

[0026] Secondly, this application provides a call detail record (CDR) reconciliation device comprising:

[0027] The first call detail record (CDR) processing module is used to process the acquired user traffic CDRs through a CDR preprocessing program and output the user's CDRs to be merged.

[0028] The statistical data entry module is used to statistically enter the call detail records to be merged into the database through a statistical program, so as to obtain the statistical data of the user before the merger.

[0029] The second call detail record (CDR) processing module is used to process the target CDRs that meet the user's traffic threshold and time threshold in the CDRs to be merged through a dynamic merge program, and output the final merged CDRs.

[0030] The call detail record (CDR) reconciliation module is used to determine the user's post-consolidation statistical data and pricing list data based on the final consolidated CDRs, and to perform CDR reconciliation based on preset dimensions by combining the pre-consolidation statistical data, the final consolidated CDRs, and the pricing list data.

[0031] Thirdly, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the call detail record reconciliation method described in the first aspect.

[0032] Fourthly, this application also provides a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium including a computer program, which, when executed by the processor, implements the call detail record reconciliation method described in the first aspect.

[0033] Fifthly, this application also provides a computer program product, which includes a computer program that, when executed by the processor, implements the call detail record reconciliation method described in the first aspect.

[0034] The call detail record (CDR) reconciliation method, device, electronic equipment, and computer storage medium provided in this application merge traffic-based CDRs during the CDR reconciliation process using traffic thresholds and time thresholds. Simultaneously, CDR reconciliation is performed based on preset dimensions combined with statistical data before merging, the final merged CDRs, and the pricing list data. This achieves full-process auditing of traffic-based CDRs, improves the accuracy of auditing merged CDRs, and reduces operational risks. Attached Figure Description

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

[0036] Figure 1 This is a flowchart illustrating the call detail record (CDR) reconciliation method provided in this application;

[0037] Figure 2 This is a schematic diagram of the call detail record (CDR) reconciliation device provided in this application;

[0038] Figure 3 This is a schematic diagram of the structure of the electronic device provided in 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 with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] Combination Figures 1 to 3 This application describes the call detail record (CDR) reconciliation method, apparatus, electronic device, and computer storage medium provided. Figure 1 This is a flowchart illustrating the call detail record (CDR) reconciliation method provided in this application; Figure 2 This is a schematic diagram of the call detail record (CDR) reconciliation device provided in this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in this application.

[0041] This application provides an embodiment of a call detail record (CDR) reconciliation method. It should be noted that although the logical order is shown in the flowchart, under certain data conditions, the steps shown or described may be completed in a different order than that shown here.

[0042] This application uses an electronic device as the execution subject for example, and the embodiment of this application uses a perception evaluation system as one of the manifestations of the electronic device, without limitation.

[0043] Reference Figure 1 , Figure 1 This is a flowchart illustrating the call detail record (CDR) reconciliation method provided in this application. The CDR reconciliation method provided in this embodiment includes:

[0044] Step S10: Process the obtained user's traffic call details using the call detail record preprocessing program, and output the user's call detail records to be merged.

[0045] Step S20: The call detail records to be merged are statistically processed and stored in the database using a statistical program to obtain the user's pre-merging statistical data.

[0046] It should be noted that, in this embodiment of the application, a judgment is added to the call detail record (CDR) processing flow. If the GPRS CDR itself meets the requirements (traffic size), it will be directly processed for billing. This traffic size can be configured. The average traffic capacity of each CDR for online traffic services is 4.3M. The default is to directly process offline CDRs that exceed 5M for billing, thereby reducing the risk of users exceeding the limit and owing money (according to the CDR data statistics, the number of CDRs exceeding 5M only accounts for 5% to 7%. This part of the CDRs is small, and the long waiting time for merging the CDRs is more noticeable to users who have exceeded the limit).

[0047] For the new call detail record (CDR) merging subsystem for small CDRs smaller than 5MB, differential rate conditions are used as the CDR merging conditions in the CDR preprocessing stage. The batch rate remains unchanged before and after merging. At the same time, the maximum traffic for merging is dynamically set by querying the free resources of the users to be queried. Through this technology, it is estimated that the total number of CDRs will decrease by 40% to 60% after merging.

[0048] Specifically, the call detail record (CDR) preprocessing program (ICB) acquires fragmented CDRs from users in real time and processes them to determine which fragmented CDRs need to be merged. Further, the ICB identifies these fragmented CDRs as the user's pending CDRs and outputs them to downstream storage for processing. Simultaneously, the ICB's statistical output includes, but is not limited to, user information, time, uplink traffic, and downlink traffic.

[0049] Furthermore, the downstream statistical program to be processed stores statistical data according to the user's call detail records to be merged, and stores the statistical files required for merging the call detail records into the database according to preset dimensions, so as to obtain the user's pre-merging statistical data. The pre-merging statistical data is the data to be audited later. The statistical files required for merging the call detail records can be understood as uplink traffic and downlink traffic. The preset dimensions include, but are not limited to, user information dimensions and time dimensions.

[0050] Therefore, it can be further understood as follows: the downstream pending storage statistical program, based on the user's pending call detail records (CDRs), statistically analyzes and stores the user's uplink and downlink traffic according to the user information dimension, obtaining the user's pre-consolidation statistical data. It can also be understood as follows: the downstream pending storage statistical program, based on the user's pending CDRs, statistically analyzes and stores the user's uplink and downlink traffic according to the time dimension, obtaining the user's pre-consolidation statistical data.

[0051] Step 30: The dynamic call detail record (CDR) merging program processes the target CDRs that meet the user's traffic threshold and time threshold, and outputs the final merged CDR.

[0052] Furthermore, before processing the call detail records to be merged, the dynamic call merging program needs to obtain the user's remaining free resources from the BDS user database, and set the traffic threshold and time threshold for the user's call merging based on the dynamic rules and the user's remaining free resources.

[0053] Furthermore, the dynamic call detail record (CDR) merging program analyzes the CDRs to be merged based on the user's traffic and time thresholds to identify target CDRs that meet both thresholds. In other words, it identifies CDRs with traffic values ​​exceeding the traffic threshold and / or time values ​​exceeding the time threshold as target CDRs. The dynamic CDR merging program then processes these target CDRs and outputs the final merged CDR.

[0054] Specifically, the billing event call records in the target merged call records are identified, and the billing event call records are sorted according to the Redis node number and key; the call record labels of the sorted billing event call records are identified, and billing event call records with the same call record label are merged to obtain the sorted target billing event call records; if the lock key-value pair of the sorted target billing event call records is the lock value pair of the local process, then the sorted target billing event call records and the local billing event call records are identified as the final merged call records and output to the downstream storage to be processed.

[0055] Specifically, the dynamic billing merging program obtains the target merged call detail records (CDRs) by supporting file locks and / or database row locks and / or RedisList task list file retrieval methods, and determines the billing event CDRs in the target merged CDRs. The billing event CDRs are configured through process input parameters. Furthermore, the dynamic billing merging program reads files one by one. In the case of an exception where the file cannot be found by filename, an error log is printed, the next file is processed, and the process exits otherwise.

[0056] Furthermore, the dynamic order merging program submits database read tasks, and the database transaction is treated as a single transaction for the entire storage file; in case of exceptions, an error log is printed and the process exits.

[0057] Furthermore, the dynamic billing event call detail records (CDRs) are sorted according to the Redis node number and the keyword. Specifically, the function is executed when the batch Redis OperMerge Event Count is not 1. The keyword fields can be configured with cdrMerge Fields, meaning that the keyword fields must start with subno, and other fields can be configured arbitrarily. Fields are separated by ^, and the fields correspond to the field attributes of the billing event CDRs.

[0058] Furthermore, the dynamic billing process submits billing event call detail records (CDRs) in batches while the process is active. Specifically, the amount of data for each batch of CDRs is determined by the batch RedisOperMerge Event Count (default is 1, -1 is stored in the file, other non-positive integers will cause the process to exit with an error). If the batch RedisOperMerge Event Count is greater than 1, it is necessary to ensure that data records do not cross Redis node numbers.

[0059] Furthermore, the dynamic order merging program obtains cache information by calling Redis via Lua scripts. For complex script processing logic, EVALSHA can be used to replace the script, avoiding the overhead of sending the Lua script each time. Additionally, for Redis connection failures, configurable retries (redis ConnectTryTimes) and sleep time (redis Connect TryWaitTime) are required. This can be provided as an array to retrieve information for multiple keys and perform locking (SETNX), where the lock key-value pair is `lock:key, myip:pidid`, and the lock expiration time is set (redis Lock ExpireTime). If locking fails, re-attempts are required, with configurable attempts (redis GetLockTryTimes) and sleep intervals (redis Get LockTryWaitTime). For multiple unsuccessful attempts, an error log is printed, the database transaction is rolled back, processing of the current storage file is abandoned, and processing of the next data storage file begins.

[0060] Furthermore, each billing event call detail record (CDR) corresponds to a unique CDR tag `flag*`. This can be understood as: performing cumulative calculations on cached and local billing event CDRs, determining and initializing whether an instantiated flag is needed. It's necessary to determine if a cached `flag*` exists in the billing event CDR; if so, it cannot be accumulated, tagged, and printed to the duplicate call log. Furthermore, it cannot be merged into the `cdrflag` flag of the billing event CDR. This can be further understood as: determining the CDR tags of the sorted billing event CDRs, and merging CDRs with the same tag to obtain the sorted target billing event CDR.

[0061] Furthermore, it supports providing data-based services. First, it checks if the lock's value matches the `myip:pidid` of the current process, i.e., whether the sorted target billing event call detail record's lock key-value pair matches the current process's lock value pair. If the sorted target billing event call detail record's lock key-value pair is not the current process's lock value pair, it returns to the dynamic merging program's cache retrieval step for reprocessing, attempting again for (redis UpdateTryTimes). If the sorted target billing event call detail record's lock key-value pair matches the current process's lock value pair, then the sorted target billing event call detail record and the local billing event call detail record are determined as the final merged call detail record. Further, the dynamic merging program commits the database transaction; in case of a commit exception, an error log is printed, and the program exits.

[0062] Furthermore, the dynamic order merging program migrates the processed data storage files to the backup directory. In case of submission errors, it prints an error log and exits. Additionally, when the dynamic order merging program commits a Redis transaction, it needs to delete the Redis call detail record (CDR) deduplication flags. This is done using the batch Redis OperatorClearCdrFlag Count (default is 1, -1 is for storage files, other non-positive integers will cause the process to exit with an error). Full deletion is configured to -1.

[0063] The approach used in this application is the Redis middleware. The program solves the problems of duplicate and missing orders in the combined order through various error-detection and deduplication mechanisms, thus achieving the requirement of accurate billing.

[0064] Step S40: Based on the final merged call detail records (CDRs), determine the user's post-merger statistical data and pricing list data, and perform CDR reconciliation based on a preset dimension, combining the pre-merger statistical data, the final merged CDRs, and the pricing list data.

[0065] Furthermore, the downstream pending storage determines the user's consolidated statistical data and pricing list data based on the user's final consolidated call detail records (CDRs). Specifically, the downstream pending storage's inbound statistical program performs statistical inbound processing based on the final consolidated CDRs and according to preset dimensions to obtain the user's consolidated statistical data. The preset dimensions can be user information and time dimensions. Therefore, it can be understood that the downstream pending storage's inbound statistical program performs statistical inbound processing on the user's uplink and downlink traffic based on the final consolidated CDRs and according to the user information dimension to obtain the user's consolidated statistical data. Alternatively, it can be understood that the downstream pending storage's inbound statistical program performs statistical inbound processing on the user's uplink and downlink traffic based on the final consolidated CDRs and according to the time dimension to obtain the user's consolidated statistical data.

[0066] Furthermore, the downstream pending-processing storage pricing program performs pricing on the final merged call detail records (CDRs) according to preset dimensions, obtaining the user's pricing list data. These preset dimensions can be user information and time dimensions. Therefore, it can be understood that the downstream pending-processing storage pricing program performs CDR pricing on the user's uplink and downlink traffic according to the final merged CDRs and user information dimensions, obtaining the user's pricing list data. Alternatively, it can be understood as the downstream pending-processing storage pricing program performing CDR pricing on the user's uplink and downlink traffic according to the time dimension, obtaining the user's pricing list data.

[0067] Furthermore, call detail record (CDR) reconciliation is performed by combining pre-consolidation statistical data, final consolidated CDRs, and pricing list data with preset dimensions. These preset dimensions can be time-based or user-information-based. This can be understood as: statistically analyzing user uplink and downlink traffic based on the time dimension to obtain the first statistical report data. Further, CDR reconciliation is performed based on the first statistical report data combined with pre-consolidation statistical data, final consolidated CDRs, and pricing list data.

[0068] Furthermore, based on user information dimensions, the user's uplink and downlink traffic are statistically analyzed to obtain the user's second statistical report data. Then, based on the second statistical report data, combined with the pre-merger statistical data, the final merged call detail records (CDRs), and the approved pricing list data, CDR reconciliation is performed.

[0069] The call detail record (CDR) reconciliation method provided in this application merges traffic-based CDRs using traffic and time thresholds during the reconciliation process. Simultaneously, it reconciles CDRs based on preset dimensions, combined with pre-merging statistical data, final merged CDRs, and pricing list data. This achieves full-process auditing of traffic-based CDRs, improving the accuracy of audited merged CDRs and reducing operational risks. Specifically, it can be understood as statistically analyzing CDR volume and uplink / downlink traffic at the entry, exit, and pricing stages of the fragmented traffic CDR merging process, based on time or user information dimensions. The output statistical results are then audited and reconciled through an audit process, achieving full-process auditing of fragmented traffic CDR merging, improving the accuracy of audited merged CDRs, reducing operational risks, further improving maintenance efficiency, and reducing overall system load. Furthermore, the CDR reconciliation method provided in this application significantly reduces the number of offline CDRs, accelerating CDR processing speed and preventing backlogs and delayed pricing due to excessive CDR volume. Furthermore, the CDR reconciliation method provided in this application greatly saves time in handling sudden requests for review. Furthermore, the call detail record (CDR) reconciliation method provided in this application embodiment does not result in an excessive number of traffic records being displayed on the front end during the query process, thus improving the user experience.

[0070] Furthermore, the call detail record (CDR) reconciliation device provided in this application will be described below. The CDR reconciliation device and the CDR reconciliation method can be referred to each other accordingly.

[0071] like Figure 2 As shown, Figure 2 This is a schematic diagram of the call detail record (CDR) reconciliation device provided in this application. The CDR reconciliation device includes:

[0072] The first call detail record (CDR) processing module 201 is used to process the acquired user traffic CDRs through a CDR preprocessing program and output the user's CDRs to be merged.

[0073] The statistical entry module 202 is used to statistically enter the call detail records to be merged into the database through a statistical program, so as to obtain the statistical data of the user before the merging of the call detail records;

[0074] The second call detail record (CDR) processing module 203 is used to process the target CDRs that meet the user's traffic threshold and time threshold in the CDRs to be merged through a dynamic merging program, and output the final merged CDRs.

[0075] The call detail record (CDR) reconciliation module 204 is used to determine the user's post-consolidation statistical data and pricing list data based on the final consolidated CDR, and to perform CDR reconciliation based on a preset dimension by combining the pre-consolidation statistical data, the final consolidated CDR, and the pricing list data.

[0076] Furthermore, the second call detail record (CDR) processing module 203 is also used for:

[0077] Identify the billing event call records in the target merged call records, and sort the billing event call records according to the Redis node number and key;

[0078] Determine the call detail record (CDR) labels for the sorted billing event CDRs, and merge the CDRs with the same CDR labels to obtain the sorted target billing event CDRs.

[0079] If the lock key-value pair of the sorted target billing event call detail record is the lock value pair of this process, then the sorted target billing event call detail record and the local billing event call detail record are determined as the final merged call detail record.

[0080] Furthermore, the call detail record (CDR) reconciliation module 204 is also used for:

[0081] The user's uplink and downlink traffic are statistically analyzed based on the time dimension to obtain the user's first statistical report data;

[0082] Call detail records (CDRs) are reconciled based on the data from the first statistical report, the statistical data before the call detail record merging, the final merged CDRs, and the approved pricing list data.

[0083] Furthermore, the call detail record (CDR) reconciliation module 204 is also used for:

[0084] The uplink and downlink traffic of the user are statistically analyzed based on the user information dimensions to obtain the user's second statistical report data;

[0085] Call detail records (CDRs) are reconciled based on the data from the second statistical report, combined with the statistical data before the merging, the final merged CDRs, and the approved pricing list data.

[0086] Furthermore, the call detail record (CDR) reconciliation module 204 is also used for:

[0087] The merged call detail records (CDRs) are statistically entered into the database through an input statistics program to obtain the merged statistical data for the user.

[0088] The final merged call detail records (CDRs) are processed through a pricing process to obtain the user's pricing list data.

[0089] Furthermore, the call detail record (CDR) reconciliation device also includes a cleanup module for:

[0090] The final merged call detail records (CDRs) are submitted to a Redis transaction, and the CDR deduplication identifier with the Redis node number and keyword is deleted.

[0091] Furthermore, the call detail record (CDR) reconciliation device also includes a backup module for:

[0092] The final merged call detail records are stored in a backup directory file.

[0093] The specific embodiments of the call detail record (CDR) reconciliation device provided in this application are basically the same as the embodiments of the CDR reconciliation methods described above, and will not be repeated here.

[0094] Figure 3 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 3 As shown, the electronic device may include: a processor 310, a communications interface 320, a memory 330, and a communication bus 340, wherein the processor 310, the communications interface 320, and the memory 330 communicate with each other via the communication bus 340. The processor 310 can call logical instructions in the memory 330 to execute a call detail record (CDR) reconciliation method, which includes:

[0095] The obtained user traffic call records are processed by the call record preprocessing program, and the user's call records to be merged are output.

[0096] The statistical procedures are used to collect and store the call details to be merged, thereby obtaining the user's pre-merging statistical data.

[0097] The dynamic call detail record (CDR) merging program processes the target CDRs that meet the user's traffic threshold and time threshold, and outputs the final merged CDR.

[0098] Based on the final merged call detail records (CDRs), the user's post-merger statistical data and pricing list data are determined. CDR reconciliation is then performed based on preset dimensions, combining the pre-merger statistical data, the final merged CDRs, and the pricing list data.

[0099] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] On the other hand, this application also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer is able to execute the call detail record reconciliation method provided by the above methods. The method includes:

[0101] The obtained user traffic call records are processed by the call record preprocessing program, and the user's call records to be merged are output.

[0102] The statistical procedures are used to collect and store the call details to be merged, thereby obtaining the user's pre-merging statistical data.

[0103] The dynamic call detail record (CDR) merging program processes the target CDRs that meet the user's traffic threshold and time threshold, and outputs the final merged CDR.

[0104] Based on the final merged call detail records (CDRs), the user's post-merger statistical data and pricing list data are determined. CDR reconciliation is then performed based on preset dimensions, combining the pre-merger statistical data, the final merged CDRs, and the pricing list data.

[0105] Furthermore, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is implemented to perform the aforementioned call detail record (CDR) reconciliation methods, the method comprising:

[0106] The obtained user traffic call records are processed by the call record preprocessing program, and the user's call records to be merged are output.

[0107] The statistical procedures are used to collect and store the call details to be merged, thereby obtaining the user's pre-merging statistical data.

[0108] The dynamic call detail record (CDR) merging program processes the target CDRs that meet the user's traffic threshold and time threshold, and outputs the final merged CDR.

[0109] Based on the final merged call detail records (CDRs), the user's post-merger statistical data and pricing list data are determined. CDR reconciliation is then performed based on preset dimensions, combining the pre-merger statistical data, the final merged CDRs, and the pricing list data.

[0110] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0111] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0112] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for phone bill reconciliation, the method comprising: The application comprises the following steps: processing the obtained traffic bill of the user through a bill preprocessing program, and outputting the user's to-be-merged bill; storing the to-be-merged bill through a statistical program, and obtaining the pre-merge statistical data of the user; processing the target merged bill in the to-be-merged bill which meets the traffic threshold and the time threshold of the user through a dynamic merge program, and outputting the final merged bill; determining the post-merge statistical data and the price list data of the user based on the final merged bill, and performing bill reconciliation based on the pre-set dimension in combination with the pre-merge statistical data, the final merged bill and the price list data; processing the target merged bill through a dynamic merge program, and outputting the final merged bill, comprising: determining the billing event bill in the target merged bill, and sorting the billing event bill according to the Redis node number and the keyword; determining the bill label of the sorted billing event bill, and merging the billing event bills with the same bill label to obtain the sorted target billing event bill; if the lock key-value pair of the sorted target billing event bill is the local lock value pair, then the sorted target billing event bill and the local billing event bill are determined as the final merged bill.

2. The method of claim 1, wherein, The pre-set dimension comprises a time dimension; The bill reconciliation based on the pre-set dimension in combination with the pre-merge statistical data, the final merged bill and the price list data comprises: statistically obtaining the first statistical report data of the user according to the time dimension; performing bill reconciliation according to the first statistical report data in combination with the pre-merge statistical data, the final merged bill and the price list data.

3. The method of claim 1, wherein, The pre-set dimension comprises a user information dimension; The bill reconciliation based on the pre-set dimension in combination with the pre-merge statistical data, the final merged bill and the price list data comprises: statistically obtaining the second statistical report data of the user according to the user information dimension; performing bill reconciliation according to the second statistical report data in combination with the pre-merge statistical data, the final merged bill and the price list data.

4. The method of claim 1, wherein, The determination of the post-merge statistical data and the price list data of the user based on the final merged bill comprises: statistically storing the final merged bill through a storage statistical program to obtain the post-merge statistical data of the user; performing bill pricing on the final merged bill through a pricing program to obtain the price list data of the user.

5. The method of claim 1 to 4, wherein, After the sorting target billing event bill and the local billing event bill are determined as the final merged bill, the method further comprises: submitting the final merged bill to a redis transaction, and deleting the bill de-duplication identifier of the Redis node number and the keyword.

6. The method of claim 1 to 4, wherein, After the sorting target billing event bill and the local billing event bill are determined as the final merged bill, the method further comprises: storing the final merged bill in a backup directory file.

7. A statement reconciliation apparatus, characterized by The application comprises the following steps: The first bill processing module is configured to process the traffic bills of the user by a bill preprocessing program, and output the user's to-be-merged bills; The statistical storage module is configured to statistically store the to-be-merged bills by a statistical program, and obtain pre-merge statistical data of the user; The second bill processing module is configured to process target merged bills in the to-be-merged bills that meet the traffic threshold and the time threshold of the user by a dynamic merge program, and output final merged bills; The bill reconciliation module is configured to determine post-merge statistical data and bid list data of the user based on the final merged bills, and perform bill reconciliation based on a preset dimension in combination with the pre-merge statistical data, the final merged bills and the bid list data. The second bill processing module is further configured to: determine billing event bills in the target merged bills, and sort the billing event bills according to Redis node numbers and keywords; determine bill tags of the sorted billing event bills, and merge billing event bills with the same bill tag to obtain sorted target billing event bills; if a lock key-value pair of the sorted target billing event bills is a local lock value pair, the sorted target billing event bills and local billing event bills are determined as the final merged bills.

8. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the bill reconciliation method of any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium comprising a computer program, characterized in that, The computer program is executed by the processor to implement the bill reconciliation method of any one of claims 1 to 6.

Images