工作问题总结-----付款

背景：付款成功后需要给外围系统回写付款成功状态，一个定时任务发送需要支付的信息给第三方（cbs），一个定时任务从第三方同步支付状态，然后调用外围系统接口回写付款状态。

　　　涉及的表：单据头表heder，单据支付表boepayment，待支付表efspayment

 

问题：出现零星几笔付款成功后没有回写的数据。

分析：1、在数据库里面日志表中查询，这几笔单据表里面没有存付款成功的报文，两个原因：

　　　　　　a.对方接口返回结果为null(排除，接口是稳定的)

　　　　　　b.我方系统在调用对方接口前出现异常，没有调用对方接口（排除，查看当天日志没有异常）

　　　2、以上两个原因都排除了，我就去查当天打印的日志，之前做这一块的时候添加了一些打印信息为了方便查找，查日志也没有查出具体原因，但是缩小了范围，日志中可以看到程序没有执行到我做了标记的那行。但是分析了程序，只要同步了付款状态过来，就一定能到达这一行，因为中间只查询了一次，而且不可能查不到，查到了就放到map中，做了一次去重处理，所以一直想不到原因。

　　　　　　

 

3、分析了上面的两点之后不知道从哪里下手了，当时怀疑是查询boeheader没查出来导致的，但是又不可能查不出来，有付款行信息，肯定是能通过付款行信息查到头信息的，这很矛盾，但是又没有别的想法，基于此拿了这几笔没有成功回写的单据，改了一部分不影响的数据后在本地进行调试，没有任何问题。无解了，没有任何头绪。

4、周天早上7点有了一点方向，想试图从付款时间方面分析一下，结果如下：

　　付款时间：04/12/ 11：30：14

　　定时任务开始时间：04/12/ 11：30：00    结束时间：04/12/ 11：30：28

　　思考是不是有一种可能是定时任务开始同步的时候，拿到的状态还是付款中，然后在定时任务结束之前，付款成功了，但是我们系统这时候是付款中。但是马上否认了，因为即便刚好有这个时间差，我们系统表里面的状态还是付款中，这样就会6分钟以后重新去cbs同步付款状态过来，这时候拿到付款成功，然后也会回写。

　　但是付款时间是从待付款表中拿出来的，说明14的时候已经同步过来了，付款状态是成功，那为什么没有回写呢？回写的逻辑是取单据头表中支付状态判断，是待付款表更新了状态，头表没有更新吗？

5、再查看日志，结合时间看，发现问题：

　　系统在11：30：28发送过一次，付款中。28时待付款表已经时付款成功了。   ？？？

　　然后在11：35有一条语句更改单据头标状态。

 　　初步想法是，在同步付款状态过来的时候，待付款表状态更改为了付款中，但是头表没有同步成付款中，之后有某个地方再更改了头表状态。

6、查看代码

　　付款逻辑：一个单据可能包含多个支付行，支付行存在【单据支付表】中，在【确认付款】操作的时候，从【单据支付表】生成记录到【待支付表】中，【待支付表】只存一定需要付款的结算信息（【单据支付表】可能存在不需要付款的记录，比如质保金）

　　同步付款状态逻辑：查询出【待付款表】中的支付中的数据，同步这些数据，过来的状态更新【待付款表】，更新【单据支付表】，然后再判断如果每一行都为支付成功状态，更新【单据头表】，表明这个单据已经付款成功。

　　逻辑上没啥问题，但是仔细一翻，发现在判断是否每一行都支付成功的时候，取的是【单据支付表】中的记录来做判断，之前说过了，这个表里面可能存在不需要付款的记录（或者是暂时不需要付款），这个时候就会是存在有还没付款成功的行，所以此时，【单据头表】变成了付款中，而【待付款表】和【单据支付表】的对应行是付款成功，出现了状态不一致了，而我回传付款状态的时候，是要取【单据头表】的付款状态，此时为付款中所以没有回写，而下一次定时任务再执行的时候，因为【待付款表】已经为付款完成了，所以不会再同步这些数据的状态，也就是说这几个单据在第一次执行完定时任务之后，就不会再被这个定时任务执行了（为了防止重付发送）。

 

至于最后【单据头表】状态又是在哪里更新为付款成功的，查看到有另一个定时任务：查询付款成功（查的【单据支付表】）但单据付款状态为支付中的单据，并更新这个单据为付款成功。

所以看到这个时间差是合理的，最后验证，打开这几个单据查看，发现每个单据中都包含不需要付款的行信息。确定了分析正确。

解决方案：在判断是否所有行都支付成功的时候，不查询【单据支付表】，而是查询【待付款表】

总结：没有仔细看过同步支付状态这块的逻辑，不是很清楚，如果是比较清楚的话，可能从单据页面上就能发现问题，就不会花费这么多时间去查原因了，而且如果没有仔细查看这个时间问题，很可能会一直找不到原因，在写代码的时候，还是需要考虑到各种场景，最好是能够画出图来，这样比较能够理得清逻辑。