API 很強，但不代表第一版就要寫回
鼎新 API 能讓外部系統用較標準的方式取資料，甚至在條件允許時寫回。但寫回牽涉單號、審核、庫存異動與錯誤回復，責任比「只能看」重很多。主管真正急的，常常只是每天少匯一次 Excel、開會看得到欠料與庫存。
因此第一版最穩的定位是：外部網頁看板只讀鼎新資料，進銷存與開單仍回 ERP 原流程。先證明數字對、有人用，再評估要不要做通知或有限寫回。
- 唯讀：風險低、驗收快、現場較敢用
- 寫回：要先釐清權限、單據與失敗重試
- 每日看板：優先正確與更新頻率
- 不要把「有 API」等同「什麼都能自動做」
第一版 API／整合看板建議只做這些
範圍建議鎖在主管每天會問的查詢：庫存可用量、安全庫存、採購未交、欠料影響工單或出貨。畫面用工廠語言，不要做成 ERP 操作複製品。
技術上可走 API、資料庫唯讀，或兩者搭配。重點是欄位口徑要和鼎新原查詢對得上，並顯示資料更新時間，避免大家質疑數字。
- 品號、庫存、可用量、倉別
- 採購未交、預計到料、欠料量
- 影響的工單／訂單（若資料取得到）
- 最後同步時間、查詢條件與匯出
導入前先確認三件事
一是環境與版本：測試區能否先串、正式區權限誰開。二是資料範圍：哪些公司別、倉別、品號要進看板。三是成功標準：例如「生管不再每天匯欠料表」或「早會只看這張板」。
這三件事寫進第一版範圍，比先討論框架與中台架構更重要。API 只是水管，水管通了若沒人天天看，專案仍算失敗。
什麼時候再考慮寫回？
當唯讀看板已穩定使用、欄位口徑沒有爭議，且有明確「外部系統一定要寫回」的流程（例如報工、簡易領料）時，再單獨立案做寫回。
寫回專案要另訂驗收：成功／失敗紀錄、誰可操作、錯帳怎麼查。不要跟第一版看板綁在同一個含糊報價裡。
想把這個痛點做成第一版系統？
可以先從一段流程開始，例如庫存查詢、缺料追蹤、訂單交期、鼎新資料看板或 Excel 轉網頁。範圍先小、驗收先清楚，再逐步擴充。