異動完成後去哪裡查

這篇寫給「剛辦完一筆異動，想確認系統真的有生效」的人。 先不要急著往管理費統計找。先看這筆異動是哪一種，再挑對的查詢頁。

先記住一句話

不是每個查詢頁都拿「這次異動完成的日期」當篩選軸。
篩錯軸 = 資料明明在，卻查不到，看起來像 bug，其實不是。

最容易踩的是管理費統計。畫面上有日期篩選，很自然會填「今天」， 但那個日期篩的是繳費日期，不是晉塔日期、不是遷出日期。 一個位置可能是 20 年前繳的管理費、今天才真的晉塔，承辦人查詢當下根本不會知道當初繳費是哪一天。 篩「今天」自然查不到——不是系統漏接，是這頁的日期軸本來就跟你想找的事件對不上。

兩種查不到，嚴重程度不一樣

1. 篩錯軸：資料還在，換個日期範圍或拿掉日期篩選就找得到。
2. 真的消失：資料被軟刪或這件事根本沒有專屬查詢頁，怎麼調日期都沒用。

第 2 種比第 1 種麻煩很多，因為承辦人會誤以為「系統沒處理成功」， 但其實是系統設計上沒有給這件事一個可查的地方。

各異動類型速查表

異動類型	完成後寫進哪裡	該去哪查	篩選軸對不對得上
晉塔／安奉	enshrinements.f_in 變 '1'（要等通報完成才會寫，見下方說明）	綜合查詢、安奉使用編號查詢、通報查詢	對得上，三個都即時反映
轉讓／繼承	Transfers 表 + modifications + 權狀持有人	轉讓／繼承查詢頁	對得上（日期欄位表單沒接 UI，永遠落完成當下）
換位	modifications + 權狀位置	換位查詢頁	對得上，同上原因
執行人變更／使用人變更（禮儀）	產品上的執行人／使用人欄位	客戶管理「客戶異動歷史」Tab	對得上
預繳管理費	management_fees 新增一列，繳費日期＝表單上填的日期	管理費統計	對得上——因為這裡篩選軸剛好就是這次異動自己寫的那個日期，且表單預設今天
標準退貨作廢（當天建當天完成的單）	權狀狀態改成作廢	申請單總覽（篩「申請日期」）	對得上，因為這種單是當天建、當天完成
遷出	move_outs 新增一列，不寫管理費繳費日期	通報查詢（對得上）、綜合查詢（無日期篩選）	⚠️ 管理費統計篩不到，理由見下
管理費退費	該筆管理費被軟刪	沒有專屬查詢頁	⚠️ 直接從管理費統計消失，見下
作廢（issue #51 逐權狀作廢舊單的那條路）	只改「更新時間」，不改「建立時間」	申請單總覽	⚠️ 篩「申請日期」找不到，見下

已知的三個陷阱

1. 遷出：管理費統計篩「繳費日期」找不到

遷出完成時只會新增一筆 move_outs，不會補一筆新的管理費繳費紀錄。 所以在管理費統計把「使用狀況」切成「遷出」是找得到這筆的， 但如果順手把「繳費日期」也篩成今天，就會查不到——因為這次遷出根本沒動繳費日期這個欄位。

要看「今天誰遷出了」，正確的地方是通報查詢，它的日期欄位就是遷出當天填的日期，對得上。 綜合查詢也可以，因為它沒有日期篩選，遷出完馬上就能看到位置變成空的。

2. 管理費退費：查無此人，因為那筆真的被刪了

管理費退費不是新增一筆「退費紀錄」，而是把原本那筆管理費軟刪。 管理費統計的所有查詢都會過濾掉軟刪的列，所以退費完成後， 這筆管理費會直接從清單上消失——不管日期怎麼調都找不到，因為它已經不在查詢範圍裡了。

系統目前沒有一個地方專門顯示「退費紀錄」。 要確認退費真的生效，只能回去看：

• 那張退費申請單本身（申請單總覽／詳情頁）
• 綜合查詢裡這張權狀的管理費累計金額有沒有變少

如果承辦人回報「退費申請單完成了，管理費怎麼查都查不到」， 先確認是不是這個原因——這其實是退費成功的正常結果，不是 bug。

3. 逐權狀作廢舊單：申請單總覽篩「申請日期」找不到

系統有一條路可以對很久以前建立的舊申請單（例如原始購買單）逐權狀作廢 （issue #51 那條路，跟一般「當天建當天完成」的退貨作廢單不是同一種）。

這條路只會更新「更新時間」，不會動「建立時間」。 但申請單總覽的日期篩選只有「申請日期」（＝建立時間），沒有「更新日期」這個篩選欄。

所以今天用這條路作廢了一筆很久以前建立的舊單， 在申請單總覽篩「今天」是找不到的——因為篩的是建立日期，不是這次操作的日期。

管理費統計本身要記住的事

管理費統計（5.6.3）不是用來查「最近晉塔了誰」或「最近誰動了什麼」的頁面。

它的定位就是管理費對帳報表（前身叫「管理費對帳查詢」）， 篩選軸只有一個：繳費日期。這是規格設計本來就這樣，不是漏做。

想查「最近晉塔了誰」  → 用安奉使用編號查詢或通報查詢，篩晉塔／安奉日期
想查「最近誰遷出了」  → 用通報查詢，篩通報日期
想對帳「這筆錢收了沒」→ 用管理費統計，篩繳費日期

三件事看起來都跟「管理費」有關，但只有最後一件才是管理費統計真正該回答的問題。

查 bug 時先問哪一句

看到「查無資料」，先不要假設是系統漏接，照下面順序排除：

1. 這個查詢頁的日期篩選欄，篩的到底是哪個日期？
   （繳費日期？申請日期？異動日期？跟我以為的是不是同一個？）
2. 如果篩選軸看起來對，資料是不是被軟刪了（退費、作廢）？
   軟刪的資料大部分查詢頁會直接濾掉，不會顯示「已刪除」，而是完全消失。
3. 如果以上都排除了，才往「這個查詢頁的讀路徑是不是真的沒接到這張表」去查。

換句話說：先懷疑篩選條件，再懷疑軟刪，最後才懷疑讀路徑真的漏接。 大部分「查無資料」回報，卡在前兩步就能解釋清楚。

相關概念

• 申請單異動從建立到完成怎麼運作 — 異動完成當下實際寫了哪些表，本頁接著回答「寫完之後去哪查得到」
• 晉塔流程 — 晉塔完成其實是兩階段（申請單完成 ≠ 真正入位），本頁的晉塔那列是這兩階段跑完之後的查詢結果

本次驗證範圍

本頁於 2026-07-01 對照現行程式碼整理，並以 memorySeatManagement-service-test/Verify-EnshrinementFlow.cs 實際跑過一次晉塔完成流程（含通報完成）驗證晉塔那一列：

• ComprehensiveQueryService、EnshrinementQueryService
• ManagementFeeQueryBuilder、ManagementFeeSummaryQueryService
• TransferQueryService、PositionChangeQueryService、CustomerHistoryQueryService
• MoveoutApplicationManager、ApplicationActionService（含 VoidCertificateItemsAsync／issue #51 路徑）
• ApplicationQueryService

本次未重新查詢 grace2 存量資料分布，遷出／退費／作廢那三個陷阱是對照現行程式碼邏輯推導， 不是每一種都各自跑過一次端到端實測（晉塔那條例外，已實測驗證）。