進銷存系統開發指南：什麼時候該從試算表與套裝軟體換成客製
「庫存到底還有幾個」這個問題，在不少公司是沒有人敢直接回答的。倉庫說一個數字、業務手上的試算表說另一個、購物網站後台又是第三個。等到客人下單才發現缺貨，只好道歉、取消、退款，然後回頭補記錄。
進銷存系統要解決的，其實不是「把數字記下來」，而是讓分散在不同人、不同工具裡的同一批貨，永遠只有一份可以相信的紀錄。
以下整理從試算表或套裝軟體走向客製開發的判斷訊號、系統該有哪些核心模組、庫存為什麼常常對不起來，以及與電商、POS、電子發票串接時要先想清楚的事。
什麼時候該離開試算表
試算表被詬病，但它其實是很好的起點：免費、彈性、人人會用。真正的問題不是它太陽春，而是它沒有「同時多人異動同一筆資料」的保護機制。
出現下列狀況時，代表工具已經撐不住了：
- 同一個數字有兩個以上的來源：倉庫一份、業務一份、電商後台一份，每週都要有人花時間核對差異。
- 靠檔名管版本：出現「庫存表_最新_0912_確認版」這種檔名，就代表沒有人真的知道哪一份是對的。
- 常常事後補記錄：先出貨再回頭記帳，中間的空窗期任何人查到的數字都是錯的。
- 查不到「是誰、什麼時候、為什麼改的」：盤盈盤虧無法追溯原因，只能整批認列。
- 報表要靠人工整理才做得出來：每個月結帳前有人固定加班貼資料。
這個判斷邏輯跟一般後台系統一樣，訊號是「人工修補的時間持續增加」，而不是規模大小，詳細的判斷方式可以參考內部後台系統開發指南。
套裝進銷存與客製系統的分界
先講結論：流程越接近產業標準，越該用套裝；流程越是你的競爭優勢，越值得客製。
套裝軟體的價值在於它已經替你想過一遍：單據格式、庫存計價方式、報表結構都是多年累積的結果。導入快、有客服、換人也容易交接。
會走向客製，通常是因為下列其中一種情況：
- 作業方式本身就是差異化：例如寄倉代管、組合包裝、代客加工、專案式出貨，這些流程套裝軟體往往只能勉強對應。
- 需要跟既有系統深度綁定：官網、POS、客服工單、生產排程之間要即時同步，而套裝軟體只提供有限的匯出入。
- 同仁已經在「繞過系統」：出現大量體外的試算表、群組訊息、便條紙，代表系統與實際流程脫節，此時繼續加購模組通常解決不了根本問題。
還有一種常被忽略的折衷做法：保留套裝系統當核心帳務，另外客製前端與報表層。例如業務用客製的簡易介面收單，資料再回寫套裝系統；或是把各系統資料集中後另做報表系統與儀表板。這種做法風險低、可以分期，適合不想一次全面換血的公司。
核心模組怎麼拆
不論套裝或客製，一套堪用的進銷存大致由這幾塊組成，理解它們的關係比記名詞更重要。
品項主檔：所有東西的源頭。品號怎麼編、有沒有規格／顏色／尺寸這種變體、單位怎麼換算（箱與個）、有沒有批號或效期。這一塊定義錯，後面全部要重來。
採購與進貨：請購、採購單、到貨驗收、入庫。關鍵在於「採購單」與「實際入庫」要分開記，因為下單數量與實收數量經常不同。
銷售與出貨：報價、訂單、揀貨、出貨、退貨。同樣要區分「已成立訂單」與「已出庫」，中間那段就是預留庫存。
庫存異動與盤點：所有會讓數量改變的事件都要留下一筆紀錄，包含調撥、報廢、盤盈盤虧、樣品領用。這是後面對帳能不能查得清楚的關鍵。
多倉與庫位：有第二個倉庫、寄倉或門市庫存時就需要。一開始只有一倉也建議在資料結構上先預留，之後擴充成本差很多。
報表：庫存餘額、進銷存明細、呆滯品、周轉狀況。報表不是附加功能，而是驗收這套系統有沒有真的解決問題的證據。
為什麼庫存數字會對不起來
導入系統之後庫存還是不準，是很常見的狀況。原因幾乎都落在下面幾類，值得在規劃階段就處理：
帳面庫存與可售庫存混為一談。倉庫裡有一百件，但其中一部分已經被訂單預留、一部分是待驗退貨品、一部分已經包好等貨運來收。這幾種狀態如果全部算成同一個數字，超賣就會反覆發生。系統設計上要明確區分「實體在庫」「可售」「已預留」「在途」。
異動沒有即時記錄。人工補登的空窗期就是誤差的溫床。解法通常不是要求同仁更勤勞，而是讓記錄動作發生在原本就會做的操作裡，例如掃條碼出貨的同時就完成扣帳。
退貨與換貨流程沒設計完整。退回來的東西是良品回架、待檢、還是報廢？誰有權決定？這段流程通常最晚被想到，卻是庫存差異的主要來源之一。
多通路各自扣帳。同一批貨同時掛在自營官網與其他通路上，如果沒有統一的庫存來源，就必然出現兩邊都賣掉同一件的情況。
盤點只做不修。盤出差異卻沒有記錄原因與調整單，下一次還是會遇到同樣的問題。
與電商、POS 與電子發票的串接
進銷存很少獨立存在，它通常是整組系統的中心。串接的難度不在技術，而在先講清楚誰是權威來源。
與電商網站：官網或開店平台下單後，庫存要即時反映。要決定的是庫存由進銷存統一管理再同步出去，還是各平台各自維護、定時回沖。前者較準，但需要穩定的介接；後者簡單，但要接受短時間的落差與超賣風險。相關取捨可以搭配電商網站開發指南一起看。
與門市 POS：門市銷售也會扣庫存，而且常常在網路不穩的環境下運作，需要考慮離線與補傳的處理方式，細節可參考POS 與門市系統開發。
與物流：出貨單要能直接產生宅配或超商取貨單號，並回收配送狀態。狀態回傳的設計會影響客服要不要人工查件，可參考物流串接完整指南。
與電子發票：出貨與開立發票的時機、作廢與折讓怎麼對應退貨、載具資訊怎麼帶，都要在流程中想好，實務細節見台灣電子發票串接指南。
與會計系統：多數公司不會把會計也一起客製，而是約定固定格式的傳票或明細匯出，交給既有的帳務軟體。
每一條串接都是一份需要驗收的契約，介接怎麼談、風險在哪，可以對照系統整合與 API 串接開發指南。
導入順序與舊資料搬遷
想一次到位通常會失敗。比較穩的順序是：
- 先整理品項主檔。品號規則、單位、規格變體先定案。這一步沒做好，後面所有模組都會歪。
- 先上進貨與庫存。讓庫存數字先變得可信，這是所有後續功能的基礎。
- 再上銷貨與出貨。此時庫存已經準確，出貨扣帳才有意義。
- 最後接外部系統。電商、POS、發票、物流一條一條接，每接一條就驗一次庫存是否仍然正確。
資料搬遷的原則是只搬需要的，不搬全部。設想一間有數年交易紀錄的公司要換系統：把所有歷史單據都搬過去，等於把舊系統累積的錯誤一起繼承。比較務實的做法是設定起帳日，只搬主檔與經過實地盤點確認的結存數，歷史資料則保留在舊系統或匯出檔案供查詢。
切換當下建議安排並行期，新舊系統同時記錄一小段時間並每日對照，確認沒有落差再停用舊系統。
常見錯誤與驗收該看什麼
實務上最常見的幾個坑：
- 把系統當成流程本身。系統只會忠實執行你給它的流程；流程本身的模糊之處不會因為上線就消失，反而會被放大。
- 需求只訪談主管，不訪談實際操作的人。倉管與出貨人員知道所有例外狀況，而例外狀況正是系統最容易漏掉的部分。需求怎麼整理可以照軟體需求怎麼寫的結構來。
- 忽略權限設計。誰可以改庫存、誰可以作廢單據、誰可以看成本，這些如果全部開放，追溯就失去意義。
- 沒有安排教育訓練與過渡期。上線初期一定比舊方法慢，沒有預期到這件事的公司往往在第二週就退回試算表。
驗收時不要只看功能有沒有做出來，重點放在庫存狀態能不能被拆開驗：同一批貨在「實體在庫／可售／已預留／在途」四種狀態之間移動時，四個數字有沒有同步變動、加總之後還等不等於實際在架的數量。接著刻意製造例外——部分到貨與超收、退貨要判給良品或待檢、跨倉調撥還在路上、同一天對同一個品項多次異動——每做一次就回頭看報表有沒有跟著動。財務面的月結與帳務對帳是另一層驗收，如果你同時在評估整套系統，那一層的看法在中小企業 ERP 導入指南。驗收的組織方式可以參考軟體驗收怎麼做。
進銷存系統的價值不在於畫面多漂亮，而在於有人問庫存幾個的時候，你能直接回答，而且不用再去核對。做到這件事，後面的報表、成本分析、自動補貨才有基礎。
庫存數字什麼時候才會變得可信，通常要把流程與串接範圍談過一輪才知道。和 NETVANA 聊聊你的專案，我們會先把品項主檔、庫存狀態與外部串接的範圍盤一遍，再談做法與時程——軟體服務沒有固定套餐，一律採詢問報價制。想先了解我們做哪些事、交付什麼，看軟體服務介紹。
延伸閱讀：想先判斷該不該離開試算表，看內部後台系統開發指南；庫存要跟門市同步，先了解POS 與門市系統開發；出貨要開發票，細節在台灣電子發票串接指南；需求文件不知道怎麼下筆，照軟體需求怎麼寫的結構整理。
