遷出流程
定義（SA 術語）
| 術語 | 說明 |
|---|---|
| 遷出 | 已晉塔或安奉的往生者遷出原所在位置的異動申請。 |
| 底座 | 蓮位的配備，遷出時家屬會帶走，所以已簽的蓮位申請轉讓/繼承時需要檢查並收費。 |
| 再度使用 | 遷出後再次發生轉讓、晉塔等異動，系統自動收取「牌位底座」與「牌位代刻」費用。 |
資產生命週期中的位置：已申購 →（選位）→ 已使用（晉塔）→ 已遷出，
遷出後可再晉塔（BR-AST-03 的前置就是「未使用或已遷出」）。
前置條件（BR-AST-04）
- 權狀狀態必須為**「已晉塔」或「已安奉」**
（建立端卡控：未晉塔選遷出直接擋「此權狀尚未晉塔/安奉，無法申請遷出」，
ModificationValidationManager） - 管理費已繳清或已退費（處理存檔端 guard：管理費效期已全數到期會擋 「請先補繳或辦理退費後再辦理遷出」）
- 目前版本限制：只支援單一入位列。同權狀多位入位（合葬）辦遷出會擋 「合葬部分遷出尚未支援」
反向關聯（同一套建立端卡控）：
- 已晉塔的權狀不能再選晉塔／換位／換裝 → 要先辦遷出
- 已晉塔的權狀不能直接退貨作廢（BR-APP-07）→ 要先完成遷出申請再辦退貨
主流程（SA 4.1.6 / UC03）
SA 層面與晉塔共用同一張泳道圖（「遷出流程與晉塔類似」）：
客戶提出遷出申請
→ 櫃檯收單
→ 系統產生申請單 [(2.1)申請單總覽]
→ 行政人員確認資料 + 處理存檔
→ 系統建立遷出通報 → 管理處/執行人員現場執行
→ 執行人員回報完成
→ 行政人員輸入實際執行日期 → 點擊完成
→ 資產狀態更新為「已遷出」、通報已完成、申請單歸檔
資料流向：每一步實際寫了什麼
新站實作分三段，寫入點都在 MoveoutApplicationManager：
建立申請單（moveout 項目）
└→ 只建申請單；不動 move_outs / enshrinements
處理存檔（申請單詳情儲存 → MaterializeMoveoutAsync）
└→ 守門：產品存在有權狀號 → 恰好一筆入位列（f_in='1'）→ 管理費效期
└→ move_outs 每位勾選使用者 INSERT 一列
（f_app_id 為批次鍵，重複存檔冪等：更新既有列、多的軟刪、少的補建）
└→ 同步建立遷出通報（NotifType=MoveOut，委派通報權威）
└→ 順手補正該使用者名下管理費的 f_auth_no 關聯鍵
申請單完成（ApplyMaterializedMoveoutCompletionAsync）
└→ 只驗證 move_outs 已由處理存檔建立（沒有就擋「請先完成處理存檔」，不補建）
└→ 蓮位：position.f_pedestal_count -1（底座被家屬帶走，對應 SA 底座定義）
└→ 寫 statusLog「遷出完成」
遷出通報完成
└→ 只改通報狀態；不寫 move_outs、不動 f_in
（FinalizeEnshrinementAsync 對 notifType=moveOut 直接 return）遷出「不寫」什麼（跟直覺相反，都是刻意設計）
| 不寫 | 說明 |
|---|---|
enshrinements.f_in | 永遠維持 ‘1’，不改成 ‘2’（全表 0 筆 f_in=‘2’）。遷出狀態唯一表示＝move_outs 有列 |
positions.f_rsvStatus／products.f_capacity | 完成端不碰位置預約狀態與容量 |
| 管理費退費 | 不 auto-settle。退費走既有管理費畫面另案辦理，遷出 executor 只做前置檢查 |
modifications | 新流程遷出不寫舊異動表（客戶異動歷史 Tab 查不到是設計結果） |
move_outs 欄位語義
| 欄位 | 來源 |
|---|---|
f_t_use_fid | = enshrinements.f_id（遷出鍵；是入位列主鍵，不是 f_auth_no 粗鍵） |
f_auth_no／f_position_id／f_use_id／f_use_idnum | 抄自入位列 |
f_use_name | 詳情頁勾選的使用者（沒勾則 fallback 入位列的 f_useName） |
f_plan_d | 遷出日期（＝申請單詳情頁必填的執行日期） |
f_acct_d | 原晉塔日期（抄自入位列，不是遷出日期） |
f_app_id | 來源申請單 id（批次鍵，冪等／作廢連帶都靠它） |
「現役晉塔中」的正確判定
現役 = enshrinements.f_in='1' 且該列沒有對應的未刪 move_outs 列
（move_outs.f_t_use_fid = enshrinements.f_id）
唯一權威是 EnshrinementGuard（含 GetActiveOccupantsAsync），
全系統任何「是否在位／選哪一列辦異動」都必須委派這裡。
自製查詢／報表直接抄裸 f_in='1' 一定會把已遷出者誤算成在位——
這是本系統踩過最多次的坑（綜合查詢、異動選列都修過一輪）。
管理費連動（SA 4.4.2 異動項目表）
- 前置：遷出要同步處理管理費——過期的要繳清、未使用的可退費（BR-AST-04）
- 遷出退費計算：可退管理費＝短期管理費計算額 − 應收短期管理費 （從當前期數−1 的期數截止日起算到當天收短期費，退當前期數以後的所有期數）
- 一次性管理費：不退費；晉塔＋遷出算 1 趟，趟數超過納骨量時再晉塔要收規費； 同一人重複晉塔＋遷出，管理費效期內不再收
- 費率權威見 SA 5.7.3.5（
ShortTermFeePricingManager）
後置效果
| 遷出完成後 | 說明 |
|---|---|
| 資產狀態 → 已遷出 | 綜合查詢使用狀況顯示「遷出」、位置騰空 |
| 可再晉塔 | BR-AST-03 前置＝未使用或已遷出 |
| 再度使用收費（蓮位） | 之後轉讓/再晉塔要檢查遷出記錄 → 收「底座＋代刻」費，每遷出一次刷新重新記錄，再晉塔時強制檢查 |
| 解鎖退貨作廢 | 已晉塔不可直接退貨（BR-APP-07），遷出後才能辦 |
| 申請單作廢連帶 | 遷出單作廢 → 軟刪該單未完成的 move_outs 列（SoftDeletePendingMoveoutsAsync，已完成不刪） |
完成後去哪查（含管理費統計篩不到的日期軸陷阱）→ 見 異動完成後去哪裡查。
已知陷阱（別當 bug 修）
f_in永不回寫：不是漏寫，是設計。判在位一律委派EnshrinementGuard。- 法會通知仍寄給遷出者：#209 Part B 拍板「仍寄」；曾加排除又明確 revert （28840b11 → 7d0512ce）。寄不寄遷出者是 #211 P5 待寺方決策，盲改＝重新引入已 revert 的回歸。
- 遷出／安奉登記書要印遷出者：刻意正交（PM 2026-06-08 拍板）——登記書本來就要印遷出資料，
f_in在套印是取數來源不是 gate；只有金流類（FEE_REMINDER）排除遷出者。 - 舊站對照：舊站遷出＝物理刪除
tb_towerUsed那一列（備份 h 表 → INSERT tb_towerMoveOut → DELETE）。 新站改成 move_outs 軟記錄＋讀取端排除，語義等價：遷出＝未使用、異動只作用現役列。 - 管理費統計查不到今天的遷出：那頁篩選軸是繳費日期，遷出不寫繳費紀錄。 要看「今天誰遷出」用通報查詢。詳見 異動完成後去哪裡查。
程式碼位置
| 檔案 | 角色 |
|---|---|
services/DomainServices/Shared/MoveoutApplicationManager.cs | 遷出 executor：materialize（處理存檔）、完成端驗證、作廢連帶軟刪 |
services/DomainServices/Shared/EnshrinementGuard.cs | 現役判定唯一權威 |
services/DomainServices/ApplicationCreate/ModificationValidationManager.cs | 建立端卡控（未晉塔擋遷出、已晉塔擋再晉塔/退貨） |
EnshrinementNotificationService.cs | 遷出通報（SyncMoveoutNotificationsAsync）；通報完成對 moveOut 不 finalize |
ComprehensiveQueryService.cs | 讀取端已排除有 move_outs 的入位列 |
相關 DB 表：move_outs（遷出記錄）、enshrinements（入位列，f_in 不回寫）、
tb_enshrinement_notification（NotifType=MoveOut）。
SA 章節索引
| 章節 | 內容 |
|---|---|
| SA 術語定義 | 遷出、底座、再度使用 |
| SA 4.1.6 | 晉塔與遷出及通報流程（共用泳道圖） |
| SA 4.3.3 (UC03) | 辦理晉塔/安奉與通報作業（遷出流程與晉塔類似） |
| SA 4.4.2 | 異動項目表：遷出需已晉塔/已安奉、要同步處理管理費繳清/退費 |
| BR-AST-03 | 晉塔前置＝未使用或已遷出（遷出後可再晉塔的依據） |
| BR-AST-04 | 遷出前置＝已晉塔/已安奉且管理費已繳清或已退費 |
| BR-APP-07 | 已晉塔不可直接退貨作廢，需先遷出 |
相關概念
- 晉塔流程 — 遷出的逆操作；兩者共用通報機制與
EnshrinementGuard - 異動完成後去哪裡查 — 遷出完成後的查詢入口與日期篩選陷阱
- 申請單異動從建立到完成怎麼運作 — 申請單主線（建立→處理存檔→完成）
- 資產狀態機 — 已使用→已遷出的狀態轉換權威
本次驗證範圍
本頁於 2026-07-02 對照現行程式碼撰寫：MoveoutApplicationManager（全檔精讀）、
ModificationValidationManager（建立端卡控訊息）、EnshrinementNotificationService.FinalizeEnshrinementAsync
（moveOut 不 finalize）、ComprehensiveQueryService（遷出列排除）、SA 系統設計規格書 V1.6
（術語表、4.1.6、UC03、4.4 業務規則）。
沿用而未重新驗證的部分：「全表 0 筆 f_in=‘2’」與陷阱 2/3 的拍板紀錄（#209/#211、 commit 28840b11/7d0512ce、PM 2026-06-08）為 2026-06-24 的稽核與決議紀錄；本次未重新查 grace2。