[REFACTOR] 實作側邊欄與儀表板多語系化,修復 UI 位移與樣式優化
All checks were successful
star-cloud-deploy-demo / deploy-demo (push) Successful in 52s
All checks were successful
star-cloud-deploy-demo / deploy-demo (push) Successful in 52s
This commit is contained in:
@@ -43,10 +43,20 @@
|
||||
|
||||
---
|
||||
|
||||
## 4. 待確認事項 (To-be-confirmed)
|
||||
## 4. 數據完整性與異常處理 (Integrity & Exceptions)
|
||||
|
||||
### 4.1 數據完整性稽核
|
||||
1. **自動對帳**:是否需要定期自動比對「B600 收取金額」與「B602 實際出貨金額」,並將差異標記為異常訂單?
|
||||
### 4.1 自動對帳機制 (Auto-Reconciliation)
|
||||
* **機制**:系統後台需建立定期定時任務(Scheduled Task),比對同一 `flow_id` 下的以下數據:
|
||||
- **B600 (收取金額)**:訂單總計金額。
|
||||
- **B602 (出貨總價值)**:機台實際出貨商品之總價值。
|
||||
* **異常標記**:若兩者金額不符(例如:付了 $50 但僅出貨 $0 或 $30),系統應自動將該訂單標記為 **「金額異常」**,並同步產出警示通知供營運人員手動稽核。
|
||||
|
||||
### 4.2 失敗補償邏輯
|
||||
2. **出貨失敗處理**:若 B602 回報「出貨失敗」,系統是否需觸發自動退款程序(限線上支付)或發送補發通知?
|
||||
### 4.2 出貨失敗處理 (Dispense Failure)
|
||||
* **原則**:若 B602 回報「出貨失敗」,系統**不觸發自動退款**程序。
|
||||
* **處理流程**:系統僅記錄失敗狀態並維持訂單為「待處理/異常」,後續由客服或管理員介入,根據實際情況進行人工退款、補發指令或現場處理。
|
||||
|
||||
---
|
||||
|
||||
## 5. 待確認事項 (已結案)
|
||||
|
||||
所有關鍵決策已於 2026-03-12 完成確認。
|
||||
|
||||
Reference in New Issue
Block a user