一个基于 .NET 8.0 构建的简单、跨平台、模块化商城系统mt

公司SaaS系统有个给客户的员工发放金币，最后计算金币老是流水和总额对不上，以前负责这块的人做过修改还是不对，后来这负责人离职，接手大数据的事情后，该客户真在用金币这块业务，而且财务用这个结算对账，2023年底客户逼急了，要彻底解决这个问题:

和负责这块的产品经理沟通这块内容，说这个金币计算有历史原因导致流水和总额不对，不确定是谁不对，程序也有bug，但现在要重新计算对上，因不懂这块业务，产品经理最后确定原则：

1，每条金币日志流水中会保留当前的金币总数，用这个2022年12月31日的总额为准，把不对的总额改成当前的流水的总额

2，在按当天总额+后面的流水重新计算得到每天的期末和期初（金币余额）

持续多少年的问题，一直没解决，一听就头疼，尽接这样的难题，这里面的坑也不小：

后来查询金币报表的计算逻辑，同时按上面的思路做发现，不能按2的来做，因为到2022年12月31日批量计算后，和报表的总额有部分还是对不上。后来找了产品经理，他说他只是提供一下解决思路，具体怎么做自己想办法了！

整体解决方法如下：

1，SQL查出截止到2022年12月31日的最新的一个金币记录数（2023-01-01前）

2，对比金币数据，不一致的改成上面总额一致

3，通过计算金币流水的存储过程，重新计算从2023-01-01到2023-12-25的每天的金币明细

4，对比金币在2023-12-25的流水总额，不一致的查看不一致原因

5，发现有几十个账号的金币还是不一致， 期初是一致的，通过计算流水到2023-12-25就不一样，不得不一个账号查原因再计算

其中发现有程序bug：2个金币明细表的数据有同一条重复的数据，修改其中的一条金币数为0，还有金币数小于0的计算。

通过这样的笨办法，一个一个看数据，再修正数据到一致，修的眼睛都看花了，程序的bug导致提交后，有2条是一样的数据，让研发同学去改程序。

没想到2周后，客户发现又有账号的金币又对不上，自己手工重新计算后，对比发现就只有1个账号不对，修正好，再加上程序的修正，到现在2024年11月18日，客户再也没说金币不对的问题。

总结：

想想为何这么多年的问题一直没有彻底解决，是真的很难？现在看来，就是数据细心核对修正和程序bug修改，就OK，真是事上无难事，只怕有心人。

本博客参考westworld加速。转载请注明出处！