今天是5月的最后一天，又到了财务出报表，库房盘点库存的日子。有客户反映报表不准确，我遂决定到客户现场一探究竟。通过努力很快找到了报表不准确的原因，修正过后，发现报表已经准确无误了。暗自庆幸，挺顺利的。
下午，正在埋头编写代码，库房的医师跑来了办公室反映盘点有问题，一般这种问题都是由现场工程人员对接的。怎奈，刚好同事们都不在办公室，她直接跑到我的面前，跟我说：“工程师啊，我盘点只是点了保存，单子怎么就完成了呢？而且怎么没有生成盘盈盘亏单呢？”。停下手中的工作，开始排查她的问题。
通过查询发现盘点单的完成标志确实打上了，而且确定没有盘盈盘亏的单子生成。继续排查盘点单明细，发现明细里面确实存在盘盈盘亏的药品。程序源码搜索一遍，发现只有点击确认按钮的时候，才会更新盘点单的完成标志。按照这样的推理，库房医师肯定是点了确认按钮，但是排查代码发现假如点击了确认按钮，肯定会生成盘盈盘亏的单子啊。由于今天是五月的最后一天，库房药师也比较着急，不停的跟我说：“今天一定要解决啊！”。其实，我个人还是比较喜欢这种问题的，一旦出现了，我肯定要弄个明明白白。
接下来，就进入了我俩的沟通时间。我首先问她：“操作的过程中，系统有报错吗？”。她肯定的回答我：“没有！”。我查询了后台数据，也没有发现错误日志产生。我接着问她：“你记不记得，你最后的一步操作是什么？”。她跟我说，她盘点数据录入完成后，发现有个药品实盘数量输错了，然后就把这条记录查找出来，修正完实盘数量之后就点击了保存按钮。我让她把修改的那条记录找出来让我看一下。当她熟练的在电脑上找到那条记录后，我一下就明白了出错的原因了。我开始问她：“你确定当时点的是保存按钮？不是确认按钮？”。她跟我说：“记不太清楚了，以前点击确认按钮，都会提示生成了盘盈盘亏单，但是这次没有提示！”。当我明白原因后，我确信她当时点击的是确认按钮而不是保存按钮。至于为什么没有生成盘盈盘亏单，答案马上见分晓。
盘盈盘亏单的生成是根据盘点单明细里面的盘前数量和盘后数量差值生成的，点击确认按钮的时候，会循环判断明细里面的每一条记录，检查盘前数量和盘后数量是否不一致，如果一致就跳过，不一致就将差值插入到对应的盘盈盘亏单中。写到这里，估计很多小伙伴都已经明白原因了。盘点单界面左下角有个辅助功能用于快速过滤要查找的记录，库房医师先前的操作是快速过滤出了那条要修改的记录，将盘后数量修正成了盘前数量，此时盘点单界面明细里面只有她过滤出来的那一条唯一的记录，库房医师接下来本来想点击保存按钮的，但是她不小心点成了确认按钮。
有的小伙伴，可能会说了，确认按钮里面的代码逻辑肯定要考虑先前有没有过滤，如果有过滤，要先把过滤掉的记录恢复回来啊，当然了，这篇文章读到这里，每个小伙伴都自然而然想到要把过滤掉的数据恢复回来。其实案例中，也确实这么做了，有的小伙伴肯定又会问了：“确实这么做了，怎么还会有问题呢？”。答案是，通过盘点单明细循环判断盘盈盘亏产生盘盈盘亏单明细的代码，出现在了恢复过滤掉数据的前面。这样的话，案例中库房医师的操作过程变成了，先过滤出一条记录，然后循环判断这一条记录，发现盘前数量等于盘后数量，然后就没有生成盘盈盘亏单，接下来执行到的代码就是过滤数据的恢复。当她确认完成后，前台显示的是所有的盘点明细，她当然不知道中途发送了什么啊。试想一下，如果库房医师过滤出的数据不是一条，而是好几条，而且如果顺利生成了盘盈盘亏单，她还会察觉到这个问题吗？当然察觉不到了，结果就是业务逻辑里面跳过了对被过滤掉的哪些明细记录的处理。在没有察觉中，产生了数据的不一致性。
在这个案例中，快速过滤出想要查找的记录，作为一个辅助功能，体现了它存在的价值。但是，对辅助功能的处理一定要严谨。否则，不但会引发数据的不一致性，而且会困扰系统维护人员，因为这种隐藏的bug确实太难发现了。
