情境化申請單

問題

主檔維護畫面通常長這樣：一張攤開 40 個欄位的大表單，什麼都能改。

結果是：

• 使用者要自己知道「單位升等」該改哪三個欄位（漏一個就資料不一致）
• 改完之後沒有人知道為什麼改（稽核記錄只有 before/after，沒有意圖）
• 每個人的操作順序都不一樣，交接時只能口耳相傳

做法

先選情境，再填欄位。

① 挑情境          ② 只顯示該情境的欄位      ③ 必填「異動原因」
   單位升等   →      等級、折扣率、信用額度  →   為什麼要升等
   暫停往來   →      狀態、生效日            →   為什麼暫停
   更新聯絡   →      聯絡人、電話、地址      →   （免填，非敏感）
                                            ↓
                                   一筆帶情境與原因的稽核記錄

三個效果：

效果	說明
不會漏欄位	情境定義了「這件事要改哪些」，系統幫你記得
稽核有意圖	記錄裡有「為什麼」，不只有「改了什麼」
可以做權限	權限掛在情境上（誰能做升等），比掛在欄位上更貼近業務語言

關鍵：這不是另一套資料源

情境化申請單直接寫進既有的稽核記錄，只是多帶 scenario 與 reason 兩個欄位。

✅ 這樣做

申請單 → 立即套用 → 記一筆帶情境與原因的稽核。單一資料源。

🚫 不要這樣

不要另建一套「申請單」資料表然後跟主檔對帳。 兩套資料一定會不同步，而且不同步的時候沒有人知道哪一邊才對。

取捨

代價：情境要事先定義。 使用者遇到「不屬於任何情境」的異動時會卡住。

解法不是回頭開放全欄位編輯，而是：

• 保留一個「其他異動」情境（欄位較寬鬆，但原因必填且要寫得具體）
• 把它當成訊號：某個「其他」被用了 20 次，就該補一個正式情境

反例

✅ 這樣做

情境數量控制在 6–10 個，每個都對應一件真實會發生的事。

🚫 不要這樣

不要為每個欄位各開一個情境（「改電話」「改地址」「改分機」）。 那只是把大表單拆成 40 個小表單，使用者更痛苦。

實作提示

• 情境 → 欄位對映寫成設定（Record<Scenario, FieldKey[]>），不要寫成 40 個 if
• 原因欄位是 required，而且不接受少於 5 個字——「修正」「更新」等於沒寫
• 敏感情境（改額度、改狀態）一律留痕；非敏感（改聯絡方式）可以免原因， 但仍然要記稽核