一 核心復雜性

負數單并非獨立功能，它必須與正向流程（訂單、認款、開票、結算）形成精準的逆向對稱，牽一發而動全身。

二 關鍵設計模式：

• 事件驅動架構 (EDA)
  是解耦復雜流程、避免“牽一發而動全身”的理想方案。通過“發布-訂閱”模式，讓售后事件觸發后續的負數單生成、財務更新等操作，保持系統靈活性。

• 狀態機與優先級規則：系統必須依賴明確的狀態機（如發票狀態、結算單狀態）和業務規則（如“優先沖銷已開票部分”）來決定行為，確保流程正確

三 棘手場景與解決方案：

1.分批合并處理：負數單需能智能拆分，精準沖銷多批次的正向單據。

2.優先級問題：

• “規則”的優先級（約束性）：明確“已開票部分優先沖銷，未開票部分做占用標記”的優先級規則。

• “選擇”的優先級（策略性）：先進先出 (FIFO) ，比如：先認款的先被賬扣
  
• “規則的優先級”>“選擇的優先級”:“規則的優先級”決定了流程的路徑，“選擇的優先級”決定了路徑上的執行順序。

3.超額處理：系統應堅決攔截而非處理，防止資金損失和財務混亂。

4.“事務級精確追蹤”與“賬戶級靈活核銷”之間的矛盾

• 硬關聯（事務級精確追蹤）：指的是訂單A的付款必須與訂單A的售后退款一一對應。這種關聯是強約束的、精確的、可追溯的。這是系統設計和財務審計的理想基礎。

• 弱關聯（賬戶級靈活核銷）：指的是將供應商視為一個整體賬戶，所有你和該供應商之間的交易（訂單A、訂單B的付款、退款）都計入這個賬戶的余額。系統更關心的是最終余額是否正確，而不是每一分錢是否嚴格一一對應。

系統如何解決這個矛盾？（架構師的思路）
優秀的系統設計不會二選一，而是同時容納這兩種模式，并清晰定義它們的轉換邊界。

a.底層保留“硬關聯”：

• 在事務發生層，依然嚴格記錄最初的“硬關聯”。例如，系統永遠記錄著：付款記錄X 來自 訂單A；負數單Y 來自 訂單A的售后。
• 這是系統數據的“基石”，不可動搖。

b.上層提供“弱關聯”工具：

• 在應付款管理模塊中，提供一個“資金池”視圖，按供應商匯總所有往來賬。
• 提供人工核銷工具，允許財務人員打破原始的“硬關聯”，在池子里進行靈活的沖銷操作（如用訂單A的退款去沖訂單B的應付款）。

c.通過“狀態”進行橋接和沖突管理：

• 當一份試圖維持“硬關聯”的退款單（負數單）發現其對應的資金已被“弱關聯”操作挪用時，它的狀態就被置為 “沖突”或“異常”。
• 這個 “沖突狀態” 就是兩種模式矛盾的集中體現，也是觸發人工介入的信號
  示例：