一.integral
1.1：tradecapture duplication
解決方案：每一條通過integral進入的trade，17（execid）屬性是唯一的，把這個屬性改一下就不會出現這個問題了
1.2 value date not consistent on back to back trades
解決：作為一筆abook trade，對應了兩條trade（兩條fixmessage），settledate要一致（swap除外），所以64（settledate）屬性值要一樣。
同時解決了乙個問題，fix的資訊都會先進入tradecapture，所以一定要從這裡開始看，coverid是關鍵資訊。
二.journal–cashbalance
2.1：cashbalance裡面的資料缺了financing fee
cashbalance是在earth模組裡生成的，裡面的初始資料是posting_activity，在這裡我只找到了由trade生成的資料，而從journal過來的並沒有看到。
關鍵點在於journal的執行過程中會去生成journal_posting，這些資料就是我們需要的。但讓我困惑的是，我jounal生成的posting也有了，那生成的cashbalance怎麼就不對？
2.2 手動錄入的journal和自動生成的journal的對比
在測試中發現currency所對應的所有資料為0，此時是否應該顯示出來，這裡跟一般的資料有就顯示出來不同的是，它實際上並沒有出現，這就需要測試憑藉經驗去思考正確與否。系統裡的功能繁多，針對不同的產品，會有不同的細節，如何控制好這些細節，並得到乙個正確的結果，這個需要好好思考。
訂單業務梳理
校驗使用者是否存在以及是否被禁用 校驗商品，是否已下架，選購數量是否正，不能為0，不能為null並不能操作5件，檢查商品庫存，門店會員則檢查門店庫存 預售商品，檢查預售時間 預售渠道是否滿足配置要求 組裝滿足條件的商品資料結構 處理收件人，獲取預設收件人資訊，如果沒有預設收件人則獲取收件人第一條資料...
系統梳理業務日誌記錄
標題索引 一.日誌現狀 接觸某政務集群伺服器後，運維的不規範化體現的淋漓盡致，嚴重違反了本公司首席架構師提出 統一規劃 統一管理 統一運維 統一運營 的理念，首先無監控系統 其次無日誌管理系統，日誌管理系統統一採用本地日誌管理，因此與統一管理的理念差之毫釐，受相關委託進行優化服務架構，基於集群伺服器...
業務導航需求框架梳理
1 角色分為營銷人員 營業部管理員 分公司管理員和總部管理員，賦權崗位為老總 合規，需要功能模組賦權 2 營銷人員檢視自己名下客戶業務開通情況，關注點在未開通的業務，分兩個路徑，查詢某項業務有哪些客戶尚未開通，沒有開通是卡在哪一步 查詢單個客戶，哪些業務尚未開通，未開通的業務是卡在哪一步 3 營業部...