閱讀標記：先把「確定」和「推定」分開

一分鐘結論：這套系統其實是什麼？

1. 一個現實中的申訴，不一定只對應一筆資料。一份請求書可能包含多個稅目、年度或原處分，所以系統會生成一組互相關聯的受付番号。
2. 同一個受付番号，又被橫向切成三張一對一資料表。基本資訊、審理活動日期、進行管理／備忘各放一張表。
3. 核心不是「狀態」而是大量里程碑日期。系統用「答求、答受、初合、議決、法了、裁決、発送……」判斷進度與產生報表。
4. 大量報表是它真正的產出。它按支部、稅目、事件種、結果、處理期間、未結階段、延誤原因等輸出管理資料。
5. 很多規則只是表單層警告，不是不可突破的資料約束。日期矛盾可以按「是」繼續保存；部分原本設計的檢查與彙總更新已被註解停用。

我到底拆了多少東西？

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

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

先不看程式：一件國稅審查請求正常會怎麼走？

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

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

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

裁決結果：代碼 0～6 到底在說什麼？

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

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

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

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

用一個完全虛構的例子

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

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

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

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

【程式】三張核心表目前都各有 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 解釋成複雜的說法都只是猜測，本文不這樣做。

事件種

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

當前審理區分

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

案件怎麼進來

• 受理態樣：持參、經原處分機關、郵送等、電子申請、其他——偏向物理／管道。
• 収受態樣：始審、3 個月經過、みなす 89 条、みなす 90 条，以及再調查後的一取／棄却／却下／変更／其他——偏向前置程序與法定路徑。縮寫「一取」的正式全稱需向內部確認。
• 審理態樣：無、併合、分離、併せ、併合併せ、分離併せ。
• 調整：無、削番、稅目變更、事件種變更、本支所移送、他支部移送。許多正式統計查詢會排除 調整≠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，以及一年內排除的實際外部作業。