🛠️ Odoo 在救援物資管理中的應用：從零開始的數位轉型實踐

引言

當災害來臨，救援物資的調度往往決定了第一線的效率與存亡。花蓮馬太鞍堰塞湖潰壩事件，就是一個震撼的提醒：如何讓物資更快抵達需要的人？如何避免重複送貨或浪費？這些問題看似複雜，其實可以透過數位工具來解決。Odoo 這套來自開源社群的 ERP 系統，正展現了在救援情境中的潛力。它不只是企業的管理軟體，也能成為 NGO、社區組織，甚至小型企業推動數位轉型的實用平台。

本文將以「救援物資」為例，從零開始介紹如何利用 Odoo 建立數位化管理，並進一步探討開發者經驗、客製化技巧，以及數位轉型與永續發展的未來視角。

🛠️ Odoo 救援物資管理學習路徑

Odoo 的基礎起點：救援物資的進銷存

在災區，最基本的需求就是知道「有多少物資、在哪裡、要送去哪裡」。Odoo 的 Inventory 模組 就像是一個智慧倉庫：

可以快速登錄礦泉水、毛毯、藥品等項目；

設定保存期限，避免藥品過期；

建立需求單與出庫單，確保物資有序流動。

對沒有技術背景的小團隊而言，Odoo App Studio 提供了「零程式碼」的客製化功能。只需拖拉，就能新增一個「安置點需求單」或「物資配送表」，讓物資資訊即時流通。這樣的設計，讓數位轉型不再只是大企業的專利。

開發者經驗與客製化：從工具到解決方案

然而，救援現場常常有更複雜的需求，例如不同安置點需要不同數量的物資，或需要自動生成配送路線。這時候，開發者的參與就顯得重要。

Python 擴充模組：Odoo 允許開發者利用 Python 撰寫模組，快速建立「配送建議」按鈕，讓系統根據需求自動分配物資。對小團隊來說，這樣的程式碼簡單易懂，學過一點 Python 就能上手。

自動化工作流：可設定規則，當需求單超過一定數量，就自動通知倉庫主管；反之則直接生成出庫單，減少人力耗損。

開源社群模組：Barcode 掃描器、SMS 通知、Helpdesk 需求單等，都能快速導入，讓物資流程更快一步。

這些工具的關鍵在於「能用」，而不是「複雜」。小技巧如：用群組權限限制志工操作範圍，避免誤刪資料；或是設置自動提醒，讓即將過期的物資優先配送，都是現場立刻能派上用場的設計。

策略與未來視角：Odoo 與在地永續

Odoo 的價值不只在操作便利，更在於它帶來的 策略性思考。

1. 數據驅動決策
   救援結束後，透過 Odoo 的報表，可以統計最常缺乏的物資、物流效率、各安置點的需求模式。這些數據能幫助決策者改善下一次的救災流程。

2. 複製營運流程
   如果有新的 NGO 或政府單位加入，只需複製 Odoo 的模組，就能快速擴張。這對於台灣常面臨地震、颱風的現實環境尤其重要。

3. ESG 與永續實踐
   救援物資透明化、本地採購紀錄、使用效率指標，都是 ESG 的重要面向。透過 Odoo，不僅能讓捐助者放心，也能讓社會看見資源被有效利用。

4. 在地整合的未來
   在台灣，若能將 Odoo 與 LINE Bot 結合，讓居民直接用熟悉的工具回報需求、查看配送進度，數位轉型將更貼近人心。

結語

從零開始學 Odoo，其實並不困難。最重要的是找到一個明確的應用場景，像是「救援物資管理」，然後逐步導入：

先用 App Studio 做最基本的登錄；

再用 Python 擴充模組，增加自動化與智能分配；

最後利用報表與數據分析，形成可持續改進的策略。

災害是一場不願面對卻無法避免的考驗。但科技能幫助我們把有限的資源，用在最需要的人身上。Odoo 就像是一個可以隨團隊成長的工具箱，從臨時志工團體到跨縣市的救援網絡，都能找到適合的使用方式。

在數位轉型與 ESG 成為時代潮流的今天，Odoo 提供了一個清晰的訊號：數位化，不再只是大企業的遊戲，而是所有組織——尤其是小團隊——在災害中守護人命的重要武器。

三步驟具體化，用能落地的欄位設計、流程、與可直接複製的樣板（App Studio 介面配置＋Python 模組＋報表/KPI）。你可以先只做第 1 步，跑順了再加第 2 步與第 3 步。

「先收集 → 再分配 → 最後分析」：

1️⃣ 先把資料收集好

用 App Studio 建立「物資表」和「需求單」，就像在 Excel 開兩張表：一張寫「倉庫有什麼」、一張寫「誰需要什麼」。

關鍵在於：資料結構要統一（物資代碼、數量、地點），這樣後續才能計算。
👉 原理：把現場的雜亂資訊，轉成「規格化的資料」放進系統。

2️⃣ 再讓系統自動分配

用 Python 模組，設定「分配規則」：例如藥品先給需求量最大的安置點、水依比例分配。

系統可以：

自動算「分配建議」

自動扣庫存

匯出資料給配送規劃（VRP）算出車子/無人機的最佳路線。
👉 原理：用程式把「人腦的判斷」轉成演算法，減少人工算錯或漏算。

3️⃣ 最後做報表分析

把每日需求、配送、缺口變成 KPI 指標：

配送達成率

缺口率

熱點安置點

用圖表或地圖呈現，讓指揮官一眼看到問題點，並自動生成補貨任務。
👉 原理：數據可視化，不只是救急，而是讓下一次更快、更好。

📌 整個邏輯就是：

1. 把資料變乾淨、統一（規格化） → 才能算。

2. 用程式規則自動分配（自動化） → 才能快。

3. 轉成數據報表（可見化） → 才能改。

這樣一來，Odoo 就能從「電子倉庫」進化成「智慧救援平台」。

救援物資管理：三步驟

Step 1｜用 App Studio 先把資料「登錄起來」

目標：0 程式，1 小時內做出能用的「物資庫存 + 需求單」兩張表，讓志工就能開始登打。

A. 建立模型（Models）

1. 物資主檔 x_rescue_item

• x_code（Char，必填，唯一）— 物資代碼，例如 WATER500
• x_name（Char，必填）— 物資名稱（礦泉水 500ml）
• x_category（Selection：water/blanket/med/food/other）
• x_unit（Char：瓶/件/盒）
• x_expiry_date（Date：有效期限，藥品用）
• x_qty_onhand（Float：現有庫存，預設 0）
• x_location（Many2one: stock.location 或自建 x_site）

2. 需求單 x_rescue_request

• x_request_no（Char，自動命名：REQ/%(year)s/%(seq)s）
• x_site（Char 或 Many2one: x_site）— 需求地點/安置點
• x_need_date（Date）— 需要到達日期
• x_contact（Char）— 聯絡人/電話
• x_state（Selection：draft/approved/delivered/cancel）
• 行明細 One2many：x_lines → x_rescue_request_line
  • x_item（Many2one: x_rescue_item）
  • x_qty（Float：需求數量）
  • x_priority（Selection：high/med/low，預設 med）

B. 視圖與小技巧（App Studio）

• 在 x_rescue_request 清單視圖加入群組欄位：x_site、x_state、x_need_date
• 新增快速動作（Buttons）：
  • 提交審核：把 x_state → approved
  • 標記已配送：把 x_state → delivered
• 驗證規則（Studio → Rule）：
  • 當 x_state = delivered 時，x_need_date 必須有值
  • 行明細 x_qty > 0

C. 條碼掃描（可選）

• 安裝 Barcode 模組，對 x_rescue_item.x_code 賦值，讓志工用手機掃碼入出庫（把掃到的 code 對應到 item）

Step 2｜用 Python 擴充：自動分配 + 自動扣庫 + VRP 匹配欄位

目標：按一下「分配建議」就能把有限庫存分到多張需求單，並自動扣庫。之後你再把結果匯給路線最佳化（VRP）。

A. 最小可用模組骨架

rescue_allocation/ ├─ manifest.py ├─ init.py ├─ models/ │ ├─ init.py │ ├─ rescue_allocation.py └─ security/ └─ ir.model.access.csv

__manifest__.py
python
{
"name": "Rescue Allocation",
"version": "1.0",
"depends": ["base"],
"data": [],
"installable": True
}

models/rescue_allocation.py（核心邏輯：比例分配 + 扣庫）

from odoo import api, fields, models
from collections import defaultdict

class RescueRequest(models.Model):
_name = "x_rescue_request"
_inherit = ["x_rescue_request"] # 若用 Studio 創的模型，採 monkey patch 方式；或改用 _name 一致

suggest_ready = fields.Boolean(string="已產生建議", default=False)

def action_suggest_allocation(self):
    Item = self.env["x_rescue_item"]
    for req in self:
        # 依高→中→低優先度排序
        lines = req.x_lines.sorted(key=lambda l: {"high":0,"med":1,"low":2}[l.x_priority])
        # 聚合各物資需求
        need_map = defaultdict(float)
        for l in lines:
            need_map[l.x_item.id] += l.x_qty

        # 查庫存
        item_map = {i.id:i for i in Item.search([("id","in",list(need_map.keys()))])}

        # 依比例分配（簡化版）
        for l in lines:
            item = item_map.get(l.x_item.id)
            if not item or item.x_qty_onhand <= 0:
                l.x_qty_alloc = 0  # 你可在 Studio 加欄位 x_qty_alloc
                continue
            total_need = need_map[l.x_item.id]
            if total_need <= 0:
                l.x_qty_alloc = 0
                continue
            ratio = l.x_qty / total_need
            alloc = min(item.x_qty_onhand * ratio, l.x_qty)
            l.x_qty_alloc = round(alloc, 2)

        req.suggest_ready = True

def action_confirm_allocation(self):
    Item = self.env["x_rescue_item"]
    for req in self:
        for l in req.x_lines:
            if l.x_qty_alloc and l.x_qty_alloc > 0:
                item = Item.browse(l.x_item.id)
                item.x_qty_onhand = max(0.0, item.x_qty_onhand - l.x_qty_alloc)
    self.write({"x_state": "approved"})

配合欄位：請在 x_rescue_request_line 用 Studio 新增 x_qty_alloc（Float）儲存「建議分配量」，再把兩個 server action 綁定到按鈕：分配建議 → action_suggest_allocation()；確認出庫 → action_confirm_allocation()。

B. 自動化（Server Action / Scheduled Action）

Server Action：「提交審核」後自動呼叫 action_suggest_allocation()

排程：每 15 分鐘跑一次報表快照（供儀表板用）

C. VRP/配送整合（先加欄位，之後可對接外部排程器）

在 x_rescue_request 加欄位：

x_geo_lat, x_geo_lng（Float）— 安置點座標（可用 Google Maps/LINE 定位填）

x_time_window_start, x_time_window_end（Datetime）— 可到貨時間窗

將「已核可 + 有 x_qty_alloc > 0」的行明細匯出 CSV/JSON 給路線規劃服務（或寫簡單的 Google OR-Tools 對接）

Step 3｜報表與數據分析：形成持續改進的策略

目標：把每日營運數據變成「看得懂的圖表＋KPI」，回饋到補貨、招募志工、人力排班。

A. 核心 KPI 與儀表板（Dashboard 小抄）

配送達成率 = 已配送需求量 / 核准需求量

缺口率 = (核准需求量 − 分配量) / 核准需求量

交期達成 = 準時到貨單 / 總到貨單

即將過期物資數（藥品）

熱點安置點（近 24/72 小時需求最高的前 5 名）

建議圖表

堆疊長條：各安置點需求 vs 已分配 vs 已配送

折線：日需求量與日補貨量走勢

地圖：安置點熱度（需求量）＋ 配送狀態（顏色）

B. 快速取數（Pivot / 自訂報表）

在 x_rescue_request_line 建立關聯欄位（related）以便樞紐分析：安置點、日期、物資類別、優先度、需求量、分配量、到貨日

常用樞紐配置：

Rows：x_item.category / x_site

Columns：x_need_date（以週）

Measures：sum(x_qty)、sum(x_qty_alloc)

C. 改進閉環（持續優化）

每日 18:00 自動寄送「KPI 報表」PDF 給指揮官/倉儲主管

針對缺口率 > 20% 的品項，建立再採購任務（自動建立 x_purchase_task 或對接採購模組）

把「熱點安置點」清單發給志工召集（整合 LINE Bot：推訊息＋回覆「我可以支援」→ Odoo 建立 Timesheet/日班）

附：最小 CSV 範例（可用來導入測試）

x_rescue_item.csv

x_code,x_name,x_category,x_unit,x_qty_onhand,x_location
WATER500,礦泉水500ml,water,瓶,12000,倉一
BLANKET01,保暖毛毯,blanket,件,1500,倉二
MEDKIT_A,基本醫療包,med,組,800,倉一

x_rescue_request.csv（主檔）

x_request_no,x_site,x_need_date,x_contact,x_state
REQ/2025/0001,光復國小,2025-09-29,張先生,draft
REQ/2025/0002,馬太鞍教會,2025-09-29,林小姐,draft

x_rescue_request_line.csv（明細）

x_request_no/x_lines/x_item,x_request_no/x_lines/x_qty,x_request_no/x_lines/x_priority
REQ/2025/0001/WATER500,4000,high
REQ/2025/0001/BLANKET01,300,med
REQ/2025/0002/WATER500,2000,med
REQ/2025/0002/MEDKIT_A,120,high

現場小技巧（真能省時間）

欄位預設值：x_priority 預設 med，讓志工少點一次。

清單批次編輯：需求高峰時，用 list view 勾選多筆批次「提交審核」。

即將過期提醒：對 x_expiry_date 加 Automation → 到期前 30 天寄通知、前 7 天轉高優先配送。

權限：志工只可「新增/讀取」，主管可「核准/扣庫」；避免誤扣庫存。

離線備援：低網區域用 Google Sheet 暫收，夜間再匯入 Odoo；欄位名稱與型別保持一致。

一句話總結

先把資料規格化（App Studio），再讓分配自動化（Python/Server Action），最後用儀表板把營運可見化（KPI/地圖）——這就是「救援物資管理」從 0 到成熟的最短路。

Odoo 在救援物資管理的應用整理表