函證Table Design Specification

永輝查帳系統資料庫設計參考資料

函證是主+明細?還是單一表?

這是設計「函證模組」時最關鍵的結構抉擇之一。
讓我們清楚區分兩種模式：

---

最佳實務建議：主表 + 明細表（Header + Line Items）

→ 在專業審計系統（如 CaseWare Cloud、TeamMate+、Evershine AIS）中，
函證通常採「主表＋明細表」結構。

為什麼？

因為實務上函證有兩個層次：

1. 函證批次／作業層（主表）：描述整個寄發作業（例如「2025年度應收帳款函證」）
2. 函證明細層（子表）：每一封寄出的函證（對象、金額、回覆狀態）

---

主表：confirmation_batches（或簡稱 confirmations_header）

功能：控制整體函證作業的一次寄發或年度層級設定。

欄位	說明
id	主鍵
engagement_id	所屬查核案件
subject_area	bank / receivable / payable / legal …
batch_code	批次代號（例如 CONF-AR-2025）
title	「2025年度應收帳款函證作業」
description	範圍、目的、樣板說明
prepared_by_user_id / approved_by_user_id	編製與核准人
sent_at / completed_at	寄發與結束時間
total_requests / total_replies	數量統計
status	draft / in_progress / completed / archived
template_id	使用的函證樣板
delivery_method	postal / email / online_portal
notes / tags	補充說明與標籤

---

明細表：confirmation_items（或 confirmations_detail）

功能：紀錄每一封函證的寄發與回覆情況。

欄位	說明
id	主鍵
batch_id	外鍵 → confirmation_batches.id
counterparty_id	對象（客戶/銀行/供應商）
account_item	科目（應收帳款、銀行存款等）
account_code	對應 TB 科目代號
amount_per_books	帳載金額
currency_code	幣別
is_blank_confirmation	是否空白函證
sent_at / response_at	寄發與回覆時間
response_amount	回覆金額
response_status	received / no_response / discrepancy_found / resolved
discrepancy_notes	差異說明
follow_up_count / last_follow_up_at	追蹤次數與日期
workpaper_id	對應底稿 C-3 等
finding_id	若導致查核發現
document_count	附件數
status	pending / sent / replied / closed
created_at / updated_at	稽核追蹤

---

其他輔助表

表名	功能
confirmation_documents	儲存寄發與回覆附件（多對多）
confirmation_logs	記錄每次追蹤行為（寄發、再發、致電、回覆）
confirmation_wp_links	指到底稿內頁（例如「C-3 第3頁」）

---

優點

面向	說明
效率	一次建主表（控制設定），多筆明細批量匯入
彈性	可對每一筆明細分別追蹤寄發/回覆狀態
可稽核性	主表記錄整體流程、明細追蹤個別進度
可重用性	下一年度可複製批次架構再寄發

---

簡化模式：單一表（Flat Table）

適用於中小型會計師事務所或非系統化作業。

在這種情況下，所有資訊（批次 + 明細）都放在同一張表：
每一列代表一封函證。

欄位範例	備註
engagement_id	查核案別
counterparty_id	對象
account_item	科目
amount_per_books	金額
sent_at / response_at	寄發 / 回覆
response_amount	回覆金額
status	狀態
batch_name	用文字標示所屬批次（非外鍵）

優點：簡單、容易維護
缺點：

• 無法有效追蹤批次統計（例如「本次寄出50封、回覆45封」）
• 批次設定無法重用
• 多年度或多次寄發難以區分

---

實務建議（Evershine等中大型事務所）

採用「主表 + 明細表」結構，再搭配：

• confirmation_batches（控制整體流程）
• confirmation_items（記錄個別寄發狀況）
• confirmation_documents（附件）
• confirmation_logs（追蹤紀錄）

函證有兩種選擇: (1)主+明細 (2)單一表，選擇(1) 0r (2) 跟 Document Table 的多對多關係有關嗎?

沒有直接關係。
不論你選 (1)「主＋明細」或 (2)「單一表」，Document（附件）和函證資料都應採多對多 (M↔N) 關係，用中介表連結，而不是把 document_id 直接塞進函證主表/明細表或 documents 表裡。

---

為什麼與結構選擇無關？

• 同一份檔案（例如「客戶A回函.pdf」）常同時被：
  • 某一筆函證明細的回函證據，
  • 同一張底稿（如 C-3）的附件，
  • 甚至匯入管理階層聲明書或報送封面等。
• 反過來，一筆函證（不論是單一表的一列、或主＋明細的某一筆）也可能對應多份檔案（寄發函、回函、追蹤郵件、電話紀錄、快遞收據…）。
  ➡️ 典型多對多，所以要用 junction table。

---

兩種模型下應如何連 Documents？

(1) 主＋明細（建議做法）

你會同時存在批次層與個別函證層的附件：

• 批次層（整批共用的憑證/樣板）
  • 範例：寄發名冊、制式函證模板、快遞總收據
  • 建議：confirmation_batch_documents(batch_id, document_id, role)
    • role 例：template, mailing_manifest, batch_receipt
• 明細層（每一封的往返證據）
  • 範例：某客戶回函PDF、單筆的追蹤郵件、通話紀錄單
  • 建議：confirmation_item_documents(item_id, document_id, role)
    • role 例：outbound_letter, inbound_reply, email_thread, phone_memo

好處：批次與個別證據清楚分流；查詢與權限控管更貼近實務。

(2) 單一表

• 只有一層：每一列就是一封函證
• 建議：confirmation_documents(confirmation_row_id, document_id, role)
  • role 同上（寄發/回覆/追蹤/收據…）

好處：表數少；
限制：缺乏「批次」維度（像模板、批次寄送收據就不好掛）。

---

為何不要把外鍵塞進 documents？

• 同一檔案可能同時屬於多個明細、同張底稿、其他模組；
• 若在 documents 上放 confirmation_id 或 workpaper_id，會造成一檔只能掛一處，破壞正規化並誘發重複上傳。
  ✅ 正解：永遠用 junction。

---

快速決策建議

需求情境	建議模型	對 Documents 的設計
有批次操作（名冊、統一模板、快遞總收據）	(1) 主＋明細	兩張 junction：batch_documents、item_documents
僅少量單封函證、無批次管理	(2) 單一表	一張 junction：confirmation_documents
預期擴充、跨年度比對	(1) 主＋明細	批次層利於複製/統計/權限

---

小技巧（不論選 1 或 2 都適用）

• role 欄位一定要有：outbound_letter / inbound_reply / email_thread / phone_memo / delivery_proof / template …
• 在 junction 上放時間戳與上傳人，方便追溯：uploaded_by, uploaded_at
• 文件版本：Documents 表管理 version / is_active / checksum，junction 只做連結與語意（role）

---

結論

• 函證結構 (主＋明細 vs 單一表) 不影響 Documents 一定用 M↔N 的原則。
• 若有批次管理與統計需求，選 (1) 主＋明細，並分設 批次文件與明細文件兩個 junction；
• 簡單案可用 (2) 單一表＋單一 junction。

函證有兩種選擇: (1)主+明細 (2)單一表，選擇(1) 0r (2) 跟 Workpaper Table 的多對多關係有關嗎?

沒有直接關係、是正交的設計點。
選 (1)「主＋明細」或 (2)「單一表」不會決定與 Workpaper 是否為多對多；是否 M↔N 取決於業務規則：一封（或一筆）函證，需不需要同時掛多張底稿？

---

標準實務（建議預設）

• Workpaper ↔ Confirmation：一對多 (1→N)
  一張底稿（如 C-3 應收函證底稿）對應多筆函證；
  每筆函證只屬於一張底稿。
• 不論你選 (1) 或 (2)，都可以這樣做：
  • (1) 主＋明細：在 明細項（confirmation_items）放 workpaper_id。
  • (2) 單一表：在 同一表 直接放 workpaper_id。

---

需要多對多的情境（才加 M↔N）

只有在下列「共享」情境才需要 M↔N：

• 同一封銀行函證回函同時作為存款與借款兩張底稿的證據。
• 合併/多公司案件下，一筆函證要同時掛多張底稿。

實作方式

• (1) 主＋明細：
  • 仍建議在 明細 放 workpaper_id 做預設 1→N；
  • 另外加 選配關聯表 confirmation_workpapers(confirmation_item_id, workpaper_id) 以支援 M↔N 例外。
• (2) 單一表：
  • 直接加 選配關聯表 confirmation_workpapers(confirmation_id, workpaper_id)。

這樣「常態一對多」簡潔、偶發多對多也能覆蓋。

---

小抄（如何選）

問題	建議
90% 情況每筆函證只掛一張底稿？	用 1→N（欄位 workpaper_id），最簡單
偶爾需要跨掛多張底稿？	保留 workpaper_id + 加一張 junction 覆蓋例外
常態要跨掛（銀行函證常同時支援多底稿）？	直接改用 純 M↔N（只用 junction，不放 workpaper_id 欄位）

---

兩個實務建議

1. 唯一性約束：避免同一年度、同一對象、同一 TB 科目重複建單（例如 UNIQUE(engagement_id, counterparty_id, tb_id)）。
2. 人類可讀索引：在函證記錄保存 workpaper_index_code（如「C-3」），報表易讀、JOIN 仍用 ID。

結論：Workpaper 是否與函證為多對多，由你的流程決定，與 (1) 或 (2) 的資料表結構選擇無直接關聯；最佳做法是預設 1→N，再以「選配 junction」安全覆蓋 M↔N 情境。

永輝查帳系統資料庫設計參考資料

接洽我們：

永輝啟佳聯合會計師事務所- EvershineCPA.tpe
臺灣永輝協同網路服務股份有限公司- EvershineBPO.tpe
永輝專利師事務所 – EvershineIPO.tpe
臺北市長春路378號6F 靠近長春路與復興北路交叉口
捷運文湖線與松山線交口 南京復興站,兄弟大飯店附近
接洽人:
陳中成 首席合夥人/會計師/專利師
Mobile: +886-933920199    
Office: +886-2-27170515 E100    
Skype: daleccchen
Wechat ID: evershiinecpa | Line ID:evershinecpa
Linkedin address:Dale Chen Linkedin    
E-mail: dalechen@evershinecpa.com

Evershine在以下城市擁有100%的附屬公司：

永輝總部、臺北永輝、廈門永輝、北京永輝、上海那靈、深圳常新、紐約永輝、加州永輝、德州永輝、鳳凰城永輝、東京永輝、首爾永輝、河內永輝、越南胡志明、曼谷永輝、新加坡永輝、吉隆玻永輝、雅加達永輝、馬尼拉永輝、墨爾本永輝、澳洲雪梨、孟加拉永輝、新德里永輝、印度孟買、杜拜永輝、法蘭克福永輝、巴黎永輝、倫敦永輝、荷蘭永輝、西班牙永輝、義大利永輝、羅馬尼亞永輝、多倫多永輝、墨西哥永輝。
其他已提供中文化服務城市：
邁阿密、亞特蘭大、俄克拉荷馬、密歇根、西雅圖、特拉華；
柏林; 斯圖加特;布拉格；布加勒斯特；班加羅爾；泗水；
高雄、香港、深圳、東關、廣州、清遠、永康、杭州、蘇州、崑山、南京、重慶、許昌、青島、天津。
永輝潛在可服務城市 (2個月籌備期)：
我們為IAPA會員所,總部在倫敦，全球300個會員所，員工約1萬人。
我們為LEA會員所,總部在美國芝加哥，全球600個會員所，員工約2萬8千人。
Evershine is local Partner of ADP Streamline® in Taiwan.
(版本:2025/10)