电信计费业务:预后融合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每条话单也需要更新帐本余额,而不是原来简单的累加。原来考虑的效率问题就变得没那么严重,而且云化给计费带来的效率提升是显而易见的。

上一篇:Linux的五个查找命令


下一篇:PHP build notes - WARNING: This bison version is not supported for regeneration of the Zend/PHP parsers (found: 3.0, min: 204, excluded: 3.0).