黑水虻回收廠 ERP：從問老闆清單到全系統定案
這篇原本是一份問老闆清單——第一輪需求分析後，把所有假設寫成問題、括號附上我方猜測，準備面談逐條驗證。現在二輪面談結束，清單上的問題全數有了答案，系統逐個定案。這篇跟著長大：記錄問題如何被答案收斂，以及幾個猜錯的地方——猜錯的部分往往才是整案最有價值的認知。
物料流全景（定案版）
收受廢棄物（派車→收料）：廚餘、植物殘渣…黑水虻可分解之物
│
▼ 前處理（分解比例＝系統參數表）
├── 廚餘水（特定比例分離）──→ 發酵 ──→ 液態肥
└── 殘渣 ──→ 破碎 ──→ 儲料
│
▼ 每日餵養黑水虻
▼
加工成產品：蟲乾、凍蟲、肥料…──→ 訂單/出貨
所有系統都掛在「收受 → 前處理 → 儲料 → 餵養 → 加工 → 銷售」這條物料流上。
當初的星號問題，答案怎麼收斂
★ 兩套參數——問「數字是多少」，答案卻是「鏈長不同」。這是整案最核心的修正：原以為申報參數和實際參數只是比例不同，面談後發現計算鏈的長度根本不一樣——申報套用「整包料含廚餘水」的總重一步算到底，算完只進申報報表、到此為止；內部套是兩段式：收料先扣廚餘水變儲料，每天記錄餵了多少儲料，那時才用實際參數算產出、才真正動產品庫存。一條鏈一步、一條鏈兩步，庫存永遠只信內部那條。
★ 參數版本機制——白擔心了。原設計備忘寫著「帶生效版本、推算紀錄冷凍當時參數」，答案簡單得多：輸入即算、結果落地存——參數改了舊紀錄不動（結果本來就存好了）、新紀錄用新參數。不需要任何版本/回溯機制。過度設計在需求訪談前就先寫進備忘，是這次的自我警惕。
★ 多工廠——降級成一個欄位。原假設要做帳號綁廠、廠區切換。定案：單廠開發、schema 帶廠——所有業務表第一天就帶 factoryId，但 UI 按單廠做。未來真擴廠時是加功能，不是改資料。
★ 種蟲提領 20KG 的語意——收料算出的蟲先扣一部分作種蟲、不進庫存，其餘才入帳。文件兩處寫法不一致的謎解開了。
訂單／出貨／退回＝一張訂單的三段狀態。原本當三個系統問，答案是合併：待出貨 →（記日期）已出貨 →（可）退回。帶價邏輯三層：客戶議價 → 產品定價 → 手改。出貨才扣庫存、不足提示不硬擋（現場實貨為準）、退回一律回沖。
幾個乾脆的「不做」：簽核 v1 不做（平台 audit log 留痕頂上）；月結不做（庫存＝當下狀態，隨時手調、調整留痕）；發酵批次 v1 不做（液態肥全走參數推算）；環保局申報凍結（前面完成到一定程度再議，v1 傾向出報表供人工填）；對帳確定要做但細節專題訪談再定——費率規則是工期黑洞，不憑想像寫。
模組切法與分期
從 monorepo 基底複製 _starter 起 apps/bsf，十個 feature module 沿物料流單向依賴（billing → order/intake → inventory → feeding → parameter/customer/product → factory）。分三期：
- 物料流主幹：客戶合約→收料→儲料→餵料→庫存自動算（雙參數）——全案價值核心，取代紙本的人工換算加總
- 營運兩翼：派車（月曆＋印司機收運單）＋訂單/出貨
- 錢與官方：對帳（先專談）＋申報解凍＋報表收尾
單位紀律先立好：庫存內部一律以 kg 為基準存，公噸/公升只在輸入與顯示層換算——否則重演紙本總表人工換算之亂。
方法論的收穫
「假設寫成清單、括號附猜測、面談逐條驗證」這個格式證明有效：老闆說「對」的直接打勾，說「不對」的地方全是金礦——兩套參數的鏈長、參數不需版本、訂單三段狀態，都是被「不對」修出來的。需求訪談的產出不是答案清單，是被推翻的假設清單。