本章目標

本章為一間 30 人的台灣服務業公司建立採購申請 MVP。員工能提出辦公用品、軟體或外包採購，主管依部門與金額核准，財務完成最後審查，所有決策留下不可覆寫的事件。

完成後，系統會具備：

• 草稿、送出、退回、核准、拒絕、下單與驗收狀態。
• 申請人、部門主管、財務與管理者角色。
• 金額門檻與禁止自我核准。
• 私有附件、修訂與重新簽核。
• 可追查的狀態事件與權限驗證。

為什麼這一章重要

許多中小企業用聊天室請主管回一句「OK」，再由行政貼進試算表。這會造成金額或附件改過卻沿用舊核准、主管不在時無人處理、申請人核自己的單，以及事後找不到決策依據。

簽核系統不是把紙本表單搬上網，而是把「誰在什麼條件下能做哪個狀態轉換」寫成資料層規則。

思考模型：狀態轉換就是權限邊界

本案例採用：

draft -> submitted -> manager_approved -> finance_approved -> ordered -> received
             |               |
             +-> changes_requested
             +-> rejected
             +-> cancelled

低於公司門檻的申請可在主管核准後直接進入 finance_approved 或略過財務，但「略過」也要寫事件。送出後若金額、供應商或附件重大修改，建立新 revision 並重新簽核，不直接覆寫核准版本。

開始之前

準備 Lovable Cloud 或 Supabase，建立四個測試帳號：申請人、主管、財務、管理者。金額使用新台幣整數，附件放私有 storage bucket。

我要為 30 人的台灣服務業公司建立採購申請系統，請先規劃不要實作。
角色有申請人、部門主管、財務與管理者。流程包含草稿、送出、退回修改、主管核准、財務核准、拒絕、取消、已下單與已驗收。
主管只能核自己部門，任何人不可核自己的申請。金額門檻決定是否需要財務。
送出後修改金額、供應商或附件要建立 revision 並重新簽核。附件為私有，所有狀態變更要留下不可覆寫事件。
請提出資料模型、狀態轉換表、權限矩陣、並行防護、建置順序與驗收案例。

步驟 1：建立組織與角色

新增：

• departments：名稱、啟用狀態。
• memberships：使用者、部門、角色、有效起訖日、狀態。
• approval_policies：金額下限／上限、需要的角色、版本與生效日。

角色不放在使用者可修改的 profile。主管權限需同時滿足有效 membership、正確部門與申請不是本人。管理者負責組織設定，不代表能跳過所有財務規則。

步驟 2：建立申請與明細

核心資料：

• purchase_requests：申請人、部門、用途、供應商、總額、成本中心、狀態、current revision。
• request_items：品名、數量、單價、稅別與小計。
• request_revisions：版本、送出時的欄位快照與政策版本。
• attachments：request、revision、私有 object path、檔名、類型、大小。
• approval_steps：revision、順序、角色、指定核准者、狀態與決策時間。
• request_events：事件、操作者、前後狀態、revision、原因、時間。

後端重新計算明細總額，不能接受前端傳入的最終總額。統一編號只有在供應商或發票流程確實需要時收集。

步驟 3：先完成草稿與送出

申請人能反覆編輯自己的 draft。送出時後端驗證必填欄位、明細、附件規則與目前政策，建立 revision 快照與 approval steps，再把狀態改為 submitted。

請實作採購草稿與 submit_request 後端操作。
申請人只能編輯自己的 draft。送出時從 request_items 重新計算新台幣總額，保存不可變的 revision 快照與當時 approval policy 版本，再產生簽核步驟。
相同 idempotency key 重送只能送出一次。送出後原欄位不可直接覆寫；重大修改必須建立新 revision。
附件使用私有 storage 與短效 signed URL。

圖 28-1：填入 60,000 元軟體採購後，畫面顯示後端預計總額；送出會建立不可變的 revision 1 快照。

步驟 4：用後端狀態轉換核准

建立 decide_approval，輸入 request、revision、decision 與 comment。後端驗證：

1. 目前 revision 仍是有效版本。
2. 目前步驟正輪到該角色。
3. 核准者 membership 有效且部門正確。
4. 核准者不是申請人。
5. 同一步驟尚未決策。

核准、拒絕與退回在同一交易更新 step、request 並建立 event。兩個分頁重複按核准只能成功一次。

圖 28-2：低額採購只需主管，高額採購顯示主管加財務路徑，自我核准控制被停用。

圖 28-3：主管核准 8,000 元申請後，最終狀態與 actor 一起寫入本次操作事件。

步驟 5：處理退回與修訂

changes_requested 必須附原因。申請人建立新 revision，修改完成後重新送出。舊 revision、附件與決策保留唯讀，新政策是否套用由公司明確決定；本案例在重新送出時套用當下政策並記錄新版本。

重大欄位為金額、供應商、品項、附件與成本中心。說明文字的小錯字可以建立 non-material note，但不能偷偷改掉已核准的商業內容。

圖 28-4：重大變更建立 revision 2 並重新簽核；自我核准拒絕、政策版本與附件掃描狀態皆保留。

步驟 6：建立待辦與詳情頁

申請人看自己的申請與目前進度；主管看所屬部門輪到自己的項目；財務看已通過主管且需要財務的項目。詳情頁清楚標示 revision、金額、附件與決策紀錄。

步驟 7：下單與驗收不等於核准

財務核准後，採購或行政將狀態改為 ordered，保存訂購日期、採購單號與必要備註。收到商品或服務後由指定人員標記 received。這兩個操作仍需事件，不能因為已核准就任意刪改。

取消規則取決於是否下單；已下單不能直接取消，應建立取消請求或人工處理。

步驟 8：驗證權限與並行

測試：

1. 申請人看不到同部門其他人的草稿。
2. 主管只能看與核自己部門，且不能核自己的單。
3. 低金額與高金額依政策產生不同步驟。
4. 前端竄改總額不影響後端計算。
5. 同一決策重送只產生一次事件。
6. 送出後修改重大欄位必須新建 revision。
7. 舊 revision 與附件仍可供授權人員查閱。
8. 使用者無法猜路徑下載私有附件。
9. 管理者停權 membership 後立即失去權限。
10. 已完成事件不能從 UI 修改或刪除。

請驗證採購簽核系統。
使用申請人、兩個部門主管、財務與管理者測試跨部門存取、自我核准、金額門檻、前端竄改總額、重複決策、修訂重簽、私有附件和 membership 停權。
逐項列出 request、revision、approval step、event 與實際權限證據。

實作練習

設定 10,000 元以下只需主管、10,000 元以上需主管與財務。建立 8,000 元辦公用品與 60,000 元軟體採購，測試正常核准、自我核准被拒、退回後改價重簽、附件替換與兩個分頁重複核准。

常見錯誤

• 只隱藏核准按鈕： 權限必須在後端與資料層強制。
• 送出後直接覆寫： 核准依據會消失，應建立 revision。
• 管理者可以做所有決策： 管理設定與商業核准應分離。
• 公開附件 URL： 報價單可能有敏感資訊，使用私有儲存與短效連結。
• 刪除事件： 修正應新增補正事件，不改寫歷史。

上線前檢查清單

• [ ] 角色由受保護 membership 管理。
• [ ] 自我核准在後端被拒絕。
• [ ] 金額由後端明細重算。
• [ ] 政策版本保存在 revision。
• [ ] 重大修改會重新簽核。
• [ ] 決策重送只處理一次。
• [ ] 附件為私有並使用短效 URL。
• [ ] 跨部門與跨角色測試通過。
• [ ] 所有決策、下單與驗收都有事件。
• [ ] 停權會立即撤銷存取。

延伸閱讀

• Lovable Cloud
• Lovable security
• Supabase Storage access control
• Supabase Row Level Security

名詞解釋與延伸提問

• Revision（修訂版本）：送出當下的不可變申請快照。
• Approval policy（簽核政策）：依金額、部門等條件決定所需步驟。
• Self-approval（自我核准）：申請人核准自己的申請，通常應禁止。
• Signed URL：有期限、受控制的私有檔案存取網址。

你可以接著問 Lovable：「請依我的部門、金額門檻與代理規則，產生狀態轉換和權限測試。」下一章會加入公司 Google 身分、通知、代理人與 Google Drive 文件核准的選配整合。

嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。

如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：

📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。

📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。

🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。

如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！

🎁 免費送 Lovable 額度給讀者！

我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。

參加方式：

1. 訂閱本系列文章
2. 分享任一篇系列文章
3. 私訊分享截圖及你的 Lovable 帳號 Email

確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！