年末調整321畫面：為什麼有些欄位不能輸入？--追因備忘20251027

| Work Notes | 3 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1290

背景

客戶在 321 年末調整データ登録（詳細）發現兩個行為難以理解：

  • 生命保險料（イ／ロ／ハ）那一列是灰色不可輸入，但其下兩行「地震保險料（B／C）」與「新・舊生命保險料金額（A／B）等」卻可輸入

  • 幾乎整段「金額欄」都變成不可輸入

本文把實際程式邏輯、資料依據與常見誤會整理成一篇給操作人員與開發共用的小結。

結論先講

  • 生命保險料（イ・ロ・ハ）是系統「計算結果欄位」，設計上永久禁止手動輸入。先在下方可輸入欄（A／B／C／D／E 等）輸入，再按「計算」，結果才會回寫到（イ・ロ・ハ）。

  • 「金額欄」幾乎整段不可輸入，是因為系統判斷「該年度12月沒有調查實績」。只要判斷為無實績，所有加了 class=money 的欄位都會被一鍵鎖定；若判斷為有實績，才會開放。

前端行為（誰被鎖、何時鎖）

  • 頁面載入時，所有 .disabled 一律設為不可輸入
    src/main/webapp/js/adj321.js:12

  • 若 12 月實績旗標為 0（不存在），則把整個 .money 金額欄和「計算」鍵鎖住
    src/main/webapp/js/adj321.js:25
    src/main/webapp/js/adj321.js:26

  • 生命保險料（イ／ロ／ハ）本身就標了 disabled（永遠手動不可）

    • 生命保險料（イ）：src/main/webapp/WEB-INF/view/ADJ321/adj321.jsp:162

    • 生命保險料（ロ）：src/main/webapp/WEB-INF/view/ADJ321/adj321.jsp:164

    • 生命保險料（ハ）：src/main/webapp/WEB-INF/view/ADJ321/adj321.jsp:165

  • 相對地，地震保險（B／C）與新生命保險（A）等欄位沒有 disabled，只會在「12 月無實績」時被一併鎖住

    • 地震保險（B）：src/main/webapp/WEB-INF/view/ADJ321/adj321.jsp:173

    • 新生命保險（A）：src/main/webapp/WEB-INF/view/ADJ321/adj321.jsp:185

後端資料來源（怎麼判斷 “12月有實績”）

  • 321 畫面的 12 月實績旗標來自 yearEndAdjust.trrFlg，放在隱藏欄位 #ExistsDecemberFlag
    src/main/webapp/WEB-INF/view/ADJ321/adj321.jsp:26

  • DTO 欄位
    src/main/java/jp/tokyo/metro/tstt/dto/ADJ321YearEndAdjustDto.java:196

  • 判斷 SQL（重點）：看 T_RESEARCH_RECORD 是否存在「該年度12月」且「金額 > 0」
    src/main/resources/sql/ADJ321GetResearcherYearEndInfo.sql:58
    條件是 PERFORM_YM = {年度}12 且 (REWARD_AMOUNT > 0 OR COST_RESTITUTE_AMOUNT > 0)。
    符合則 TRR_FLG='1'，否則 '0'。

換句話說：不是看 211 畫面「支払月」打勾與否，而是看 T_RESEARCH_RECORD 12 月那筆的「彙總金額欄」是否真的大於 0。

為什麼 211 看起來有 12 月，但 321 仍鎖住？三個常見原因

  1. 只是做了「切替え／打勾」，但還沒經過會把金額落進 T_RESEARCH_RECORD 的計算或集計流程，導致 12 月 REWARD_AMOUNT、COST_RESTITUTE_AMOUNT 仍為 0。

  2. 321 畫面的目標年和 211 的 12 月不一致（SQL 只看「321 畫面目標年」的 12 月）。

  3. 211 的變更只更新了明細或旗標，並未更新到彙總金額欄（同樣導致 >0 的條件不成立）。

計算欄位（イ・ロ・ハ）怎麼來的？為何不能手改？

  • 「計算」時由後端計算並回填，屬於輸出欄位

    • 計算入口：
      src/main/java/jp/tokyo/metro/tstt/action/ADJ321Action.java:181

    • 新生命保險等計算：
      src/main/java/jp/tokyo/metro/tstt/action/ADJ321Action.java:260

    • 回填（例：イ）：
      src/main/java/jp/tokyo/metro/tstt/action/ADJ321Action.java:266

    • 回填（例：ロ）：
      src/main/java/jp/tokyo/metro/tstt/action/ADJ321Action.java:269

    • 計算共用：
      src/main/java/jp/tokyo/metro/tstt/action/ADJ321Action.java:1626

因為是系統算出的結果，設計上禁止手動編輯，避免與計算邏輯不一致。

給操作同仁的口語版說法

  • 看到灰色（イ／ロ／ハ）正常，因為那些是系統算出來的。請把底下可輸入的（A／B／C／D／E 等）填好後按「計算」。

  • 整段金額欄都鎖住，多半是系統判斷「12 月無實績」。這個「有／無」是看 T_RESEARCH_RECORD 裡 12 月那筆的「金額 > 0」，不是看 211 的勾選。
    請先讓 12 月金額確實寫進 T_RESEARCH_RECORD（REWARD_AMOUNT 或 COST_RESTITUTE_AMOUNT 其中之一 > 0），再回到 321 就會開放輸入。

現場排查清單

  1. 確認 321 畫面目標年 → 查 T_RESEARCH_RECORD 是否存在該人的 PERFORM_YM={目標年}12

  2. 檢查該筆的 REWARD_AMOUNT、COST_RESTITUTE_AMOUNT 是否任一 > 0

  3. 若為 0：請補執行對應的計算／集計，或正規流程讓金額落帳；再回到 321 驗證欄位是否解鎖

這套邏輯的關鍵點在於「12 月實績的定義」：

只有當 12 月那筆在 T_RESEARCH_RECORD 的彙總金額欄真正大於 0，321 才會放開金額欄讓你編輯；否則，為了避免在尚未有實績的狀態誤填年末調整金額，前端會鎖住輸入。

This article was last edited at