公司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，真是事上無難事，只怕有心人。