# CR-045　「參數極大化」三位一體（商品組合 × 行銷活動 × 系統參數）——現況盤點與落差

| 項目 | 內容 |
|---|---|
| 文件編號 | CR-045 |
| 版本 | **1.3** |
| 狀態 | ★ **現況盤點已完成、治理提案待裁定**（BEAM PMO 2026-10-15 指示「參數極大化」為最高宗旨）；本版已更正文件／程式漂移及 L0–L3 分級 |
| 提出日期 | 2026-10-15 |
| 提出者 | 開發團隊（★ 來源為 BEAM PMO 2026-10-15 口頭指示：**「最高宗旨為參數極大化」**） |
| 影響文件 | `SCS-023`（商品組合）、`SCS-005`（產品服務）、`SCS-019`（批次框架）、`SCS-022`（安全）、`SDD-001 §3`（資料模型）、`SDD-005`（狀態機）、`GOV-004`（追溯矩陣） |
| 影響模組 | `product-service`、`pricing-service`、`limit-service`、`rewards-service`、`billing/statement-service`、`card-service`、`common-security`、全體領域服務（消費端） |
| 優先級 | **P1（高）**——跨全系統治理議題；★ 參數表/API 與部分規格已具備，但**執行期消費閉環未獲證明且文件有漂移** |
| 相關前例 | **`SCS-023 v1.4`**（「組合優於列舉」，BEAM PMO 2026-09-20 指示）、`CR-014`（`SPECIAL_LIMITS`）、`CR-043 §3.1`（移除未實作端點宣告；卡片級查詢需求另追 `GOV-006 2.4.4`）、`#A-234`／`#A-235` |

---

## 1. 摘要

BEAM PMO 2026-10-15 明示：**最高宗旨為「參數極大化」**，其至少須達成
**三位一體**——**① 商品組合、② 行銷活動、③ 系統參數**——之參數化。
並附帶一句關鍵提醒：**RFP 未載明「卡片級可用額度查詢」，但客戶最終一定會要求**。

本文為**現況盤點與落差報告**（★ **未動手新增功能**，**待裁定後另案執行**）。
★ 全篇逐項以**現行原始碼 ＋ 現行規格 ＋ 現行 DDL** 重新核對（**非抄舊結論**；
依 `MEMORY-RULES` #17／#38 之「未查證之待辦／他人之已完成，皆可能是幽靈」紀律）。

**一句話結論**：本系統已有 `product.parameters` 參數表/API、`product.rule_sets` 規則表，
亦有 SCS-023 的 24 個能力鍵與 7 個測試 profile；但**規格宣告的跨服務同步取參數路徑，
在現行 Java 原始碼中找不到實際下游客戶端**。因此，應將它們視為**「資料模型與規格先備、
尚未證明執行期消費閉環」**，不可把「有表／有端點／文件列相依」等同「參數已驅動業務」。
工作重心是**先釐清權威與程式/文件漂移，再逐個打通『參數 → 可觀察行為』**；
也不宜為追求「單一」而把所有領域規則硬塞進同一張泛型表。

---

## 2. 緣起與判準

### 2.1 BEAM PMO 指示原文（逐字）

> 「……最高宗旨為：**『參數極大化』**，所謂參數極大化是個模糊空間，但至少要達到：
> **商品組合、行銷活動、系統參數**，這三位一體參數極大化的目的。
> 就**商品組合**而言：新用卡、借記卡、無擔保貸款、採購卡……，這一類『商品』要能夠用參數定義，
> 當然包括**總額度、個別額度等多維度的設計**。
> 就**行銷活動**而言：年費、免年費、紅利積點、里程累計、刷卡滿額禮……等，都要是**參數化**。
> 就**系統參數**而言：大到**每年的節假日、跑批、結算、帳單週期**，
> 小到**人員安控機制**等，也都要**參數化**。」

### 2.2 本文採用之「參數化達成度」判準（四級）

為避免「有表即算完成」之**假綠**，本文對每一參數維度採四級判定：

| 級別 | 意義 | 判準（可稽核） |
|---|---|---|
| **L0 無** | 無可確認的資料模型／功能實體 | 文件、DDL、程式皆查無該能力（只在需求描述出現不算有） |
| **L1 已建置、未閉環** | 有資料模型／設定端點／獨立子域規則，但未證明被目標業務流程消費 | 必須指出具體 API／表／程式；消費鏈缺失或僅能查閱設定 |
| **L2 有執行期消費、未閉環** | 有真實消費路徑，但部分行為仍寫死、功能覆蓋不足或未證明參數變更可即時生效 | 找到生產程式的讀取與決策分支，但閉環測試未全 |
| **L3 閉環** | 參數變更 → 執行期行為隨之改變（**實測可證**） | 改權威值後，真機業務行為隨之改變且可還原 |

★ **判準核心**：以「**改了參數，行為會不會跟著變**」為準，**不以「表是否存在」為準**。

---

## 3. 軸一：商品組合（Product Composition）

### 3.1 已具備（規格層）

- **`SCS-023 v1.4`《卡片商品組合與測試卡片檔產生規格》** 已立，核心原則為
  **「組合優於列舉」**（BEAM PMO 2026-09-20 指示）——即商品不由「硬編代碼」列舉，
  而由**能力維度組合**定義。
- **`CAPABILITY_KEYS` 共 24 維度**已定義，涵蓋：
  - 發行／額度：`issuance.form`、`limit.model`、`limit.shared_scope`、`limit.grant_required`
  - 循環／還款：`revolving.enabled`、`revolving.rate_annual`、`payment.grace_days`、`payment.auto_debit`
  - 分期／預借：`installment.enabled`、`cash_advance.enabled`
  - 商戶控制：`mcc.allowed`、`mcc.blocked`
  - 票券／附卡：`ticket.*`、`supplementary.*`
  - 跨境／代碼化：`cross_border.enabled`、`dcc.enabled`、`tokenization.platforms`
  - **帳務：`billing.cycle_day`、`billing.currency`**
  - 風控／網路：`kyc.level`、`network_allowed`
- **7 個測試／設計 profile**已規劃：`REVOLVING_CREDIT`、`CHARGE_CARD`、
  **`VIRTUAL_LOAN_CARD`**（對應**無擔保貸款 eLOAN**）、**`PURCHASE_CARD`**（對應**採購卡**）、
  `COBRAND_TICKET`、`PREPAID`、`CORP_TRAVEL`。★ 這是 `SCS-023` 的組合範本，**不等同於 7 個已部署、
  已可供線上授權使用的商品**；另缺借記卡 profile。
- **Oracle 實查已存在**：`CC_PRODUCT.PRODUCTS`、`PARAMETERS`、`RULE_SETS` 三表皆存在。
  `PARAMETERS` 有 namespace／param_key／JSON value／value_type／effective date；
  `RULE_SETS` 有 rule_type／condition／action／priority／status，但**沒有 product_code、campaign_id、
  生效區間欄位**，且尚無其 CRUD API／執行期 RuleEngine。

### 3.2 落差（實作層）

| # | 落差 | 級別 | 證據（as-found） |
|---|---|---|---|
| P1 | **商品參數未證明進入線上決策** | **L1** | 全 backend 源碼檢索未找到下游呼叫 `/api/v1/parameters` 的 client／port；`SAD-002` 列有同步依賴、`CR-031` 又稱 9 服務同步取值，但 `CR-031 §3.1` 同時記錄 9 服務無 `ProductClient`／`ParameterPort`——**文件與程式結論互相矛盾**，應以現行程式為執行事實、以文件為待更正之設計意圖 |
| P2 | **`limit.model`／`limit.shared_scope` 尚未被額度路徑消費** | **L1** | `limit-service` 無產品參數遠端 client／port；目前有帳戶額度及專用額度模型，但未按 SCS-023 商品能力組合決定額度層級／共享範圍 |
| P3 | **總額度／個別額度的商品多維度尚未端到端落地** | **L1** | 既有帳戶永久／臨時額度與專用額度不是「已按商品參數完成總額度／個別額度建模」的證據；`CAPABILITY_KEYS` 無執行期分支，卡片與帳戶／企業共享池的分攤語意尚待規格 |
| P4 | **`借記卡`（Debit）無對應 profile** | **L0** | 7 個 SCS-023 profile 中無 Debit／借記檔（`PREPAID` 為預付、非借記）；BEAM PMO 明列「借記卡」為應支援商品 |
| P5 | **`product.rule_sets` 僅有資料表，尚無管理／執行鏈** | **L1** | Oracle DDL 有表；Java 無 `RuleSet` repository／API／RuleEngine 實作；表本身亦缺商品／活動關聯與生效區間欄位 |

### 3.3 小結

商品組合**有設計字典與測試 profile，尚無證據證明線上決策消費這些能力參數**：
`CAPABILITY_KEYS` 的 24 維度不等於已實作的商品行為；既有帳戶級額度、專用額度亦不等於
已按商品定義總額度／個別額度／共享額度。BEAM PMO 所舉情境中，無擔保貸款與採購卡有測試 profile，
一般信用卡有 profile；**借記卡 profile 缺漏**，且 7 個 profile 均不能視為已上線商品。

---

## 4. 軸二：行銷活動（Marketing／Campaign）

### 4.1 BEAM PMO 所列五項之現況

| BEAM PMO 所列 | 現況 | 級別 | 證據（as-found） |
|---|---|---|---|
| **年費** | **有規則設定查詢，未形成費用收取閉環**——`PRICING_RULES.RULE_TYPE=ANNUAL_FEE`／`FEE_AMOUNT`／生效區間存在；`GET /fees` 可查 | **L1** | `SCS-006 §6／§7.7` 明定本期只查詢、不計算／不入帳；`feeName` 由 `RuleType` 對照表硬編，`currency` 固定 `TWD`；DDL 無 `fee_name`／`currency` 欄，也無活動連結 |
| **免年費** | **有規則型別，未證明減免政策被費用流程消費**——`RuleType.FEE_WAIVER`／設定列存在 | **L1** | `GET /fees` 僅查詢設定；無年費收取／免除計算或入帳流程；減免條件未連商品／客層／活動生命週期 |
| **紅利積點** | **有獨立的回饋規則維護端點，未證明規則被累點流程消費**——`rewards-service` `RewardRule`／`/reward-rules` | **L1** | `RewardRuleRepository` 只在規則維護服務被使用；累點服務未讀取規則計算交易點數；規則與 `product.rule_sets`、商品／活動未關聯 |
| **里程累計** | **無** | **L0** | 源碼／DDL 檢索未找到里程帳戶、里程規則或里程累計流程 |
| **刷卡滿額禮** | **無** | **L0** | 源碼／DDL 檢索未找到滿額禮活動實體、資格追蹤或達標發放流程 |

### 4.2 結構性落差

| # | 落差 | 級別 | 說明 |
|---|---|---|---|
| M1 | **無「行銷活動」aggregate／生命週期模型** | **L0** | 現有 DDL／Java 未找到 campaign 主檔、活動狀態、活動對象／受眾、活動期間及管理 API |
| M2 | **規則設定與執行規則分離** | **L1** | `product.rule_sets` 僅有通用 JSON DDL、無 CRUD／RuleEngine；pricing 只查年費設定，rewards 有 RewardRule 維護端點但累點路徑不消費規則 |
| M3 | **行銷規則分散於各域且未接合** | **L1** | 點數規則在 rewards、年費／費用規則在 pricing；未見共同活動識別碼／跨域參照或統一有效期 |
| M4 | **無活動資格、期間、疊加／互斥、預算上限模型** | **L0** | `PARAMETERS` 的單鍵生效區間不等於活動生命週期，也無活動間優先序／疊加及發放上限語意 |

### 4.3 小結

行銷活動為**三軸中最弱之一軸**：里程與滿額禮**缺模型與流程**；年費／免年費只有費率設定查詢、
沒有費用收取或免除執行；紅利規則可維護，但累點流程未消費該規則。**核心缺口不只是「少一張活動表」**，
而是缺活動生命週期、規則所屬權威、活動資格／期間／疊加，以及連接 pricing／rewards 執行端的契約。
`product.rule_sets` 目前只是通用表，沒有 API／消費者，且 schema 缺商品／活動關聯與有效期；
不得僅因它有 `REWARD`／`FEE` 值域就推定其足以承載行銷活動。

---

## 5. 軸三：系統參數（System Parameters）

### 5.1 BEAM PMO 所列各項之現況

| BEAM PMO 所列 | 現況 | 級別 | 證據（as-found） |
|---|---|---|---|
| **系統參數儲存** | **有可用設定庫/API**——`product.parameters` ＋ `GET`／`PUT /api/v1/parameters/{namespace}/{paramKey}` | **L1** | product schema／API 存在；但全 backend 源碼未找到下游呼叫；文件所稱 9 服務同步取值與實作檢索不符（§5.2/S5） |
| **節假日** | **無日曆模型** | **L0** | 源碼／DDL 未找到 holiday／business calendar；批次規格僅要求「須納入」營業日曆 |
| **跑批** | **有排程機制、非集中業務參數**——`SCS-019` common-batch 框架存在；具體排程由服務註冊 | **L1** | `@Scheduled` 可由服務屬性覆寫且帶預設值；頻率／作業參數沒有集中納入 `product.parameters`，各領域 SCS 尚需凍結 |
| **結算** | **有服務作業與排程，非統一設定** | **L1** | clearing 等域有其作業；「每日結算」屬 `SCS-019` 設計意圖，未見統一結算日曆／營業日規則模型 |
| **帳單週期** | **部分建置**——`CC_PARTY.ACCOUNTS.statement_day` 已存在；SCS-023 另列 `billing.cycle_day` 商品能力 | **L1** | 原始碼／DDL 有帳戶級結帳日；未找到 `billing.cycle_day` 商品參數消費路徑或其與 statement job 的商品級連動 |
| **人員安控（RBAC）** | **認證存在、角色授權缺失** | **L0** | JWT 認證／角色 claim 解析能力存在；`SCS-022 §6.3` 明載本期不實作角色授權，故尚無可限制參數／活動維護者的生產授權政策 |

### 5.2 結構性落差

| # | 落差 | 級別 | 說明 |
|---|---|---|---|
| S1 | **參數讀取／事件消費的文件與實作漂移** | **L1** | `product.parameter.changed.v1` 有生產端；`CR-031` 設計目的為快取失效，並確認 9 服務無快取；但其「各服務同步取值」文字與現行 Java 無下游 HTTP client／port 之檢索結果矛盾。事件無消費者目前不構成「快取失效缺陷」，真正前置工作是先落地至少一個業務參數消費路徑 |
| S2 | **無節假日／工作日曆模型** | **L0** | `SCS-019` 提及營業日曆需求，但現行 schema／程式無日期、地區、日曆版本及順延規則模型 |
| S3 | **批次／結算／帳單參數未有統一權威** | **L1** | 部分 `@Scheduled` 使用服務屬性（可覆寫）而非程式常數；但排程觸發、作業業務日、結算窗口仍為服務級設定，沒有中央業務日曆／參數來源與統一變更稽核 |
| S4 | **RBAC 授權政策未實作** | **L0** | JWT 認證與 role claim 解析不等於授權；`SCS-022 §6.3` 明載本期未實作角色授權，參數維護 API 尚無角色／職責分離政策 |

### 5.3 小結

系統參數軸已有可用的 `product.parameters` 設定庫/API，但**沒有證據證明它已驅動下游業務**；
此外批次排程有服務級屬性、帳戶級結帳日也已有欄位，不能籠統稱作「全數硬編」。
真正缺口是**統一的權威分類、業務日曆、跨域參數消費與人員授權**。
★ 切入點不是「一口氣新增全體事件消費者」：先選一項業務能力（例如商品級額度策略）
完成**規格 → API／port → 真實消費 → 改權威值之真機閉環**；快取與事件失效僅在有快取且效能有量測需求時落地。
RBAC 及設定維護稽核必須先於將敏感參數維護 API 開放給業務角色。

---

## 6. 卡片級可用額度查詢之定位（★ BEAM PMO 特別提醒）

### 6.1 現況

- **RFP 未載明**「卡片級可用額度查詢」。
- `CR-043 §3.1` 已從 OpenAPI **清除未實作的卡片級端點宣告** `GET /api/v1/cards/{cardId}/limits`
  （端點數 96 → 95）。這只完成**契約清理**，不是卡片級查詢需求的實作或需求結案。
- 目前有帳戶級額度查詢 `GET /api/v1/accounts/{accountId}/limits`；其存在**不代表**已定義卡片／附卡／企業子額度的可用額度分攤。
- ★ BEAM PMO 2026-10-15 明示：RFP 未列、但客戶最終一定會要求；因此列為**預期需求準備項**，與 CR-043 契約清理分開追蹤。

### 6.2 定位建議（★ 不回復 stale 端點）

| 選項 | 說明 | 建議 |
|---|---|---|
| A | 回復已移除之 `/cards/{cardId}/limits` | ✗ **不建議**——原契約端點沒有實作及消費者，亦未定義查詢語意；不應直接復活 |
| B | **另立 WBS 預期需求項＋後續 CR**，先凍結額度模型／卡片分攤口徑，再設計新端點 | ★ **建議** |

**理由**：卡片級可用額度**本質是「商品組合 × 額度多維度」之消費端**（§3 軸一）。
帳戶級額度查詢存在，但不等於卡片／附卡／企業子卡共用池的分攤已定義。
在 `limit.model`／`shared_scope`、卡片—帳戶關係、佔用／保留額展示口徑未凍結前，直接重建端點會產生語意不完整的回應。
故建議順序為：**先凍結額度權威與多維度規格 → 實作消費閉環 → 依客戶口徑另立卡片級查詢 CR**。

### 6.3 追蹤動作

1. 已在 **`GOV-006 2.4.4`** 登錄「預期需求：卡片級可用額度查詢」，與 CR-043 的契約清理分開追蹤。
2. **不**在 `gen_openapi.py` 恢復該端點；正式需求需有新 CR／SCS／生成器規格，並依賴商品額度多維度模型。

---

## 7. 治理提案：三位一體之統一參數化架構

### 7.1 核心設計原則

**「三軸治理一致、每一領域權威清晰、執行期消費可驗證」**——不是把所有設定與規則塞進一張泛型表：

```mermaid
flowchart TD
    subgraph UP["上游權威（參數／規則持有）"]
        PS["product-service<br/>products / parameters<br/>商品能力與一般系統設定"]
        PR["pricing-service<br/>pricing rules<br/>費率／費用計算權威"]
    end
    subgraph CON["消費閉環（執行期行為驅動）"]
        LS["limit-service<br/>額度策略之消費端"]
        ST["statement<br/>帳單週期消費端"]
        PO["posting<br/>實際入帳端"]
    end
    subgraph DOWN["下游規則消費與活動聚合"]
        RW["rewards-service<br/>points rules + ledger<br/>點數計算與帳務權威"]
        CA["Campaign aggregate<br/>新增規格：資格／期間／疊加<br/>連結各域規則，不接管計算"]
    end

    PS -->|domain-owned synchronous API| LS
    PS --> ST
    PS --> PO
    PR --> LS
    PR --> ST
    PR --> PO
    LS --> RW
    ST --> CA
    CA -->|連結各域規則（不接管計算）| RW
```

> **注意**：`product.parameter.changed.v1` 事件僅在快取實際存在、失效需求經量測後，作快取失效訊號；不把它當成所有業務行為的命令，也不把未定義的規則值塞入事件。

★ `product.rule_sets` 現況僅是資料表；是否升格為規則管理 API／執行引擎須經規格裁定。
節假日／批次排程／RBAC 亦應分別由日曆、作業調度、安全政策的權威模型承載，不能假設都適合用同一 JSON 參數。

### 7.2 三軸之治理動作

| 軸 | 治理動作 | 對應落差 |
|---|---|---|
| **軸一 商品組合** | ① 先對齊 `SAD-002`／`CR-031` 的同步取值設計與現行實作；② 為首個線上消費場景（建議商品額度策略）立 SCS，經 `ProductPort` 取版本化參數並真機證明改值改行為；③ 定義總額度／個別額度／共享範圍權威與一致性；④ 補借記卡測試 profile；⑤ `RULE_SETS` 只在規則語意、管理 API 與真實消費者確定後才接線 | P1–P5 |
| **軸二 行銷活動** | ① 先立 Campaign aggregate（活動代碼／期間／受眾資格／疊加互斥／優先序／上限／稽核）；② Campaign 關聯 pricing／rewards 各自擁有的規則，不預設將規則搬進 `product.rule_sets`；③ 年費定價查詢升級到有明確幣別與收取／減免執行鏈；④ 里程與滿額禮先立語意、帳務與冪等規格再實作 | M1–M4 |
| **軸三 系統參數** | ① 建工作日曆權威（地區／日期／日曆版本／順延規則）；② 對齊已存在的 `statement_day` 與 `billing.cycle_day`，禁止重複真相；③ 將批次「何時跑」與「業務日／業務參數」分離治理；④ 先補設定維護者之 RBAC／職責分離／變更稽核；⑤ 參數事件僅於快取存在且需失效時訂閱 | S1–S4 |

### 7.3 建議優先順序（依「正確性 × 依賴 × 可驗收」排序）

| 批次 | 內容 | 理由 |
|---|---|---|
| **0：權威與安全** | 更正文檔與程式漂移；定義參數 owner／key schema／單位／生效日／稽核；先決定誰能維護參數（RBAC） | 避免錯把文件意圖當已實作；不能先開放高影響設定寫入再補授權 |
| **甲：商品消費閉環** | 選一條商品能力（優先額度多維度）補 SCS、client/port、runtime 分支與 Oracle 真機改值實驗 | 以最小閉環證明 SYS-4 真能驅動業務，而非先鋪 9 個空消費者 |
| **乙：系統營運參數** | 工作日曆；帳單日權威映射；批次／結算作業業務日與排程設定分層 | 先處理會影響跨域日期計算與批次的共同基礎；採既有欄位／框架，不重複建模 |
| **丙：行銷活動** | Campaign lifecycle + eligibility/stacking/priority/limits；連接 pricing／rewards 實際執行 | 需業務政策輸入與帳務、冪等、撤銷語意，先規格後開發（★ 政策已於 2026-10-15 由 BEAM PMO 核定，見 §8.2） |
| **丁：預期需求準備** | 商品額度多維度完成後，另立卡片級可用額度查詢 CR 並真機驗證共享額度分攤 | 依賴商品／額度權威模型；本期不恢復 stale 端點 |
| **戊：擴充商品與規則** | 借記卡 profile、里程／滿額禮等增量能力 | 每項依客戶政策逐一形成可執行規則與追溯，不以一張泛型 JSON 表假裝完成 |

---

## 8. 待裁定事項

| # | 事項 | 建議／待決 |
|---|---|---|
| D1 | 是否採納 §7 之治理原則與批次排序 | ★ 建議採納「單一權威、領域規則由各域持有、消費閉環逐項驗證」；不採一張泛型表／全體事件消費者的做法 |
| D2 | 卡片級可用額度查詢之定位 | ★ 另立 WBS 預期需求準備項，待額度多維度與分攤語意凍結後另立 CR；不恢復 stale endpoint |
| D3 | 行銷活動實體與規則擁有者 | ★ 建 Campaign lifecycle／關聯模型；pricing 與 rewards 保留各自計價／點數規則權威。`product.rule_sets` 不直接升格為活動模型，除非後續規格證明語意適合 |
| D4 | 軸一第一條消費閉環 | 建議先補規格與驗收案例；不直接改程式。首案可選商品額度策略，仍須確認 account/card/family/corporate 分層 |
| D5 | GOV-004／GOV-006 追蹤方式 | 新增 CR-045 治理工作包與卡片級查詢依賴項；GOV-004 需先對應確切 FR/NFR 後再追溯，避免創造不存在的需求編號 |
| D6 | 參數寫入與人員安控先後 | ★ 建議先凍結維護角色／maker-checker／資料範圍；在授權政策落地前，不將參數／活動寫入 API 作為生產維護入口 |

### 8.1 不可由開發臆造之業務輸入

以下需客戶／產品／營運權責單位提供或核定；本文**不預填政策值**：

| 範疇 | 待確認內容 |
|---|---|
| 商品與額度 | 額度模型（單一／共享／子額度）、共用範圍、卡片／附卡／企業子卡扣用順序、總額度與個別額度核算式 |
| 行銷活動 | 年費及免年費條件、紅利／里程換算、滿額門檻與贈品履約、活動是否可疊加、撤銷／退款後回沖、活動預算與每戶上限 | ★ **已核定（2026-10-15 BEAM PMO 口述，詳 §8.2）**；以下不再視為待輸入 |
| 日曆與作業 | 權威節假日來源、地域／時區、遇假日之提前或順延規則、帳單日與批次窗口、清算結算日 |
| 人員安控 | 業務角色清單、角色來源、資料範圍、覆核人數、金額門檻、緊急權限與稽核保留期 |
| 卡片級額度查詢 | 客戶希望看到的卡片／帳戶／共享池口徑、附卡如何分攤、是否揭露保留額、權限與遮罩規則 |

---

## 8.2 行銷活動政策（BEAM PMO 2026-10-15 口述核定，對應 §8.1「行銷活動」六項）

> ★ 本節為**客戶／產品權責單位核定之業務政策**，非開發臆造；作為 `SCS-026` Campaign 模型之權威語意來源。後續若政策異動，須由 BEAM PMO 重新裁定並升版本節。

| # | 政策項 | 核定內容 |
|---|---|---|
| 1 | 年費及免年費條件 | ① 聯名卡（co-brand）**強制繳交年費**，且銀行須提供對等福利（例：航空公司聯名卡 年費 20,000、給 50,000 里程）；其餘卡種**第一年全免年費**。② 第二年起依「**年累計消費金額**」或「**年累計刷卡次數**」擇一達標即減免。③ 偶發促銷：當月刷卡金額達門檻 → 次年免年費（視為一種限時 Campaign）。 |
| 2 | 紅利／里程換算 | 依**卡種／卡別（tier）**分級距：例 VIP **100 元 1 點**、一般 **200 元 1 點**；里程亦採分級距換算。→ 屬 `rewards-service` 點數／里程規則權威（`SCS-010`）。 |
| 3 | 滿額門檻與贈品履約 | 滿額禮為季節性／百貨周年慶等常見促銷；門檻與贈品按**卡種／卡別級距**而異。→ 屬 Campaign 活動的一種類型，贈品履約由履約／通知路徑處理。 |
| 4 | 活動是否可疊加 | **關鍵參數與業務邏輯**：活動**可疊加**或**不可疊加**皆為合法配置；必須以 Campaign 層級參數 `stackable` 顯式聲明，並定義疊加時的優先序（priority）與互斥群組（exclusion group）。 |
| 5 | 撤銷／退款後回沖 | 點數／里程類 → **一律回沖（reversal）**；贈品類 → 多半以**「打呆帳」**處理（不主動追回實體贈品，僅作帳務沖銷／呆帳認列）。→ 回沖邏輯屬 `rewards-service`；打呆帳認列須有對應科目與稽核。 |
| 6 | 活動預算與每戶上限 | 活動設有**總預算上限**與**每戶（per-household）參與／獲利上限**，二者皆為 Campaign 參數。達上限即停止發放或進入候補。 |

★ 與 D3 治理原則一致：`pricing-service`（年費／免年費計算）與 `rewards-service`（紅利／里程累點與回沖）**各自保留領域規則權威**；`SCS-026` 之 Campaign aggregate 負責「活動生命週期、資格、疊加互斥、預算／上限、與各域規則之關聯」，**不接管計算**。

---

## 9. 附錄：查證證據（as-found）

> ★ 以下皆為 2026-10-15 以**現行原始碼／規格／DDL** 實查之結果（非抄舊結論）。

| 查證項 | 命令／來源 | 結果 |
|---|---|---|
| 商品參數表與產品表 | Oracle 唯讀查詢：`CC_PRODUCT.USER_TABLES`／`USER_TAB_COLUMNS` | `PRODUCTS`／`PARAMETERS`／`RULE_SETS` **皆存在**；`PARAMETERS` JSON／生效日欄位、`RULE_SETS` condition/action JSON 與型別欄位均在 DDL |
| 商品參數 runtime consumer | 全 backend 源碼檢索 `api/v1/parameters`／Product client／port | **只找到 `product-service` 自身 Controller/Repository**；未找到下游遠端呼叫程式 |
| 文件 vs 程式 | `SAD-002 §3`、`CR-029 §5`、`CR-031 §3.1` 對照現行 Java | 文件宣告同步依賴／9 個 client，但 `CR-031` 同段又稱 9 個服務無 `ProductClient`／`ParameterPort`；本次源碼掃描支持「無下游 client」，需更正文件，不能當作已實作 |
| `limit-service` 商品客戶端 | 全 backend `limit-service` 源碼檢索 | **無 `ProductClient`／`ProductPort`**；現有帳戶級／專用額度並未因此證明商品 capability 已被消費 |
| `product.rule_sets` API／執行 | Oracle DDL + 全 backend Java 源碼 | 表存在；無 RuleSet CRUD API／repository／RuleEngine，且 schema 無 product/campaign/effective-date link |
| 參數變更事件消費 | `SCS-005 §7.1`／全 backend 事件名檢索 | `product.parameter.changed.v1` 有生產端、無消費端；`CR-031` 證實原規劃為快取失效，當時 9 服務均無快取 |
| 行銷活動模型 | DDL＋全 backend Java 源碼檢索 | 無 campaign aggregate／資料表／管理 API／活動執行路徑 |
| 節假日／日曆 | DDL＋全 backend Java 源碼檢索 | 未找到 holiday/business-calendar 模型；`SCS-019 §4` 僅要求時區與銀行營業日曆納入設計 |
| 帳單日 | backend 全庫 `statement_day`／`billing.cycle_day` 檢索 | `CC_PARTY.ACCOUNTS.statement_day` 已存在；`billing.cycle_day` 僅在 SCS-023，未發現商品參數消費 |
| 排程 | backend 全庫 `@Scheduled`／`fixedDelayString` 檢索＋`SCS-019` | 有服務級排程，部分屬性可覆寫；不是全部硬編，但亦非由統一業務參數／日曆權威治理 |
| 年費／幣別 | Oracle `CC_PRC.USER_TAB_COLUMNS`、`SCS-006 §6／§7.7`、`FeeService`／`FeeView` | `ANNUAL_FEE`／`FEE_WAIVER` 與 `FEE_AMOUNT` 存在；fee endpoint **僅查詢設定、不計費**；無 `fee_name`／`currency` 欄，顯示名按 enum 硬編、currency 固定 TWD |
| 點數規則 | `RewardRuleService`／`RewardRuleRepository`／`AccrualService` 源碼檢索 | `/reward-rules` 可維護獨立規則；未找到累點流程消費 `RewardRuleRepository` 的路徑，故不是已閉環行銷規則 |
| RBAC | `SCS-022 §6.3`＋認證/授權程式 | JWT 認證／role claim 解析存在；角色授權與維護權限政策未實作 |
| 卡片級額度端點 | `CR-043 §3.1`／`gen_openapi.py` | 未實作端點已從契約清除（96→95）；這是契約修整，不是未來卡片級需求結案 |

---

## 10. 變更紀錄

| 版本 | 日期 | 變更 |
|---|---|---|
| 1.2 | 2026-10-15 | §7.1 架構示意由 ASCII 圖改為 Mermaid flowchart（通過 validate_mermaid 語法檢查，0 錯誤）；原圖內事件注意事項改為區塊引用 |
| 1.3 | 2026-10-15 | 新增 §8.2 行銷活動政策（BEAM PMO 2026-10-15 口述核定六項：年費/免年費、紅利里程換算、滿額門檻、疊加、回沖/打呆帳、預算每戶上限），作為 `SCS-026` Campaign 模型之權威語意來源；§8.1 行銷活動列標註已核定；§7.3 丙註記政策已到 |
| 1.1 | 2026-10-15 | 回訪事實查證後修正初版：把規格宣告的同步取參數與現行程式缺少下游 client 之矛盾明列；更正 annual fee／RewardRule 僅查詢／維護、不等於 runtime 消費；區分可覆寫之服務排程屬性與中央業務參數；補 Oracle DDL 實查、角色授權現況、域權威治理、客戶待輸入政策及 card-level 查詢的契約清理／預期需求分離 |
| 1.0 | 2026-10-15 | 初版——三軸盤點（L0–L3 判準）、落差總表、治理提案與優先順序（甲–戊）、待裁定事項、as-found 證據附錄 |