背景痛點
臺北市政府一樓熊讚商店販售城市紀念品。需求是建一個官方購物網站，但實際上店面也要用同套系統做 POS 結帳，而政府機關團購又需要產出正式報價單。
三個通路（線上 / 店面 / 政府機關）流程都不一樣，但庫存、訂單、發票、會員資訊要共用一個來源 — 不能線上賣完店面還顯示有庫存。
電子發票必須完整符合台灣最新法規：B2C 載具、B2B 統編、捐贈碼、FTP 回傳，缺一不可。
我們怎麼做
Next.js 15 + Prisma + MSSQL Server 2019（沿用客戶既有 DB infra，避免另建一套）。
三介面共用同一套 schema：前台線上購物、店員 POS（觸控友善）、後台管理。
POS 設計成觸控優先：大按鈕、條碼掃描即扣庫存、自動開發票（依結帳設定 B2C/B2B/捐贈）。
報價單流程：政府機關專用，含商品圖片正式格式，可一鍵轉成正式三聯式發票。
後台儀表板：營運報表支援政府人員檢視（不同權限不同範圍）。
寄售分潤結算：一份計算、兩邊共用。 店裡有部分商品是供應商寄售的，每期要跟供應商對帳。系統依約定的結算方式（成交單價乘上分潤比例）自動產出對帳單，列出銷售件數、請款金額、平均結算單價與商品銷售排行，供應商登入後看到的就是後台那一份計算結果，不是另外算一次。
門市自辦的活動折扣不分攤給供應商。 這是寄售實務最容易起爭議的地方 —— 店家為了衝業績自己下的折扣，成本不該由供應商吸收。結算規則把這件事寫死在計算裡，並顯示在對帳單上，雙方一開始就看得到，不必每期解釋一次。
成果
三通路一套系統。電子發票完整符合台灣最新法規。
店面結帳速度大幅提升（條碼掃 → 自動發票 → 結束）。政府機關團購流程從「人工 Excel 報價」變「系統一鍵產出」。
供應商對帳從人工試算變成系統產出，而且雙方看同一份數字 —— 對帳的爭議點從「金額對不對」變成單純的「確認無誤」。