电信计费项目实施：浅谈如何对账

基本上，BOSS系统的所有工程实施人员，从事的第一项工作就是对帐（除非你是从项目维护期开始），其实这并不是因为对帐是个简单的工作，恰恰相反，对帐是所有工程实施工作中最难的，它需要有扎实的业务功底，那为什么基本上所有的工程实施人员第一课都是对帐呢？原因很简单，从业务学习的角度来说，对帐是一个最好的切入方式，也是一个相对容易上手的方式。但是，也因为这个工作要做好，实际比其他任何的工程实施工作要复杂，要难，所以基本上所有的新手压力都非常巨大，本文的目的，在于给新手们提供一点指导，由于作者的水平和长期以来喜欢装B的个性，错误之处和唬人之处在所难免，也希望得到老鸟们的指正。

 

1、 什么是对帐

基本上所有的文章都这么开始。先给自己要写的东西下个定义，比如什么是马克思主义，什么是大学生就业，什么是爱情，什么是理想，诸如此类。我们在这儿不能免俗。我是说清楚自己要干的事情非常重要。

对帐是一个业务术语，单从BOSS系统的角度，它的定义非常狭义，基本上是指对新系统计费程序的结果，与老系统的计费程序的结果进行比较，找出其差异的原因。当然，这个定义很不靠谱，遇到这种不太好做的具体问题时候，我们就提高它的高度（细细的读论语，你会发现这点）：

对帐是一种测试手段，用于测试系统或者程序是否向下兼容，测试系统的配置和资料的割接是否正确。对于所有的程序，都是：

输入 +  程序处理 =  输出

    对帐，就是对于相同的输入数据源（或者相近的数据源，这实际很重要），针对不同的程序处理方式，对程序输出的结果进行比较的工作。

    PS：其实不仅仅是计费程序，很多BOSS系统工程实施的时候，面对复杂的问题，都需要用到这种方法，只是他们叫数据比对，或者其他的什么，不叫对帐，但是归根结底他们是一样的。

 

2、    对帐脚本的编写

既然是对结果进行比较，那么我们首先要做的，就是编写一套比对的脚本，一般来说是SQL脚本或者存储过程，找出结果的差异。

首先，你要明确，与老系统相比，哪些字段能唯一确定一个结果值，这个会根据业务的实际情况有所不同。比如说语音话单，开始时间，结束时间，计费用户基本能够确定一条唯一话单。

其次，要清楚参与比对的哪些结果。对于计费，可能钱(charge)这个字段是最终需要比对的结果，但是可能还要参杂其他的的结果，比如帐目（可能涉及到用户最后的发票是否一致），当然，对于新手，对帐的方案一般不会由你制定，你询问清楚，哪些需要参与比对，为什么要比对就OK。

另外，哪些字段是需要去参考比对的。这个可能会很复杂，新老系统与批价有关的字段你都应该列入，比如事件类型，定价计划，费率ID，费率，用户产品，等等等等。尽可能多是很好的选择。

一般来说，我们把差异列为三种：

新有老无：表示这个结果在新系统中存在，而在老系统中不存在。

老有新无：表示这个结果在老系统中存在，而在新系统中不存在。

不一致：表示这个结果在新老系统都有，但是结果（一般来说指批价结果，charge）不一致。

    这儿你可能有点晕了，会有新有老无和老有新无的情况出现呢？没事，我接下来会对这三种情况的比对一一做一些详细说明。

    PS：对帐脚本最好自己编写，并逐步完善。

 

3、 对帐的一些通用逻辑。

A、老有新无与新有老无

前面提到的，输入+程序处理=输出。这对于一个程序，实际是明确的，但是，其实这儿的程序处理，并不是指单个程序， 这中间会有很多个程序，实际上，是多个程序。程序的输出，也不可能只包括一种，肯定有多个的输出。举实际的例子，比如HB语音对帐（OCS实际更加复杂）。

输入 =  联采话单。

程序A = 预处理 输入=联采话单  输出A = 预处理正常话单 输出B = 预处理过滤话单 输出C = 预处理错误话单

程序B = 批价  输入= 预处理正常话单 输出A = 批价正常话单 输出B = 批价错误话单

程序C = 合帐入库  输入= 批价正常话单  输出A = 合帐正常话单 输出B = 合帐错误话单。

而实际上我们比对的结果，是合帐后的正常话单，所以在中间这么多程序中，都会丢掉一些话单，造成比对中存在老有新无和新有老无的情况。所以，新有老无和老有新无的比对办法是，了解数据的流转过程，清楚每一步的输入输出，并分析：

• 是否存在话单，并不存在于所有结果表中的情况。如果有这种情况，需要提供给研发人员分析。
• 如果老系统与新系统不一致，比如老系统进入错单而新系统成功批价，那新系统逻辑（包括程序，配置，以及资料）是否正确。（一般来说，需要请教预处理配置，批价配置，和研发人员）

 

还有一种情况，也需要参与分析，那就是数据源的一致性。一般来说，我们最好是选取相同的数据源，比如HB对帐，新老系统，我们用同一的联采数据。但是在很多情况下，这个要求是达不到的。比如OCS的对帐，对于老系统的历史数据，我们的话单来源都为DCC消息，而新的数据源，你无法重新获得一份全部的DCC消息，所以，一般采用平台的离线话单或者OCS自身出的结果话单进行比对（局方认可的方式），这个数据源本身就与实际数据源存在差异，所以出现新有老无或者老有新无时，检查数据源是否一致也是非常必要的。

 

B、不一致的比对。

如果说老有新无和新有老无仅仅是对数据流的分析，那么不一致的比对就是针对程序逻辑，配置，资料的分析。虽然对帐的要求是找到所有的差异原因，即就是说，你肯定需要知道新系统和老系统，为什么批价出来是这个结果。但是很多情况下，新老系统对于你都是一个黑盒子，所以首先，你需要有一个标准，什么样的结果才是正确的？

一般来说，我们是以老系统为准的，但是这个仅仅是一般的情况。最终的目的是局方认可我们的差异。

如果结果不正确，那么为什么不正确？

三个原因：资料割接错误，配置错误，程序处理错误。

资料：对于老系统，如果不是我们自己的系统，黑盒子的情况很多。但是有一点你是必须清楚的，老系统的资料是什么，是什么产品，什么商品，享受什么样的资费与优惠。我们的比对的第一步，也是从资料开始，首先，就是比较资料割接的对不对，原来老系统，用户有ABC三个商品，而在新系统只有AB两个，老系统用C商品进行了批价，这时候你就要去质疑资料割接的人员，为何C商品在系统中没有体现，是否存在问题。

配置：面对上面同样的问题，你先去找了商品割接人员，商品割接人员告诉你，已经跟配置约定好，原来的BC商品，目前都对应到B商品，那么，你就要去检查，是否B商品涵盖了原来BC商品所有的批价逻辑？如果检查到有资费缺失，那就要去联系配置人员，为何这条资费没有被配置。

程序逻辑：如果你检查到配置是有的，条件也符合，那最终的怀疑对象是程序逻辑，程序为何没有按照配置进行批价？这时候去找研发人员，跟配置人员与资料割接人员一起讨论。

当然这些人一般都很烦，一般来说，配置人员和对帐人员的比率是1：5左右，但是，你肯定需要不停的是骚扰他们，你的目的是，不管是新系统还是老系统，不管是程序还是资料还是配置，这中间的黑盒子越来越少。这样才能更少的去烦他们。

 

4、 一些常见的方法。

A、二八定律。最开始，对帐的结果差异肯定是非常大的，比如说，有30%的差异，那么，你需要做的工作，是尽可能找出这30%的差异中最多的差异是什么，先花20%的时间去解决80%的问题，批价的错误永远不可能只有一个，当一个问题造成了很大的差异时，它往往会覆盖掉其他的差异，所以，不要纠结单条话单的情况，永远关注批量的情况。每次找到问题的80%（注意不要一个问题一个问题的去找配置和资料割接人员），找到后就要求相关的人员修改，然后再进行第二次对帐。

B、 Group by 。如何找到问题的80%呢？你需要去寻找问题的共性。前文提到的结果表的参考字段就很有用。你可以尝试去group by 一些关键字段，比如定价计划字段，事件ID字段，看看有没有共性，另外联想能力和怀疑能力也是很重要的。

C、 做好记录。应该列出一个表格，对发现的问题，问题的特征，解决的办法，是否重复出现等情况进行记录，有总结才有提高。

D、   换位思考。如果我是资料割接人员，配置人员，或者研发人员，我该如何处理这个问题，面对困难的时候，找更困难的事情来思考，你会发现自己提升的很快。