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