IT知识库 购物 网址 游戏 小说 歌词 快照 开发 股票 美女 新闻 笑话 | 汉字 软件 日历 阅读 下载 图书馆 编程 China
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
图片批量下载器
↓批量下载图片,美女图库↓
图片自动播放器
↓图片自动播放器↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
vbs/VBScript DOS/BAT hta htc python perl 游戏相关 VBA 远程脚本 ColdFusion ruby专题 autoit seraphzone PowerShell linux shell Lua Golang Erlang 其它教程 CSS/HTML/Xhtml html5 CSS XML/XSLT Dreamweaver教程 经验交流 开发者乐园 Android开发资料
站长资讯 .NET新手 ASP.NET C# WinForm Silverlight WCF CLR WPF XNA VisualStudio ASP.NET-MVC .NET控件开发 EntityFramework WinRT-Metro Java C++ PHP Delphi Python Ruby C语言 Erlang Go Swift Scala R语言 Verilog 其它语言 架构设计 面向对象 设计模式 领域驱动 Html-Css JavaScript jQuery HTML5 SharePoint GIS技术 SAP OracleERP DynamicsCRM K2 BPM 信息安全 企业信息 Android开发 iOS开发 WindowsPhone WindowsMobile 其他手机 敏捷开发 项目管理 软件工程 SQLServer Oracle MySQL NoSQL 其它数据库 Windows7 WindowsServer Linux
  IT知识库 -> 企业信息化其他 -> 电信计费业务:预后融合OCS到底应该实扣还是虚扣? -> 正文阅读

[企业信息化其他]电信计费业务:预后融合OCS到底应该实扣还是虚扣?

电信计费业务:预后融合OCS到底应该实扣还是虚扣?       
       引入OCS的初衷之一是为了让计费系统能够参与到用户的通讯控制中来,也就是所谓的实时信控。用户在没有余额时,通讯就会被停止,不会造成”天价欠费 ”,一方面保障用户的利益,一方面也保障了运营商的利益。由于OCS要进行实时信控,所以在通话结束后,会将产生的费用实际扣除,称为实扣;而OFCS则不同,由于在后付费支撑那边的惯性,需要支撑固网的后付费业务,所以余额就不能实扣,而是先将产生的费用累计起来,作为“当月实时费用”到月底对余额进行批冲,再将费用扣除,称为虚扣。
实扣和虚扣已经事实上成为一种“业务规则”,。由于实扣和虚扣对余额的处理方式不一致,造成很多业务规则的实现上实际也不一致,最典型的是OCS和OFCS在用户提醒上,按照OFCS的规则,用户查询余额时,需要提醒用户余额,当月的实时费用,可用余额,这几个值按照实际值填好即可,是按照用户余额-当月实时费用=可用余额的逻辑。但是对于OCS,由于用户的余额为实扣,则用户余额是反算出来的,是用户余额=当月的实时费用+目前余额的逻辑,所以,虽然给用户的查询结果一致,但是实际的处理方式确实不一样的,发票打印上的本期余额和上期余额实际也有类似的问题。
这实际上已经成为统一服务的一个比较大的“负担”。甚至有些问题,业务规则的制定者也不一定清楚详情。比如OCS侧帐务优惠的处理。假设某套餐存在满100送20元的优惠,在OFCS的系统,帐务优惠是很清晰的,如果到了月底,用户消费101元,送出那最终的计费结果就只有81元,月底再将这笔虚扣的钱进行销帐。但是对于OCS,用户消费的101元已经实扣,到月底的时候,就需要给用户返20元到余额帐本中,问题就来了,假设用户有多个帐本,按照什么顺序执行扣费顺序,又该往哪个帐本返还呢?这个规则实际很多人都没弄清楚。
举个极端的例子,比如说用户有11元本金帐本,每月有个划拨的赠送90元(保底消费90元)的帐本,赠送帐本需要先扣,那赠送的90元的先扣掉了,本金的11元再扣掉,那么返还的时候,如果20元都送到本金,那么用户本金平白无故增加了9元,这9元实际不是用户本金存入的,用户明显占了便宜,财务上也会造成不平,如果全部返还到赠送帐本上,那也有问题,用户的划拨帐本冲入20元后,又会被保底消费把这个20元扣掉,那等于给用户没赠送。正确的做法应该是后扣费的先返还,先扣费的后返还。先给用户返回11元到本金帐本,再给用户返9元到赠送帐本,最后用户划拨的90元帐本被保底消费扣完,而本金剩余11元。
       排除真正意义上的后付费用户不说,准实时的预付费和实时预付费用户的余额处理逻辑,应该要统一。那么到底该如何统一呢?下表中列了一下主要的处理差异:
                                                       
涉及差异
实扣
虚扣
改造难度


计费效率
效率低
效率高
信控规则
简单
复杂
帐务优惠
复杂
简单
发票规则
需改造
不需改造
用户查询惯性
不遵循
遵循
支持灵活帐期
简单
复杂
实时出帐
简单
复杂
             
   如果考虑现阶段的业务,自然还是OCS改造为虚扣更加合适一些。首先是因为改造的难度,OCS改造为虚扣,对每一个帐本增加一个虚扣余额的字段,实时信控时也要参考这个字段,这一块虽然改造难度以及涉及的周边模块的改动也不小,但是整体比OFCS做实扣的改动难度,还是要小很多。另外效率问题,帐务优惠的问题,用户的习惯问题等都是用虚扣好一些。
   但是如果要考虑将来的话,应该会得到不一样的结论,从业务的发展角度去考虑,业务将向数据运营方向发展,更加注重用户体验。这方面,OCS比HB在实时信控上存在较大优势(如AOC和针对内容的信控),OCS应该是计费发展的主流;数据业务的收入也势必会超过语音业务,原来在语音业务这边惯性思维的帐务优惠的套餐会越来越少;灵活帐期和实时出帐也能很好的提升用户体验。从技术发展的角度去考虑,PC化、云化也是计费这边的大势所趋,OFCS也需要具备消息计费的能力,计费的流程势必要统一,OFCS每条话单也需要更新帐本余额,而不是原来简单的累加。原来考虑的效率问题就变得没那么严重,而且云化给计费带来的效率提升是显而易见的。
上一篇文章      下一篇文章      查看所有文章
加:2016-12-20 15:58:21  更:2017-05-16 20:03:24 
 
  企业信息化其他 最新文章
中小公司网站架构
用Gogs在Windows上搭建Git服务
路由知识 静态路由 rip eigrp ospf
路由知识 静态路由 rip eigrp ospf
第一节 信息化知识
第二节 信息系统服务管理
Atitit.软件兼容性原理与实践 v5 qa2.docx
踏上Salesforce的学习之路(一)
国际贸易术语及比较
网管的自我修养
技术频道: 站长资讯 .NET新手区 ASP.NET C# WinForm Silverlight WCF CLR WPF XNA Visual Studio ASP.NET MVC .NET控件开发 Entity Framework WinRT/Metro Java C++ PHP Delphi Python Ruby C语言 Erlang Go Swift Scala R语言 Verilog 其它语言 架构设计 面向对象 设计模式 领域驱动设计 Html/Css JavaScript jQuery HTML5 SharePoint GIS技术 SAP Oracle ERP Dynamics CRM K2 BPM 信息安全 企业信息化其他 Android开发 iOS开发 Windows Phone Windows Mobile 其他手机开发 敏捷开发 项目与团队管理 软件工程其他 SQL Server Oracle MySQL NoSQL 其它数据库 Windows 7 Windows Server Linux
脚本语言: vbs/VBScript DOS/BAT hta htc python perl 游戏相关 VBA 远程脚本 ColdFusion ruby专题 autoit seraphzone PowerShell linux shell Lua Golang Erlang 其它教程
网站开发: CSS/HTML/Xhtml html5 CSS XML/XSLT Dreamweaver教程 经验交流 开发者乐园 Android开发资料
360图书馆 软件开发资料 文字转语音 购物精选 软件下载 新闻资讯 小游戏 Chinese Culture 股票 三丰软件 开发 中国文化 网文精选 阅读网 看图 日历 万年历 2018年10日历
2018-10-24 3:17:04
多播视频美女直播
↓电视,电影,美女直播,迅雷资源↓
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
图片批量下载器
↓批量下载图片,美女图库↓
  网站联系: qq:121756557 email:121756557@qq.com  IT知识库