探索

接下來是新章節的開始，將針對 訂單追蹤表 功能進行說明。om_account_accountant 沒有此功能。

簡單探索「為什麼需要訂單追蹤表」？

主要原因是希望需求單位可以快速了解訂單的情況，但就這個基礎的功能需要蹲好馬步，需要先研究原生關聯，最後發現ODOO的關聯與台灣想要的不太一樣，邏輯如下:

• 台灣軟體: 訂單->出貨->應收
• ODOO: 訂單->出貨 ； 訂單->應收

由上可以看出，國外軟體在出貨明細到應收明細的關聯不見了，那這會造成什麼問題，最直觀的就是對帳不易，尤其當你一張訂單多次出貨時，常常會導致沒有明細報表可以核對，再加上月結多筆情況，那可說是雪上加霜。

架構

依照前述探索的案例，我們的目標是針對訂單追蹤表進行管理，具體架構如下：

• 訂單追蹤表
  • 增加關聯模組：打底工作，讓拋轉的出貨資料存在應收帳款明細中。
  • 出貨進度追蹤：自動計算已出貨數量與出貨單號，追蹤訂單執行進度
  • 應收進度追蹤：自動計算已開票數量與發票號碼，追蹤財務處理進度
  • 完整訂單資訊：整合訂單數量、單價、金額、出貨、開票等完整業務資訊

如上探索遇到的問題，原生其實透過單號，勉強可以進行關聯，但筆者想要更徹底的解決問題，因此寫了一個模組去增加出貨單與應收間的關聯，這也是為了後續成本計算利潤進行鋪路。採購追蹤表為同樣的架構，因此就用實作一起呈現，不特地再用一篇文章進行說明。

實作

此次的案例會實現出不同單據的呈現效果，異動如下：

• S0001 有訂單/有出貨
• S0002 有訂單/有出貨/部分開發票，有部分要請趕快開
• S0003 有訂單/部分出貨
  當有部分出貨，或者是部分開發票時，有一個總表可以追蹤時，異動結果如下：

範例畫面

訂單追蹤表

採購追蹤表

小補充 - 進階開發

當系統存在 按訂單補貨（MTO, Make to Order） 的情境時，理論上可透過補貨組（Replenishment Group）關聯後續單據。
應用在台灣的製造案例中，這類訂單追蹤報表甚至可以擴展給 生產管理（生管） 使用：

• 在報表中加入工單號與生產數量
• 便能清楚追蹤：
  • 哪些訂單尚未生產
  • 哪些訂單已生產完成但尚未出貨

小結

訂單追蹤表的核心價值，在於使用者可以透過此表很快速的追蹤目前單據的情況，過往輔導經驗，很常會有使用者問我有沒有這種報表，筆者都會特別去製作此報表或查詢作業給使用者，很常經過身邊就跟我說他正在用這個報表在追蹤什麼事情，然後就會延伸出不同的細部需求。

此外，補上 Odoo 原生設計中 出貨與應收之間缺少直接關聯 的空白。
對台灣企業來說，這種關聯尤為重要，因為：

• 一張訂單可能多次出貨、多次開票，若無明細對應，對帳將變得複雜且容易出錯。
• 管理單位需要同時掌握「物流進度（出貨）」與「財務進度（開票）」，才能快速反映訂單執行情況。

透過本章的探索與實作，我們讓訂單追蹤表能：

• 一表整合訂單數量、金額、出貨進度、開票進度。
• 在部分出貨、部分開票的情境下，仍能清楚追蹤未完成的差額。
• 為後續的 成本與利潤分析 打好基礎。

總結來說，訂單追蹤表不只是業務單位的工具，也是 銷售、倉庫、財務跨部門協作的重要橋樑，真正落實「單據貫通」的價值。