案例重點
通用零售 POS 處理一位客人同一次付款，花店卻要保存三個身份與完整送貨、製作及會計關係。
客戶是一間香港本地花店。付款客戶、送花人與收花人可能完全不同，訂單亦要保存送貨日期、時段、花材、心意卡、聯絡方式及店內製作安排。
項目建立花店專用網頁 POS 與受控整合層，前台讓門市及電話接單同事按真正工作次序操作，Odoo 19 繼續管理 Contacts、Sales Orders、Invoices、Payments、Credit Notes 及 Journals。
唔可以將付款人、送花人與收花人全部當成同一個 Contact。
舊資料包括重複 Customer ID、不同電話格式、舊聯絡人與不完整欄位。直接搬去新介面只會將舊問題一併搬過去。新流程分開三個角色，並用姓名、Customer ID 或已正規化電話搜尋。
選中客戶後，店員可以重用購買紀錄、過往地址、收花人與長期備註。資料更新加入版本檢查，另一位同事已修改時，舊畫面不能直接覆寫新內容。
商品、訂製花束、送貨、改價原因與備註沿同一張訂單保存。
店員可以搜尋 Odoo 商品，加入訂製項目、送貨費、急單費及折扣。任何改價都要記低原因，而 Odoo 原價保持不變。送貨部分包括標準時段、指定時間、地址建議、地區、收花人電話與聯絡失敗安排。
未填完的訂單可以先儲存。必需資料齊全後，同一位置才會變成正式提交。完成後可列印收據、送貨單與執貨文件，送貨文件不會顯示不應交給收花人的付款資料。
付款、取消、Credit Note 與退款保持為可追查的不同動作。
POS 支援未付款、全數付款與訂金。付款方式只能選用後端核准的 Odoo 設定。收到款項後，系統建立正式 Sales Order、已過帳 Invoice 及 Payment，並記錄操作員、參考編號與時間。
取消未付款訂單不會製造退款。已付款訂單則按選項建立 Credit Note，再處理 Customer Credit、現金或銀行退款。銀行退款保留待配對狀態，直至會計人員用真實銀行交易完成 reconciliation。
正式 Invoice、Payment、Credit Note、Journal Entry 及 Reconciliation 仍然由 Odoo 擁有。
固定交易 UUID、防重複提交、Sandbox UAT 同 Odoo readback 一齊驗證。
前端在送出前保存完整待處理訂單，後端用固定 checkout UUID 及 payment UUID 做冪等檢查。網絡逾時、重新整理或重按時，系統查回同一筆結果，而唔係再建立一張訂單。
最近一次完整回歸包括 634 項前端測試、513 項後端測試與 184 項 subtests。瀏覽器流程亦覆蓋客戶搜尋、歷史、草稿、付款、Customer Credit、退款、列印及同步異常。
主要開發與大規模 UAT 已完成，80% 與 60 小時仍然係正式上線前估算。
客戶預期接單、資料查找與日結相關效率提高約 80%，每月減少約 60 小時重複人手工作。功能與 Odoo readback 已經驗證，但正式成效應在 production 使用四至八星期後重新量度。
建議指標包括新客與熟客平均落單時間、每張訂單重複欄位、日結時間、重複訂單、漏填地址、錯配客戶與需要人工修正的同步記錄。
常見問題
點解唔直接使用 Odoo 原生 POS？
客戶要處理付款人、送花人、收花人、長期備註、送貨與花藝要求的特定次序。客製前台改善日常操作，正式銷售及會計資料仍然寫回 Odoo。
網絡逾時會唔會重複落單？
固定交易 ID 與後端冪等檢查會查回原有結果。重複訂單及重複退款亦有獨立保護及測試。
80% 效率提升係咪已經由 production 證實？
未。呢個係 UAT 後的新舊流程估算，文章清楚標示狀態，正式上線四至八星期後應以實際指標更新。
EXPERT AUTOMATION CONSULTATION
你公司都有一條重複、容易出錯嘅流程？
同我哋講現時點做、每月工作量同最常見例外。我哋會先判斷邊一段值得自動化，再提出可驗收嘅第一階段。