CN101697613A - Method and device for processing abnormal call ticket - Google Patents
Method and device for processing abnormal call ticket Download PDFInfo
- Publication number
- CN101697613A CN101697613A CN200910205586A CN200910205586A CN101697613A CN 101697613 A CN101697613 A CN 101697613A CN 200910205586 A CN200910205586 A CN 200910205586A CN 200910205586 A CN200910205586 A CN 200910205586A CN 101697613 A CN101697613 A CN 101697613A
- Authority
- CN
- China
- Prior art keywords
- ticket
- interim
- disk state
- state file
- original cdr
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention discloses a method for processing an abnormal call ticket. The method comprises the following steps of: when the obtained original call ticket is converted, recording the processing state of the current call ticket in a disk status file at a designated time; and when the current call ticket conversion flow is accidentally quitted and restarted, loading the disk status file, returning to the corresponding position according to the information recorded in the disk status file so as to continuously executing the call ticket conversion flow. Therefore, when the call ticket conversion flow is accidentally quitted, the call ticket conversion flow can be recovered from a break point, and the correctness of the formal call ticket after the conversion is ensured. The invention also discloses a system used for processing the call ticket.
Description
Technical field
The present invention relates to communication system, particularly a kind of processing method of abnormal call ticket and device thereof.
Background technology
In mobile communication system, the development of value-added service presents diversified trend, based on the diversity of value-added service and and the complexity of content, correspondingly, require more and more higher to the executive capability of charging flow; Generating user's traffic inventory (being called for short ticket) how in time, exactly, is the primary problem that solves of charge system.
The ticket conversion processing mode is at present:: service processor (is called out at all kinds of business, short-message sending) produces ticket message, transfer them to accounting server by the TCP/IP Ethernet then, accounting server sends message for the charging reception server again, after the charging reception server receives ticket message, carry out encoding process and generate Original CDR; Then, read each bar record in the original bill files again, and after filtering, changing, be written to text; After Original CDR disposes, delete this original bill files.
In whole ticket conversion process; the improper unexpected state that withdraws from of system is not provided with any safeguard measure; therefore; after system withdraws from because of accident and resumes operation; when understanding improper withdrawing from, the partial data in the Original CDR that has been untreated is lost, obviously; this has had a strong impact on the accuracy of the formal ticket of charge system generation, thereby has reduced the service quality of charge system.
In view of this, need provide in a kind of charge system processing method, to overcome above-mentioned defective at abnormal call ticket.
Summary of the invention
The embodiment of the invention provides a kind of processing method and device thereof of abnormal call ticket, in order to effectively to handle at the abnormal call ticket situation in charge system, improves the accuracy of the final formal ticket that generates.
The concrete technical scheme that the embodiment of the invention provides is as follows:
A kind of processing method of abnormal call ticket comprises:
When the Original CDR that obtains is changed, opportunity current ticket treatment state is carried out record in the Disk State file in appointment;
After accident withdraws from current ticket conversion flow process and restarts, described Disk State file is loaded, and according to the information rollback of this Disk State file logging to the relevant position, to continue to carry out the ticket conversion flow process.
A kind of system that is used for the ticket processing comprises:
The ticket generation module is used for generating Original CDR according to user data;
The ticket processing module is packaged with dynamic link library, is used for the Original CDR that obtains is changed, and opportunity current ticket treatment state is carried out record in the Disk State file in appointment; And after accident withdraws from current ticket conversion flow process and restarts, described Disk State file is loaded, and according to the information rollback of this Disk State file logging to the relevant position, to continue to carry out the ticket conversion flow process.
In the embodiment of the invention, when the ticket processing module converts Original CDR to operator needed formal ticket, can appointment opportunity with current system mode: interim CDR file name, when the Original CDR of pre-treatment and filename and last information such as access location save as the Disk State file, thereby make the snapshot of a time point for the ticket handling process, the ticket processing module can still can be recovered from the point of interruption after withdrawing from the ticket conversion flow process because of anything unexpected, reach not loss of phone bill and not heavy single purpose, thereby guaranteed the accuracy of the formal ticket after the conversion.
Description of drawings
Fig. 1 is charge system architectural framework figure in the embodiment of the invention;
Fig. 2 is a ticket processing unit functional structure chart in the embodiment of the invention;
Fig. 3 carries out process chart in the embodiment of the invention at abnormal call ticket;
Fig. 4 is a ticket conversion flow chart in the embodiment of the invention.
Embodiment
Situation about withdrawing from unusually takes place at ticket conversion flow process in the charge system, accuracy for the formal ticket that guaranteed final generation, in the embodiment of the invention, when the Original CDR that obtains is changed, opportunity current ticket treatment state is carried out record in the Disk State file in appointment, and after accident withdraws from current ticket conversion flow process and restarts, described Disk State file is loaded, and according to the information rollback of this Disk State file logging to the relevant position, to continue to carry out the ticket conversion flow process.
Based on the foregoing description, the interface message processor (IMP) platform that can also unify to be provided with, by file transfer protocol (FTP) (as, File Transfer Protocol), gather the Original CDR that produces opportunity in appointment, and be saved under the Original CDR catalogue of appointment, call the corresponding dynamic chained library according to default configuration parameter again, the Original CDR of having preserved is changed, and will be changed what happened latter patrilineal line of descent with only one son in each generation and give charging center 12; Related content can be introduced in subsequent step.
Below in conjunction with accompanying drawing the preferred embodiment of the present invention is elaborated.
Consult illustrated in figures 1 and 2ly, in the embodiment of the invention, the charge system in the mobile communication system comprises business processing device 11 at least, this business processing device 11 is used to carry out the ticket conversion flow process, specifically comprises ticket generation module 110 and ticket processing module 111, wherein
Ticket generation module 110 is used for generating Original CDR according to user service data, and it is mail to ticket processing module 111 carries out conversion process;
Further, preferably, can also read the Original CDR of generation from ticket generation module 110 by the FTB function of supporting on the unified interface message processor (IMP) platform 10 that is provided with, and be saved under the Original CDR catalogue of appointment in the ticket processing module 111 and preserve, in order to subsequent treatment.
Ticket processing module 111 encapsulates with dynamic link library, thereby realizes the ticket conversion handling process; Be specially: the Original CDR that obtains is changed, and opportunity current ticket treatment state is carried out record in the Disk State file in appointment; And after accident withdraws from current ticket conversion flow process and restarts, described Disk State file is loaded, and according to the information rollback of this Disk State file logging to the relevant position, to continue to carry out the ticket conversion flow process.
Further, preferably, different dynamic link libraries can be encapsulated in respectively in the different ticket processing modules 111, and by the unified interface message processor (IMP) platform 10 (having configured the method for calling of various dynamic link libraries) that is provided with, according to the format of billing/content demand of operator, call corresponding 111 pairs of Original CDR of ticket processing module and carry out conversion process.Each ticket processing module 111 also can be shared other functions that interface message processor (IMP) platform 10 is supported, the integral body that can reduce system like this realizes cost, also is beneficial to later maintenance simultaneously.
Based on the said system framework, in the practical application, ticket processing module 111 scans according to setting cycle, the Original CDR of having preserved under the Original CDR catalogue is obtained in trial, preserving under the Original CDR catalogue under the situation of Original CDR, ticket processing module 111 begins to carry out the ticket conversion flow process, specifically comprises:
To earlier the Original CDR that obtains be renamed before the conversion, as, it is just processed to identify this Original CDR to increase suffix .m;
In the transfer process, transformation result is charged to one by one, in real time in the interim ticket under the interim ticket catalogue of appointment, when the file size of interim ticket reaches setting threshold, or receive when being used to notify the message that has generated conversion back ticket, with corresponding its identification information recording of current treatment state of ticket in corresponding Disk State file, this Disk State file comprises at least: the filename of interim ticket, when the filename of pre-treatment Original CDR and the position of last visit; At last, to change the interim ticket that finishes again renames formal ticket as and backs up to corresponding storage device, simultaneously formal ticket is moved under the saving contents of formal ticket, then, the Original CDR that deletion has been handled, and be next round transformed structure state, be ready to complete new round conversion operations.
Based on above-mentioned application scenarios, ticket processing module 111 because of anything unexpected (as, cut off the power supply, crash, restart or the like non-any factor) when withdrawing from the ticket conversion flow process of current execution, when starting once more, at first to carry out initialization operation, load the Disk State file of having preserved behind the last conversion operations by initialization operation, thereby judge the operation of current required execution by the information that this Disk State file comprises, with the running environment of arrangement ticket handling process.In the practical application, when arrangement running environment, there is not any interim ticket under the interim ticket catalogue if know, before illustrating that then last accident withdraws from, system's executed once complete ticket conversion flow process, and the formal ticket that will obtain is forwarded to the charging center, then ticket processing module 11 need not the conversion operations that the last time carries out is carried out any correction process, directly make up transition status, prepare the Original CDR conversion that produces is once more got final product; And if know when having interim ticket under the interim ticket catalogue, illustrate that then last accident withdraws from before, system does not carry out once complete ticket conversion flow process, needs 11 pairs of last conversion operations of carrying out of ticket processing module to carry out corresponding correction process.So, consulting shown in Figure 3ly, in the embodiment of the invention, is example with second kind of situation, and after ticket processing module 111 withdrawed from flow process because of accident and restarts, the detailed process that carries out respective handling at abnormal call ticket was as follows:
Step 300: load the Disk State file of having preserved; This Disk State file comprise the last carry out the ticket conversion flow process after, the filename of the interim ticket of preservation, the filename of the Original CDR of having handled and last access location when carrying out the ticket conversion flow process.
Step 310:, judge whether the filename of the interim ticket that writes down in the filename of the interim ticket of preserving under the current interim ticket catalogue and the Disk State file mates, if then carry out step 320 according to the information of Disk State file logging; Otherwise, carry out step 340.
Step 320: to interim ticket rename (promptly removing suffix .m), and the formal ticket that will obtain after will renaming moves under the formal ticket catalogue, deletes the interim ticket under the interim ticket catalogue simultaneously, then, execution in step 350 is for ticket conversion flow process is next time made preparation.
Step 320: interim ticket is renamed (promptly removing suffix .m), and the formal ticket that will obtain after will renaming moves under the formal ticket catalogue.
In the practical application, if the filename of the interim ticket that writes down in the filename of the interim ticket of preserving under the current interim ticket catalogue and the Disk State file is complementary, then illustrate when last accident withdraws from, system has intactly carried out the ticket conversion flow process one time, just in time the transformation result that obtains is not exported with the form of formal ticket, therefore, ticket processing module 11 directly is that formal ticket gets final product with interim ticket conversion.
Step 330: the interim ticket of having renamed under the interim ticket catalogue is backed up, and at the interim ticket of deletion under the interim ticket catalogue after the backup, then, execution in step 350 is for ticket conversion flow process is next time made preparation.
Wherein, so-called formal ticket: promptly be meant the CDR file that meets client's form/content request;
Interim ticket under the so-called interim ticket catalogue: promptly be meant the temporary file that produces at formal ticket in the transfer process, form is with formal ticket;
So-called interim ticket catalogue is promptly: promptly be meant the memory location that is used to preserve interim ticket that sets in advance.
Step 340: with the deletion of the interim ticket under the interim ticket catalogue, carry out rollback according to the last access location that writes down in the Disk State file, then, and execution in step 350, conversion operations is continued to carry out in the position that arrives behind the rollback.
In the practical application, if the filename of the interim ticket that writes down in the filename of the interim ticket of preserving under the current interim ticket catalogue and the Disk State file does not match, then illustrate when last accident withdraws from, system has not intactly carried out the ticket conversion flow process one time, what exist under the interim ticket catalogue is the interim ticket that produced when carrying out ticket conversion last last time, therefore, ticket conversion module 11 needs current interim ticket deletion, and according to the last access location of Disk State file logging, the correspondence position that return back to Original CDR continues to carry out last uncompleted ticket conversion operation.
Step 350: make up transition status, get ready for carrying out the ticket conversion flow process.
In the present embodiment, the so-called transition status that makes up mainly comprises: read configuration file (as, Original CDR format configuration file, conversion back ticket format configuration file, conversion parameter configuration file); Then, ticket conversion module 11 initialization memory informations, and create the work order that needs in the transfer process.
Step 360: begin to carry out corresponding ticket conversion flow process.
Based on above-mentioned flow process, consult shown in Figure 4ly, in step 360, the detailed process that ticket processing module 111 is carried out the ticket conversion flow processs is as follows:
Step 400: scan according to setting cycle Original CDR to its preservation under the Original CDR catalogue of appointment.
Step 410: judge whether preserve the Original CDR that has been untreated under the Original CDR catalogue,, then carry out step 420 if do not have; Otherwise, carry out step 430.Wherein, when carry out judging flow process including but not limited to following mode: the filename of the Original CDR of preserving under the filename of the Original CDR of pre-treatment and Original CDR catalogue that writes down in the Disk State file is compared, if then there is the Original CDR that has been untreated in coupling, not matching does not then exist.
Step 420: read next undressed Original CDR, back up earlier, it is renamed again, be about to change .m into behind its file, just processed, the file header from this Original CDR begins reading of data again with sign this document, then, carry out step 440.
Step 430: read the Original CDR that has been untreated, the last access location that writes down from the disk access file begins reading of data, then, carry out step 440.
Step 440: judge that the current Original CDR content that reads finishes? if then return step 400; Otherwise, carry out step 450.
Step 450: the content to the Original CDR that reads is changed, and then, returns step 410.
In the content of Original CDR being carried out process by turns, specifically comprise: one by one the content after the conversion, write in real time under the interim ticket catalogue in the interim ticket, file size at interim ticket reaches setting threshold, perhaps arrive the time point that default timing generates formal ticket, then with the treatment state (filename that comprises interim ticket at least of current Original CDR, when the filename of the Original CDR of pre-treatment and the position of last visit) write the Disk State file, after preserving the Disk State file after upgrading, again to the interim ticket under the current interim ticket catalogue rename (as, remove follow-up .m), rename, backup, and, delete the interim ticket under the interim ticket catalogue at last again under the extremely formal ticket catalogue of the formal Call Detail Record dump of interim ticket conduct after renaming.
In the above-described embodiments, after the conversion of the 111 pairs of Original CDR of ticket processing module finished, the formal ticket that also needs to obtain was forwarded to charging center 12 and presents.
In the embodiment of the present application, when breaking down for the ticket handling process that guarantees charge system, the ticket that generates is not lost, improve the accuracy of ticket, ticket processing module 111 must be judged the ticket treatment state of system according to the Disk State file of having preserved when starting initialization, and the running environment of arrangement ticket handling process; Wherein, the ticket treatment state of judgement system comprises: when the filename coupling of the interim ticket of current existence under the filename of the interim ticket that writes down in the Disk State file and the interim ticket catalogue, illustrate that ticket processing module 111 has generated complete interim CDR file in last once ticket conversion flow process, at this moment, should delete the Original CDR that when the Original CDR of pre-treatment, has identified that in the Disk State file, writes down earlier, because, when the file size of Original CDR is smaller, in the complete interim CDR file that generates, might comprise the ticket writing that is converted to by a plurality of Original CDR, must delete the Original CDR that has identified when the Original CDR of pre-treatment that in the Disk State file, writes down this moment, otherwise will be when carrying out conversion operations next time, these Original CDR are carried out conversion operations once more, will cause ticket to repeat like this.Then, ticket processing module 11 is renamed, is backed up at the interim ticket under the interim ticket catalogue, converts thereof into formal ticket again.
When the filename of the interim ticket of current existence under the filename of the interim ticket that writes down in the Disk State file and the interim ticket catalogue does not match, then explanation may exist in the front disk once and finish (as, because of accident withdraws from) the ticket conversion flow process, then ticket processing module 111 should be deleted the interim ticket under the interim ticket catalogue, equally also to delete write down in the Disk State file except that other the relevant information of Original CDR when the Original CDR of pre-treatment, and carry out rollback according to the last access location that writes down in the Disk State file, the access location that arrives behind rollback begins to read the data the Original CDR, and begins to carry out the ticket conversion flow process.In like manner, write down in the deletion Disk State file earlier except that when the Original CDR of pre-treatment, the relevant information of other Original CDR is not repeat for the formal ticket after guaranteeing to change; And carry out rollback according to the last access location that writes down in the Disk State file, then can guarantee to change the back ticket and not lose.
In sum, the technical scheme that adopts the embodiment of the invention to provide, when ticket processing module 111 converts Original CDR to operator needed formal ticket, can appointment opportunity with current system mode: interim CDR file name, when the Original CDR of pre-treatment and filename and last information such as access location save as the Disk State file, thereby make the snapshot of a time point for the ticket handling process, ticket processing module 111 can still can be recovered from the point of interruption after withdrawing from the ticket conversion flow process because of anything unexpected, reach not loss of phone bill and not heavy single purpose, thereby guaranteed the accuracy of the formal ticket after the conversion.
On the other hand, in the embodiment of the invention, can directly generate Original CDR by the ticket generating apparatus, do not need as in the prior art by accounting server, charge and to accept can generate Original CDR after repeatedly mutual between the server, therefore, compared with prior art, save the cost that ticket generates.And Original CDR is directly under the Original CDR catalogue of the collected ticket processing module 111 of FTP function by interface message processor (IMP) platform 10, with respect to the transmission message mechanism under the prior art, guaranteed that Original CDR do not lose in transmission course.
At last, in the embodiment of the invention, preferably, can be with ticket processing module 111 needed dynamic link libraries, call by interface message processor (IMP) platform 10 is packaged, the benefit of doing like this is, can be according to operator to changing the formally requirement of the form/content of ticket of back, develop correspondingly a plurality of dynamic link libraries, and configure at interface message processor (IMP) platform 10, like this, just can start a plurality of ticket processing modules 111, each ticket processing module 111 correspondence the needed format of billing/content of a kind of operator, thereby each ticket processing module 111 just can be carried out the filtration of corresponding format/content demand respectively to Original CDR, operations such as conversion make the charge system can be according to the different demands of different operators, Original CDR is converted to the target ticket of required form/content, it is used result data to be offered charging center 12 or operator again, and then has reduced the networking and the operation cost of operator, has improved the market competitiveness of charge system.
Obviously, those skilled in the art can carry out various changes and modification to the embodiment among the present invention and not break away from the spirit and scope of the present invention.Like this, if these in the embodiment of the invention are revised and modification belongs within the scope of claim of the present invention and equivalent technologies thereof, then the embodiment among the present invention also is intended to comprise these changes and modification interior.
Claims (14)
1. the processing method of an abnormal call ticket is characterized in that, comprising:
When the Original CDR that obtains is changed, opportunity current ticket treatment state is carried out record in the Disk State file in appointment;
After accident withdraws from current ticket conversion flow process and restarts, described Disk State file is loaded, and according to the information rollback of this Disk State file logging to the relevant position, to continue to carry out the ticket conversion flow process.
2. the method for claim 1 is characterized in that, described appointment comprises opportunity: the file size of the interim ticket that produces when handling described Original CDR reaches setting threshold, perhaps, arrives the time point of the formal ticket of setting of generation.
3. method as claimed in claim 1 or 2 is characterized in that, described Disk State file comprises the filename of the interim ticket that generates when handling described Original CDR at least, when the filename of the Original CDR of pre-treatment and last access location.
4. method as claimed in claim 3 is characterized in that, described the Disk State file is loaded, and according to the information rollback of this Disk State file logging to the relevant position, to continue the carrying out ticket conversion flow process, comprising:
To specify the filename of the interim ticket that writes down in the filename of the interim ticket that exists under the interim ticket catalogue and the described Disk State file to compare, when determining that both do not match, according to the filename rollback of described last access location and described Original CDR correspondence position, and begin to continue to carry out the ticket conversion flow process from this position to this Original CDR.
5. method as claimed in claim 4 is characterized in that, described the Disk State file is loaded, and according to the information rollback of this Disk State file logging to the relevant position, to continue the carrying out ticket conversion flow process, comprising:
To specify the filename of the interim ticket that writes down in the filename of the interim ticket that exists under the interim ticket catalogue and the described Disk State file to compare, when determining that both mate, to specify the interim ticket that exists under the interim ticket catalogue to back up, and rename behind the formal ticket it as unloading to the formal ticket catalogue of appointment.
6. method as claimed in claim 1 or 2 is characterized in that, obtains described Original CDR by the unified interface machine platform that is provided with, and is saved to the memory location of appointment.
7. method as claimed in claim 6 is characterized in that,, calls corresponding dynamic link library Original CDR is changed according to default format of billing/content demand by described interface message processor (IMP) platform.
8. one kind is used for the system that ticket is handled, and it is characterized in that, comprising:
The ticket generation module is used for generating Original CDR according to user data;
The ticket processing module is packaged with dynamic link library, is used for the Original CDR that obtains is changed, and opportunity current ticket treatment state is carried out record in the Disk State file in appointment; And after accident withdraws from current ticket conversion flow process and restarts, described Disk State file is loaded, and according to the information rollback of this Disk State file logging to the relevant position, to continue to carry out the ticket conversion flow process.
9. system as claimed in claim 8, it is characterized in that, described ticket processing module writes down current ticket treatment state in appointment and comprise opportunity in the Disk State file: the file size of the interim ticket that produces when handling described Original CDR writes down described Disk State file when reaching setting threshold, perhaps, when arriving the time point of the formal ticket of setting of generation, write down described Disk State file.
10. system as claimed in claim 8 or 9, it is characterized in that, described ticket processing module records current ticket treatment state in the Disk State file, comprising: the filename of the interim ticket that generates when the major general handles described Original CDR, be recorded in the described Disk State file when the filename and the last access location of the Original CDR of pre-treatment.
11. system as claimed in claim 10, it is characterized in that, described ticket processing module loads the Disk State file, and according to the information rollback of this Disk State file logging during to the relevant position, to specify the filename of the interim ticket that writes down in the filename of the interim ticket that exists under the interim ticket catalogue and the described Disk State file to compare earlier, when determining that both do not match, according to the filename rollback of described last access location and described Original CDR correspondence position, and begin to continue to carry out the ticket conversion flow process from this position to this Original CDR.
12. system as claimed in claim 10, it is characterized in that, described ticket processing module loads the Disk State file, and according to the information rollback of this Disk State file logging during to the relevant position, to specify the filename of the interim ticket that writes down in the filename of the interim ticket that exists under the interim ticket catalogue and the described Disk State file to compare earlier, when determining that both mate, to specify the interim ticket that exists under the interim ticket catalogue to back up, and rename behind the formal ticket it as unloading to the formal ticket catalogue of appointment.
13. system is characterized in that as claimed in claim 8 or 9, obtains described Original CDR by the unified interface machine platform that is provided with, and is saved to the memory location of appointment.
14. system as claimed in claim 13 is characterized in that,, calls corresponding dynamic link library Original CDR is changed according to default format of billing/content demand by described interface message processor (IMP) platform.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910205586A CN101697613A (en) | 2009-10-30 | 2009-10-30 | Method and device for processing abnormal call ticket |
| PCT/CN2010/072903 WO2010145385A1 (en) | 2009-10-30 | 2010-05-18 | Method for processing bill abnormality and system for processing bills |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910205586A CN101697613A (en) | 2009-10-30 | 2009-10-30 | Method and device for processing abnormal call ticket |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101697613A true CN101697613A (en) | 2010-04-21 |
Family
ID=42142673
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910205586A Pending CN101697613A (en) | 2009-10-30 | 2009-10-30 | Method and device for processing abnormal call ticket |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101697613A (en) |
| WO (1) | WO2010145385A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010145385A1 (en) * | 2009-10-30 | 2010-12-23 | 中兴通讯股份有限公司 | Method for processing bill abnormality and system for processing bills |
| CN108123810A (en) * | 2016-11-28 | 2018-06-05 | 中国移动通信集团公司 | A kind of error bills processing method and processing device |
| CN112804406A (en) * | 2019-11-14 | 2021-05-14 | 中国移动通信集团广东有限公司 | Call bill processing method and device and electronic equipment |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10346802B4 (en) * | 2003-10-06 | 2009-04-23 | Belerofon Gmbh | Method for processing CDR information |
| CN100596159C (en) * | 2005-12-01 | 2010-03-24 | 大唐软件技术有限责任公司 | Method for processing multiprogress message and method for processing multiprogress talk ticket |
| CN101262356B (en) * | 2007-03-07 | 2012-07-11 | 中兴通讯股份有限公司 | A CDR processing system for communication system |
| CN101409877B (en) * | 2008-11-28 | 2010-07-14 | 中兴通讯股份有限公司 | Method for generating call ticket |
| CN101697613A (en) * | 2009-10-30 | 2010-04-21 | 中兴通讯股份有限公司 | Method and device for processing abnormal call ticket |
-
2009
- 2009-10-30 CN CN200910205586A patent/CN101697613A/en active Pending
-
2010
- 2010-05-18 WO PCT/CN2010/072903 patent/WO2010145385A1/en active Application Filing
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010145385A1 (en) * | 2009-10-30 | 2010-12-23 | 中兴通讯股份有限公司 | Method for processing bill abnormality and system for processing bills |
| CN108123810A (en) * | 2016-11-28 | 2018-06-05 | 中国移动通信集团公司 | A kind of error bills processing method and processing device |
| CN112804406A (en) * | 2019-11-14 | 2021-05-14 | 中国移动通信集团广东有限公司 | Call bill processing method and device and electronic equipment |
| CN112804406B (en) * | 2019-11-14 | 2022-12-16 | 中国移动通信集团广东有限公司 | Call bill processing method and device and electronic equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010145385A1 (en) | 2010-12-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101753344B (en) | Method, device and system for logging | |
| CN102685018B (en) | A kind of method of network instant communication information processing, system and instant communication device | |
| CN105871587A (en) | Log uploading method and device | |
| WO2010124495A1 (en) | System and method for multi-service format file processing | |
| CN101163043A (en) | Network management function configuring method and system | |
| CN111142905A (en) | OTA (over-the-air) upgrading method, OTA server and OTA upgrading system | |
| CN111240812A (en) | Task execution method and device | |
| CN107870982A (en) | Data processing method, system and computer-readable recording medium | |
| CN103024782A (en) | Base station software version management method and system | |
| CN104660639B (en) | Cloud terminal upgrade processing method and device | |
| CN101697613A (en) | Method and device for processing abnormal call ticket | |
| CN113793450B (en) | Shared battery replacing method and device, electronic equipment and storage medium | |
| EP2479962A1 (en) | Method and mobile terminal for recycling short messages | |
| CN100556192C (en) | The method that information of mobile terminal reports automatically | |
| CN102413247B (en) | The restoration methods of crash site of terminal and device | |
| CN106204031B (en) | Card application processing method and device | |
| WO2024066748A1 (en) | Operating system event processing method, operating system, electronic device and storage medium | |
| CN103220662A (en) | Application program processing method and mobile terminal | |
| CN106557530B (en) | Operation system, data recovery method and device | |
| US20140038548A1 (en) | Information processing apparatus and information processing method | |
| CN103369722B (en) | Mobile terminal control method and mobile terminal control apparatus | |
| CN107155167A (en) | Mobile terminal and its Bluetooth pairing name class processing method and storage device | |
| CN103699994B (en) | A kind of method and system that space transference is carried out to mobile terminal stored value card | |
| CN100442715C (en) | Plan and task realizing method in device management | |
| CN102867247A (en) | Automatic office system and method for rapidly deploying and safely sending files |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20100421 |