基礎介紹
專案背景與問題說明
隨著業務規模成長，部分 Partner（客戶的客戶）已不再適合以「單筆即時請款」方式處理帳務，而改採 月結／週期性彙總請款（Statement of Account, SoA）。
原有系統以 Debit Note 為核心，能正確記錄每一筆費用，但在以下情境中逐漸出現限制：
- 同一 Partner 於一個結帳週期內有多筆 Debit Note
- 不同 Partner 有不同的結帳截止日（Closing Term）
- 需避免跨期、重複或漏列請款資料
- 人工彙整與核對成本高，錯誤風險大
因此，本專案目標並非「重做帳務系統」，而是在 不破壞既有資料結構的前提下，補齊月結請款所需的資料欄位、操作介面與輔助自動化。
核心設計原則
本次設計遵循以下原則：
-
帳務邏輯優先於操作便利
- 系統必須能清楚區分「單筆費用」與「彙總請款」
- 避免任何自動行為導致帳務歸屬不明
-
不重複維護 Partner 主資料
- Partner 資訊仍以既有 CRM 為唯一來源
- FIN 資料庫僅同步必要欄位，避免多頭維護
-
讓系統「限制錯誤」，而非依賴使用者記憶
- 透過欄位設計與介面結構，降低誤選、跨期、重複入帳的可能性
系統架構概述
SoA 功能主要包含以下三個層面：
1. 資料結構層
- Partner（CRM）：沿用既有 Closing Date 欄位作為關帳規則來源
- Debit Notes（FIN）：新增必要欄位以支援月結請款流程
- Statement of Account（FIN）：新增獨立資料表承載彙總請款資訊
詳細說明請參閱：資料結構說明
2. Interface 操作層
透過狀態分區的 Interface 設計，分為三個主要區塊：
- 區塊一：SoA Draft（帳務對帳單草稿）：建立與編輯 SoA 草稿
- 區塊二：Ready for SoA（可納入對帳清單）：顯示可納入 SoA 的 Debit Notes 清單
- 區塊三：SoA Sent（已完成寄送之對帳單）：追蹤已完成寄送的 SoA 紀錄
詳細說明請參閱：Interface 說明
3. Automation 輔助層
採用「非全自動化」設計原則：
- 自動更新狀態欄位，確保資料一致性
- 保留人工判斷彈性，確保帳務準確性
詳細說明請參閱：Automation 設計說明
整體效益
透過本次調整，系統可達成：
- 支援不同 Partner 的月結請款需求
- 明確區分單筆費用與彙總帳單
- 降低跨期、漏列、重複請款風險
- 保留人工判斷彈性，同時避免人為錯誤
本設計為「可擴充的帳務基礎」，未來可再依實際營運需求，逐步加入發票、收款狀態或報表輸出功能。