## 1. ReSettleHandler
重新結算，產生沖銷單跟訂正單
單號就用一樣的，沖銷單意思就是把原注單正變負，負變正
訂正單就是這張單最後被修改的結果
原注單+沖銷單+訂正單的數值 = 最後修正的結果

## 2. GameThirdPartyStakeID是不是一定只能對應TxId
GameThirdPartyStakeID 就是他們後台的注單號
TxId 只是單一錢包那邊用來判斷交易的，他不一定是住單號


## 3. 负数的话，有个日志记录下就好了
開一張表，紀錄，哪個遊戲商，哪個注單號，甚麼時候被扣到負數的金額為多少
遊戲商交易紀錄都不變，主要是錢包餘額異動這邊有點像是紀錄我們"認賠"了多少錢

ex:如果我剩900 那他要扣1000，交易紀錄這裡要寫多少？

交易紀錄都是留原始資料 -1000
交易紀錄是我們要跟對方對帳用

## 4. 文字統一轉小寫判斷

## 5. 設定代理 owindev, dev_owint, 密碼隨便

## 6. TODO 標記，然後要記得解。

## 7. 遊戲商注單測試報告。

## 8. 要不要做個Postman整合報告。

## 9. 除了下注要判斷遊戲是否已加入該分站及遊戲狀態、遊戲館狀態外，其他結算派彩等動作指需要拿到對應資料即可，否則下注成功但後續狀態改變永遠無法派彩成功，純拿資料的話，連狀態都不能擋。

(流程上如果方便驗遊戲及遊戲館狀態在驗就好，也不是每個遊戲流程都會跟我們系統架構剛好有配合的)


## 10. 新增遊戲時，Owin測試站與Queen99測試站。要打勾。

## 11. 專案檔案總管分類一致

## 12. 電子遊戲類是不會有取消單的

## 13. 重複單據判斷欄位
/// <summary>
/// 原注單序號(對沖注單)
/// </summary>
public string? ParentStakeId { get; set; }

## 14. 要存資料或是Where資料的時候要多注意條件，比如加上，遊戲商代號之類的。才不會不小心重複。

## 15. 注意對方遊戲商的環境(DEV、UAT或是直接就是正式)

## 16. 注單有效投注額確認，注單只要是取消、拒絕、不成單的狀態(或任何遊戲商有指定的狀態)，有效投注都應該要是零。

## 17. 注單Handler ID 分離

## 18. 沒用到的參數要注意，量多一定會消耗記憶體，儘量使用DTO Class傳遞API參數，指傳遞有用到的部分。

## 19. IDR與VND的幣別轉換確認

## 20. 如果情況允許，就用String去接Datetime

## 21. 注單如果遊戲未定義的話，要去定義，主要是對應ThirdPartyGameNo欄位。定義完成後，會有另一個排成把這些資料，丟到正常排程內。

## 22. SP參數對應檢查。

## 23. Switch default及狀況對應檢查

## 24. ThirdPartyGameNo 是對方系統識別的遊戲編號，GameNo是我方系統識別的遊戲編號。bucketGame的GamNo === Game的No === Report_Stake的GameNo

## 25. 更新Entity要記得移除DB context連線字串。

## 26.