Actions
CR #898
open
RA
[CR-083] 額度「佔用 → 已用」之跨服務缺口（消費不會推升 `used_amount`）
CR #898:
[CR-083] 額度「佔用 → 已用」之跨服務缺口（消費不會推升 `used_amount`）
Status:
New
Priority:
P1-High
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:
0%
Estimated time:
Story Points:
Description
h2. 來源文件
/Users/ecsrevamp/Documents/GitHub/WorkBuddy/cardcore/docs/05-change-requests/CR-083_額度佔用結算（佔用→已用）之跨服務缺口.md
h2. 摘要（節錄自文件）
| 項目 | 內容 |
|---|---|
| 文件編號 | CR-083 |
| 版本 | 1.0 |
| 日期 | 2026-10-25 |
| 提出者 | WorkBuddy AI（開發團隊） |
| 緣起 |
CR-073 GAP-003⑪-1（5-11 每期出帳）之事實查證（GAP-003 §1.5 B） |
| 狀態 | 待 BEAM PMO 核定（本文件為提案） |
| 影響範圍 |
limit-service（主要）、installment-service（消費端）、authorization-service（未來）、契約、SCS-002、ACL |
| 關聯 |
CR-073 #886、SCS-002、SCS-009 §7.8、SDD-001 §3.4、SDD-005 §3
|
1. 現象（不是推論，是實查）¶
目前專案中沒有任何路徑會因為「消費」而增加 CC_LIM.ACCOUNT_LIMITS.USED_AMOUNT。
| 查證項 | 實查結果 |
|---|---|
LimitRepository 之寫入方法 |
createHold／releaseHold／restoreUsedAmount（減）／reoccupyUsedAmount（加，但語意為「繳款沖正後重新佔用」）／applyAdjustedAmount／raiseTemporary／lowerTemporary
|
LimitController 之端點 |
只有 5 個：查帳戶額度、查載具額度、建佔用、查專用額度適用、釋放佔用——無 settle／consume |
restoreUsedAmount／reoccupyUsedAmount 之呼叫者 |
僅 JdbcPaymentPostedProjectionRepository（繳款入帳→恢復）與 JdbcPaymentReoccupyProjectionRepository（繳款沖正→重新佔用） |
PostingTransactionPostedListener（limit 端） |
只做 8-6 專用額度迄日校正（CR-035 §2.4），不更新 used_amount
|
StatementIssuedListener（limit 端） |
只做 8-6 迄日校正，不更新 used_amount
|
後果：used_amount 在現行系統中只會「因繳款而減少、因繳款沖正而加回」，
不會因刷卡／分期出帳而增加——它是一個只降不升的欄位。
2. 影響¶
| # | 影響 | 嚴重度 |
|---|---|---|
| 1 |
BRD-004 5-11「出帳金額佔卡人額度」無法成立（CR-073 唯一未交付條文） |
高（POC 驗收項） |
| 2 |
可用額度之計算失真：available = permanent + temporary − used − hold。消費若只留在 hold，則交易一旦被「釋放」（取消／逾期）額度就全回來，已實際消費的金額從未計入已用
|
高（資金風險） |
| 3 | 帳單金額與額度已用不一致：帳單有金額、used_amount 卻沒動 → 對帳差異無法解釋 |
高 |
| 4 |
CC_LIM 之 used_amount 實質成為「歷史殘值」，報表／風控引用即失真 |
中 |
⚠️ 第 2 點意味著本缺口不只影響 5-11，而是全專案消費鏈路的共同缺口。
3. 選項與建議¶
完整內容以版本受控文件為準（GOV-008 §2 單一真實來源）。
RA Updated by Redmine Admin about 15 hours ago
h2. 實作完成並閉環（2026-10-25，#A-396）
狀態：由「待核定」→ 已實作並真機驗證。
h3. 交付
- 端點：@POST /api/v1/limit-holds/{holdId}/settlements@（body @{amount}@）——@released_amount += n@、@settled_amount += n@、@used_amount += n@（兩步同交易）→ 淨效果 @available@ 不變（消費不應讓可用額度回升）。
- 遷移：@V22@ 加 @SETTLED_AMOUNT@（@CHECK settled <= released@）。
- ★ @V23@ 修既有潛在缺陷：@LIMIT_HOLDS.STATUS@ 為 @VARCHAR2(16)@，但 CHECK 宣告之 @'PARTIALLY_RELEASED'@ 長 18 → 永遠寫不進去（@ORA-12899@）。既有 @releaseHold@ 之 SQL 為 @ELSE status END@（部分釋放保留 @HELD@），故從未寫入該值、長期未浮現；本 CR 首次寫入即撞牆。→ 放寬至 @VARCHAR2(24)@（值域／CHECK 不變）。
- 消費端：@installment@ 出帳由 @release@ 改 @settle@，使 BRD-004 5-11「出帳金額佔卡人額度」成立。
- 規格：@SCS-002 §7.23@、@SDD-006 v1.31@（@CC-LIM-3001@ 描述擴充）、@SCS-009 §7.8@；決策 D-054；契約 145 端點 0 錯誤。
h3. 真機驗證（8 項）
出帳前：@used=200,000@、@hold=1,073,334@、@avail=8,726,666@¶
出帳 @2027-01-25@：11 期中 10 成功、1 期失敗（見下）¶
出帳後：@used=473,334@、@hold=800,000@、@avail=8,726,666@（不變） ¶
失敗那期：500 @ORA-12899@ → 修正後以 API 重放 200 成功（@used@ 再 +400,000）¶
超額／已全釋放 → 409 @CC-LIM-3001@ ¶
查無 hold → 409 @CC-LIM-3001@ ¶
純 @releases@ → @used@ 不變（既有語意未回歸）¶
DB：@E56DB478@／@0816869F@ 之 @settled=0@（取消交易→純釋放）、@625497A6@ 之 @settled=13,334@（出帳→結算）——同一欄位可區分¶
h3. 如實揭露
未發射 @limit.hold.settled@ 事件——下游（報表／風控）目前只能靠查詢得知。¶
@used_amount@ 之既有殘值不追認（如 @…0003@ 的 200,000），未重算。¶
@authorization@ 之「授權→請款→已用」鏈路未改——本 CR 只讓 @installment@ 使用 settle，授權端仍 hold→release，屬另案。¶
驗證在開發 DB 產生真實 @used@／@hold@ 變動，未清理。¶
h3. 證據
@docs/08-evidence/CR-083_佔用結算_20261025/@（README＋4 份原始輸出）
h3. 影響
@CR-073@ 之 8/8 缺口全部收斂（5-11 之 ⑪-1＋⑪-2 完成）。
Actions