【IT168 技术文档】说起IBSS与帐务系统的接口就是一把火，本来都是普信公司的东西，想当然的，这当中要做个接口那还不是小菜一碟，手到擒来的不费那吹灰之力的啦。可是事实可还真不是那样，每个点上的都是胆战心惊，到了月底那几天都是要兴师动众，将数据update过来update过去的，忙得不可开交的。

　　也真是可怜中山局计算中心和帐务中心的同事们，都4月份上了线的，已经出过4次帐期了，虽然是在不断的改进，问题订单的数量也一直在下降。可是，十堆的问题解决了九堆，还是有那么一大堆的问题。我跑到那边协助他们升级版本的时候，看到胡工桌面上的几页问题记录，触目惊心，升级完成之后就赶快闪人了。(不是我没义气哦，只是自己暂时还没那能耐解决所有的问题，帮不了。)

　　但是，对于营销方案、套餐的设计太复杂了，里面的参数变化也太频繁了。本来就已经定义好的方案或者套餐，已经在用了一段时间之后，由于模型的变更或者是参数增减，或者是参数意义的调整，就会造成方案与在用实例之间的不一致。这个不一致，到了帐务那边就不认帐了，无法搞清楚具体对应哪个计费的方案。或者是对应到了具体的方案，无法跟里面的计费所需要的项目参数，比例参数，折扣参数等等进行相匹配。一句话，旧有生成的实例数据，无法在帐务里面正确的计算出费用信息。

　　正是因为这当中的差别，导致了每个月的计费时段（月底到月头这几天），搞得是各个部门都伤筋动骨，鸡飞狗跳的。IBSS依照协议送过去一批的计费属性数据，帐务检查翻译一番；挑出一片的不符合计费要求的订单，要IBSS做修正，这个修正可是要我们的后台人员在数据库里头操作SQL语句完成；修正完了之后，再送到帐务系统去算费。就这样周而复始，不断的修正，不断的计算，最终大家都累了个半死之后，才勉强把用户该交的钱算出来。当然，这当中由于原始资料不正确的，或者是IBSS的参数配置不正确的，导致部分用户的费用计算错误也是难以避免的了。

　　我们的主要工作是根据帐务部门的要求，对原始的计费数据做修修补补了。这也就牵扯了我们大部分的人力。从中山计起，到湛江、肇庆，再去到东莞，每个点我们都投入了相应的人员，每个月都在协助局方处理类似的东西。Hjy,hjl,gdq,lyx等几位同事，每到月底都是最为忙活的几个人。

　　局方烦，我们也烦。

　　能否将这些处理动作进行相关的归类呢？提炼出来，写成一个简单的操作指引，指导局方自行处理？

　　或者写出一个可执行的程序，规定相关的输入规则之后，判断是哪种情况就自动调用哪些特定的处理程序进行数据修补动作？

　　又或者我们可以考虑，不要集中到月底才来进行统一的处理，在平时就检查数据是否有问题，及时做个修补的动作？

　　甚至于我们来个先“防患于未然”，从源头上面止住这种情况，不允许对现有的营销方案、套餐做改动处理，只允许新增的方式来做会不会好些呢？