我到底拆了多少東西？

【程式】資料庫以停用巨集與啟動程式碼的方式唯讀開啟，沒有執行 AutoExec，也沒有修改原檔。盤點結果如下：

694 張報表不代表 694 套不同業務；其中大量是同一統計按支部、税目、事件種、実件／延件、明細／合計、橫式／縱式等變體展開。

先不看程式：一件国税的「審査請求」通常怎麼走？

先把角色記住，後面所有欄位就不會再像天書：

【官方】国税不服審判所公開的流程可以壓成下面十步。官方完整說明見「審理と裁決」：

1. 審査請求書の提出：原則上可直接向国税不服審判所提出，也可能在再調査の請求後提出。一般期限是知道處分之翌日起 3 個月內；若經再調査決定，通常為送達翌日起 1 個月內。精確例外須以現行法與官方說明為準。
2. 収受與形式審査：先看審査請求書是否具備必要記載、是否在期限內、代理権證明文件是否齊全；能補的就要求「補正」。明顯不適法且不能補正的，可不進實體審理而「却下」。
3. 答弁書の要求：原処分庁說明它要維持什麼處分、事實與法律理由是什麼；答弁書の写し送給審査請求人。
4. 合議体の指定：指定 1 名担当審判官及至少 2 名参加審判官。担当審判官成為雙方提交主張、証拠、程序申請的主要窗口。
5. 争点整理與審理計画：把雙方真正爭什麼、已交什麼、還缺什麼、下一步何時做整理清楚，必要時交付「審理の状況・予定表」與「争点の確認表」。
6. 主張・証拠の提出：審査請求人可交反論書與証拠；原処分庁及参加人可交意見書；審判所也可要求回答、文件或補充說明。
7. 手続上の権利：審査請求人或参加人可申請口頭意見陳述；雙方可在法定範圍內請求閲覧或写しの交付。口頭意見陳述時，審査請求人可經担当審判官許可向原処分庁発問。
8. 職権調査：担当審判官等可質問、検査、要求帳簿書類、留置物件或委託鑑定，用來釐清事實。
9. 審理終結・合議・議決：調査完畢後終結審理；合議体以過半數形成「議決」。議決是合議体的結論，裁決則是審判所長依議決作成的正式行政判斷，兩者不是同一個日期。
10. 裁決・発送・訴訟：裁決書謄本送達審査請求人與原処分庁。審査請求人仍不服時可依法提起訴訟；原処分庁受裁決拘束，不能因不服而起訴。

最容易混淆的一句：「審査請求人贏了一部分」叫一部取消し；「審査請求人在實體理由上沒被接受」叫棄却；「這個請求程序上不合法」叫却下；「審査請求人自行取下」叫取下げ。這四個不能混寫。

処理態様：代碼 0～6 到底在說什麼？

【官方】裁決不得把審査請求人處境改得比原処分更不利；裁決對有關行政機關有拘束力。完整定義可核對国税不服審判所的裁決内容與拘束力說明。

【程式】若処理態様為全部取消し或一部取消し，系統會要求選「取消事由」；若為却下或取下げ，會要求「却下事由」或「取下事由」。取消案件且税目代碼小於 90 時，還要求入力本税與加算税的取消金額。這些條件是本程式的統計口徑，不應倒推成法律本身的分類。

全系統最難的一關：実件、延件、総延、総総到底是什麼？

先用一句人話：同一個人遞交的一份請求書，可能同時挑戰好幾個税目、年分或原処分；管理上想把它看成一組，但統計上又必須分別計件。所以系統同時保存三層數量。

用一個完全虛構的例子

假設甲公司用同一份請求，爭執「法人税兩個年分」和「消費税一個原処分」。管理上是 2 個実件，統計最小單位是 3 個延件：

上表是依欄位說明與複写演算法製作的教學例，並非資料庫中的真實案件。

【官方】国税庁歷史統計資料說明，件數原則上按處分或事案分別計 1 件；本税與特定加算税同時爭執時，可能合併按 1 件計。這就是為什麼畫面上人的直覺「我只申訴一次」與統計數量可以不同。可參考国税庁統計編的計件註記。

開發時不要做錯：実、延不是布林版的「真／假」，而是統計權重；総延是実件小計，総総実／総総延是整組總計。它們雖常見 0 或 1，但資料中也存在 Null、0、1、-1 等歷史值，不能直接改成嚴格 Boolean 而不做資料清洗。

同一受付番号，為什麼要住在三張表？

【程式】三張核心表目前都各有 2,107 筆，以 受付番号一對一連結。関連設定同時啟用唯一性、更新串聯與削除串聯。把它想成一張太寬的案件卡被剪成三頁：

削除為什麼危險？因為情報表是親表：削除其中一個受付番号，另外兩表同號資料會被連鎖削除；若削除的是関連グループ的親レコード，削除表單還可能先削除整組情報資料。

還有一條「暫定版」支線：事績処理３有 51 個欄位，搭配 暫定版補完入力表單及報告資料建立查詢，追蹤国税通則法第 96／97 條相關資料提出節點；但本快照為 0 筆，名稱也明示「暫定版」。因此它不是目前 2,107 筆核心資料的第四頁，應視為尚待確認是否啟用的試行／補充模型。

主輸入畫面的三個頁籤，各自在問什麼？

【程式】主フォーム 事績処理入力有三頁，名稱正好對應三張核心表。它不是要操作員一次填完 409 個欄位，而是在案件生命週期中不斷補日付、結果與メモ。

第一頁：情報——「這是誰的什麼案件？」

• 識別與聯絡：支部、受付番号、関連受付番号、請求人、共同、代表者、郵便番号、住所等、請求人電話、代理人、補佐人。
• 案件性質：税目、事件種、事件処理区分（初期／変更／再変更）、設定日、変更理由、争点番号、海外取引、争点（海外）、評価。
• 原処分來源：局部課、本支所、原処分庁、受理態様、収受態様、審理態様、青白区分、年分、原処分。
• 計件與関連：請求書、実、総延、延、総総実、総総延、継続管理。
• 特殊管理：情報共有事件、本部報告日、調整、審理留保、再開、重要事件、公表判定。
• 処理結果：裁決番号、処理態様、取消事由／却下事由／取下事由、取消税額（本税／加算税）。
• 手続上の権利：口頭意見陳述、閲覧／謄写、徴収猶予、差押解除、発問権、出席、審理手続意見聴取。
• 担当・審査体制：部、部門、担当審判官、参加審判官 1／2、分担者、法審部門、法規審査、形式審査、事件主任。
• 本人確認：法人番号確認、個人番号確認、個人身元確認。官方也說明，含 My Number 的請求書須附相應確認資料。
• 謄写／写しの交付：最多五輪，逐輪保存謄写対象特定書収受日、謄写請求書収受日、頁数、費用、納付、交付與除外日数。

第二頁：日付（情報）——「雙方與審判所做過哪些程序活動？」

• 面談種類、予定日、実施日、出席者，以及書類／物件的預り與返却。
• 三輪要求書類：要求什麼、何時要求、期限、何時收到。
• 「審理の状況・予定表」最多三輪，分別記錄交付給請求人與原処分庁的日期。
• 「争点の確認表」最多三輪，分別追蹤雙方的交付日期。
• 本部照会與回答、一般文書的要求／収受／送付。
• 反論書、請求人意見書（多輪）、原処分庁意見書（多輪）、雙方回答書：各有要請日、提出期限、収受日。
• 参加人意見、釈明陳述録取書、面談、口頭意見陳述、閲覧／写しの交付、審理手続意見聴取。
• 最多五輪調査的計画日、実施日與内容；另有マスキング、デジタルカメラ等實務欄位。

第三頁：日付（進行管理）・メモ——「現在走到哪裡，接下來怎麼辦？」

• 完整主時間軸：請求、収受、補求、補完、答求、答受、事件回付、配付、指定、着手、初合、審理終結、議決、法回、法了、返戻、再開、決裁、裁決、発送、送達。
• 七個核心節點的当初計画與修正計画：答弁書要求、答弁書収受、当初合議、議決、法審了、裁決、発送。
• 文字備忘：進捗状況、第 96 条資料未提出理由、特記事項、遅延理由、今後の処理方針、各種備考、事案概要。
• 大量以 F結尾的旗標，用來決定親レコード更新時，此欄是否要同步到関連レコード。

「答求、初合、法了」是什麼？日文欄位逐項說明

下面先給能從官方流程或程式前後文確定的白話意思；帶「推定」者是內部縮寫，程式沒有正式字典，重建前必須請業務確認。

操作員怎麼用：検索、新規、更新、複写、削除

1．先検索，不允許「什麼都不填」

検索表單可按支部、受付番号、請求人、税目、請求／収受／裁決日期區間、関連受付番号篩選。三組日期都檢查「自 ≤ 至」。受付番号與請求人使用 Access 的 Like，程式本身沒有自動在前後加萬用字元，所以一般輸入等同精確比對；使用者自己輸入萬用字元時才可能模糊検索。

結果列顯示支部、受付番号、請求人、税目、請求日、収受日、裁決日、実、総総延與関連受付番号。從這裡進入更新、新規、関連複写或削除。

2．新規：先建三張表，再依総延製造延件

1. 使用者確認新規登録。
2. 執行必須チェック、条件付必須チェック與日付チェック。
3. 檢查受付番号未重複。
4. 若填関連受付番号，確認親レコード存在、請求書=1，而且請求人相同。
5. 依序向三張核心表插入同一受付番号。
6. 若 総延 > 1，自動再建立 総延-1個延件行。新號碼固定用「原受付番号前 8 字元＋四位流水號」。

複写出的延件會承接支部、請求人、税目、事件分類、担当與多數共通日期，但個別原処分專屬欄位不全都複写；它們設為 実=0、総延=0、延=1。

3．更新：先改本レコード，再把共通欄位同步到整組

1. 確認、必須チェック與日付チェック。
2. 若受付番号有改，檢查新號碼唯一性；資料庫関連會串聯更新兩張子表的鍵。
3. 依序更新三張核心表。
4. 若目前是親レコード，呼叫 UpdKanren1，把姓名、分類、担当、共通程序日期、計画與進捗等同步至同一関連受付番号的関連レコード。
5. 若重新指定親レコード，程式會把舊親レコード的 請求書改為 0。

4．「複写」不是另存新案件，而是補齊缺少的延件

只有 総延 ≥ 2且存在関連受付番号時才能用。進入複写模式後，大部分欄位被鎖住；程式先數同一受付番号前 8 字元、且同一関連受付番号的現有行，再只補造不足的流水號。因此按鈕名稱很容易誤導：它的業務目的是依総延補足計數行，不是讓使用者自由複製一件案件。

5．削除：看你削除的是親レコード還是関連レコード

• 沒有関連受付番号：只削除目前情報行，兩張日付表由関連設定連鎖削除。
• 有関連受付番号且 請求書=1：削除所有同一関連受付番号的情報行，也就帶走每行的兩張日期資料。
• 関連レコード：只削除目前受付番号。

注意：削除後重新計算 総総実／総総延的呼叫已被註解，所以剩餘親レコード的總數可能變舊。

関連同步的 F 旗標：為什麼每個日期後面又有一個 F？

【程式】資料表說明寫得很明確：0 或 Null＝同步更新，-1＝不更新。例如 裁決F、法了F、発送F。

這是在「整組通常共用日期，但少數延件例外」之間做折衷。新系統若要重建，最好把它表達為明確的「繼承／覆寫」模型，而不是讓每個日期旁都長一個難懂的 Boolean。

哪些是真必填？哪些只是警告？

必須チェック（無条件）

【程式】主流程會要求：支部、受付番号、請求人、住所等、税目、事件種、局部課、本支所、原処分庁、受理態様、収受態様、青白区分、年分、原処分、実、総延、延、請求日、収受日、処理態様，以及法人番号／個人番号／個人身元確認三個確認欄位。注意：是否真的該三者同時要求，是程式現況，不代表所有案件法律上都必然同時適用。

条件付必須チェック

日付チェック不是硬擋

程式檢查大量先後順序，例如：

• 収受／収調 → 補求 → 補完；答求 → 答限 → 答受。
• 初合 → 終合 → 議決；法回 → 返戻／法了 → 裁決 → 発送。
• 浄書回付 → 浄書終了；次席回付 → 次席決裁；所長回付 → 所長決裁。
• 面談通知 → 面談実施；書類提出要求 → 提出；閲覧請求 → 実施；口頭意見陳述の申立て → 実施。
• 当初計画及修正計画的七個節點順序、三輪予定表／争点の確認表順序、各種要請日 ≤ 提出期限。

關鍵：發現矛盾後，DateCheck把全部訊息串起來，最後問「処理を続行しますか？」；按「是」就回傳成功並繼續保存。因此這是可覆寫的警告。若業務需要例外，理想設計應要求記錄覆寫理由與操作者，而不是只有 Yes／No。

已被註解、目前不生效的規則

• 主要争点番号的部分必填要求。
• 総延 > 1時関連受付番号必填。
• 若干要求書類期限、争点／予定表交付日期的必填。
• 除外期間（至）必填。
• 多個「後日期存在時，前日期必須存在」的檢查；有些只剩「兩者都有值時比較大小」。

為什麼有這麼多「表、書、意見、閲覧、謄写」？

【官方】這些程序不是 VBA 作者憑空想像。可核對国税不服審判所審理手続說明、官方提出書類一覧及現行国税通則法。

內部分類代碼：它們是報表維度，不一定是法律分類

事件処理区分：A、B、C、D、E、A'

【程式】代碼表只保存這六個標籤，沒有說明 A 到 E 各代表何種難度或処理方法。帳票會優先採「再変更区分」，其次「変更区分」，最後才是初期区分；並用它產生硬編碼モデル日程。任何把 A 解釋成簡易、D 解釋成複雜的說法都只是猜測，本文不這樣做。

事件種

推計課税等、行政訴訟関連、査察関連、その他訴訟関連、調査課等、特調等、税関長等、その他一般。它決定統計分類與可能的処理特性。

審理区分（現在卡在哪個工作階段）

管理手持、議決未済、返戻未済、報告未済、法審未済、決裁未済、留保事件。這是管理者看「卡在哪個工作籃」的欄位，不是処理態様。

案件怎麼進來

• 受理態様：持参、処分庁経由、郵送等、電子申請、その他——偏向實際收件管道。
• 収受態様：始審、３か月経過、みなす８９条、みなす９０条、再調査一取、再調査棄却、再調査却下、再調査変更、再調査その他——偏向前置程序與法定路徑。縮寫「一取」的正式全稱仍需向內部確認。
• 審理態様：該当なし、併合、分離、併せ、併合併せ、分離併せ。
• 調整：該当なし、削番、税目変更、事件種変更、本支所移送、他支部移送。許多正式統計查詢會排除 調整≠0的資料。

海外取引、重要事件與公表判定

• 争点（海外）：外国税額控除、非居住者・外国法人の納税義務、非居住者・外国法人の源泉課税、移転価格、国外関連者寄附金、過少資本、外国子会社合算税制、その他、消費課税、資産課税。
• 重要事件：重要先例見込事件、個別管理重要事件、本部協議事件、情報共有事件、本部照会事件、相互審査事件；代碼文字引用內部《提要》章節。
• 公表判定：未判定、公表適、公表否（「審査請求人等が容易に特定されるおそれがあるもの」「審査請求人等の営業上の秘密がもれるおそれがあるもの」「その他」）、公表留保。這是裁決公開前的隱私與機密判斷。

取消事由・却下事由・取下事由・長期化理由

• 取消事由：「法令、通達等の解釈、適用誤り」「事実関係の認定誤り」「新たな資料が提出又は発見」「重加算税の賦課決定要件の認定誤り」「計算誤り」「その他」；推計課税事件另分「推計方法の変更」「推計の基礎項目の変動」「同業者率の異動」「実額採用（収支計算）」等。
• 却下事由：「期限徒過」「原処分不存在」「不利益処分でない」「既に判決又は裁決により確定」「法定の請求事項に該当しない」「再調査の請求が不適法」「再調査の請求に係る決定なし」「請求の資格がない」「補正要求に応じない」「その他」。代碼表另混有「原処分取消し」類歷史項目，不能直接當成純粹的現行却下事由字典。
• 取下事由：大類包含「適法事件／原処分取消」「請求人が原処分を容認」「主張を放棄」「訴訟等の終結等により裁決を求める利益なし」，以及各種「不適法事件」原因。
• 長期化理由：「請求人側の理由／調査非協力」「原処分庁側の事由」「関係人等の事由」「事実関係の複雑」「法令の解釈・適用の困難」「事件の急増」「査察・訴訟関連」「担当審判官の病気等」「その他」「審理留保事件」「議決済事件」。

報表才是終點：管理層到底想看什麼？

【程式】主選單把報表大致分成六組：

1. 発生・処理実績：按税目、事件種、支部／本所、原処分庁、処理態様、取消税額、取消事由／却下事由／取下事由、月別等統計，另有受付簿。
2. 平均処理期間：每案、全体、実件／延件、支部、税目、事件種、部門，以及圖表和期間異常チェック。
3. 未済管理：各支部的未済件数、処理段階、逐案経過月数、全国／支部平均、審理留保事件、長期化理由及明細。
4. モデル日程：把 A～D、A' 的內部モデル日程與実績／計画日並排。
5. 業務計画・実績報告：計画指標、処理実績、進捗表。
6. 入力品質：入力状況確認、未済状況確認、汎用入力チェック、期間與日付矛盾清單。

報表的「今天」不是固定今天

所以不能簡單說「本系統年度都是 4 月」或「都是 7 月」：兩套起點都存在，由不同報表使用。

四個會改變數字的隱藏口徑

1. 有効な収受日：IIf(収調 Is Null, 収受, 収調)。只要填了収調，経過期間就改從収調算。
2. 未済的終點不統一：有的帳票按裁決日統計処理，有的未済クエリ要到 発送完成才排除。因此「已裁決但尚未発送」可能法律判斷已完成，操作帳票仍在待辦。
3. 調整資料常被排除：調整=0才進正式統計，削番、税目變更、移送等通常被濾掉。
4. 代表行與計件權重：有的清單只取 請求書=1，有的統計加總 実或延；同一批資料若選錯口徑，件數會完全不同。

経過期間の区分

系統至少存在兩套分桶：

• 細版：6 個月內、9 個月內、1 年內、1 年 6 個月內、2 年內、2 年 6 個月內、3 年內、3 年超。
• 彙總版：6 個月內、1 年內、2 年內、3 年內、3 年超。

另有逐階段耗時：収受→答求、答求→答受、答受→指定、指定→着手、着手→議決、議決→法審了、法審了→裁決等。這使管理者不只知道「慢」，還能知道慢在答弁、調査、合議、法審或決裁。

A～D、A' 的硬編碼模型日程

【程式】進行管理一覧把一年分成每月上／中／下旬，用 ①～⑦標記モデル、計画與実績：

①答弁書要求　②答弁書収受　③当初合議　④議決　⑤法規審査了　⑥裁決　⑦謄本発送

千萬別把上表當法定期限。這些只是 VBA 中從「有効な収受日」加固定天數的內部管理モデル。官方公開的 1 年標準審理期間與這套 A～E 日程是不同層次的概念。

１年以内処理：官方口徑和本程式的落差

【官方】国税不服審判所把「審査請求到達後至裁決通常所需的標準審理期間」設為 1 年。最新的令和 7 年度（2025-04-01～2026-03-31）公開資料顯示：発生 3,159 件、処理 3,128 件，其中全部認容／一部認容 226 件、認容割合 7.2%，１年以内処理割合 98.8%。官方註明，計算該比例會排除相互協議、公訴相關等留保期間，以及災害或審査請求人原因造成的中斷期間。見令和 7 年度審査請求概要。

【程式】資料庫有 １年以内判定除外、除外期間（自）、除外期間（至）、留保與再開欄位；但全庫検索只發現這些欄位被入力、驗證及輸出到參考清單，沒有發現自動把除外日数扣掉後重新判定１年以内的公式。而且只設一組除外起訖，無法自然表示多次中斷。這表示最終１年以内統計可能另靠人工計表、外部作業或尚未納入本檔的処理。

從開發者角度看：VBA 架構怎麼串起來？

開啟主輸入表單時，OpenArgs區分「新規、更新、複写」。SelData一次把三張表的大量欄位搬到表單；更新時又逐一搬回。這是典型 Access「巨型表單＋程序式資料映射」架構，業務規則散落在表單事件、模組、欄位說明與查詢中，而不是集中在一個領域層。

已確認的技術風險與疑似缺陷

以下不是對業務好壞的評價，而是「若你要維護或重建，最容易出事故的地方」。

如果你要重建：不要照抄 409 欄巨表，要還原成領域模型

目前設計把「一件案件的一切」橫向鋪成欄位。新系統更適合把可重複、可多輪、可追歷史的東西變成子實體：

新系統至少要守住的資料不變條件

1. 受付番号對外唯一，但內部主鍵用不可變 UUID；改受付番号不等於改實體身份。
2. 一份 AppealRequest 必有且只有一個親レコード；同組 Party／Matter／Disposition 都指向同一根。
3. 総総実與総総延不由人輸入，而由明細即時計算；必要時保存報表快照，但不可有兩個真相。
4. 新規登録一件及所有子項必須在同一交易中成功或全部回滾。
5. 日期順序分成「絕對禁止」與「允許例外」；例外需原因、權限、時間與審批記錄。
6. 法定期限、官方標準期間、內部模型日程是三種不同規則，分開配置、分開顯示。
7. 同一事件可有多次分類変更、多次計画修正、多次留保、多輪文書與閲覧，不用固定 1／2／3／5 欄位。
8. 報表明確標示計件口徑（請求書／実件／延件）、期間起點（収受／収調）、完成點（議決／裁決／発送／送達）與排除條件。
9. 個資與稅務敏感資料採最小權限、加密、匯出審批、下載追蹤與保留期限。

最安全的重建順序

1. 先定義字典：把本文末的待確認問題逐一取得業務簽認。
2. 做唯讀對帳層：先用視圖重現現有 727 查詢中真正被使用的口徑，不急著改 UI。
3. 建立正規化領域模型：保留舊受付番号作外部識別，建立映射與資料品質報告。
4. 先遷移計件與主時間軸：這兩塊是所有報表共同底座。
5. 逐組替換文書／調査／閲覧：把固定輪次欄位改成可重複子表。
6. 雙跑報表：新舊系統以同一基準日比較実件、延件、未済、平均処理期間及処理態様，差異必須能逐件解釋。
7. 最後才關閉 Access 寫入：在交易、權限、審計、備份與回退全部驗證後切換。

重建前，一定要拿去問業務的 16 個問題

1. A、B、C、D、E、A'的正式定義、選定條件與可變更權限是什麼？
2. 請求書、実、延、総延、総総実、総総延的正式統計定義，是否與本文三層模型完全一致？哪些本税／加算税組合要合併計件？
3. 収調在什麼情況可改、由誰核准、是否必須保留原収受日與理由？
4. 形回、予担回、文合、法回、再法、三次受理的正式全稱與完成條件是什麼？
5. 每一張報表的「処理完了」到底用議決、裁決、発送還是送達？為何不同？
6. 一年內比例的排除期間由誰認定？可否多段？起訖日是否含首尾？目前外部怎麼計算？
7. 関連同步的 F 旗標由誰操作？-1 是永久例外、單次例外，還是只對親レコード同步有效？
8. 次席決裁使用浄書終了F是否確為缺陷，或有極特殊業務意圖？
9. UpdSousou與UpdKanren2為何停用？是歷史事故、人工流程，還是已由外部作業取代？
10. 11 碼受付番号目前還在使用嗎？若使用，自動複写如何避免前綴錯誤？
11. 日期警告允許覆寫是否有紙本／外部審批？哪些日期其實應該硬性禁止逆序？
12. 事績処理３與「暫定版補完入力」是否仍屬正式業務？若是，0 筆是尚未上線還是資料在別處？
13. 公表、重要事件、情報共有、本部照会與相互審査代碼的維護責任和生效日期如何管理？
14. 削除整組、直接編輯核心表、C:\temp匯出與「テーブル移行」的正式操作手冊、權限與備份程序在哪裡？
15. 目前有沒有獨立的變更履歷、使用者權限與覆寫記錄？若沒有，稽核時如何還原誰改過資料？
16. 694 張報表中，哪些仍在法定／管理作業使用，哪些只是歷史版？每張的業務 owner 是誰？

最後一張小抄：只記住這 12 句就夠了

1. 這是案件管理與統計系統，不是自動法律判斷器。
2. 一份請求書可以有多個実件；一個実件可以有多個延件。
3. 関連受付番号把整組綁在親レコード；親レコード的請求書＝1。
4. 同一受付番号在三張核心表各有一行。
5. 収調有值時，報表不用原収受日，而用収調算期間。
6. 議決是合議体結論；裁決是正式行政判斷；発送與送達又是後續節點。
7. 却下是程序不適法，棄却是實體理由不成立，取下げ是審査請求人自行取下。
8. 日期矛盾目前只是警告，使用者可以繼續。
9. F＝-1代表不要把親レコード值同步覆蓋到此欄。
10. A～E是內部事件処理区分；固定加天數是管理モデル，不是法定期限。
11. 一年標準期間是官方目標；排除期間的完整計算不在這份 VBA 裡。
12. 重建時先保計件、関連、時間軸與帳票口徑，再談漂亮畫面。

官方驗證來源

• 国税不服審判所：審理と裁決——形式審査、答弁書、合議体、主張立証、口頭意見陳述、閲覧／交付、調査、終結、議決、処理態様與拘束力。
• 国税不服審判所：不服申立制度等——提出路徑、一般期間、標準審理期間及訴訟入口。
• 国税不服審判所：審判所的角色——第三者立場、行政內部最終判斷與制度定位。
• 国税不服審判所：代理人と総代——代理權、特別委任、共同請求與總代。
• 国税不服審判所：参加人とは——参加人的資格與手続上の権利。
• 国税不服審判所：提出書類一覧——反論書、意見書、口頭意見陳述、補佐人、閲覧／交付、取下げ等官方表單。
• 国税不服審判所：審理手続與透明性說明——審理の状況・予定表、争点、調査、口頭意見陳述、閲覧／交付與終結效果。
• 国税不服審判所：争点の確認表說明——表內整理的原処分、争点與雙方主張，以及依個案可能不交付。
• 国税不服審判所：標準審理期間——標準期間 1 年與可能難以在期間內裁決的事件例。
• 国税庁：令和 7 年度における審査請求の概要——最新発生／処理／認容／未済／１年以内処理割合及排除口徑。
• 国税庁：統計編——審査請求件數按處分或事案計件的註記。
• e-Gov 法令検索：国税通則法（2026-04-01施行版）——答弁、反論、参加人意見、口頭意見陳述、証拠、調査、閲覧／交付、終結與裁決等法源。

法令與運用會更新。本文核對時間為 2026-09-02；實際開發上線前，仍應重新確認當時生效版本及內部業務規程。

分析方法與可信度

原始 ACCDB 以 Access Automation Security 強制停用 VBA／マクロ後唯讀盤點；匯出所有テーブル、クエリ、フォーム、レポート、マクロ、モジュール定義，再對核心 CRUD、驗證、関連同步、日付函式、レポート函式及關鍵クエリ逐段追蹤。原檔未被修改，啟動マクロ及匯入／轉換程序未執行。

最有把握的是：三表結構、関連、欄位群、CRUD 順序、日付チェック可覆寫、関連複写、計件集計函式、硬編碼モデル日程與已註解呼叫。仍需內部確認的是：A～E與若干縮寫的正式業務定義、停用程式碼的決策背景、各帳票 owner，以及一年內排除的實際外部作業。