Telfort融合计费项目总体设计方案V精选

1、2Huawei Tech no logies Co. Ltd.华为技术Product versi on产品版本Con fide ntiality level 密级秘密Total pages : 共167页Telfort 2.0工程总体技术方案Prepared by拟制Telfort 2.0分析设计组Date日期yyyy-mm-ddReviewed byDateyyyy-mm-dd评审人日期Approved byDateyyyy-mm-dd批准日期Authorized byDateyyyy-mm-dd签发日期Huawei Technologies Co.，Ltd.华为技术All rights r

2、eserved版权所有侵权必究Revisi on record修订记录Date日期Revisi onVersi on修订版本CR ID / DefectID CR号Section Number 修改 早节Change Description修改描述Author作者2021-09-120.10根据各专题的写作和检视结果，初稿合并 完成Telfort 2.0分析设计组2021-10-040.20根据客户CR修正局部描述。1. DC模块将被客户的 CACS替换2. FM将被KPN系统替换局部功能的修改1、帐户优惠方案的修改2、接触管理的修改和批注与 IPCC部 分信息未达成一致3、MDS方案修改4、

3、Real time chari ng5、修改订单落地方案，增加设计方案和 增加订单查询及订单修改6、 补充 SCP 与 Rating&Billing集成方 案语音计费、 VMS计费以及AOC 等业务7、预付费生命周期管理增加功能分解：1、扫描件的存储和管理Telfort 2.0分析设计组Distribution LIST 分发记录Copy No.Holders Name & Role持有者和角色Issue Date分发日期1yyyy-mm-dd2yyyy-mm-dd3yyyy-mm-dd4yyyy-mm-ddCatalog 目 录Keywords关键词：Telfort、CCBS、CBS、总体设

4、计方案Abstract 摘 要：本文档主要描述Telfort 2.0融合计费工程的系统构成、部件部署、关键业务流程 和方案、内外部接口说明，以及系统整体的需求包和需求分解。在结合Telfort 2.0的外部系统环境进行方案分析和设计的根底上，本文档侧重在Huawei解决方案内部的设计说明，Huawei解决方案与Telfort外部系统的方案将在与局方的系统架构和接口文档中进行说明。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综合客户管理系统，包括Custom Care、 Billing&Bill Formatting 、AR、DC、PC、 PRM、Mediation、Provision、InventoryBOSSBusin ess & Operati on Support ingSystem业务运营支撑系统，是中国移动的称谓。文中指CCBS。CCCustom Care客户关心管理模块:ARAcco unt Receivable应收款管理模块DCDebt Collectio n催欠管理模块PCPricing C

6、atalogue产品目录管理模块BFBill Formatt ing帐单格式化模块ProProvisi on效劳开通模块MDMediation米集预处理模块InvInven tory资源管理模块DWHData Warehouse数据仓库CBSCon verge nee Billi ng System融合计费系统，包括预付费和后付费OCSOn li ne Charg ing System在线计费系统EBITDAEarnings Before In terest, Taxes,Depreciatio n and Amortizati on利息、税收和折旧、摊销前收入TTMTime to Marke

7、t上市时间TCOTotal Cost of Own ership总拥有本钱SMESmall Medium En terprises中小企业ESPEnhanced Service Provider增强效劳提供商工程背景1.1 Telfort 现状介绍Telfort 是于 1997年在荷兰成立的一家独立移动运营商，他将自己定位于移动市场的挑战者。在2005年Telfort被荷兰最大的固定/移动运营商KPN收购。收购后两家的网络架构进行了整合，Telfort将会把其网络迁移到 KPN。今天Telfort已经成为KPN整体品牌下的挑战品牌。 Telfort将作为关注价格细 分市场的增强效劳提供商ESP

8、，这是KPN对Telfort品牌和历史定位。同时，KPN在2006年收购了荷兰的In ternet效劳提供商荷兰 Tiscali i nternatio nal Tiscali group的一部分，并重新进行品牌包装交由Telfort管理和运营。因此，Telfort同时包括Mobile和In ternet业务。为提高Telfort的EBITDA，同时也为了支撑其在 Mobile和In ternet业务的融合以及对应组织结构和人员进行调整，Telfort需要在其IT支撑系统上进行改造，目标包括有：Faster time to market TTM Lower TCO of IT本次的支撑系统范围

9、为融合的 CRM & Billing系统，也就是Telfort 2.0工程。注：在此前，有Telfort 1.0工程，只涵盖预付费业务局部，目前尚未实施，将被同时包括在Telfort 2.0中，所以 Telfort 2.0是个预付费融合、 Mobile/Internet 融合的 CRM & Billing 解决方案1.1.1 Telfort Mobile目前的 Telfort 移动根底设施的特点是：大量的应用众多专有接口一个复杂的系统架构系统支离破碎，数据冗余在多个系统，数据复制不总是完全正确复制 复杂系统的堆栈含有大量的冗余功能，例如不同的系统大致相同的功能是用于消费者和企业的局部，这导致了

10、以下结果：本钱高需要较多人力操作，质量保证，投诉处理系统维护复杂 产品的灵活性低，响应市场时间长开发新产品 /效劳时需要复杂的，定制的接口开发没有E2E效劳保证收入保障流程复杂客户操作复杂，很难实施有效的客户的自助效劳Telfort 当前移动业务支撑系统架构如下(由欧洲厂商 Capgimini 等提供管理效劳)：1.1.2 Telfort internet由于历史的原因荷兰 Tiscali的Customer Care和billing系统被外包给 Tiscali services管理，Tiscaliservices的平台为多个国家效劳，外包合同将在09年6月份结束，开发商为：?Billing:

11、Geneva?CRM: Siebel1.2 目标业务Telfort 2.0需要支撑的(主要)业务包括如下，其中，移动业务中包含预付费和后付费业务，对于In ternet业务，仅仅包括后付费业务：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 ,对于具有复杂组织结构、特殊网络业务类型的集团客户不在 支持的范围

13、之内。再有，由于Telfort本身作为KPN的一个增强效劳提供商，所以原那么上针对其它ESP、MVNO业务的支持不在Telfort 2.0范围之内，但由于考虑到网络和系统的变迁方便，针对话单处理、效劳开通局部可 能会涉及我们的Mediation和Provision，需要参考更详细的方案设计内容。1.3 目标用户数整个系统需要支撑到 Telfort今后5年的业务开展即从 2021年到2021年，在这个过程中，系统需支撑的用户数预计如下表所示：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 实施阶段按照业务和网络情况考虑，整个工程将会分三个阶段实施：第一阶段phase 1: Mobile Postpaid Service支持，在迁移旧有后付费用户和业务系统功能的同时，T

16、elfort 2.0需要支持新开展的移动后付费用户。此时，Telfort 2.0将和原有的预付费系统、In ternet系统共存。第二阶段Phase 2：在支持后付费的根底上，迁移预付费。此时，所有的移动用户将由Telfort2.0支持，但与旧有的In terne t系统共存。第三阶段phase 3:迁移In ternet用户，并支持新增In ternet用户。这是系统的最终演进结果 和目标架构。2 系统总体描述 0 级视图2.1 系统总体构架我司提供的融合计费解决方案共有 CCBS、OCS、IPCC、BI和外协几个产品组成，在逻辑上分为三 层，如下列图所示:2.1.1 效劳控制层效劳控制层各

17、部件的功能如下:Provision 部件将为客户效劳层提供网络的效劳开通接口。Mediation 部件负责采集网络设备上的话单，同时也负责漫游结算话单的解码工作。SCP部件负责话音类业务的呼叫控制，并触发到CBS进行计费处理。UVC 部件负责充值卡管理和对应的充值流程。2.1.2 计费帐务层计费帐务层由CCBS国内海外计费帐务统一版本完成。CBS实现对预付费用户的业务使用进行预算和实时扣费。对后付费用户的业务使用进行批价全触发模式后需要实时批价 、出话单、累帐出帐。在计费帐务处理后，将由帐单格式化、帐务管理、欠费催缴模块完成后续的帐单生成、缴费销帐、 以及欠费催缴功能。收入保障采用的是外协 E

18、ctel的产品，包括对非法使用情况的分析、一致性的分析和处理准确性的 校验功能等。注1：对于话音类业务，由核心网经 Camel协议触发到SCP，再由SCP转换成DCC协议到CBS进行计 费处理。对于其它增值类业务，由增值业务平台采用DCC协议直接触发到CBS进行计费处理。注2：考虑到核心网以及其它业务系统的性能以及业务能力的改造，同时结合我们的分阶段实施步 骤，在总体上未采用全触发的方案，即预付费采用实时接口触发，后付费采用话单方式进行计费。但后付费的数据业务需要通过 DCC到CBS进行鉴权注3:由于Telfort工程的特殊性，后付费的缴费是采用Telfort的财务系统支持，所以这里采用“Ac

19、count Management的说法，没有采用海外通常的Account Receivable，以保证与客户交流的一致性。注4：欠费催缴已经明确使用原有的CACS系统，不再由我司提供。注5： E-CARE/E-SHOP可能要与portaI捆绑在一起单独招标2.1.3 客户效劳层客户效劳层主要由CCBS和IPCC两个产品共同提供，覆盖 Telfort 2.0所有客户效劳渠道的日常功 能，包含产品管理、资源管理、业务受理、业务变更、综合查询、投诉建议等功能。在业务受理流程中，客户效劳层一方面将通过效劳控制层的Provision子系统对网络进行效劳开通，另一方面也将更新计费帐务层的客户资料、信用度数

20、据、产品定购数据等信息。同时计费帐务层 也为客户效劳层提供具体的资费规那么定义、用户实时状态等信息。版本配套关系CCBS产品各部件版本配套关系如下，将基于此版本进行开发:配套产品版本个人业务受理包括缴费、产品管理TopEng CC&BM V200R003C01B43资源管理TopEng BOSS IM V200R003C01B190订单管理TopEng BOSS GP V200R003C02B200客户管理/营销管理渠道管理/合作伙伴管理系统管理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 系统外部接口描述暂不写作，将引用架构与接口相关交付内容系统外部接口总图如下将根

22、据架构和接口组的最终输出调整2.3 系统物理组网(暂不写作，将引用物理部署内容)2.3.1 系统总体物理组网3系统方案设计(1级视图)3.1 Rating&Billing与PC产品定义配合3.1.1 业务需求描述先在测试床进行测试资费配置，在测试床进行资费验证以后，进行生产库发布资费配置，此时配置的资费政策(tariff_plan)，同步到营业的计费资费接口表(billing_plan)，供产品管理进行产品定义。3.1.2 系统功能分解分配3.1.2.1 Rat.001计费资费同步到营业PC资费接口表计费资费政策(TARIFF_PLAN )的变动通过定时启动后台进程方式进行差异同步, 主要同步

23、资费ID与资费名称的变动，到营业资费接口表( BILLING_PLAN )。TARIFF_PLANBILLING_PLAN差异检查字段缺省处理设置Tariff_plandItemid是Tariff_plan_nameItemnamesubstr(tariff_plan_name,1,32)PlantypePlantypeNetworkedGSMIsbaseplan1Status1StatusdateSysdateRegion9993.1.3 接口说明3.1.3.1 内部接口接口名称接口类型接口提供方接口使用方接口说明资费同步接口表接口计费账务产品管理计费账务TARIFF_PLAN的资费ID与

24、名称到产品管理的BILLING_PLAN的 同步处理。3.132夕卜部接口无3.1.4 性能要求无3.2 Rating&Billing与帐务管理提供已批价CDR、Bill配合3.2.1 业务需求描述计费账务通过表方式提供未销帐的后付费账单，账务处理与账务管理共用同一个数据库，后付费账单通过数据库接口表的方式提供。计费账务提供账单明细费用项与GLCODE参照表的维护。已经批价话单CDR采用表接口方式提供应账务管理，不作格式转换。3.2.2 系统功能分解分配3.2.2.1 批价话单提供方式计费账务已批价话单CDR采用表接口方式提供，不作格式转换。3.2.2.2 后付费账单提供方式计费账务提供月结出

25、帐和立即出帐的后付费账单，账务管理直接访问计费账务账单表BILL 和明细账单表BILLITEM，账务管理读取计费的账单进行销帐处理并将结果生成到账务管理的账单表，3.2.2.3 GLCODE 处理方式计费账务提供明细费用项与 GLCODE参照表帐单项定义表 Acctltem_def 的维护。3.2.3 接口说明3.2.3.1 内部接口接口名称接口类型接口提供方接口使用方接口说明批价话单表接口计费账务账务管理采用表接口方式提供，不作格式转换后付费账单表接口计费账务账务管理账务管理直接访问计费账务账单表接口BILL 和明细账单表BILLITEMGLCODE处理方式表接口计费账务账务管理计费账务提供

26、明细费用项与 GLCODE参照表帐单项定义表 Acctltem_def的维护323.2 外部接口无3.2.4 性能要求无3.3 Rating&Billing 与CC资料接口3.3.1 业务需求描述营业受理产生资料的变更，需要向计费账务进行资料同步方式。由于对业务的实时性要求的不同， 采用不同的同步方式。对于预付费的激活处理和资费变动时，采用实时同步方式，营业直接调用计费 账务的实时客户资料刷新的socket接口，同时能够在资料同步触发器中标识出已经采用了实时接口。其他业务采用触发器异步处理方式，但是需要营业支持区分资料变动的操作类型支持不同的优先 级和处理类型。新增操作类型，采用2为字符标识，

27、第一位定义为批量类型，第二位定义受理方式，具体说明如下：第一位：批量类型1- 单笔受理，对应优先级高2- 批量受理，对应优先级低第二位：受理方式1 -普通受理，更新营业数据库，通过触发器同步到计费2 -实时受理，先更新计费，再更新营业数据库，不需要进行同步计费3 反向同步，计费已经更新，反向同步到营业，营业进行相应操作，不再同步到计费。操作类型举例：营业单笔普通受理，标志为 11,采用触发器同步方式到计费，同步优先级高。营业批量普通受理，标志为 21，采用触发器同步方式到计费，同步优先级低。批量反向同步处理 ,，标志为 23，触发器特殊处理，不生成同步数据，只生成核对数据，且同步优 先级低。计

28、费账务进行预付费用户的生命周期管理过程中，预付费用户状态变动，需要由计费账务反向同步资料到营业。3.3.2 系统功能分解分配3.3.2.1 CC2RAT.001 营业到计费的触发器资料同步接口Rating&Billing 部件通过表触发器方式进行资料同步。客户资料上增加资料同步触发器，触发到计费账 务的资料增量接口表 custinfo 中，再同步到计费账务数据库，由计费的客户资料管理 程序刷新进行增量的数据库和共享内存的资料刷新。由于存在普通受理、批量后台受理、实时资料同步、反向同步等资料同步方式，需要在触发器中增加受理的操作类型标识。从而区分批量受理类型，确定资料处理优 先级，通过区分受理方

29、式，决定资料同步方向。具体实现方式：实现方式采用数据库package全局变量方式2位字符方式。CC 部件营业受理时进行数据库操作时，先设置数据库package全局变量，Rating提供的触发器检查此全局变量，进行相应的处理。Rating&Billing 部件在同步资料表上增加操作类型字段，触发器进行不同判断处理。计费资料同步触发器改造：支持营业不同受理类型，生成不同接口数据。1 判断批量处理类型，设置同步优先级。2 判断受理方式，确定同步方向。A: 普通受理业务，生成到计费同步数据。B: 实时受理业务，不生成同步数据。C:反向同步业务，不生成同步数据。3.3.2.2 营业到计费账务的 sock

30、et 实时资料同步接口Rating&Billing 部件对于预付费的激活、预付费的修改资费，计费账务提供sockect方式的资料增量同步接口，计费账务为效劳端，营业进行客户端调用。CC 部件调用计费提供的同步接口 ,完成预付费的激活 预付费资费修改接口 .3.3.2.3 计费账务到营业的反向资料同步接口计费账务进行预付费用户的生命周期管理，当用户状态变化时，计费账务的预付费用户的状态进 行改变包括数据库、共享内存变动，同时需要同步到营业系统，营业进行相应的处理，当需要进 行停机时，营业发送 HLR 指令，当状态进入回收状态时 po ol ，需要进行销户处理，接口方式采用 状态变更表方式。计费账

31、务状态变更同步到营业，营业进行状态变更后，不再会传给计费账务。但是由此引起的其 他资料变动，会通过数据库表触发方式同步到计费账务。接口表字段包括：用户号、状态、状态变更时间。Rating&Billing 部件 将预付费用户状态的变化 ,写入状态变更接口表 ,同步到营业系统 修改状态变更触发器 ,根据针对这种在计费发生的状态变化不再回传给计费帐务.但是引起的其他资料变动还是需要通过触发器同步到计费帐务 .CC 部件根据计费帐务传过来的状态变更表 ,进行相应的处理 ,包括 :修改营业，同时修改上节提到的package全局变量为23.当需要停开机时 ,发送相关 HLR 指令当状态进入回收状态时 po

32、ol， 需要进行销户处理修改状态变更触发器 ，根据针对这种在计费变化3.3.3 接口说明333.1 内部接口接口名称接口类型接口提供方接口使用方接口说明资料同步触发器接口触发器方式的表接口营业计费账务表触发器方式进行资料同步。计费帐 务针对营业的表写触发器Sockect 资料同步接口Sockect计费账务营业计费账务提供sockect方式的资料增量 同步接口，计费账务为效劳端，营业 进行客户端调用。预付费用户状态变化反向同步接口表接口计费账务营业预付费用户的生命周期管理产生的状态变化。3.3.3.2 外部接口无3.3.4 性能要求无3.4 预付费和后付费互转3.4.1 业务需求描述预付费用户与

33、后付费用户进行互转，涉及的用户资料的变更、出帐、月结优惠、余额转移的方面 的内容。预付费用户转为后付费用户时，采用统一的处理逻辑，变更新的账号，新账号为后付费账号，且 采用后付费账期。后付费用户转为预付费用户时，采用用户号不变，改变账号的方式进行处理。3.4.2 系统功能分解分配342.1 预付费用户转为后付费用户CC部件预付费用户转为后付费用户时，考虑用户感知和资料变动的问题，用户号不进行变 更。由于需要考虑存在预付费合并付费的情况，因此采用统一的处理逻辑，变更新 的账号，新账号为后付费账号，且采用后付费账期方案用户的账期方案采用此用 户的主账号的账期方案属性。AR 部件调用计费帐务提供的逻

34、辑进行预付费余额转移处理Rating&Billing 部件对预付费用户进行立即出帐，由于新账号采用后付费账期方案。因此此时同一个用 户、账号的账单通过不同的账期方案进行区分。 解决后付费用户的月末出帐按照用 户的费用进行优惠处理的问题。 因为账单中账期的变化， 后付费费用以及相关优惠， 完全与原预付费的账单无关。预付用户进行实时销帐，而由于采用新的账号，需要将预付费用户的剩余余额进行转移。计费帐务提供业务逻辑给 AR部件3.4.2.2 后付费用户转为预付费用户CC部件后付费用户转为预付费用户时，用户号不进行变更，需要生成新的预付费账号.预付费账号采用预付费的账期方案，此账期方案与原后付费账号的

35、账期方案不同。 账号改变为预付费账号，同时新账号采用预付费账务周期方案。后付费账号不立即出帐，等待一定时间以后进行出帐，在此期间产生的迟到漫游话 单，要求合账到后付费账号上。后付费账号的账单进行单独出帐账期方案不同。Rating&Billing 部件对于转为预付费用户的原后付费用户的出帐，由于没有变更用户号，因此需要特殊处理。出帐以后的迟到话单，需要匹配话单的效劳开始时间获取用户号和账号，并且能够 将此话单合到原后付费账号的账单上。后付费用户月租按天收取的情况下，在后转预后可能仍需计算后付费用户的租费， 但此费用的发生时间在转换之后，对于对于此时互转的用户，需要进行特殊处理， 生成的固定费用和

36、优惠记录的效劳开始时间应该设置为用户进行互转前，此时严格 按照时间匹配合到后付费帐户 由于后付费用户不能进行实时销帐，互转用户的后付费账号的预存款不能进行余额 转移，需要出帐销帐以后再进行处理。因此后付费用户转为预付费用户，在转换过 程中不进行余额或预存款转移。目前的合账处理时，采用处理时间进行账号匹配，不支持按效劳开始时间进行匹配账号。计费账务主要改造点：合账支持效劳开始时间匹配账号。合账支持处理时间匹配账号。以上两种处理方式可以根据局方要求进行设置。以上两种处理方式可以根据受理不同的业务，支持设置不同的合账方式。例如 后转预：迟到话单合到老账号。后付费用户之间的过户，可以合到老账号，也支持

37、合到新账号。343接口说明343.1 内部接口接口名称接口类型接口提供方接口使用方接口说明343.2 外部接口无3.4.4 性能要求无3.5Rating&Billing支持帐户级优惠3.5.1 业务需求描述计费账务需要支持帐户级的账务级优惠与话单级优惠。用户的优惠加载在用户的主帐户资料上，主账号下的每个用户均享受此类优惠。需要支持的优惠主要有互打优惠，累计赠送优惠，累计赠送的共享优惠。3.5.2 系统功能分解分配3.5.2.1 同一个主账号下的用户的互打优惠Rating&Billing 部件设置一个种特定优惠 , 此种优惠加载帐户，实现账户内用户互打优惠，修改程序支持 PC部件将此类优惠配置为

38、帐务级优惠 .3.5.2.2 帐户级月结优惠优惠加载账户，月结优惠处理，目前已经支持。3.5.2.3 帐户级话单优惠1帐户级话单优惠，资费加载到账号上，需要优惠处理账号下的每个用户(无累计、赠送要求， 如互打)。2帐户级话单优惠，资费加载到账号上，需要优惠处理账号下的每个用户，累计、赠送属性存储 在帐户资料的使用量表上，采用共享方式( SHAREPOOL )处理。3帐户级话单优惠，资费加载到账号上，需要资费处理账号下的每个用户，累计、赠送为每个用 户独立使用，不进行共享处理。资费加载到帐户，累计、赠送用户级计费账务进行处理。累计不需修改程序，赠送量的管理需要支持。月结资费送赠送，只需要修改用户

39、资费获取逻辑。同理，固定费用计算也支持此 类处理。资料中需要标识出此类资费特性。即：资费在帐户资料上，固定费用、累计赠送等的使用在用户资料上，需要营业同步资料时 能够标识。4。帐户级话单资费，资费加载到用户上，累计、赠送存储在帐户资料的使用量表上，采用共享方 式( SHAREPOOL )处理(目前无实际场景)。用户的赠送管理和累计量的处理，在资料中标识出需要累计到帐户的共享属性中，而且赠送量的 管理同样需要加载在帐户的使用量属性上。3.524帐户级资费的赠送量管理支持帐户级资费的共享赠送量处理。支持帐户级资费的单个用户的赠送量管理。支持帐户级资费的赠送累计，按天分摊大小账期，建议采用整月生效处

40、理，躲避分摊。支持帐户级资费失效失效时的赠送量流出管理。需讨论3.5.2.5帐户级资费固定费用计算支持只收取到帐户的帐户级资费的固定费用计算。支持实例化到每个用户的帐户级资费的固定费用计算。3.526帐户级资费的资料接口处理帐户级资费生成赠送量，和处理用户级资费生成共享帐户的赠送量。营业采用帐户级的资费定购处理，同时增加附加参数。资料同步和月末赠送时，需要判断附加参 数进行固定费用计算、赠送量管理、话单级优惠处理。具体接口为:1. 账号2. 资费编码3. 附加属性假设资费为话单级赠送时，以下属性意义如下：aN = 0此类资费中，用户的赠送量需要实例化的具体用户，包月费收取也实例化到 用户，话单

41、级优惠bN0 此类资费中，赠送量共享，包月费收取N份到帐户，话单级优惠4. 生效时间5. 结束时间3.5.3 接口说明3.5.3.1 内部接口接口名称接口类型接口提供方接口使用方接口说明帐户级资费 资料同步接 口触发器方式的表接口营业计费账务处理帐户级资费生成赠送量，和处理 用户级资费生成共享帐户的赠送量。 营业采用帐户级的资费定购处理，同 时增加附加参数。资料同步和月末赠送时，需要判断附加参数进行固定费 用计算、赠送量管理、话单级优惠处 理。计费帐务针对营业的表写触发器3.532外部接口无3.5.4 性能要求无3.6预付费用户的实时销帐3.6.1 业务需求描述预付费用户采用简单余额的实时销帐

42、模式，只支持简单账本复杂账本后续版本支持，账本模 型与后付费不一致，通过帐号的prepaytype类型区分后付费和预付费。计费账务在合账时，进行实时的销帐，销帐处理逻辑：合账时触发实时销帐，实时销帐采用销减accou nt上的简单余额和销减账本的余额的方式，不会更新详细账单。在营业受理用户缴费相关业务时，调用AR接口增加帐号的prepaytype类型的传递，在AR效劳端中根据帐号的prepaytype类型来决定走不同的逻辑分支后付费用户，走原boss中AR提供的业务逻辑账务管理与账务处理为同一个数据库的两个不同用户，原boss中AR提供的业务逻辑和billing提供新的处理逻辑的API接口中处

43、理逻辑，都使用现在 AR的数据库模型，只是帐号根据 prepaytype类型不同 而各自负责自己的数据记录。接口中的涉及到两类帐号间prepaytype类型不同的两个帐号的业务主要是余额转移、过户转 帐单、余额转移等，需要分别调用原boss中AR提供的业务逻辑和billing提供新的处理逻辑的 API接口， 分别处理各自的数据。预付费用户，调用billing提供新的处理逻辑的 API接口 billing提供处理逻辑，该局部代码直接 嵌入在AR效劳中，主要处理逻辑如下：通过营业缴费或缴费回退时，判断帐户类型，假设为预付费，修改预付费帐户的账本，同时更新account表上的简单余额字段，并进行缴费

44、优惠和预付费生命周期管理等操作，生成缴费刷 新接口表，由账务处理通过此接口表数据进行异步账单资料的刷新共享内存余额刷新。 假设为后付费用户，账务管理采用原处理逻辑。通过dec接口进行预付费用户充值时，计费账务直接修改内存和数据库的预付费帐户的余额和 账本，并生成缴费日志，缴费日志同步到营业数据库。账务管理的余额查询采用数据库方式进行查询，判断帐户预付后付属性，假设为预付费时，直接读取account表时的简单余额返回，假设为后付费时，采用目前国内处理逻辑。进行余额转移时，账务管理直接读取预付费用户的账本，此时账本上的余额为该预付费用户的实时销帐后的账本余额。余额流出时，需要同步修改accou n

45、t上的简单余额。账务管理调整账单变更，需要判断帐户上预付后付属性，假设为预付费帐户，那么需要在调整账单费用的同时，同步修改 accou nt上的简单余额。后付费用户，采用目前国内处理逻辑。3.6.2 系统功能分解分配3.6.2.1 预付费用户实时销帐Rating&Billing 部件账务处理合账时，对预付费用户的账本与 account上的余额进行销减。不在 billitem上 进行销帐。3.6.2.2 预付费后付费判断方式AR 部件帐务管理和计费帐务共用的 Accou nt表上增加预付后付属性字段，通过此字段区分帐 户的后付和预付属性，此字段属性由账务管理维护。3.6.2.3 营业缴费与回退A

46、R 部件帐务管理修改预付费用户的缴费与缴费回退处理逻辑，判断帐户类型，假设为预付费，修改预付费帐户的账本，同时更新accou nt表上的简单余额字段，生成缴费刷新接口 表;调用账务处理提供的缴费优惠赠送处理逻辑，处理预付费用户的缴费赠送和预付 费生命周期管理等操作。假设为后付费用户，账务管理采用原处理逻辑。Rating&Billing 部件帐务处理通对帐务管理产生的缴费刷新接口表数据进行异步账单资料的刷新共享 内存余额刷新以上处理均在数据库进行操作，通过接口表缴费刷新接口、客户资料接口表方式进行异步的 数据库和内存的同步预付费用户的同步余额、账本、有效期等3.6.2.4 Dcc 预付费充值流程

47、Rating&Billing 部件计费账务通过dec接口进行预付费用户充值时，计费账务直接修改内存和数据库的预 付费帐户的余额和账本，调用缴费优惠存储过程处理缴费赠送，并生成缴费日志， 缴费日志反向同步到营业数据库。3.6.2.5 余额查询流程AR 部件帐务管理的余额查询采用数据库方式进行查询，判断帐户预付后付属性，假设为预付 费时，直接读取aceoun俵时的简单余额返回，假设为后付费时，采用目前国内处理逻 辑。3.6.2.6 余额转移流程AR 部件进行余额转移时，账务管理直接读取预付费用户的账本，此时账本上的余额为该预 付费用户的实时销帐后的账本余额。余额流出时，需要同步修改aceou nt

48、上的简单余额。3.6.2.7 调整账单AR 部件帐务管理调整账单变更，需要判断帐户上预付后付属性，假设为预付费帐户，那么需要 在调整账单费用的同时，同步修改accou nt上的简单余额。后付费用户，采用目前国内处理逻辑。362.8后付费余额信控余额计算Rating&Billing 部件预付费用户采用简单余额的实时销帐处理方案，而后付费用户采用目前国内处理方 式。因此计费账务针对帐户的预付后付属性，进行不同信控用户计算方式。针对telfort局方，预付费用户采用简单余额方式，信控余额直接采用account的简单余额。对于后付费用户，采用国内后付费方式的信控余额。3.6.3 接口说明3.6.3.1

49、 内部接口接口名称接口类型接口提供方接口使用方接口说明缴费日志反 向同步接口表接口营业计费账务营业分配给计费账单缴费日志的写权 限，由计费账务反向将dec缴费日志同 步到营业数据库中，供营业查询处理。余额查询表接口计费账务营业预付费用户余额查询，直接查询account表上的简单余额3.6.3.2 外部接口无3.6.4 性能要求无3.7 后付费用户的信控处理方式3.7.1 业务需求描述后付费用户的信控，以用户当前处理时间对应账期的未出帐费用总额或总累计量作为参考，进行 信控的处理。而目前的信控方式，采用帐户的信控余额进行参考计算帐户的信控状态，假设新旧状态变 化，那么下发信控指令，将此帐户状态变

50、化传递到营业进行信控指令的执行。修改计费账务的信控处理方式，信控参数 CREDIT_CONTROL_SCHEMA 增加参照量类型字段 ref_type ，缺省字段为空，表示参照为信控余额 ,此字段填写参考费用组。修改处理逻辑，假设此字段 非空时，获得当前帐户当前账期的对应费用组的总量数据作为参考进行信控处理。对于后付费用户的信控，采用特殊的信控模式，此类信控模式设置ref_type 为指定费用组，信控处理根据此字段提取参照信息信控余额或费用组进行信控处理。每个账期初始时，扫描对应账期后付费用户的信控状态，将非正常用户插入信控接口表，触发信 控处理，到达月初费用复位的信控处理的开机处理。3.7.

51、2 系统功能分解分配3.7.2.1 信控处理支持以费用组做参考量。PC部件设定相关FUP产品，指定其信控模式为“参照费用组信控对选择FUP产品的用户指定其信控模式为“参照费用组Rating&Billing 部件修改计费账务的信控处理方式，信控参数 CREDIT_CONTROL_SCHEMA 增加参 照量类型字段ref_type,缺省字段为空，表示参照为信控余额，此字段填写参考费用组。3.7.2.2 帐期初期费用复位信控处理Rating&Billing 部件每个账期初始时，扫描对应账期后付费用户的信控状态，将非正常用户插入信控接 口表，触发信控处理，到达月初费用复位的信控处理的开机处理。3.7.

52、3接口说明3.731内部接口接口名称接口类型接口提供方接口使用方接口说明信控下发接口表接口计费账务营业计费账务将帐户的状态变更的信控指 令以表的方式下发到营业，由营业进 行信控处理。3.7.3.2 外部接口无3.7.4 性能要求无3.8 NP计费匹配方案3.8.1 业务需求描述由于离线话单和在线消息中，不能获得对方号码的运用商信息，因此需要计费通过查表方式获取 对方号码的运营商信息。但对方运营商的总量数据过于庞大，不能简单地作为参数数据通过值映射 关系进行映射处理。同时由于某些类型话单不含IMSI，所以也不能以IMSI作为对方运营商判定的依据。方案采用将NP数据作为虚拟用户资料的进行管理，单独

53、维护一个虚拟地区如888地区的资料。此类虚拟用户资料只包含两个属性，号码属性和归属运营商属性，用户号格式采用【地区前缀+填充 假设干0+ 号码】的方式生成。NP号码的增量变化，转换为运营商属性的变更，通过客户资料刷新进行管理。预处理过程中，通过匹配对方号码虚拟地区资料的属性的方式获取对方运营商信息。3.8.2 系统功能分解分配3.8.2.1 全量数据转换虚拟地区：888 用户号：888 0000 1234566用户资料属性(subscriber_attr)号码属性： 号码资料装载时，建立索引运营商业属性：对于 号码变更历史数据迁移组需进行初始的全量数据转换。3.822 增量数据修改接口部件接收COIN传递过来的号码运营商属性变动通知