Telfort融合計費項目總體設計方案V精選

1、2Huawei Tech no logies Co. Ltd.華為技術(shù)Product versi on產(chǎn)品版本Con fide ntiality level 密級秘密Total pages : 共167頁Telfort 2.0工程總體技術(shù)方案Prepared by擬制Telfort 2.0分析設計組Date日期yyyy-mm-ddReviewed byDateyyyy-mm-dd評審人日期Approved byDateyyyy-mm-dd批準日期Authorized byDateyyyy-mm-dd簽發(fā)日期Huawei Technologies Co.，Ltd.華為技術(shù)All rights r

2、eserved版權(quán)所有侵權(quán)必究Revisi on record修訂記錄Date日期Revisi onVersi on修訂版本CR ID / DefectID CR號Section Number 修改 早節(jié)Change Description修改描述Author作者2021-09-120.10根據(jù)各專題的寫作和檢視結(jié)果，初稿合并 完成Telfort 2.0分析設計組2021-10-040.20根據(jù)客戶CR修正局部描述。1. DC模塊將被客戶的 CACS替換2. FM將被KPN系統(tǒng)替換局部功能的修改1、帳戶優(yōu)惠方案的修改2、接觸管理的修改和批注與 IPCC部 分信息未達成一致3、MDS方案修改4、

3、Real time chari ng5、修改訂單落地方案，增加設計方案和 增加訂單查詢及訂單修改6、 補充 SCP 與 Rating&Billing集成方 案語音計費、 VMS計費以及AOC 等業(yè)務7、預付費生命周期管理增加功能分解：1、掃描件的存儲和管理Telfort 2.0分析設計組Distribution LIST 分發(fā)記錄Copy No.Holders Name & Role持有者和角色Issue Date分發(fā)日期1yyyy-mm-dd2yyyy-mm-dd3yyyy-mm-dd4yyyy-mm-ddCatalog 目 錄Keywords關(guān)鍵詞：Telfort、CCBS、CBS、總體設

4、計方案Abstract 摘 要：本文檔主要描述Telfort 2.0融合計費工程的系統(tǒng)構(gòu)成、部件部署、關(guān)鍵業(yè)務流程 和方案、內(nèi)外部接口說明，以及系統(tǒng)整體的需求包和需求分解。在結(jié)合Telfort 2.0的外部系統(tǒng)環(huán)境進行方案分析和設計的根底上，本文檔側(cè)重在Huawei解決方案內(nèi)部的設計說明，Huawei解決方案與Telfort外部系統(tǒng)的方案將在與局方的系統(tǒng)架構(gòu)和接口文檔中進行說明。List of abbreviati ons縮略語清單：Abbreviatio ns 縮略語Full spelli ng英文全名Chin ese expla natio n中文解釋TF 2.0Telfort 2.0 p

5、rojectTelfort 2.0 工程CCBSCustom Care & Bill ing System綜合客戶管理系統(tǒng)，包括Custom Care、 Billing&Bill Formatting 、AR、DC、PC、 PRM、Mediation、Provision、InventoryBOSSBusin ess & Operati on Support ingSystem業(yè)務運營支撐系統(tǒng)，是中國移動的稱謂。文中指CCBS。CCCustom Care客戶關(guān)心管理模塊:ARAcco unt Receivable應收款管理模塊DCDebt Collectio n催欠管理模塊PCPricing C

6、atalogue產(chǎn)品目錄管理模塊BFBill Formatt ing帳單格式化模塊ProProvisi on效勞開通模塊MDMediation米集預處理模塊InvInven tory資源管理模塊DWHData Warehouse數(shù)據(jù)倉庫CBSCon verge nee Billi ng System融合計費系統(tǒng)，包括預付費和后付費OCSOn li ne Charg ing System在線計費系統(tǒng)EBITDAEarnings Before In terest, Taxes,Depreciatio n and Amortizati on利息、稅收和折舊、攤銷前收入TTMTime to Marke

7、t上市時間TCOTotal Cost of Own ership總擁有本錢SMESmall Medium En terprises中小企業(yè)ESPEnhanced Service Provider增強效勞提供商工程背景1.1 Telfort 現(xiàn)狀介紹Telfort 是于 1997年在荷蘭成立的一家獨立移動運營商，他將自己定位于移動市場的挑戰(zhàn)者。在2005年Telfort被荷蘭最大的固定/移動運營商KPN收購。收購后兩家的網(wǎng)絡架構(gòu)進行了整合，Telfort將會把其網(wǎng)絡遷移到 KPN。今天Telfort已經(jīng)成為KPN整體品牌下的挑戰(zhàn)品牌。 Telfort將作為關(guān)注價格細 分市場的增強效勞提供商ESP

8、，這是KPN對Telfort品牌和歷史定位。同時，KPN在2006年收購了荷蘭的In ternet效勞提供商荷蘭 Tiscali i nternatio nal Tiscali group的一部分，并重新進行品牌包裝交由Telfort管理和運營。因此，Telfort同時包括Mobile和In ternet業(yè)務。為提高Telfort的EBITDA，同時也為了支撐其在 Mobile和In ternet業(yè)務的融合以及對應組織結(jié)構(gòu)和人員進行調(diào)整，Telfort需要在其IT支撐系統(tǒng)上進行改造，目標包括有：Faster time to market TTM Lower TCO of IT本次的支撐系統(tǒng)范圍

9、為融合的 CRM & Billing系統(tǒng)，也就是Telfort 2.0工程。注：在此前，有Telfort 1.0工程，只涵蓋預付費業(yè)務局部，目前尚未實施，將被同時包括在Telfort 2.0中，所以 Telfort 2.0是個預付費融合、 Mobile/Internet 融合的 CRM & Billing 解決方案1.1.1 Telfort Mobile目前的 Telfort 移動根底設施的特點是：大量的應用眾多專有接口一個復雜的系統(tǒng)架構(gòu)系統(tǒng)支離破碎，數(shù)據(jù)冗余在多個系統(tǒng)，數(shù)據(jù)復制不總是完全正確復制 復雜系統(tǒng)的堆棧含有大量的冗余功能，例如不同的系統(tǒng)大致相同的功能是用于消費者和企業(yè)的局部，這導致了

10、以下結(jié)果：本錢高需要較多人力操作，質(zhì)量保證，投訴處理系統(tǒng)維護復雜 產(chǎn)品的靈活性低，響應市場時間長開發(fā)新產(chǎn)品 /效勞時需要復雜的，定制的接口開發(fā)沒有E2E效勞保證收入保障流程復雜客戶操作復雜，很難實施有效的客戶的自助效勞Telfort 當前移動業(yè)務支撐系統(tǒng)架構(gòu)如下(由歐洲廠商 Capgimini 等提供管理效勞)：1.1.2 Telfort internet由于歷史的原因荷蘭 Tiscali的Customer Care和billing系統(tǒng)被外包給 Tiscali services管理，Tiscaliservices的平臺為多個國家效勞，外包合同將在09年6月份結(jié)束，開發(fā)商為：?Billing:

11、Geneva?CRM: Siebel1.2 目標業(yè)務Telfort 2.0需要支撐的(主要)業(yè)務包括如下，其中，移動業(yè)務中包含預付費和后付費業(yè)務，對于In ternet業(yè)務，僅僅包括后付費業(yè)務：Mobile Voice services(Prepaid and Postpaid)o Voiceo Voice Roamingo Voice MailMobile Data services(Prepaid and Postpaid)o GPRSo GPRS Roamingo WAP/WAP Pusho SMSo SMS premiumo MMSo SMS Roamingo MMS Roamingo

12、 Content ServiceInternet Access services(ADSL, VDSL)(Postpaid only)Internet VoIP services(Postpaid only)Internet Value Added services(Postpaid only)o eMailo Homepageo Doma in registrati ono Key man /F-secure另外，從客戶的角度看，Telfort 2.0需要支持如下類型客戶：Con sumerBusiness SME only ,對于具有復雜組織結(jié)構(gòu)、特殊網(wǎng)絡業(yè)務類型的集團客戶不在 支持的范圍

13、之內(nèi)。再有，由于Telfort本身作為KPN的一個增強效勞提供商，所以原那么上針對其它ESP、MVNO業(yè)務的支持不在Telfort 2.0范圍之內(nèi)，但由于考慮到網(wǎng)絡和系統(tǒng)的變遷方便，針對話單處理、效勞開通局部可 能會涉及我們的Mediation和Provision，需要參考更詳細的方案設計內(nèi)容。1.3 目標用戶數(shù)整個系統(tǒng)需要支撐到 Telfort今后5年的業(yè)務開展即從 2021年到2021年，在這個過程中，系統(tǒng)需支撐的用戶數(shù)預計如下表所示：202120212021202120212021SubscriberseoyeoyeoyeoyeoyeoyActive prepaid subscriber

14、s920,000930,000940,000940,000940,000940,000Registered Pre paid1,150,001,150,001,160,001,170,001,170,001,170,00subscribers000000875,0001,000,001,100,001,175,001,225,001,250,00Active postpaid subscribers00000Active in ter net customers383,000459,700505,650556,200611,800674,0002,178,002,389,702,545,652

15、,671,202,776,802,864,00Active Subscribers (Total)000000Active voip subscribers120,000140,000170,000200,000240,000288,000注： 其中的 Active voip subscribers 已包括在 Active internet customers 中了。其他更詳細的信息請參見RFQ材料中的?。1.4 實施階段按照業(yè)務和網(wǎng)絡情況考慮，整個工程將會分三個階段實施：第一階段phase 1: Mobile Postpaid Service支持，在遷移舊有后付費用戶和業(yè)務系統(tǒng)功能的同時，T

16、elfort 2.0需要支持新開展的移動后付費用戶。此時，Telfort 2.0將和原有的預付費系統(tǒng)、In ternet系統(tǒng)共存。第二階段Phase 2：在支持后付費的根底上，遷移預付費。此時，所有的移動用戶將由Telfort2.0支持，但與舊有的In terne t系統(tǒng)共存。第三階段phase 3:遷移In ternet用戶，并支持新增In ternet用戶。這是系統(tǒng)的最終演進結(jié)果 和目標架構(gòu)。2 系統(tǒng)總體描述 0 級視圖2.1 系統(tǒng)總體構(gòu)架我司提供的融合計費解決方案共有 CCBS、OCS、IPCC、BI和外協(xié)幾個產(chǎn)品組成，在邏輯上分為三 層，如下列圖所示:2.1.1 效勞控制層效勞控制層各

17、部件的功能如下:Provision 部件將為客戶效勞層提供網(wǎng)絡的效勞開通接口。Mediation 部件負責采集網(wǎng)絡設備上的話單，同時也負責漫游結(jié)算話單的解碼工作。SCP部件負責話音類業(yè)務的呼叫控制，并觸發(fā)到CBS進行計費處理。UVC 部件負責充值卡管理和對應的充值流程。2.1.2 計費帳務層計費帳務層由CCBS國內(nèi)海外計費帳務統(tǒng)一版本完成。CBS實現(xiàn)對預付費用戶的業(yè)務使用進行預算和實時扣費。對后付費用戶的業(yè)務使用進行批價全觸發(fā)模式后需要實時批價 、出話單、累帳出帳。在計費帳務處理后，將由帳單格式化、帳務管理、欠費催繳模塊完成后續(xù)的帳單生成、繳費銷帳、 以及欠費催繳功能。收入保障采用的是外協(xié) E

18、ctel的產(chǎn)品，包括對非法使用情況的分析、一致性的分析和處理準確性的 校驗功能等。注1：對于話音類業(yè)務，由核心網(wǎng)經(jīng) Camel協(xié)議觸發(fā)到SCP，再由SCP轉(zhuǎn)換成DCC協(xié)議到CBS進行計 費處理。對于其它增值類業(yè)務，由增值業(yè)務平臺采用DCC協(xié)議直接觸發(fā)到CBS進行計費處理。注2：考慮到核心網(wǎng)以及其它業(yè)務系統(tǒng)的性能以及業(yè)務能力的改造，同時結(jié)合我們的分階段實施步 驟，在總體上未采用全觸發(fā)的方案，即預付費采用實時接口觸發(fā)，后付費采用話單方式進行計費。但后付費的數(shù)據(jù)業(yè)務需要通過 DCC到CBS進行鑒權(quán)注3:由于Telfort工程的特殊性，后付費的繳費是采用Telfort的財務系統(tǒng)支持，所以這里采用“Ac

19、count Management的說法，沒有采用海外通常的Account Receivable，以保證與客戶交流的一致性。注4：欠費催繳已經(jīng)明確使用原有的CACS系統(tǒng)，不再由我司提供。注5： E-CARE/E-SHOP可能要與portaI捆綁在一起單獨招標2.1.3 客戶效勞層客戶效勞層主要由CCBS和IPCC兩個產(chǎn)品共同提供，覆蓋 Telfort 2.0所有客戶效勞渠道的日常功 能，包含產(chǎn)品管理、資源管理、業(yè)務受理、業(yè)務變更、綜合查詢、投訴建議等功能。在業(yè)務受理流程中，客戶效勞層一方面將通過效勞控制層的Provision子系統(tǒng)對網(wǎng)絡進行效勞開通，另一方面也將更新計費帳務層的客戶資料、信用度數(shù)

20、據(jù)、產(chǎn)品定購數(shù)據(jù)等信息。同時計費帳務層 也為客戶效勞層提供具體的資費規(guī)那么定義、用戶實時狀態(tài)等信息。版本配套關(guān)系CCBS產(chǎn)品各部件版本配套關(guān)系如下，將基于此版本進行開發(fā):配套產(chǎn)品版本個人業(yè)務受理包括繳費、產(chǎn)品管理TopEng CC&BM V200R003C01B43資源管理TopEng BOSS IM V200R003C01B190訂單管理TopEng BOSS GP V200R003C02B200客戶管理/營銷管理渠道管理/合作伙伴管理系統(tǒng)管理TopEng BOSS BC V200R003C02B110E-careTopEng BOSS E-Care V300R001C02B01Interf

21、aceTopEng BOSS INT V300R001C04B01Rating/BillingTopEng CCBS CHG V300R001C01B07MediationTopEng Mediation V100R002C07B392 + TopEng MediationV100R002C07B392E32F080System MonitoringTopEng System Monitoring V200R003C02B201ProvisionTopEng Provision V100R002C20B0412.2 系統(tǒng)外部接口描述暫不寫作，將引用架構(gòu)與接口相關(guān)交付內(nèi)容系統(tǒng)外部接口總圖如下將根

22、據(jù)架構(gòu)和接口組的最終輸出調(diào)整2.3 系統(tǒng)物理組網(wǎng)(暫不寫作，將引用物理部署內(nèi)容)2.3.1 系統(tǒng)總體物理組網(wǎng)3系統(tǒng)方案設計(1級視圖)3.1 Rating&Billing與PC產(chǎn)品定義配合3.1.1 業(yè)務需求描述先在測試床進行測試資費配置，在測試床進行資費驗證以后，進行生產(chǎn)庫發(fā)布資費配置，此時配置的資費政策(tariff_plan)，同步到營業(yè)的計費資費接口表(billing_plan)，供產(chǎn)品管理進行產(chǎn)品定義。3.1.2 系統(tǒng)功能分解分配3.1.2.1 Rat.001計費資費同步到營業(yè)PC資費接口表計費資費政策(TARIFF_PLAN )的變動通過定時啟動后臺進程方式進行差異同步, 主要同步

23、資費ID與資費名稱的變動，到營業(yè)資費接口表( BILLING_PLAN )。TARIFF_PLANBILLING_PLAN差異檢查字段缺省處理設置Tariff_plandItemid是Tariff_plan_nameItemnamesubstr(tariff_plan_name,1,32)PlantypePlantypeNetworkedGSMIsbaseplan1Status1StatusdateSysdateRegion9993.1.3 接口說明3.1.3.1 內(nèi)部接口接口名稱接口類型接口提供方接口使用方接口說明資費同步接口表接口計費賬務產(chǎn)品管理計費賬務TARIFF_PLAN的資費ID與

24、名稱到產(chǎn)品管理的BILLING_PLAN的 同步處理。3.132夕卜部接口無3.1.4 性能要求無3.2 Rating&Billing與帳務管理提供已批價CDR、Bill配合3.2.1 業(yè)務需求描述計費賬務通過表方式提供未銷帳的后付費賬單，賬務處理與賬務管理共用同一個數(shù)據(jù)庫，后付費賬單通過數(shù)據(jù)庫接口表的方式提供。計費賬務提供賬單明細費用項與GLCODE參照表的維護。已經(jīng)批價話單CDR采用表接口方式提供應賬務管理，不作格式轉(zhuǎn)換。3.2.2 系統(tǒng)功能分解分配3.2.2.1 批價話單提供方式計費賬務已批價話單CDR采用表接口方式提供，不作格式轉(zhuǎn)換。3.2.2.2 后付費賬單提供方式計費賬務提供月結(jié)出

25、帳和立即出帳的后付費賬單，賬務管理直接訪問計費賬務賬單表BILL 和明細賬單表BILLITEM，賬務管理讀取計費的賬單進行銷帳處理并將結(jié)果生成到賬務管理的賬單表，3.2.2.3 GLCODE 處理方式計費賬務提供明細費用項與 GLCODE參照表帳單項定義表 Acctltem_def 的維護。3.2.3 接口說明3.2.3.1 內(nèi)部接口接口名稱接口類型接口提供方接口使用方接口說明批價話單表接口計費賬務賬務管理采用表接口方式提供，不作格式轉(zhuǎn)換后付費賬單表接口計費賬務賬務管理賬務管理直接訪問計費賬務賬單表接口BILL 和明細賬單表BILLITEMGLCODE處理方式表接口計費賬務賬務管理計費賬務提供

26、明細費用項與 GLCODE參照表帳單項定義表 Acctltem_def的維護323.2 外部接口無3.2.4 性能要求無3.3 Rating&Billing 與CC資料接口3.3.1 業(yè)務需求描述營業(yè)受理產(chǎn)生資料的變更，需要向計費賬務進行資料同步方式。由于對業(yè)務的實時性要求的不同， 采用不同的同步方式。對于預付費的激活處理和資費變動時，采用實時同步方式，營業(yè)直接調(diào)用計費 賬務的實時客戶資料刷新的socket接口，同時能夠在資料同步觸發(fā)器中標識出已經(jīng)采用了實時接口。其他業(yè)務采用觸發(fā)器異步處理方式，但是需要營業(yè)支持區(qū)分資料變動的操作類型支持不同的優(yōu)先 級和處理類型。新增操作類型，采用2為字符標識，

27、第一位定義為批量類型，第二位定義受理方式，具體說明如下：第一位：批量類型1- 單筆受理，對應優(yōu)先級高2- 批量受理，對應優(yōu)先級低第二位：受理方式1 -普通受理，更新營業(yè)數(shù)據(jù)庫，通過觸發(fā)器同步到計費2 -實時受理，先更新計費，再更新營業(yè)數(shù)據(jù)庫，不需要進行同步計費3 反向同步，計費已經(jīng)更新，反向同步到營業(yè)，營業(yè)進行相應操作，不再同步到計費。操作類型舉例：營業(yè)單筆普通受理，標志為 11,采用觸發(fā)器同步方式到計費，同步優(yōu)先級高。營業(yè)批量普通受理，標志為 21，采用觸發(fā)器同步方式到計費，同步優(yōu)先級低。批量反向同步處理 ,，標志為 23，觸發(fā)器特殊處理，不生成同步數(shù)據(jù)，只生成核對數(shù)據(jù)，且同步優(yōu) 先級低。計

28、費賬務進行預付費用戶的生命周期管理過程中，預付費用戶狀態(tài)變動，需要由計費賬務反向同步資料到營業(yè)。3.3.2 系統(tǒng)功能分解分配3.3.2.1 CC2RAT.001 營業(yè)到計費的觸發(fā)器資料同步接口Rating&Billing 部件通過表觸發(fā)器方式進行資料同步?？蛻糍Y料上增加資料同步觸發(fā)器，觸發(fā)到計費賬 務的資料增量接口表 custinfo 中，再同步到計費賬務數(shù)據(jù)庫，由計費的客戶資料管理 程序刷新進行增量的數(shù)據(jù)庫和共享內(nèi)存的資料刷新。由于存在普通受理、批量后臺受理、實時資料同步、反向同步等資料同步方式，需要在觸發(fā)器中增加受理的操作類型標識。從而區(qū)分批量受理類型，確定資料處理優(yōu) 先級，通過區(qū)分受理方

29、式，決定資料同步方向。具體實現(xiàn)方式：實現(xiàn)方式采用數(shù)據(jù)庫package全局變量方式2位字符方式。CC 部件營業(yè)受理時進行數(shù)據(jù)庫操作時，先設置數(shù)據(jù)庫package全局變量，Rating提供的觸發(fā)器檢查此全局變量，進行相應的處理。Rating&Billing 部件在同步資料表上增加操作類型字段，觸發(fā)器進行不同判斷處理。計費資料同步觸發(fā)器改造：支持營業(yè)不同受理類型，生成不同接口數(shù)據(jù)。1 判斷批量處理類型，設置同步優(yōu)先級。2 判斷受理方式，確定同步方向。A: 普通受理業(yè)務，生成到計費同步數(shù)據(jù)。B: 實時受理業(yè)務，不生成同步數(shù)據(jù)。C:反向同步業(yè)務，不生成同步數(shù)據(jù)。3.3.2.2 營業(yè)到計費賬務的 sock

30、et 實時資料同步接口Rating&Billing 部件對于預付費的激活、預付費的修改資費，計費賬務提供sockect方式的資料增量同步接口，計費賬務為效勞端，營業(yè)進行客戶端調(diào)用。CC 部件調(diào)用計費提供的同步接口 ,完成預付費的激活 預付費資費修改接口 .3.3.2.3 計費賬務到營業(yè)的反向資料同步接口計費賬務進行預付費用戶的生命周期管理，當用戶狀態(tài)變化時，計費賬務的預付費用戶的狀態(tài)進 行改變包括數(shù)據(jù)庫、共享內(nèi)存變動，同時需要同步到營業(yè)系統(tǒng)，營業(yè)進行相應的處理，當需要進 行停機時，營業(yè)發(fā)送 HLR 指令，當狀態(tài)進入回收狀態(tài)時 po ol ，需要進行銷戶處理，接口方式采用 狀態(tài)變更表方式。計費賬

31、務狀態(tài)變更同步到營業(yè)，營業(yè)進行狀態(tài)變更后，不再會傳給計費賬務。但是由此引起的其 他資料變動，會通過數(shù)據(jù)庫表觸發(fā)方式同步到計費賬務。接口表字段包括：用戶號、狀態(tài)、狀態(tài)變更時間。Rating&Billing 部件 將預付費用戶狀態(tài)的變化 ,寫入狀態(tài)變更接口表 ,同步到營業(yè)系統(tǒng) 修改狀態(tài)變更觸發(fā)器 ,根據(jù)針對這種在計費發(fā)生的狀態(tài)變化不再回傳給計費帳務.但是引起的其他資料變動還是需要通過觸發(fā)器同步到計費帳務 .CC 部件根據(jù)計費帳務傳過來的狀態(tài)變更表 ,進行相應的處理 ,包括 :修改營業(yè)，同時修改上節(jié)提到的package全局變量為23.當需要停開機時 ,發(fā)送相關(guān) HLR 指令當狀態(tài)進入回收狀態(tài)時 po

32、ol， 需要進行銷戶處理修改狀態(tài)變更觸發(fā)器 ，根據(jù)針對這種在計費變化3.3.3 接口說明333.1 內(nèi)部接口接口名稱接口類型接口提供方接口使用方接口說明資料同步觸發(fā)器接口觸發(fā)器方式的表接口營業(yè)計費賬務表觸發(fā)器方式進行資料同步。計費帳 務針對營業(yè)的表寫觸發(fā)器Sockect 資料同步接口Sockect計費賬務營業(yè)計費賬務提供sockect方式的資料增量 同步接口，計費賬務為效勞端，營業(yè) 進行客戶端調(diào)用。預付費用戶狀態(tài)變化反向同步接口表接口計費賬務營業(yè)預付費用戶的生命周期管理產(chǎn)生的狀態(tài)變化。3.3.3.2 外部接口無3.3.4 性能要求無3.4 預付費和后付費互轉(zhuǎn)3.4.1 業(yè)務需求描述預付費用戶與

33、后付費用戶進行互轉(zhuǎn)，涉及的用戶資料的變更、出帳、月結(jié)優(yōu)惠、余額轉(zhuǎn)移的方面 的內(nèi)容。預付費用戶轉(zhuǎn)為后付費用戶時，采用統(tǒng)一的處理邏輯，變更新的賬號，新賬號為后付費賬號，且 采用后付費賬期。后付費用戶轉(zhuǎn)為預付費用戶時，采用用戶號不變，改變賬號的方式進行處理。3.4.2 系統(tǒng)功能分解分配342.1 預付費用戶轉(zhuǎn)為后付費用戶CC部件預付費用戶轉(zhuǎn)為后付費用戶時，考慮用戶感知和資料變動的問題，用戶號不進行變 更。由于需要考慮存在預付費合并付費的情況，因此采用統(tǒng)一的處理邏輯，變更新 的賬號，新賬號為后付費賬號，且采用后付費賬期方案用戶的賬期方案采用此用 戶的主賬號的賬期方案屬性。AR 部件調(diào)用計費帳務提供的邏

34、輯進行預付費余額轉(zhuǎn)移處理Rating&Billing 部件對預付費用戶進行立即出帳，由于新賬號采用后付費賬期方案。因此此時同一個用 戶、賬號的賬單通過不同的賬期方案進行區(qū)分。 解決后付費用戶的月末出帳按照用 戶的費用進行優(yōu)惠處理的問題。 因為賬單中賬期的變化， 后付費費用以及相關(guān)優(yōu)惠， 完全與原預付費的賬單無關(guān)。預付用戶進行實時銷帳，而由于采用新的賬號，需要將預付費用戶的剩余余額進行轉(zhuǎn)移。計費帳務提供業(yè)務邏輯給 AR部件3.4.2.2 后付費用戶轉(zhuǎn)為預付費用戶CC部件后付費用戶轉(zhuǎn)為預付費用戶時，用戶號不進行變更，需要生成新的預付費賬號.預付費賬號采用預付費的賬期方案，此賬期方案與原后付費賬號的

35、賬期方案不同。 賬號改變?yōu)轭A付費賬號，同時新賬號采用預付費賬務周期方案。后付費賬號不立即出帳，等待一定時間以后進行出帳，在此期間產(chǎn)生的遲到漫游話 單，要求合賬到后付費賬號上。后付費賬號的賬單進行單獨出帳賬期方案不同。Rating&Billing 部件對于轉(zhuǎn)為預付費用戶的原后付費用戶的出帳，由于沒有變更用戶號，因此需要特殊處理。出帳以后的遲到話單，需要匹配話單的效勞開始時間獲取用戶號和賬號，并且能夠 將此話單合到原后付費賬號的賬單上。后付費用戶月租按天收取的情況下，在后轉(zhuǎn)預后可能仍需計算后付費用戶的租費， 但此費用的發(fā)生時間在轉(zhuǎn)換之后，對于對于此時互轉(zhuǎn)的用戶，需要進行特殊處理， 生成的固定費用和

36、優(yōu)惠記錄的效勞開始時間應該設置為用戶進行互轉(zhuǎn)前，此時嚴格 按照時間匹配合到后付費帳戶 由于后付費用戶不能進行實時銷帳，互轉(zhuǎn)用戶的后付費賬號的預存款不能進行余額 轉(zhuǎn)移，需要出帳銷帳以后再進行處理。因此后付費用戶轉(zhuǎn)為預付費用戶，在轉(zhuǎn)換過 程中不進行余額或預存款轉(zhuǎn)移。目前的合賬處理時，采用處理時間進行賬號匹配，不支持按效勞開始時間進行匹配賬號。計費賬務主要改造點：合賬支持效勞開始時間匹配賬號。合賬支持處理時間匹配賬號。以上兩種處理方式可以根據(jù)局方要求進行設置。以上兩種處理方式可以根據(jù)受理不同的業(yè)務，支持設置不同的合賬方式。例如 后轉(zhuǎn)預：遲到話單合到老賬號。后付費用戶之間的過戶，可以合到老賬號，也支持

37、合到新賬號。343接口說明343.1 內(nèi)部接口接口名稱接口類型接口提供方接口使用方接口說明343.2 外部接口無3.4.4 性能要求無3.5Rating&Billing支持帳戶級優(yōu)惠3.5.1 業(yè)務需求描述計費賬務需要支持帳戶級的賬務級優(yōu)惠與話單級優(yōu)惠。用戶的優(yōu)惠加載在用戶的主帳戶資料上，主賬號下的每個用戶均享受此類優(yōu)惠。需要支持的優(yōu)惠主要有互打優(yōu)惠，累計贈送優(yōu)惠，累計贈送的共享優(yōu)惠。3.5.2 系統(tǒng)功能分解分配3.5.2.1 同一個主賬號下的用戶的互打優(yōu)惠Rating&Billing 部件設置一個種特定優(yōu)惠 , 此種優(yōu)惠加載帳戶，實現(xiàn)賬戶內(nèi)用戶互打優(yōu)惠，修改程序支持 PC部件將此類優(yōu)惠配置為

38、帳務級優(yōu)惠 .3.5.2.2 帳戶級月結(jié)優(yōu)惠優(yōu)惠加載賬戶，月結(jié)優(yōu)惠處理，目前已經(jīng)支持。3.5.2.3 帳戶級話單優(yōu)惠1帳戶級話單優(yōu)惠，資費加載到賬號上，需要優(yōu)惠處理賬號下的每個用戶(無累計、贈送要求， 如互打)。2帳戶級話單優(yōu)惠，資費加載到賬號上，需要優(yōu)惠處理賬號下的每個用戶，累計、贈送屬性存儲 在帳戶資料的使用量表上，采用共享方式( SHAREPOOL )處理。3帳戶級話單優(yōu)惠，資費加載到賬號上，需要資費處理賬號下的每個用戶，累計、贈送為每個用 戶獨立使用，不進行共享處理。資費加載到帳戶，累計、贈送用戶級計費賬務進行處理。累計不需修改程序，贈送量的管理需要支持。月結(jié)資費送贈送，只需要修改用戶

39、資費獲取邏輯。同理，固定費用計算也支持此 類處理。資料中需要標識出此類資費特性。即：資費在帳戶資料上，固定費用、累計贈送等的使用在用戶資料上，需要營業(yè)同步資料時 能夠標識。4。帳戶級話單資費，資費加載到用戶上，累計、贈送存儲在帳戶資料的使用量表上，采用共享方 式( SHAREPOOL )處理(目前無實際場景)。用戶的贈送管理和累計量的處理，在資料中標識出需要累計到帳戶的共享屬性中，而且贈送量的 管理同樣需要加載在帳戶的使用量屬性上。3.524帳戶級資費的贈送量管理支持帳戶級資費的共享贈送量處理。支持帳戶級資費的單個用戶的贈送量管理。支持帳戶級資費的贈送累計，按天分攤大小賬期，建議采用整月生效處

40、理，躲避分攤。支持帳戶級資費失效失效時的贈送量流出管理。需討論3.5.2.5帳戶級資費固定費用計算支持只收取到帳戶的帳戶級資費的固定費用計算。支持實例化到每個用戶的帳戶級資費的固定費用計算。3.526帳戶級資費的資料接口處理帳戶級資費生成贈送量，和處理用戶級資費生成共享帳戶的贈送量。營業(yè)采用帳戶級的資費定購處理，同時增加附加參數(shù)。資料同步和月末贈送時，需要判斷附加參 數(shù)進行固定費用計算、贈送量管理、話單級優(yōu)惠處理。具體接口為:1. 賬號2. 資費編碼3. 附加屬性假設資費為話單級贈送時，以下屬性意義如下：aN = 0此類資費中，用戶的贈送量需要實例化的具體用戶，包月費收取也實例化到 用戶，話單

41、級優(yōu)惠bN0 此類資費中，贈送量共享，包月費收取N份到帳戶，話單級優(yōu)惠4. 生效時間5. 結(jié)束時間3.5.3 接口說明3.5.3.1 內(nèi)部接口接口名稱接口類型接口提供方接口使用方接口說明帳戶級資費 資料同步接 口觸發(fā)器方式的表接口營業(yè)計費賬務處理帳戶級資費生成贈送量，和處理 用戶級資費生成共享帳戶的贈送量。 營業(yè)采用帳戶級的資費定購處理，同 時增加附加參數(shù)。資料同步和月末贈送時，需要判斷附加參數(shù)進行固定費 用計算、贈送量管理、話單級優(yōu)惠處 理。計費帳務針對營業(yè)的表寫觸發(fā)器3.532外部接口無3.5.4 性能要求無3.6預付費用戶的實時銷帳3.6.1 業(yè)務需求描述預付費用戶采用簡單余額的實時銷帳

42、模式，只支持簡單賬本復雜賬本后續(xù)版本支持，賬本模 型與后付費不一致，通過帳號的prepaytype類型區(qū)分后付費和預付費。計費賬務在合賬時，進行實時的銷帳，銷帳處理邏輯：合賬時觸發(fā)實時銷帳，實時銷帳采用銷減accou nt上的簡單余額和銷減賬本的余額的方式，不會更新詳細賬單。在營業(yè)受理用戶繳費相關(guān)業(yè)務時，調(diào)用AR接口增加帳號的prepaytype類型的傳遞，在AR效勞端中根據(jù)帳號的prepaytype類型來決定走不同的邏輯分支后付費用戶，走原boss中AR提供的業(yè)務邏輯賬務管理與賬務處理為同一個數(shù)據(jù)庫的兩個不同用戶，原boss中AR提供的業(yè)務邏輯和billing提供新的處理邏輯的API接口中處

43、理邏輯，都使用現(xiàn)在 AR的數(shù)據(jù)庫模型，只是帳號根據(jù) prepaytype類型不同 而各自負責自己的數(shù)據(jù)記錄。接口中的涉及到兩類帳號間prepaytype類型不同的兩個帳號的業(yè)務主要是余額轉(zhuǎn)移、過戶轉(zhuǎn) 帳單、余額轉(zhuǎn)移等，需要分別調(diào)用原boss中AR提供的業(yè)務邏輯和billing提供新的處理邏輯的 API接口， 分別處理各自的數(shù)據(jù)。預付費用戶，調(diào)用billing提供新的處理邏輯的 API接口 billing提供處理邏輯，該局部代碼直接 嵌入在AR效勞中，主要處理邏輯如下：通過營業(yè)繳費或繳費回退時，判斷帳戶類型，假設為預付費，修改預付費帳戶的賬本，同時更新account表上的簡單余額字段，并進行繳費

44、優(yōu)惠和預付費生命周期管理等操作，生成繳費刷 新接口表，由賬務處理通過此接口表數(shù)據(jù)進行異步賬單資料的刷新共享內(nèi)存余額刷新。 假設為后付費用戶，賬務管理采用原處理邏輯。通過dec接口進行預付費用戶充值時，計費賬務直接修改內(nèi)存和數(shù)據(jù)庫的預付費帳戶的余額和 賬本，并生成繳費日志，繳費日志同步到營業(yè)數(shù)據(jù)庫。賬務管理的余額查詢采用數(shù)據(jù)庫方式進行查詢，判斷帳戶預付后付屬性，假設為預付費時，直接讀取account表時的簡單余額返回，假設為后付費時，采用目前國內(nèi)處理邏輯。進行余額轉(zhuǎn)移時，賬務管理直接讀取預付費用戶的賬本，此時賬本上的余額為該預付費用戶的實時銷帳后的賬本余額。余額流出時，需要同步修改accou n

45、t上的簡單余額。賬務管理調(diào)整賬單變更，需要判斷帳戶上預付后付屬性，假設為預付費帳戶，那么需要在調(diào)整賬單費用的同時，同步修改 accou nt上的簡單余額。后付費用戶，采用目前國內(nèi)處理邏輯。3.6.2 系統(tǒng)功能分解分配3.6.2.1 預付費用戶實時銷帳Rating&Billing 部件賬務處理合賬時，對預付費用戶的賬本與 account上的余額進行銷減。不在 billitem上 進行銷帳。3.6.2.2 預付費后付費判斷方式AR 部件帳務管理和計費帳務共用的 Accou nt表上增加預付后付屬性字段，通過此字段區(qū)分帳 戶的后付和預付屬性，此字段屬性由賬務管理維護。3.6.2.3 營業(yè)繳費與回退A

46、R 部件帳務管理修改預付費用戶的繳費與繳費回退處理邏輯，判斷帳戶類型，假設為預付費，修改預付費帳戶的賬本，同時更新accou nt表上的簡單余額字段，生成繳費刷新接口 表;調(diào)用賬務處理提供的繳費優(yōu)惠贈送處理邏輯，處理預付費用戶的繳費贈送和預付 費生命周期管理等操作。假設為后付費用戶，賬務管理采用原處理邏輯。Rating&Billing 部件帳務處理通對帳務管理產(chǎn)生的繳費刷新接口表數(shù)據(jù)進行異步賬單資料的刷新共享 內(nèi)存余額刷新以上處理均在數(shù)據(jù)庫進行操作，通過接口表繳費刷新接口、客戶資料接口表方式進行異步的 數(shù)據(jù)庫和內(nèi)存的同步預付費用戶的同步余額、賬本、有效期等3.6.2.4 Dcc 預付費充值流程

47、Rating&Billing 部件計費賬務通過dec接口進行預付費用戶充值時，計費賬務直接修改內(nèi)存和數(shù)據(jù)庫的預 付費帳戶的余額和賬本，調(diào)用繳費優(yōu)惠存儲過程處理繳費贈送，并生成繳費日志， 繳費日志反向同步到營業(yè)數(shù)據(jù)庫。3.6.2.5 余額查詢流程AR 部件帳務管理的余額查詢采用數(shù)據(jù)庫方式進行查詢，判斷帳戶預付后付屬性，假設為預付 費時，直接讀取aceoun俵時的簡單余額返回，假設為后付費時，采用目前國內(nèi)處理邏 輯。3.6.2.6 余額轉(zhuǎn)移流程AR 部件進行余額轉(zhuǎn)移時，賬務管理直接讀取預付費用戶的賬本，此時賬本上的余額為該預 付費用戶的實時銷帳后的賬本余額。余額流出時，需要同步修改aceou nt

48、上的簡單余額。3.6.2.7 調(diào)整賬單AR 部件帳務管理調(diào)整賬單變更，需要判斷帳戶上預付后付屬性，假設為預付費帳戶，那么需要 在調(diào)整賬單費用的同時，同步修改accou nt上的簡單余額。后付費用戶，采用目前國內(nèi)處理邏輯。362.8后付費余額信控余額計算Rating&Billing 部件預付費用戶采用簡單余額的實時銷帳處理方案，而后付費用戶采用目前國內(nèi)處理方 式。因此計費賬務針對帳戶的預付后付屬性，進行不同信控用戶計算方式。針對telfort局方，預付費用戶采用簡單余額方式，信控余額直接采用account的簡單余額。對于后付費用戶，采用國內(nèi)后付費方式的信控余額。3.6.3 接口說明3.6.3.1

49、 內(nèi)部接口接口名稱接口類型接口提供方接口使用方接口說明繳費日志反 向同步接口表接口營業(yè)計費賬務營業(yè)分配給計費賬單繳費日志的寫權(quán) 限，由計費賬務反向?qū)ec繳費日志同 步到營業(yè)數(shù)據(jù)庫中，供營業(yè)查詢處理。余額查詢表接口計費賬務營業(yè)預付費用戶余額查詢，直接查詢account表上的簡單余額3.6.3.2 外部接口無3.6.4 性能要求無3.7 后付費用戶的信控處理方式3.7.1 業(yè)務需求描述后付費用戶的信控，以用戶當前處理時間對應賬期的未出帳費用總額或總累計量作為參考，進行 信控的處理。而目前的信控方式，采用帳戶的信控余額進行參考計算帳戶的信控狀態(tài)，假設新舊狀態(tài)變 化，那么下發(fā)信控指令，將此帳戶狀態(tài)變

50、化傳遞到營業(yè)進行信控指令的執(zhí)行。修改計費賬務的信控處理方式，信控參數(shù) CREDIT_CONTROL_SCHEMA 增加參照量類型字段 ref_type ，缺省字段為空，表示參照為信控余額 ,此字段填寫參考費用組。修改處理邏輯，假設此字段 非空時，獲得當前帳戶當前賬期的對應費用組的總量數(shù)據(jù)作為參考進行信控處理。對于后付費用戶的信控，采用特殊的信控模式，此類信控模式設置ref_type 為指定費用組，信控處理根據(jù)此字段提取參照信息信控余額或費用組進行信控處理。每個賬期初始時，掃描對應賬期后付費用戶的信控狀態(tài)，將非正常用戶插入信控接口表，觸發(fā)信 控處理，到達月初費用復位的信控處理的開機處理。3.7.

51、2 系統(tǒng)功能分解分配3.7.2.1 信控處理支持以費用組做參考量。PC部件設定相關(guān)FUP產(chǎn)品，指定其信控模式為“參照費用組信控對選擇FUP產(chǎn)品的用戶指定其信控模式為“參照費用組Rating&Billing 部件修改計費賬務的信控處理方式，信控參數(shù) CREDIT_CONTROL_SCHEMA 增加參 照量類型字段ref_type,缺省字段為空，表示參照為信控余額，此字段填寫參考費用組。3.7.2.2 帳期初期費用復位信控處理Rating&Billing 部件每個賬期初始時，掃描對應賬期后付費用戶的信控狀態(tài)，將非正常用戶插入信控接 口表，觸發(fā)信控處理，到達月初費用復位的信控處理的開機處理。3.7.

52、3接口說明3.731內(nèi)部接口接口名稱接口類型接口提供方接口使用方接口說明信控下發(fā)接口表接口計費賬務營業(yè)計費賬務將帳戶的狀態(tài)變更的信控指 令以表的方式下發(fā)到營業(yè)，由營業(yè)進 行信控處理。3.7.3.2 外部接口無3.7.4 性能要求無3.8 NP計費匹配方案3.8.1 業(yè)務需求描述由于離線話單和在線消息中，不能獲得對方號碼的運用商信息，因此需要計費通過查表方式獲取 對方號碼的運營商信息。但對方運營商的總量數(shù)據(jù)過于龐大，不能簡單地作為參數(shù)數(shù)據(jù)通過值映射 關(guān)系進行映射處理。同時由于某些類型話單不含IMSI，所以也不能以IMSI作為對方運營商判定的依據(jù)。方案采用將NP數(shù)據(jù)作為虛擬用戶資料的進行管理，單獨

53、維護一個虛擬地區(qū)如888地區(qū)的資料。此類虛擬用戶資料只包含兩個屬性，號碼屬性和歸屬運營商屬性，用戶號格式采用【地區(qū)前綴+填充 假設干0+ 號碼】的方式生成。NP號碼的增量變化，轉(zhuǎn)換為運營商屬性的變更，通過客戶資料刷新進行管理。預處理過程中，通過匹配對方號碼虛擬地區(qū)資料的屬性的方式獲取對方運營商信息。3.8.2 系統(tǒng)功能分解分配3.8.2.1 全量數(shù)據(jù)轉(zhuǎn)換虛擬地區(qū)：888 用戶號：888 0000 1234566用戶資料屬性(subscriber_attr)號碼屬性： 號碼資料裝載時，建立索引運營商業(yè)屬性：對于 號碼變更歷史數(shù)據(jù)遷移組需進行初始的全量數(shù)據(jù)轉(zhuǎn)換。3.822 增量數(shù)據(jù)修改接口部件接收COIN傳遞過來的號碼運營商屬性變動通知