Photo by Arlind Photography on Unsplash
很多公司的庫存帳，平常都還對得起來，一遇到「調撥」就開始亂。總倉調一批貨給門市、A 廠把材料借給 B 廠、公司倉先把貨送去委外廠加工——這些動作天天在做，單據卻常常只是 LINE 上一句「我先叫車送過去」，加上司機手上那張會被雨淋濕的出貨單。
等到月底盤點，兩邊帳都不對：出庫那端早就把數量扣掉了，收貨那端說「我沒收到這麼多」，中間那幾天貨到底算誰的，沒有人說得出來。最後往往是倉管自己吸收，調整一筆「盤損」結案。
一、調撥是最常見、卻最沒人管的那張單
進貨有採購單、出貨有銷貨單，這兩張單通常都進了系統，因為牽涉到錢。調撥不牽涉外部金流，只是公司內部把貨從甲地搬到乙地，於是很自然就被當成「小事」處理掉了。
但調撥的金額未必小。以零售業來說，門市之間互相調貨補缺，一個月累積起來的金額可能跟一家小門市的月營業額差不多；製造業把半成品送去委外加工，一車料件動輒幾十萬。這些貨在移動的期間，帳上如果沒有位置，等於每個月都有一筆金額在系統裡「暫時消失」。
更麻煩的是責任。貨少了兩箱，是出庫時就沒裝上車、路上掉了、還是收貨端點收漏登？沒有紀錄，就只能靠回憶，而回憶通常會變成互相指責。
二、帳差幾乎都卡在同樣三個斷點
第一個斷點：出庫扣帳、收貨補帳，中間空白。多數公司的做法是出貨那天把來源倉的庫存扣掉，等實體貨到了，收貨端再做一筆入庫。問題是這兩個動作之間可能隔了幾小時，也可能隔了三天。在這段時間裡，系統上這批貨哪裡都不在。老闆這時候問「我們現在到底有多少庫存」，答案就是錯的。
第二個斷點：沒有「在途」這個概念。很多 ERP 其實支援在途庫存，但沒人開來用，因為設定麻煩、而且當初導入時沒人提。於是帳上只有實體倉，沒有「正在路上」的那一塊。
第三個斷點：簽收不留痕。紙本簽收單簽完放在門市抽屜，三個月後要查，找不到；就算找到了，上面也只有一個簽名，看不出實際點收了幾件、有沒有破損、是誰點的。爭議一旦發生，手上沒有任何可以攤開來談的東西。
Photo by Rohit Choudhari on Unsplash
三、一張站得住腳的調撥單，該有哪些欄位
欄位設計不是越多越好，重點是能回答「貨在哪、數量對不對、誰負責」這三個問題。實務上建議至少包含這幾段：
- 申請段：單號、申請人、申請日期、來源倉、目的倉、品號、批號或序號、申請數量、調撥原因（補貨／借料／委外／退回）。
- 出庫段：出庫人、出庫時間、實際出庫數量、運送方式、車號或託運單號、預計到達日。
- 收貨段：收貨人、收貨時間、實際收貨數量、外箱狀況、照片。
- 差異段：差異數量與原因（短少／破損／錯件）、處置方式（補出、報損、向物流索賠）、負責單位、結案日期。
這裡有一個關鍵設計：實際出庫數量和實際收貨數量要分開填，而且不能互相帶入。很多公司的系統會「貼心」地把收貨數量預設成出庫數量，收貨的人只要按確認就好——這等於把唯一能抓出差異的機制自己關掉了。
同樣重要的是結案條件。當出庫數不等於收貨數時，系統應該擋住結案，強迫填寫差異原因與處置方式。擋單這件事一開始會被現場抱怨，但這正是整套系統唯一真正會省到錢的地方。
四、把「在途」獨立成一個虛擬倉
技術上最省力、效果也最直接的一步，是在系統裡開一個虛擬倉，叫它「在途倉」。
出庫確認時，庫存從來源倉移到在途倉；收貨確認時，再從在途倉移到目的倉。實體上什麼都沒變，但帳面上多了一個可以被查詢、被盤點的位置。這樣一來至少有三件事變得可能：
- 任何時間點都問得出「現在有多少貨在路上、分別是哪幾張單」。
- 可以設定逾期清單：出庫超過三天還沒收貨確認的單，自動列出來追。多數短少都是在這張清單上被提早發現的，而不是等到月底。
- 月底盤點有了完整等式：帳面總量＝各實體倉＋在途倉。差異有地方可以追，不會一律歸成盤損。
如果現有 ERP 改不動，也可以先用一張獨立的調撥管理表單系統來承接這段流程，再定期與 ERP 對帳。順序上，先讓流程跑對，再談系統整合，通常比一次到位來得務實。
Photo by Denny Müller on Unsplash
五、簽收搬到手機上，比買一台 PDA 更實際
不少公司以為要做到掃碼簽收，就得先買一批工業型手持裝置。其實對調撥這個情境來說，門市或現場人員用自己的手機開網頁、掃箱外的 QR Code、輸入實收數量、拍一張照片、手指簽個名，三十秒就能完成，速度比填紙本還快。
真正的價值在於時間戳與照片。外箱壓扁、封條破損、棧板翻倒，這些在當下拍一張照，日後向物流商求償時就有依據；沒拍，通常就是自己認賠。
要注意的是，簽收介面如果設計得太複雜，現場就會回去用 LINE。欄位能預設的就預設、能掃的就不要打字、網路不穩時要能先存草稿——這些細節決定這套系統三個月後還有沒有人用。
六、效益怎麼估：用自己的數字代進去
下面是一個示範算法，數字請換成自家的實際狀況，不要直接套用：
假設一家公司每月調撥 200 張單，目前每張單平均要花 12 分鐘在電話追問、翻紙本、事後補帳，一個月就是 40 小時，大約是半個人力。流程上線後若能把每張單的處理時間壓到 5 分鐘，省下的是約 23 小時。
再看損耗。假設每月調撥金額 300 萬元，不明短少率 0.3%，一年約 10.8 萬元。這筆錢不會因為導入系統就歸零——貨該掉還是會掉——但差別在於：有紀錄時，部分可以向物流商索賠，部分可以追到特定站點重新教育，剩下的至少知道發生在哪一段。管理上，「查得出來的損耗」和「查不出來的損耗」是兩回事。
這類系統的開發成本，取決於要不要串 ERP、要不要掃碼、有幾個倉。從一張線上表單加雙邊確認開始做，成本通常遠低於一次性導入完整 WMS，也比較容易在三個月內看出流程有沒有真的改變。
七、建議的導入順序
- 第一階段（約兩週，不必寫程式）：把在途倉開出來，把調撥流程寫成一頁說明：誰能開單、誰能出庫、誰負責收貨確認、差異由誰裁決。先把規則講定，系統才有東西可以實作。
- 第二階段：線上調撥單、出庫與收貨雙邊確認、差異擋結案、逾期未收清單。這一階段就能解掉八成的帳差爭議。
- 第三階段：條碼或 QR 掃描、照片與電子簽名、串接物流託運單號、自動產出月度差異報表與責任歸屬統計。
順序顛倒是常見的失敗原因。先買掃描設備、再來想流程，結果就是硬體閒置在倉庫角落。
結語：先讓貨在帳上有位置
調撥管理聽起來是倉庫的事，實際上是帳的事。只要貨在移動的那段時間在系統裡沒有位置，庫存數字就一定會有一塊說不清楚的差額，而這塊差額會持續侵蝕所有以庫存為基礎的決策——補貨、報價、盤點、甚至年度財報。
如果想從今天開始改善，有三件事不需要等系統：第一，把每月調撥的張數與金額統計出來，先知道規模；第二，在現有 ERP 裡開一個在途倉，哪怕先用人工維護；第三，規定收貨端必須填實收數量，不准直接按確認。這三件事做完，通常就能看出帳差到底集中在哪一段，接下來要不要系統化、要做到什麼程度，也才有依據判斷。