發票模組

快速理解：發票模組把已歸檔交易的預計請款安排，推進為實際開票、文件交付、收款追蹤，以及作廢或折讓後的重開結果。

1. 模組全貌

管理範圍

本模組管理兩種發票來源（一般發票、掛帳發票）及兩項後續處理（發票異動、收款追蹤）：

1. 一般發票：沿用一般訂單內的發票期數、預計日期與金額；訂單正式歸檔後，財務才從發票清單處理實際開立、文件與付款。
2. 掛帳發票：依已歸檔的掛帳或 LINE OA 訂單、平台帳號及發票月份，從 Excel 建立每月請款資料。
3. 發票異動：一般發票開立後，依申請、主管審核、會計執行與會計審核完成作廢、折讓及必要的重開。
4. 收款追蹤：維護付款狀態與付款日期，並依實際開立日及客戶收款條件標示逾期。

訂單與合約模組擁有一般訂單的發票期數、預計日期、各期金額及總額一致性，也提供掛帳與 LINE OA 合約作為掛帳發票來源；本模組擁有實際發票號碼、實際開立日、檔案、寄送紀錄、付款、折讓、作廢及重開結果。

主要角色

角色	主要責任
財務／會計	開立發票、上傳與寄送文件、維護付款、執行與審核發票異動
業務／異動申請人	針對自己負責的已開立發票提出作廢或折讓、補正退回申請
主管審核群組	判斷發票異動的商業原因與處理方式是否可接受
Project AE	接收一般發票寄送副本，並在訂單或工單查看發票與付款進度
掛帳發票維護者	匯入每月掛帳請款、補充開票與付款資訊，必要時建立回補訂單

核心概念

• 發票日期：訂單承諾或掛帳資料中的請款日期；一般發票另有「實際發票日期」記錄真正開立日。
• 開立狀態：「尚未開立」、「已開立」、「已作廢」；由發票號碼決定，規則見第 3 節。
• 付款狀態：「未入帳」、「已逾期」、「已入帳」，與開立及折讓狀態是不同維度。
• 折讓狀態：「部分折讓」或「全額折讓」；折讓不會把原發票改成「已作廢」。
• 重開發票：完成異動時新增的新發票資料，沿用原期別並指向原發票，不覆寫原始紀錄。
• 回補訂單：掛帳發票可直接建立一張已歸檔、已完成執行的一般訂單，並將兩者互相連結。

模組邊界

• 一般發票的期數與預計金額在建立訂單時就保存，但未正式歸檔的訂單不會出現在一般發票清單。
• 掛帳發票不是由一般訂單分期轉入，而是按平台、帳號與月份匯入；其金額來源為匯入檔。
• 發票異動入口目前以已歸檔一般訂單的已開立發票為主，不是掛帳發票的異動主線。
• 採購與請款模組保存的是廠商支出端發票附件及付款流程，不進入本模組的客戶收入端發票清單。
• 退佣若讀取發票結果，屬於下游計算，不改變本模組的開票與異動生命週期。

2. 核心流程

A. 一般發票開立與交付

1. 訂單建立或修改時即保存各期發票，初始為「尚未開立」、「未入帳」。
2. 訂單正式歸檔後，財務可依客戶、訂單、期別、預計日期與金額處理請款。
3. 填入符合格式的發票號碼後成為「已開立」；操作介面會在尚無實際開立日時自動帶入當日，財務仍可另行修改。
4. 有發票號碼後可上傳 PDF。
5. 寄送時，附件寄給訂單負責業務，副本給操作的會計；Project AE 與業務不同時也會收到副本。
6. 第一次下載會留下下載時間；寄送成功會留下寄送時間，供清單與訂單詳情辨識文件是否已交付。

B. 付款與逾期

1. 新發票預設為「未入帳」。
2. 財務勾選已付時，操作介面把狀態改成「已入帳」並預填當日付款日期；付款日期只有在已付狀態下可編輯。
3. 改回未付時會清空付款日期。
4. 系統每日 00:30 檢查已歸檔訂單的「未入帳」發票；今日超過付款期限時改成「已逾期」。
5. 付款期限以實際開立日為起點：
   • 「次月付款」：目前實作為「實際開立日加上收款天數」。
   • 「上線前付款」：付款期限等於實際開立日。
   • 其他或沒有實際開立日：不產生付款期限。

C. 掛帳發票

1. 維護者先下載範本，再匯入平台、掛帳帳號、發票月份、廣告費、服務費、折扣及含稅發票金額。
2. 平台與帳號必須存在且組合相符，來源訂單也必須已正式歸檔。
3. 同一平台、帳號與發票月份不可重複建立。
4. 匯入後初始為「尚未開立」、「未入帳」；財務可批次編輯費用、折扣、發票日期、號碼及付款資訊。
5. 掛帳發票把「發票日期」同時當成實際開立日。
6. 尚未建立回補訂單的掛帳發票可軟刪除；一旦已回補便不可刪除。
7. 回補會複製原掛帳訂單素材建立一般訂單，直接標示為已歸檔、已完成執行，並把掛帳發票連回該訂單。

目前只確認掛帳範本下載與 Excel 匯入；一般及掛帳發票清單未見獨立的發票匯出流程。

D. 發票異動

1. 可選訂單必須已歸檔且至少有一張「已開立」發票；可選發票限「未入帳」或「已逾期」。
2. 作廢：
   • 只可選實際開立月份次月 5 日以前（含當日）的發票。
   • 已部分折讓的發票不可再作廢。
3. 折讓：
   • 折讓金額必須大於 0，且不得超過扣除已完成折讓後的剩餘可折讓金額。
   • 小於剩餘金額時為「部分折讓」，只能不重開。
   • 等於剩餘金額時為「全額折讓」，原則上需選待開或指定重開日。
4. 作廢原則上也需要重開；若異動原因是「訂單作廢」則可選擇不重開。
5. 折讓一律需要客戶同意證明；作廢只有發票已提供客戶時需要證明。
6. 主管通過後進入會計執行；會計先在外部發票平台完成處理，再回系統進入會計審核。
7. 會計審核時，需要補齊實際重開日期、上傳異動證明並寄送給負責業務；操作介面完成這些條件後才開放通過。
8. 通過後：
   • 作廢把原發票改成「已作廢」。
   • 折讓保留原發票為「已開立」，並標記部分或全部折讓。
   • 需要重開時新增同一期「尚未開立」發票，付款狀態重新從「未入帳」開始。
9. 若以「訂單作廢」為原因，且本次所處理的發票都已作廢或全部折讓，系統通知負責業務繼續提出歸檔訂單作廢。

3. 商業規則

資料來源與金額

• 一般發票的期別、預計日期與金額以訂單保存的發票資料為來源；歸檔只是讓既有資料進入財務清單，不會另複製一套發票。
• 同一期在作廢或全部折讓後可能同時有原張與重開張；原張保留供稽核，新張透過「原發票關聯」追溯來源。
• 一般訂單仍以各期最新代表資料檢查發票總額；詳細金額與期數限制見訂單與合約模組。
• 掛帳匯入保存檔案提供的含稅發票金額；畫面另可修改廣告費、服務費與折扣，但目前不會依這些欄位重新計算發票金額。
• 發票號碼只檢查格式，填入或清空號碼直接決定「已開立」／「尚未開立」。

文件與通知

• 一般發票檔案只接受 PDF；必須已有檔案才能寄送通知。
• 一般發票操作介面只在已有發票號碼時顯示檔案操作。
• 重新上傳一般發票會清空舊的首次下載與寄送紀錄，讓新版本重新追蹤。
• 異動申請的客戶同意文件接受 PDF、JPG 或 PNG；會計完成異動時另保存會計證明。
• 會計異動證明寄出後，操作介面不再允許退回該申請。

付款

• 開立狀態、付款狀態與折讓狀態彼此獨立；「已開立」不代表已付款，部分折讓也不自動結清。
• 自動逾期只把「未入帳」改成「已逾期」，不會自動把「已逾期」還原為「未入帳」。
• 已付款發票不會出現在發票異動的可選清單。
• 一般發票的付款期限與逾期檢查，會讀取客戶模組目前保存的收款條件，而不是發票建立時的快照。
• 操作介面維持「已入帳」與付款日期的連動；後端更新目前未再次檢查兩者必須一致。

異動與重開

• 只有已歸檔訂單可以建立異動申請。
• 同一張發票在主管審核或會計審核中時，正常選擇流程不應重複申請。
• 剩餘可折讓金額只扣除已完成的折讓；退回或取消的申請不占用額度。
• 主管退回或會計退回後，申請人可修改重送或取消；修改重送一律回到「待主管審核」。
• 重開方式包含不重開、待開與指定日期；「當月重開」仍存在於資料模型，但目前操作介面不提供選擇。
• 重開發票沿用原發票金額，預計日期使用會計填寫的實際重開日。

權限與可見範圍

能力	主要權限與範圍
一般發票	「一般發票管理」控制清單查看與編輯
掛帳發票	「掛帳發票管理」控制清單查看、匯入、編輯、回補及刪除
異動申請	「發票異動管理」控制建立、查看、修改與取消；一般申請人清單只看自己建立的申請
主管審核	「發票異動主管審核」；待審清單依主管可讀的審核群組成員篩選
會計執行／審核	「發票異動會計審核」控制會計待辦、執行確認與最後審核
發票檔案下載	除發票權限外，部分訂單、合約與主管查看權限也可下載一般發票

具有異動主管權限的人員，在一般異動申請清單可看全部申請，不只自己的資料。

4. 狀態與例外

狀態說明

開票與付款狀態的名稱已自我說明，以下只列需要額外解釋的狀態。

維度	狀態	意義
開票	「已作廢」	原發票已作廢，不再由一般編輯更新
折讓	「部分折讓」	原發票仍有剩餘可折讓金額
折讓	「全額折讓」	原發票已全額抵銷；是否重開由申請內容決定
異動	「待會計執行」	主管已通過，等待會計在外部平台處理
異動	「待會計確認」	平台處理完成，等待會計確認證明與結果
異動	「已完成」	已回寫作廢、折讓及重開結果

常見阻擋與例外

情況	系統處理
一般訂單尚未正式歸檔	發票資料仍存在於訂單，但不進一般發票清單
發票號碼格式錯誤	拒絕更新
掛帳平台、帳號不存在或組合不符	整批匯入失敗並列出錯誤列
掛帳來源訂單未歸檔	拒絕匯入
平台、帳號與月份重複	拒絕匯入重複資料
掛帳發票已建立回補訂單	不允許刪除
發票已付款	不提供作廢或折讓選擇
已超過次月 5 日	不提供作廢，只能評估折讓
已部分折讓	不允許作廢
已全部折讓	不再提供新的折讓申請
折讓金額超過剩餘額度	表單阻擋送出
異動申請不是退回狀態	不允許申請人修改
主管或會計在錯誤狀態審核	後端拒絕操作
一般發票沒有上傳檔案	不允許寄送通知

5. 上下游與未確認事項

上下游影響

對象	與發票模組的關係
客戶模組	提供目前客戶抬頭、統編、聯絡資料與收款條件
訂單與合約模組	提供一般訂單歸檔事件、期數、預計日期與金額，以及掛帳／LINE OA 合約來源；接收發票異動前置完成通知及回補結果
掛帳帳戶與服務	提供可匯入的平台、帳號及其已歸檔訂單
工單與執行模組	唯讀顯示發票號碼、開立、付款期限、付款與異動證明
採購與請款模組	保存支出端發票附件並追蹤付款；與本模組的收入端發票資料分離
系統設定與權限模組	提供財務、異動申請、主管審核群組與會計審核權限
檔案與郵件	保存發票及異動證明，通知業務、Project AE 與會計
退佣／財務報表	讀取開票、折讓與付款結果；不擁有發票狀態

待確認

1. 收款條件是否應鎖定：既有發票的付款期限與每日逾期判定會套用客戶主檔目前的收款條件；需決定客戶條件變更後應沿用開票時快照，還是回溯重算。同時，兩種條件的名稱都與實作有落差：「次月付款」實作成「實際開立日加天數」，不是「發票次月」；「上線前付款」的付款期限等於實際開立日，等於開票當日即到期。需確認兩者是否符合對客戶承諾的業務語意（法務在授信審核時選定這兩個條件，見法務模組）。
2. 異動流程的後端防線：操作介面要求可選發票、折讓額度、證明、重開日期與寄信條件，但建立申請與會計通過的後端未完整重驗；甚至會計可從「待會計執行」直接完成審核。需決定哪些條件必須成為不可繞過的後端規則。
3. 進行中異動的定義：可選發票目前排除「待主管審核」、「待會計確認」，但未排除「待會計執行」，可能讓會計執行中的同一張發票再次被申請。
4. 取消狀態的保存方式：資料模型有「已取消」，但取消實作是把申請與明細軟刪除，因此清單不會保留已取消紀錄；需確認稽核上應保留可見終態還是視為刪除。
5. 全額折讓後重開金額：重開資料固定沿用原發票全額；若原發票曾部分折讓，之後再把剩餘額全額折讓，重開金額是否應為原額、剩餘額或人工指定，需明確決定。
6. 掛帳發票的鎖定門檻：目前已開立或已付款的掛帳發票仍可修改費用、日期或刪除（只要尚未回補）；需確認應在哪個狀態鎖定哪些欄位。
7. 檔案端點權限：發票異動的共用上傳與下載端點未見與其他操作一致的權限限制，需確認預期可使用角色。

附錄：技術對照（供開發）

中文業務用語	程式識別字	類型
尚未開立	NotIssued	開票狀態
已開立	Issued	開票狀態
已作廢	Voided	開票狀態
未入帳	NotPaid	付款狀態
已逾期	OverDue	付款狀態
已入帳	Paid	付款狀態
部分折讓	PartiallyCredited	折讓狀態
全額折讓	FullyCredited	折讓狀態
待主管審核	ManagerReview	異動狀態
主管退回	ManagerRejected	異動狀態
待會計執行	FinanceExecution	異動狀態
待會計確認	FinanceReview	異動狀態
會計退回	FinanceRejected	異動狀態
已完成	Completed	異動狀態
已取消	Cancelled	異動狀態
次月付款	NextMonth	收款條件
上線前付款	BeforeGoLive	收款條件
當月重開	SameMonth	重開方式
原發票關聯	ParentInvoiceId	發票欄位
一般發票管理	Common_Invoice	功能權限
掛帳發票管理	OnAcct_Invoice	功能權限
發票異動管理	Invoice_Adjustment_Mgmt	功能權限
發票異動主管審核	Invoice_Adjustment_Manager_Perm	功能權限
發票異動會計審核	Invoice_Adjustment_Finance_Review	功能權限