保健品線上經銷平台
開發提案與報價

我們把這份規格書讀成一句話：總部只供貨，N 家獨立法人的經銷商各自收款、各自開票，貨卻從中央倉直送消費者。它不是一個電商網站，是一套帳務系統長出了電商前台。

這個判讀決定了預算怎麼花。全平台高峰每日不到 500 張訂單，效能不是問題；預算要放在三件事——額度帳務的正確性、租戶之間的隔離、以及讓招商頁看起來像一個連鎖集團。我們據此把 Phase 1 切成「上線核心範圍」（固定總價）與「上線後 30 天補齊」（另計），讓 11 月上線成為可以承諾的目標，而不是一個希望。

規格書裡有兩處會直接改變系統設計的地方——額度扣抵時點在模組 4 與模組 7 的描述不一致、50 萬預付貨款的開票時點涉及稅務認定——我們在第八節給出預設做法，請於簽約前定案。

規格書的每一個模組都可以回推到同一個結構。同一張訂單上有四條線各走各的路：金流從消費者到經銷商、再從經銷商到總部；票流反向各開一張；額度在總部帳上被預留、扣抵；貨流則完全跳過經銷商。系統的工作，是讓這四條線在正確的時點對上。

規模判讀：小流量、高正確性

1,000 站 × 每站每月約 10 單 ≈ 每月 1 萬張訂單、每日 330 單。這個量任何一台中階資料庫都撐得住，我們不會把預算花在效能上。真正隨規模放大的是營運動作——每多一家經銷商就多一組特店、一組發票帳號、一次測試交易——所以擴容成本模型（第七節）談的是人力與第三方費用，不是主機。

前台的目標則相反：量不大，但招商轉換率取決於「看起來像不像一個連鎖集團」。品牌主站與子站模板的設計工時我們沒有省，兩個後台則用成熟的管理框架，把設計預算集中在對外的頁面。

下面這張圖是我們對規格書第三節的實作定義：哪個事件觸發哪一筆帳、哪一張發票。規格書模組 4 寫「訂單成立即按批發價扣抵」、模組 7 寫「出貨時開立批發發票並扣抵額度」——我們的預設做法是兩者都對：訂單成立時 hold（可用額度立即減少），出貨時 capture 並開立 B2B 發票，取消時 release。經銷商看到的可用額度即時，總部的批發發票又對得上實際出貨。

這張圖也回答了規格書沒有寫的一件事：退款怎麼辦。付款後、出貨前的取消有乾淨的回滾路徑（退款、release、作廢），Phase 1 內含；出貨後的退貨牽涉部分折讓、逆物流與額度回補的認定，我們列為上線後補齊項目，避免在時程內為一個尚未定義的流程做假設。

規格書第二節列出的三個方針我們全數採納，並各自對應到具體的系統設計。每一項我們也標出「建議你們再確認的一件事」——這些不是技術問題，但會改變技術做法。

一套系統、一個中央商品庫、掛 N 個經銷商前台。

單一資料庫、列級隔離：所有租戶資料表帶 dealer_id，由三道防線確保經銷商永遠只看到自己的資料。路徑式路由 brand.tw/{dealer} 由 Middleware 解析第一段路徑、載入租戶脈絡、注入後續所有查詢與結帳；保留字清單（products、story、franchise、stores、legal…）防止店名撞到主站路徑。

下表即 Phase 1 固定總價的完整範圍，將原文寫入規格書 v2 作為驗收依據。人天以混合日費 NT$ 10,000 計，含工程、設計、PM、QA 之混合成本；金額未稅。

這些項目不影響首批經銷商開業，但會影響營運舒適度。我們建議上線後以變更單一次啟動，時程另訂。

以 9/20 前簽約、10/15 UI 定稿、11/30 上線計，開發視窗約十週。後端（資料模型、多租戶骨架、金流與發票沙盒串接）在 UI 定稿前就開始，前端實作只需六週。關鍵路徑不在程式，在外部帳號：綠界特店審核約 5–10 個工作天、電子發票字軌約兩週，這段時間不在任何一方的鍵盤上。

任一項未達成，目標日順延相同天數，不列違約金。這些前提多數在業主與 CP 手上，我們寫得具體，是為了讓每一方都知道自己的鍵盤上有什麼。

1. 規格書 v2 於 9/20 前定稿並簽約，含第八節前三項之決定。
2. 總部自身的綠界特店與電子發票帳號於 10/15 前開通，供正式環境測試。
3. 至少一家首批經銷商於 11/5 前完成公司設立、綠界特店申請、電子發票字軌申請，作為正式環境驗收對象。
4. 商品圖文、品牌素材、法務頁文案於 10/15 前交付。
5. 二級分銷與稅務結構於 9 月定案，開發期間不變更。
6. 業主於各里程碑五個工作天內完成驗收回覆。

從 100 站到 1,000 站，軟體本身的增量成本是零——新增經銷商只是新增一筆資料。會隨站數成長的是三樣東西：主機規格（兩次小幅升級）、總部的開通人力、以及每家經銷商自己付給第三方的費用。

這三項會改變系統設計，不是細節。每一項我們都給了預設做法——若 v2 沒有另行指定，我們就依預設做法實作並以此驗收。

以下項目影響細節設計與驗收條件；未指定者依括號內預設實作。

1. 零售價是否由總部統一鎖定。技術上影響價格模型；法律上經銷商為獨立法人，總部強制統一零售價涉及公平交易法「限制轉售價格」議題，請律師一併確認。（預設：中央定價、經銷商不可改）
2. 消費者身分與歸屬：訪客結帳或會員制？會員是否跨經銷商共用？在 A 店註冊的消費者到 B 店下單歸誰？是否有「消費者綁定經銷商」規則？（預設：訪客結帳＋Email 識別，歸屬以下單子站為準）
3. 付款方式：ATM 虛擬帳號、超商代碼、分期是否需要；非即時付款需額外處理待付款狀態與逾期取消。（預設：僅信用卡）
4. 發票細節：B2C 載具種類、捐贈、統編；字軌由誰申請；首批經銷商是否已有公司登記。
5. 物流：Phase 1 實際家數；超商取貨走綠界或藍新物流；運費規則與運費在批發價／額度中的計算方式。（預設：運費由消費者支付給經銷商，不進額度）
6. 庫存與效期：缺貨時前台行為；保健品是否需批號與效期管理。（預設：缺貨隱藏購買鈕；不含效期管理）
7. 經銷商開通流程：總部代建或自助；需上傳哪些文件；合約是否線上簽署。（預設：總部代建）
8. 報表與會計整合：總部是否有既有 ERP／會計系統需對接匯出格式。
9. 批發價模型：全體統一或依經銷商分級。（預設：統一）
10. 主機與資料歸屬：雲端帳號由業主持有或我方代管；個資法下消費者資料的存取範圍。（預設：業主持有帳號、我方代管）
11. 模組 10 的定義：下層是否有獨立額度錢包；下層訂單的發票主體。僅影響選配報價。