计费简介及融合探讨

1、计费系统简介 第2页 计费系统架构 第3页 名词术语 名称英文描述 产品Product 电信企业销售给客户的原子级的、销售上不可再分的单元，可细分为主产品 和附属产品；主产品产生计费事件，附属产品不产生计费事件； 销售品Product Offer 指电信运营商运用营销手段针对不同的营销渠道、客户细分、地域细分和销 售目标等，对产品/产品包、定价计划进行必要的包装的产物。所有产品和产 品包必须封装成销售品才能销售，产品和产品包本身不直接面向客户销售。 销售品实例Offer Instance 电信销售品被客户购买，一个销售品实例就形成了，也就是客户开通了电信 业务。一个客户可以有多个销售品实例 。

2、 产品实例 P r o d u c t Instance 形成销售品实例时，会产生一个或多个产品实例。一个主产品实例有对应的 一种网络的硬性物理连接，用于识别该业务，具体表现为计费的唯一标识， 并有相应的接入号码，比如电话号码，ADSL 号等。 定价计划Price Plan针对产品/产品包制定的价格方案，它包含了资费标准和优惠计算等规则。 定价段落Pricing Section 定价段落可以理解成为一个资费的选择树，任何计费事件都可以通过一层或 多层的资费查找，定位其应当执行的一个或多个资费标准。 资费标准Tariff 对客户所使用的产品进行计费的基本费用信息，资费标准可分为一次性费用、 周期

3、性费用和使用费三种类型。 定价参考对象 P r i c i n g R e f e r e n c e Object 在对产品/产品包/销售品进行定价的过程中所牵涉的对定价有影响的数据实体 的相关参照属性，可以是（但不限于）产品/产品包、销售品、客户协议、帐 户、计费事件、行政区域、电信管理区域等实体的相关属性。 计费事件Usage Event 客户在使用电信的产品或服务的过程中，所产生的用于计费的使用记录。如 CDR、数据业务的服务使用记录、内容服务的使用记录等。 第4页 计费话单处理流程 采集预处理批价 合帐 （信控） 原始话单文件 预处理后话单文件 批价结果文件 第5页 周期费处理 种类

4、：月租、月租日算、账期初月租 周期费计算环节对周期性事件生成环节生成的周期性事件进行解析，调用算 费流程，生成周期费算费结果，算费流程如下： 1.根据周期性事件查询对应的销售品、产品包上的定价计划。 2.查询对应于事件类型的事件定价策略。 3.匹配定价策略对应的定价段落树上的定价判断条件、参考对象。 4.取得定价段落树分支资费配置。 5.根据相应的资费配置生成帐目费用。 第6页 账务优惠 种类：产品优惠、商品优惠、商品日优惠、账期初优惠、账户优惠、捆绑 优惠等。 以账单表作为优惠内容的输入和结果的输出 优惠处理流程： 1、遍历销售品表，获取符合条件的销售品。 2、根据定价计划查找定价计划策略组

5、，如果策略组定 价计划中有需要处理优惠种类的类型，则取此销售品 ID，到销售品实例表查找销售品实例。 3、找到实例之后，分析优惠条件是否满足（是否预开 通，生失效时间等），后续分析定价计划、定价组合、 定价策略，按配置账目及优惠内容进行处理。 第7页 产品、套餐、协议资费处理顺序 清单 协议资费套餐资费产品资费 账务 产品优惠套餐优惠协议优惠账户优惠 清单排他处理，账务叠加处理 CRM与计费模型融合探讨 2015年6月 现网两套三户模型所带来的问题分析 本次融合模型解决的问题 1 2 目录目录 融合后需应用或运营关注的问题 3 CRM与计费两套档案模型的背景与计费两套档案模型的背景 目前现网绝

6、大部分省公司的档案模型，即CRM和计费的档案物理模型是 不同的，同样的信息两套模型承载，信息需要转换，自然而然 就会带来数据不一致问题。 由于CRM和计费之前分属不同的功能域，规范也是各自制定的，且 现网CRM和计费系统一般是两支不同的团队 1、历史原因导致CRM和计费档案模型两套 CRM ：注重面向营销过程的需要，同时考虑与后端的衔接。系统 能够支持快速推出新业务，方便、快速地定制销售品。 计费 ： 注重对各种费用的计算处理过程，系统能够支持准确、高 效的费用计算 2、业务模式的差异性要求CRM和计费模型有差异 1010 模型差异原因一模型差异原因一：业务表达不一致（业务概念层面）：业务表达

7、不一致（业务概念层面） 因为系统历史遗留问题，或者两系统对业务的表达方式不一样，导致两系统的业 务落地数据的结构或者粗粒度存在差异； u 例如: CRM与计费的套餐粒度不一样，CRM对于不同套餐档次采用不同的销售 品来表达，而计费即采用一个套餐不同套餐属性来实现。 乐享3G-49元档 乐享3G-89元档 乐享3G-129元档 乐享3G-189元档 乐享3G套餐属性：套餐档次 属性值：49 属性值：89 属性值：129 属性值：189 CRM：多档次多个销售品 计费：多档次一个销售品 采用属性表达档次 映射 1111 模型差异原因一模型差异原因一：业务表达不一致（物理模型层面）：业务表达不一致（

8、物理模型层面） 手机 号码0 亲情功能 产品实例 属性：亲情号码1 属性：亲情号码2 属性：亲情号码3 群实例 群成员：号码0 群成员：号码1 群成员：号码2 群成员：号码3 CRM 计费 CRM与计费对于同一种业务，由于两个系统功能不同，对信息的表达或使用方 式有差异，因此数据模型的表达是不一样的； CRM注重逻辑表达灵活，计费注重对系统性能影响；例如：对亲情优惠，CRM 不生成群实例，需要计费自行实例化，两系统的数据表达是不一样： 1212 模型差异原因二模型差异原因二：主数据编码不一致：主数据编码不一致 因为CRM与计费的主数据是分开制订与管控的，并不是遵循同一套中国电信主数 据规范；因

9、而在具体落地时，两个系统共同用到的主数据在CRM和计费中各有一 套标准，两套主数据编码存在不一致的情况，需要进行映射转换处理。 l 动态主数据编码： 销售品编码 产品编码 属性编码 目录编码 区域编码 局向编码 l 静态主数据编码： 销售品类型编码 销售品构成编码 销售品关系编码 产品类型编码 产品关系编码 1313 模型差异原因三：模型差异原因三：资料资料关注侧重点不同关注侧重点不同 CRM关注业务受理的便捷性。对于业务变更前信息统一写入历史表，后续使用较少。 计费关注资料的时间连续性和准确性。 以客户更改个人定制套餐的流量属性为例，某用户2015年4月1日入网，订购套餐流量 1G，2015

10、年5月11日变更流量为2G，下月生效： 属性 标识 属性值生效时间变更时间 流量1G20150401 属性 标识 属性值生效时间变更时间 流量2G2015040120150511 属性 标识 属性值生效时间变更时间 流量1G20150401 属性 标识 属性值生效时间计费生效时间计费失效时间 流量2G201504012015060120301230 流量1G201504012015040120150601 属性 标识 属性值生效时间计费生效时间计费失效时间 流量1G201504012015040120301230 业务变更前：CRM在用表 业务变更后：CRM在用表 业务变更后：CRM历史表 业

11、务变更前：计费资料表 业务变更后：计费资料表 时间接续 1414 模型差异原因四模型差异原因四：同类功能模型分散实现：同类功能模型分散实现 CRM 一次性费用 周期性费用 计费 CRM应用 计费应用 费用信息 一次性发票打印一次性费用收取 周期性发票打印 周期性费用收取 l 一次性费用收取和发票打印在CRM收银台中直接处理，然后再同步给计费进 行存档，由于两边模型都各自制订，一次性费用的模型存在差异，在资料同 步接口中需要进行转换处理。 1515 CRM计费 业务表达不一致主数据不一致侧重点不一致 同类功能 模型不一致 转换程序问题接口技术问题运营维护问题 接口 转换 CRM与计费两套模型落地

12、问题分析与计费两套模型落地问题分析 因为以上四种情况导致资料同步时需要进行数据转换 复杂的接口转换程序带来三方面问题 1616 原原 因因 问问 题题 导导 致致 现网两套三户模型所带来的问题分析 本次融合模型解决的问题 1 2 目录目录 融合后需应用或运营关注的问题 3 BSS融合模型 业务表达不一致 （业务概念层面） 主数据不一致侧重点不一致 同类功能 模型不一致 本次融合模型从源头解决两套模型差异本次融合模型从源头解决两套模型差异，减少信息，减少信息转换转换 1818 两套两套 模型模型 问题问题 l 一套规格数据；一套规格数据； l 一一套档案资料；套档案资料； l 一一套主数据标准。

13、套主数据标准。 统一业务表达 （业务概念层面） 统一主数据编 码 兼容CRM计费 侧重点不一致 同类功能模型 统一制定 融合融合 模型模型 举措举措 无须信息转换，无须信息转换，避免复杂数据接口转换带来的数据出错、不一致问题 解决解决 问题问题 融合融合模型举措模型举措统一业务表达统一业务表达 u 模型组联合厂家整理了各种典型业务在现网的表达方式，分析了现网各省CRM和计费模型与集团模型 的差异，然后基于分析结果进行了融合模型编制； u 在模型编制过程中，BSS三户模型按照CRM和计费采用同一套模型的原则制定；并根据此原则编写落地 场景文档，统一各种典型业务CRM和计费的落地方案。 解决同一业

14、务，CRM和计费理解不一致问题：通过编写融合模型规范文档及典型业务场景 验证文档，明确定义融合模型涉及的各实体概念定义、明确典型业务落地原则，实现同一业 务CRM和计费理解一致 解决销售品粒度不一致问题：产品、销售品规格相关数据CRM和计费模型统一，表达统一 解决产品销售品实例落地CRM和计费不一致问题：产品销售品实例模型同一套，落地原则 如下： 实例数据落地时CRM和计费能达成一致的按统一的落地方式 如果因CRM和计费业务模式的不同而要求落地模式有所差异的，融合模型支持同一套 模型下CRM和计费存在冗余数据, 保证两个域性能处理需要。 1919 融合融合模型举措模型举措 统一主统一主数据编码

15、数据编码 u 模型组通过收集CRM和计费系统在各省现网的主数据，并参考CRM2.8和计 费3.5的主数据规范，统一制定CRM和计费的主数据编码。 解决动态主数据编码不一致问题：解决动态主数据编码不一致问题：产品销售品规格模型是一致的，产品目录、 销售品目录、区域编码需要全网统一，目前需求组正在梳理 解决静态主数据编码不一致问题解决静态主数据编码不一致问题： 对CRM和计费表达同样含义但主数据编码不同的主数据进行了归并 补充原来CRM和计费规范中缺失的主数据 删除原来CRM和计费规范有歧义、无用的主数据。 2020 融合融合模型举措模型举措兼容兼容CRMCRM与计费侧重点不一致与计费侧重点不一致

16、要求要求 u 融合模型考虑了CRM和计费系统对于同一实体因关注点不同而需要采集不同 信息的要求，在模型层面支持两者的兼容。 针对针对CRM与计费对产品与计费对产品、销售、销售品实例信息关注点不同的问题：品实例信息关注点不同的问题：模型设计时 兼容考虑两者要求，例如： 对于产品销售品实例涉及的相关时间信息，产品销售品实例模型支持 统一记录CRM和计费所需的时间信息，既支持完整记录CRM系统对客 户档案变动的相关时间信息，也支持记录表达计费时间连续性的内容； CRM关注产品属性的全集，而计费只关注影响资费的产品属性，因此 模型在产品属性规格上增加“是否计费需要”字段，以满足计费系统 使用要求 21

17、21 融合融合模型举措模型举措同类同类功能模型统一功能模型统一制定制定 u 针对现网同类功能在现网存在CRM和计费有两套模型的情况，融合模型 根据业务的功能特征对模型进行了整合，同类功能采用同一套模型进行 统一的表达。 一次性费用功能所涉及模型统一在帐务子域表达 特殊客户名单（如客户红名单、黑名单等）统一在客户子域表达。 产品停机记录统一在产品实例子域表达 本次融合模型调整点：本次融合模型调整点： 2222 现网两套三户模型所带来的问题分析 本次融合模型解决的问题 1 2 目录目录 融合后需应用或运营关注的问题 3 采用同一套物理模型在支撑业务需求时，由于CRM与计费的系统设计目标不同 （CR

18、M注重受理灵活性、计费保证性能），通常在存储细节上会有差异，如果为 了兼顾不同系统的要求，常需要双方在物理模型上相互妥协，影响需求支撑效率， 也可能会因相互兼容而影响CRM或计费的部分系统性能。需要从实现方案上考虑 如何更好的兼容两个系统的要求。 需求支撑问题 融合模型后如果计费与CRM耦合度比较高会导致系统故障相互影响的概率增加， 例如: CRM订单竣工环节如果与计费侧紧耦合，则计费系统有问题时CRM受理也受影响； 计费大量服务访问CRM档案库，若CRM档案库有故障，计费系统（主要为帐务）也 将同时产生故障。需要应用从技术上考虑如何规避。 CRM受理与计 费系统紧耦合 问题 如果CRM和计费

19、都访问同一个数据库，CRM资料数据库压力会比较大，特别是受理 高峰期时，如果计费持续批量访问CRM档案库会加大数据库性能损耗，从而增加 产生系统性能下降，甚至产生数据库故障的风险。需要运维考虑如何实现压力分 摊。 在物理实现和应用中：需要充分考虑性能问题, 特别是实时批价,算费需要的数 据需考虑采用物理存储上水平和纵向分离, 生产与查询分离的原则, CRM档案库压 力较大问题 CRM与计费采用融合模型后需要应用或运维考虑解决与计费采用融合模型后需要应用或运维考虑解决 的问题的问题(一一) 2424 在物理数据库与内存数据库之间同步数据时，容易因场景考虑不全或者数据同步 异常或者因网络异常等一些

20、异常原因，导致档案资料与内存数据库有可能存在数 据不一致情况，如果内存数据库的稽核比对比较困难，则会进一步加大核查、定 位生产问题的难度 大批量档案割接时，如果物理数据库与内存数据库同步接口的性能有瓶颈，则反 过来又会影响CRM和计费的正常使用 物理据库与内 存数据库的数 据一致性问题 融合模型落地后，后续需建立长效机制，对每次出新的业务或模型,都需要对模 型的表达或理解进行定义和明确, 确保理解一致性 建立融合模型 的使用规范的 长效机制 数据冗余模式下的割接准备工作量和难度都比较大, 建议制定相关的系统数据清 理或梳理的指导手册 冗余数据之间的数据一致性保持、 物理库与内存库之间的数据一致

21、性保持，都 需要有监控和校验工具支持 融合模型下, 计费侧不可避免需采用内存数据模式解决性能问题, 需要考虑约定 内存数据的存储原则 融合模型落地 过程中的难点 CRM与计费采用融合模型后需要应用或运维考虑解决与计费采用融合模型后需要应用或运维考虑解决 的问题的问题(二二) 2525 谢谢！ 目录目录 档案资料共享 融合模型资料时间连续性方案 在用表在用表历史表历史表 变更前资料变更后资料 在用表在用表履历表履历表 变更前资料变更后资料 方案方案1 方案方案2 CRM关注业务受理的便捷性。对于业务变更前资料后续使用较少。 计费关注资料的时间连续性和准确性。对于一个计费周期内的多条信息，包括在用

22、、 历史资料，均可能使用。 CRM和计费对资料模型的差异分析和计费对资料模型的差异分析 参照在用表复制一套结构相同的历史表，用于写入CRM变更前的资料。 历史表与在用表上统一增加计费资料生失效时间，维护资料时保持在用表、历史表数 据的时间连续性。 融合资料模型时间连续性方案一融合资料模型时间连续性方案一 参照在用表复制一套结构相同的历史表，用于写入CRM变更前后的资料。 历史表增加计费资料生失效时间，维护资料时保持历史表数据的时间连续性。 融合资料模型时间连续性方案二融合资料模型时间连续性方案二 融合模型资料时间连续性方案 方案方案优点优点缺点缺点 方案一： 资料分两张表存放 在用表记录当前数

23、据，历史表记录 历史数据，历史表中不包含当前记 录冗余 1、没有数据冗余。 1、计费需要连接两张表格数 据，性能开销较大。 方案二： 资料分两张表存放 在用表记录当前数据，历史表记录 历史数据，历史表中包含当前记录 冗余。 1、回避了方案一中带来的 性能问题。 1、产生了数据冗余。 方案三： 资料存放（3个月）一张表中，通过 标示符区隔当前有效及历史数据。 1、回避了方案一中带来的 性能问题。 2、消除了方案二中的数据 冗余。 1、在大数据量时存在性能瓶 颈。 2、不利于正式环境中分片存 放。 n讨论推荐： 方案二 n优缺点分析： 过渡期定义 v 过渡期业务场景过渡期业务场景 场景一：A客户在

24、2015年1月20日来营业厅办理e9-119套餐，同时订购移动语音、固定电 话和宽带，客户确认套餐次月生效。移动语音产品在2015年1月20日当天即可使用，固 定电话和宽带于2015年1月23日上门安装调测后才可使用。由于客户选择次月生效，e9- 119套餐将在2015年2月1号才生效。移动语音产品从1月20日至1月31日、固定电话和宽 带从1月23日至1月31日，计费需要按过渡期资费进行费用计算。 场景二：B客户已有乐享4G-129套餐，在2015年1月20日日来营业厅办理副卡同时订购 移动语音。移动语音产品在2015年1月20日当天即可使用，由于业务要求，副卡只能在 次月享受套餐内优惠。移动语音产品从1月20日至1月31日，计费需要按过渡期资费进行 费用计算。 v 过渡期定义过渡期定义 产品竣工后至销售品与产品关系生效之前的这段时间，认为是过渡期。 v 过渡期方案过渡期方案 方案一：由销售品定价进行区分，定义过渡期的定价方案 方案二：由销售品进行