會議摘要 — 鼎新 ERP ×
電商平台整合 設計討論
時長 1:42:23・約 2 人主談（公司方 PM/IT ×
鼎新顧問），其餘為短回應雜音被 diarization 切成多個 Speaker
TL;DR
公司方與鼎新顧問逐項確認 ERP
與電商平台（康德、快電商、蝦皮、momo、門市）整合的流程細節。會中拍板多項設計：進貨/拋單/預錄統一走寄賣轉進貨流程、品號擴充欄位一次開到
10 個預留 6
個未來平台、餘量放快電商、進貨單錯誤改用負數轉播單而非取消重打、MB38
邏輯簡化只抓轉播單數量、倉庫必須實體拆分區域以符合 IPO
規範。時程上 1/1 不可能，至少 2/1 加過年；門市與蝦皮/momo
另議。最關鍵的問題是原始合約其實是以 莫筆克 為串接標的，後續改為
ERP 直接串康德/快電商從未明確簽下，需重新確認合約
baseline。明天（2026-06-09）下午 2 點繼續討論門市。
角色
- Speaker
2：公司方對接窗口（PM/IT），主要決策者；多次援引「老闆認同 IPO
方向」「會計師不放這個」
- Speaker 3：鼎新顧問（任職約 3
年），主導討論與時數評估
- 其餘 Speaker 4 ~ 61 多為簡短應答，diarization
受同性別/短句限制將兩位主談者切碎，不代表真有 61
人
主要決議
流程整合
- 訂單拋單／預錄／寄銷三類庫存不在 ERP
的情境，全部統一走「寄賣轉進貨」邏輯，用銷售量 1:1
認進貨量，避免不同預交日造成庫存暫時負數
[0:11:46–0:12:48]
- 同步產生暫入單入賬（廠商寄銷類商品不算公司成本）
[0:12:48]
- 進貨單單別需設定「不 power 轉撥」選項，避免重複觸發
[0:13:29]
庫存分配與平台
- 訂單依來源（DSP 欄位）拆分康德 vs 超電兩張訂單
[0:15:20]
- 品號擴充欄位開 10 個（目前用 4
個：康德/超電/蝦皮/momo，預留 6 個），多花約 3
萬避免日後每加平台都要重開發+測試
[0:35:30–0:37:15]
- 欄位命名規則：
庫別代號 + 中文名稱（例
001 康德），長度固定，可預留代號待新平台確定
- 小數點抓兩位
- 餘量放快電商（4 平台比例加總若 <
100%）；採購原則仍是進貨量先除好
[0:55:48–0:56:16]
- 進貨單確認時減和檢核：4（10）個平台比例加總必須 =
100，否則無法確認進貨單
[0:56:45]
進貨／轉播逆向處理
- 不允許取消已 power
過的進貨單；改用另開單別、輸入負數走原本 MB38
同一條路徑
[0:31:15–0:32:13][0:42:45]
- 風險：平台是否接受負數庫存 update
待公司端與平台確認
[0:44:00]，否則該方案不可行
- 庫存調撥不走 MB38：人員需在 ERP +
各平台三邊手動確認當下庫存後分別開單
[0:45:19–0:46:48]，不開放系統內部跨平台調撥（IPO
要求 + 反控管濫用）
MB38（庫存上傳平台）
- 簡化計算邏輯：MB38
直接抓「轉播單性質有勾選的轉播單數量」即可，不再重新計算庫存
[0:50:04–0:51:31] — 時數可再減
- 不開「自動上傳」按鈕（顧問擔心誤按；如後續真有需要再開且須卡權限）
[0:52:13–0:54:36]
- 觸發時機：轉播單確認當下自動 call MB38
[0:48:46]
銷貨單 vs 庫存異動單
- 顧問原規劃先收後出情境直接產生結帳單 +
庫存異動單，不開銷貨單；公司方堅持必須產生銷貨單（老闆要看銷售相關報表、需要支援預購
vs 現貨屬性）
[1:14:19–1:15:22]
- 銷貨單需新增「商品屬性」欄位（預購／現貨），讓康德拋過來的訂單可帶屬性入單
[1:14:53–1:15:22]
- 待顧問確認：標準銷售報表能否抓到「庫存異動單性質為銷貨」的資料
[1:16:36–1:17:12]
倉儲規範
- 實體倉庫必須拆分區域/儲位，每個平台獨立
[0:21:09–0:23:35]
- 理由：IPO 規範下會計師不接受系統有切分倉別但實體混放 →
不修系統去配合，要改實際倉庫管理
- 之前倉庫端說空間不足拒絕拆分，現在因 IPO 強制必須改
出貨／訂單模型
- 訂單 → 銷貨單會由先收後出 / 先出後收兩種收款方式驅動
[1:08:10]
- 退貨：消費者在前端平台發起、API 傳回 ERP，不走 ERP
手動打單
[0:16:16–0:17:32]
- 分批出貨 + 貨到付款不允許（會造成發票金額對不上） →
若實務發生需拆兩張訂單
[1:17:27–1:20:11]
- 蝦皮 / momo 後續可能全部改走康德出貨（公司方傾向，但尚未拍板）
[1:02:30–1:04:37]
補貨點作業
- 標準作業以「月為單位 × 平均銷售量」推算補貨量；男裝部曾要求改 0.5
個月（兩週），財務長以「導致囤貨太多」為由駁回
[1:24:06–1:29:51]
- 公司方要求保留個案、帶回內部再評估（近期有人問是否可由
ERP 建議補貨量）
[1:29:54–1:30:42]
合約問題（重要）
- 原始專案合約以 莫筆克 為串接標的：康德 / 快電商串
莫筆克，莫筆克 拋資料回鼎新；現在的「ERP 直接串康德 /
快電商」方向從未明確簽下變更
[1:32:48–1:34:08]
- 套件部分：康德、超電兩個標準站台套件已收費，但 API
是另一個出錢客戶需求順帶開發
[1:34:34–1:35:10]
- 公司端要從業務端調最完整合約版本（顧問端 Google
無業務系統權限）
[1:35:23–1:37:40]
- 中間案子曾因前任顧問離職、整合方向未拍板而暫緩
[1:36:35–1:36:48]
時程
- 康德 ↔︎ ERP 整合（不含蝦皮/momo/門市）：6
個月（甚至可更快）
[1:04:53–1:05:36]
- 門市：3 ~ 4
個月（前提是只拆百貨/街邊兩類；若加會員、點數、優惠複雜度上升則不定）
[1:05:38–1:06:39]
- 公司方原訂 1/1 上線不可能，至少 2/1，但會卡到過年
[1:07:22–1:08:10]
- 次日（2026-06-09）下午 2 點繼續討論門市
風險與待確認
| 平台是否接受負數庫存 update |
公司端待確認 — 影響負數轉播單方案是否可行 |
| 主機效能能否承受訂單 + 銷貨單雙建檔（一日 1000+ 訂單） |
公司端 IT 評估 |
| 是否同時產生訂單與銷貨單（先收後出） |
顧問評估時數回報 |
| 標準銷售報表是否抓得到「庫存異動性質為銷貨」 |
顧問確認 |
| 補貨點個案是否保留 |
公司端內部討論 |
| 蝦皮/momo 是否全部改走康德出貨 |
公司端拍板 |
| 倉庫實體分區 |
公司端執行中（會計師硬性要求） |
| 合約 baseline |
公司端找業務調原始合約 |