Silver 模式 — 從 Silver 銀庫撥款
在 silver 模式 下，AO Master 把核准的 regear 以 silver 入帳到每個成員的 Silver 銀庫 錢包 —— 沒有物品、沒有 locker、沒有 cut-off 任務。幹部在 #Review Requests 選取核准的列，點 Payout，silver 就會立刻落到帳上。這頁涵蓋三個 silver 子模式、幹部的 Payout 動作、帳本紀錄，以及成員看到什麼。
如果要看另一條發放路徑（把物品打包進 locker），請看 物品模式 — 截止與 locker。核准步驟在上游：幹部 — 審核與核准。兩種模式並列比較請看 Regear 流程總覽。
權限 + 相依條件
Payout 動作跟核准在同一個介面，並用 同一個權限 — 「Approve Regear Requests」。沒有另外的「Payout」權限。理由是：在 silver 模式下，核准與撥款這兩個決策通常前後相連，多半由同一名幹部完成。
silver 模式真正需要的是 設定檢查清單 —— 在 Payout 能運作之前，三件事必須都成立：
| 需求 | 在哪裡開啟 |
|---|---|
| Silver 銀庫已啟用 | Settings → Guild Systems |
| Item Price 已啟用 | Settings → Guild Systems |
| Regear Mode 設為任一 silver 值 | Settings → Regear Policy → Silver Regear |
若有任一項關閉，Settings → Regear Policy 的設定檢查清單會列出還缺什麼 —— 完整介面詳見 Settings → Regear Policy。後端每次按 Payout 都會重新檢查每個條件，所以瀏覽器分頁過期也不會繞過未滿足的設定檢查清單。
三個 silver 子模式
Regear Mode 是 Settings → Regear Policy 的一個下拉。把頂層模式選為 Silver payout，下方會出現 Silver Mode 下拉，內含三個子選項：
| Silver 模式 | 撥款內容 | 適用情境 |
|---|---|---|
| Sum by Item Price | 每個遺失欄位的 silver 價格總和（核准當下從 Item Price 頻道取得快照）。 | 想要 regear 價值貼著真實市價的公會。 |
| War Role — Fixed cap | 一個固定金額，等於該 War Role 的 Silver Cap —— 忽略實際損失。 | 想要簡單的每 role 預算（「DPS role 不論勝負每人 1M silver」）的公會。 |
| War Role — Capped by actual | 取（物品價格快照總和）與（該 role 的 Silver Cap）較小者 —— 按實際撥款，但不會超過上限。 | 想要對昂貴意外有安全網的公會。 |
War-role 模式的上限要在 Set War Role Caps sub-modal（Settings → Regear Policy → 設定檢查清單 → Set War Role Caps）逐 role 設定，也可以到該 role 自身的列 Settings → War Roles → Edit → Silver Cap 欄位設定。沒設定上限的 role 撥款時會被擋並顯示「War role has no silver cap configured」錯誤，直到上限填好為止。
切換模式會被擋
當下列情況發生時，運作中公會的 Regear Mode 切換 會被擋：
- 還有任何 cut-off 任務有未完成的打包工作（離開物品模式）→ 先把所有 active 任務做完或撤回。
- 還有任何核准但未撥款的 silver 申請（離開 silver 模式）→ 先把每筆已核准的列撥款或拒絕。
當你在 Mode 下拉挑新值，存檔前會跑一次檢查；若有東西擋住，會看到 toast 錯誤並附深層連結帶你到對應清單。待審申請與模式無關 —— 不會被模式切換擋住，被核准時就用新模式。
Silver 銀庫餘額 永遠不會 因模式切換而清空。銀庫是一個長期系統；成員餘額會延續存在，即使公會切回物品模式仍可提領。
從 Approved → Payout
流程開頭跟物品模式一模一樣：幹部在 #Review Requests → Pending 分頁審核 → 按 Approve → 申請落到 Approved 分頁。從這裡開始，批次動作按鈕會依公會的 Regear Mode 換：
| 公會的 Regear Mode | Approved 分頁的批次按鈕 |
|---|---|
| Item return | Create Cut-off Task （詳見 物品模式） |
| 任一 silver_* | Payout |
撥款步驟：
- 開啟
#Review Requests→ Approved 分頁。 - 勾選要撥款的列。底部會出現批次列，含 Revert 與 Payout 動作按鈕。
- 點 Payout。每一列獨立撥款 —— 允許部分成功，所以有的列可以成功，有的列可以帶清楚的理由失敗。
每列的幹部端 toast 會告訴你結果 —— 全部成功時為「Paid out 3 request(s) — silver credited」，有問題時為「Payout failed — 2 request(s) blocked」並附理由。
單列可能被擋的原因
批次裡每一列都有自己的驗證。常見的逐列失敗訊息與修法：
| 失敗訊息 | 發生原因 | 修法 |
|---|---|---|
| Request status is "approved" — only approved requests can be paid | 該列已不在 Approved 狀態（在你勾選與按 Payout 之間，已被別人撥款或撤回） | 重整後重選。 |
| Member has no linked Albion character | 申請的成員沒連結 Albion 角色 | 成員必須透過 #Members → 🔗 Link 連結他的 Albion 角色。silver 是入帳到角色名稱，不是使用者帳號。 |
| War role has no silver cap configured | War-role 模式 + 所選 role 沒設定 Silver Cap | 到 Settings → Regear Policy → Set War Role Caps（或 Settings → War Roles → Edit）設定上限。 |
| One or more items have no price snapshot from approval time | Sum-by-Item-Price（或 Capped）模式 + 核准當下這些物品沒 Item Price 資料 | 為那些基本物品填入 Item Price，並重新核准（快照在核准當下取，不是在撥款當下）。 |
| Computed credit is zero — nothing to pay out | 所有物品都有價格但總和為 0 | 跟缺價格的修法一樣 —— 到 Item Price 頻道檢查那些基本物品。 |
好消息：失敗的列會留在 Approved 狀態，等你修好可以重試。同一批次裡已成功撥款的列不會被沖銷。
silver 落在哪 — Silver 銀庫 History
每筆成功撥款會寫一筆 Silver 銀庫 帳本紀錄 —— 一條 Add 列，附上「Regear payout」備註，入帳到該成員的角色餘額。它會出現在 #Silver Bank → History：
每一列顯示：
- 撥款的 時間戳。
- 類型 標章 —— 入帳為
Add，顏色配合銀庫的入帳主題。 - 角色 —— 成員的 Albion 角色名稱（silver 入帳到角色而非使用者）。
- 金額 —— 以 silver 計。
- 備註 —— 「Regear payout」加上子模式名稱，方便日後稽核知道是哪種算法產生的入帳。
#Silver Bank 頁面共有四個分頁 —— Balances（每角色餘額）、Withdrawals（成員發起的提領佇列）、Log（原始 chest 貼上解析緩衝 —— 是不同的概念），以及 History（你上面看到的會計帳本）。完整參考請看 Silver 銀庫。
Log vs History — 常見混淆
Log 是 chest 貼上流程用的（從存入 chest 貼上原始 silver 進出列，逐筆標 Apply 或 Disable 後送出）。History 是每一筆已落到成員錢包的入帳／扣款的完成帳本。Regear 撥款完全跳過 Log —— 直接寫入 History，跟手動 Add 按鈕一樣。
成員看到什麼
撥款完成後，申請會翻成 Paid，成員 #My Requests 的列會即時更新 —— 不需重整：
已撥款的卡片顯示：
- 5 個進度步驟全綠（Pending → Approved → Cut-off → In Progress → Delivered）。在 silver 模式下，cutoff / in-progress 步驟概念上是跳過的，但進度條會直接動畫到 Delivered，讓兩種模式視覺一致。
- 一行 💰 Credited X silver to Silver Bank 說明。（兩個 War Role 子模式下，金額欄位顯示為破折號 —— 因為那些模式不會記每件物品的 silver，所以頁面渲染不出明細；精準金額在上方的 Silver 銀庫帳本列。Sum-by-Item-Price 模式下會顯示該筆申請的實際 silver 金額。）
- 一顆 Received 動作按鈕 —— 成員可以把申請標記為已確認收到。
實際的 silver 放在成員的 Silver 銀庫 錢包，他可以在 #My Home → Silver Bank 或直接到 #Silver Bank → Balances 看到。從那裡他可以走 Silver 銀庫的標準提領流程提錢（詳見 Silver 銀庫）。
為什麼 silver 也叫「Delivered」？
進度條設計上對兩種模式都用同一個 Delivered 標章。讀法：物品模式 = 物品在你的 locker；silver 模式 = silver 在你的錢包。兩者都是終點「請求已完成」。
跟物品模式對照
| 步驟 | 物品模式 | Silver 模式 |
|---|---|---|
| 1 | 成員提交 → Pending | 成員提交 → Pending |
| 2 | 幹部審核並核准 → Approved（還沒動錢／物品） | 幹部審核並核准 → Approved（還沒動 silver） |
| 3 | 幹部把核准的批成 cut-off 任務 → 打包進 locker → 標記為發放完成 | 幹部選取核准的並按 Payout → silver 入帳 + 狀態翻成 Paid |
| 4 | 保留期過後封存 | 保留期過後封存 |
2 步驟生命週期（先核准、再發放／撥款）兩種模式都一樣 —— 是刻意設計。它仿照 Stripe / PayPal / 發薪系統都把「核准」跟「撥付」分開，這樣兩步之間發現錯誤可以靠拒絕一筆解決（不必再做沖銷分錄）。
Overcharge 怎麼算？
在 silver 模式下，Overcharge（OC）申請 永遠 採用 Sum-by-Item-Price 邏輯，不管公會選了哪個 silver 子模式 —— war-role 上限是「每死亡」的額度，套到「每物品」的 OC 提交不合邏輯（一個成員若只丟了一個昂貴的袋子，就可能拿到整筆 1M silver 的死亡上限）。
在所有 silver 模式共享的 Item Price 啟用前提下，這是自動的：只要公會處於任一 silver 模式、且損失的物品在核准當下有價格快照，OC 的 silver 撥款就會運作。
交叉連結
- 物品模式 — 截止任務 + locker —— 另一條發放路徑。
- 幹部 — 審核與核准 —— 上游步驟。
- Regear 流程總覽 —— 兩種模式一覽。
- Silver 銀庫 —— 提領、chest 貼上紀錄、設定。
- Settings → Regear Policy —— silver 路徑的完整設定檢查清單。
- Member Regear Report —— 每位成員長期的 silver 統計。