對于一個BOSS系統而言，計費賬務系統自然是一個相當重要的組成部分，在整個BOSS系統中，最有別于別的行業的部分應該也就是計費賬務系統了，或者應該更強調的說是計費系統。
一般來說，計費系統分為：采集、預處理、剃重、批價、詳單入庫、賬單入庫這幾個部分。
采集系統負責從業務網元獲取各種業務的服務使用記錄，很多情況下，我們都叫他們做CDR（call detail record），即使很多業務比方說是短信，并不是通話，我們也習慣上叫這些記錄做CDR或者是詳單。
采集的方式有很多，主要看網元的提供方式，對于電信運營商而言，核心的業務是語音、短信和GPRS，而語音和短信的話單一般都是由交換機或者是短信平臺提供文件，在這種情況下，一般都是采集系統用ftp的方式來獲取這些話單文件。這里不涉及什么高深的技術，大部分情況就是FTP，然后就是采集完后把已經采集過的話單文件移到備份目錄。
這里需要提出一點的是交換機出話單的策略，為了更快的輸出話單，交換機一般有兩種輸出策略，第一種是按時間，第二種是按文件大小。前者的意思是多長時間輸出一個話單文件，后者的意思是當話單文件達到多大，就輸出一個。自然，為了盡快的輸出話單，忙時應該用第二種策略；而閑時的話，則使用的是第一種策略。
一個完整的話單包含的元素有發話時間、結束時間、主叫、被叫、發話地點等等。這里最要命的就是結束時間，一個完整的話單必須有結束時間，所以對于一個一直沒有掛斷的通話記錄，傳統的計費系統是無法對這條記錄進行批價的，這也就是為什么會出現當你的卡上剩下1塊錢，只要你不掛斷電話，你可能可以打很長時間，很長時間！但是注意的是，我說的是“可能”，因為你知道這個秘密，運營商也不傻，他們會想辦法處理這個問題，至于怎么處理，我以后會慢慢寫。
預處理系統實際上是一個和交換廠商密切相關的領域。它需要做的是把各個交換機的話單格式轉換成一個統一的話單格式，你需要把這些交換機的話單格式都搞清楚，如此而已，幸好廠商不多，因為這里沒有什么標準可言，所以壟斷有時候也有點好處。預處理系統還有一個重要的功能是話單合并，因為交換機會對長話單進行分段處理，比方說你通話超過30分鐘，交換機會30分鐘出一條話單，對于預處理系統則需要把這些話單進行合并。
剃重，很多情況下，剃重會歸并到預處理系統里面，但是也有把他單獨拿出來說的。從字面上來說，就是把重復的話單提出掉。話單出現重復的原因主要是交換機的原因，交換機有時候會出現一個通話記錄產生兩條一樣的話單的情況，至于原因，我不是很清楚，呵呵。
剃重是一門很復雜的技術。但是剃重的條件實際上很簡單，就是同一時間的同一個人不能做兩件同樣的事情，就是說你不能在同時給同一個人打兩個電話。為什么說剃重是一門很復雜的技術呢，關鍵是涉及的話單量，你看看中國移動09年一季度的財報，一天凈賺2.8億！對于大部分省的移動運營商而言，一個月的話單都是億為單位的，每天也是千萬級。在這種海量的數據里面去迅速定位兩個重復的記錄，的確不是那么簡單的事情。可以總結出的兩種剃重技術，庫外剃重和庫內剃重，這主要看具體實現的方式是不是依賴數據庫的唯一索引，如果依賴，則一般叫做庫內剃重，反之如果是通過自建數據結構來處理叫庫外剃重。
批價系統，很多情況下，我們會經常聽說一批和二批這兩個詞，這兩個詞的叫法有很多種含義，說法也比較拗口，簡單舉個例子，如果你使用了一個套餐，包200分鐘的市話主叫，超出之后每分鐘2毛錢，這時你打了個4分鐘的市話，一批出來是8毛；二批發現如果在200分鐘內的話，則批成0。還有一種說法是一批先批成標準資費，即每分鐘4毛，4分鐘1塊6，然后再批成0，或者是8毛。總是一批和二批的說法有這么幾種，不過，隨著系統的發展，一批和二批之間的界限實際上已經越來越模糊了，越來越多的計費系統都是通過一次性的批價來得出最終的結果，這是一個發展趨勢。批價系統是計費系統里面最復雜的部分，一個計費系統好不好，可能更多的是通過批價系統來衡量。
衡量一個批價系統好不好，作為一個電信級的系統，首先當然是系統安全性要高，回退、重批等功能需要具備；其次就是要靈活。眾所周知的是移動的套餐之多，多得到了令人發指的情況，多得到了很多運營部門的人都搞不完全清楚。如此多的套餐支持，而且美其名曰要迅速對市場部門需求做出響應，所以批價系統要盡量快的應對運營商提出的各種套餐需求。在支持這個套餐的過程中，其實運營商是不關心你每次會不會要改代碼的，即使是口頭上說說，只要你每次改的快，他們也不在乎的，這似乎和很多人鼓吹的并不一樣，他們總會說是運營商要求要提高計費系統的可配置化。實際上是誰希望提高系統的可配置化呢？是集成商，集成商希望每次改套餐不要動代碼，由現場維護人員改改配置，就能搞定，這樣研發和測試就要省很多的事情。做計費系統的人都知道，運營商會要求現場有很多維護人員，至少是10個，甚至更多，他們可以給維護費，只要你支持他的需求，出錯能兜得住，他不會管你是怎么實現的，是改代碼還是修改配置？他們才不管。
關于批價系統說的比較多，大家還可以看看我的另外一篇文字《將lua嵌入C++中用來做計費系統的批價》
詳單入庫和剃重一個道理，關鍵是性能，大量的數據入庫必然對性能的要求很高。一般的做法也可以分為兩種，庫內和庫外。其中庫外存儲詳單現在越來越少了，雖然他的優點很明顯，占用資源少，速度快，但同時缺點也同樣十分明顯，就是查詢和管理不方便，越來越多的開發商放棄了庫外詳單存儲。而借助oracle的分區技術，庫內詳單存儲基本上成為大部分開發商的首選方案。
詳單入庫之后就是合并賬單了，因為賬單的特殊性，他的update操作特別多，基于性能的考慮很多開發商選擇了內存數據庫來存儲。以前很多的開發商都是自己基于Unix的共享內存技術來管理存儲當月或者上月的賬單，但是最近幾年隨著Altibase和TimesTen的流行，越來越多的開發商也開始放棄自己開發的東西，轉而使用成熟的商用解決方案。一旦使用Altibase和TimesTen之后，賬單的入庫對于開發人員來說也就沒多少技術含量了。
以上是一個對計費系統的簡單介紹，有不對之處請大家多多指正。