标签：误差 not 平衡 精度 等于 问题 一点 数据库 自己
2017年1月11日
咨询老核心的计息规则，他们的计提和结息不会抵消。会有应付利息留存的情况。
于是思索了下我们的处理方式，在思索过程中，发现我们的“应付定期储蓄存款利息”有余额并且是-0.01元。于是开始查找问题所在。（按理说，所有客户销户后，将利息都结清给客户，应付利息不应该有余额才对）
思考过程中怀疑过几个点，但是深入分析发现并不是我想的那样。明天继续分析。
新发现的几个点：
1、定期存款的计息规则，计息开始日期一直都是头次交易日，而并非像活期那样是从上次动户日开始算起。由于如此配置，所以outyn字段配置的都是N 。
2、文档里一直都是说：当日计提利息发生额=当日计提利息总额-昨日计提利息总额+当日结息发生额
但是并没有找到加当日结息发生额的地方。对于分录抽取，以为以前看明白了，其实没有。在acctiintbalhist表里是每天的计提利息总额，按日汇总。在分录抽取的时候，结息交易的抽取是在抽取je交易，以及抽取余额里。而后边的注释里写的“抽取存款结息交易”是将结息交易转换成计提交易，然后将acctintbalhist里将当日减去昨日进行抽取。计提交易抽取后，再对计提交易按照交易和余额进行分录抽取
3、分录抽取第一步，非je交易的抽取，实际上是抽取el的交易（el是中间过渡交易，其实是资金类型交易，会在fundtypdtlglacct里找资金类型的科目）。余额类型的交易就是抽mjmiacctgl的交易。一笔交易分别抽取el和notebal，由于是当日交易的汇总，所以el交易会互相抵消。而notebal会自动消减
明天继续分析，分析的点：
1、看看是不是由于精度问题导致，比如在acctintbalhist里，由于精确到6位小数，并且是两部分相加后进行四舍五入。如果提前支取后会不会造成两个比较小的数都四舍了，而一旦相加后大于5进行五入了？
2、期间没有执行过部提的账户都是正常的。计提金额和结息金额是相等的。（四舍五入后相等，并且结息金额一定是计提金额四舍五入后的值，因为算法是一致的），问题一定是出现在有部提的账户上。好在这样的账户并不多。明天将这样的账户，对其计提金额和结息金额进行对比。重点在于如何对计提金额进行汇总。
2017年1月12日
仍然不清楚原因
理论上不会出现这样的问题才对。
不过在T日round之后等于0的时候，今天减去昨天是-407.81，而结息是407.82 但是这也不合理。因为在T不等于0的时候，今天减去昨天是407.81，而结息是8.15
2017年1月13日
2017年1月13日09:48:03
昨夜想到，是不是分录抽取的金额是负数，今天来了检查了一下。涉及到定期的没有负数。（不过，有负数的数据，是活期的利息支出和应付利息科目）
然后将所有的定期应付利息（贷记方向）提取出来，然后自己用sql将今日-昨日+结息计算出来排序。对比，发现2016年4月5日的数据有问题，其他日期的数据，sql计算出来的和数据库里的一致，而4月5号的数据，自己计算出来的比数据库的正好多1分钱。决定重新执行4月5号的分录抽取动作。让刘欢准备数据
（网关评审，到11:40）
2017年1月13日15:52:00 找到原因了，由于销户的交易类型是CLST，而，sql里用的是CLS。判断当日是销户状态并且有销户交易的时候，需要取出数据并且进行将结息转换成计提，将今日减去昨日。而由于cls使用错误，所以数据错误。
不过需要继续深入分析，为什么仅仅差1分钱？
由于结息转计提交易取不出来，在今日减去昨日的时候，销户的数据也取不出来，所以两者仍然是平衡的。但是由于今日减去昨日是精确到6位，而利息时精确到2位，所以会有一个差，所以最后会有一点误差。
标签：误差 not 平衡 精度 等于 问题 一点 数据库 自己
原文地址：http://www.cnblogs.com/bbzm/p/6880479.html
