ybuild / 場景

批發經銷商訂單管理系統

批發經銷靠的是在微薄利潤上跑出來的龐大出貨量，而它遵循的那套規則，是零售或電商工具從來不會去假設的：同一個 SKU 賣給每一個客戶的價格都不一樣，訂單是依箱下、而不是依件下，而且幾乎從來不會在第一次出貨時就把整張單出齊。美國的批發商一年的銷售額超過十一兆美元，而這其中的每一美元，都流經因客戶而異的定價、賒銷帳期與分批出貨。本指南將帶你走一遍經銷商真正需要的那套訂單管理系統，以及如何把它當成一個可運行的託管應用程式架在 ybuild 上、透過你自己的網域對外提供服務。

痛點

每一個客戶都有自己談下來的價格。零售收銀機只認一個 SKU 一個價，但你跑的是合約價、量價折扣與客戶分級，所以一行的價格，其實是「誰買、買什麼、買多少、什麼時候買」的函數。
你進貨、存貨、出貨用的是不同的計量單位。一件商品放在貨架上是依「件」，賣出去是依 24 件一箱，走量是依棧板，而一個只存一個數字的系統，根本分不清「訂 3」到底是三件還是三箱。
你很少能把整張單出齊。總有東西缺貨，於是你先把手上有的出出去、剩下的掛缺貨欠交，而一個想當然的系統會假設整張單都能履行，結果不是把庫存多扣了，就是把沒出的需求悄無聲息地丟掉了。
你做的是帳期生意，不是一手交錢一手交貨。客戶依 Net 30 的帳期、在授信額度內付款，你依實際出出去的貨開發票，而一張放行時突破了客戶授信額度的訂單，就是一筆你可能永遠收不回來的錢。

你能打造什麼

客戶檔案與依客戶的價目表

一筆 B2B 客戶記錄，帶著分配給它的價目表或價格分級、付款帳期、授信額度、未結應收餘額、多個送貨地址與一位業務員。當你為這個客戶開始一張訂單時，輸入畫面會自動載入他們的價目表，於是每一行都依他們談下來的價格定價，而不是依標價。從第一次打造起，它就在 ybuild 上即時上線、託管運行。

依箱下單與缺貨欠交的訂單輸入

一個訂單畫面，你可以用任意單位輸入行——依箱或依件——系統用裝箱規格換算成基本單位，執行最小起訂量與整箱起訂規則，核對可承諾數量，把手上有的分配掉，並把任何缺口拆成一條缺貨欠交行，好讓訂單的其餘部分今天就能出貨。

揀貨、包裝、出貨與出貨即開票

一條履行流程，把一張已放行的訂單變成倉庫揀貨單，記錄實際揀出的數量，用裝箱單確認出貨，只從庫存裡扣掉出出去的部分，並依客戶的帳期與一個到期日、針對已出貨數量產生發票——全都在你即時運行的 ybuild 應用程式上完成。

數據模型

customers

公司名稱、price_list_id、價格分級、付款帳期、授信額度、應收餘額、sales_rep_id、送貨地址

products

sku、描述、基本單位、裝箱規格、標價、成本、在手數量、已配置數量、補貨點

price_list_items

price_list_id、sku、單價、最小數量、量價折扣數量、生效日期、失效日期

orders

customer_id、採購單號、下單日期、要求出貨日期、狀態、帳期、訂單明細行(sku、已訂數量、已出數量、欠交數量、單位、單價)

shipments

order_id、出貨日期、裝箱單號、承運商、追蹤單號、發票號、發票金額、到期日

系統裡的一天

早上：一位業務員或一位客戶下了一張訂單。你選中這個客戶，輸入畫面就載入該客戶的價目表，於是每一行都依他們談下來的價格定價，而不是依標價。
你依箱輸入行，「SKU 4247 三箱」，系統用裝箱規格把它換算成件，核對任何最小起訂量與整箱起訂規則，並依他們的合約價顯示這一行的金額小計。
訂單會拿客戶的授信額度與他們未結的應收餘額核對。如果這一單會讓他們超限，訂單就落到授信凍結上，而不是放行到倉庫。
一放行，手上有的庫存就分配到訂單上；缺的那部分自動拆成一條缺貨欠交行，好讓一件缺貨的商品不會把其餘一切都卡住。
倉庫依貨位分組的揀貨單來做事。揀貨員確認數量——可能少於所訂的——任何短揀都回流到缺貨欠交行上。
出貨確認產生裝箱單，只從庫存裡扣掉已出貨數量，並針對實際出出去的貨產生發票，蓋上客戶的帳期與一個到期日。
缺貨欠交的行仍掛在訂單上處於開啟狀態。當補貨採購單到貨時，它們會出現在一張「補出欠交」佇列裡，當成第二次出貨送出、單獨開票。
每天收工時，應收帳齡與未結訂單報表會顯示：誰已經逾期、哪些訂單掛在授信凍結上、以及有多少庫存被佔用、對著即將到來的補貨。

AI 容易出錯的地方

依商品記錄定價，而不是依客戶的價目表定價。在批發裡，價格是客戶、SKU、數量與日期的函數：合約價、分級折扣與促銷全都同時存在。只存一個 SKU 一個價，你就會在不知不覺中對一些客戶多收、對另一些客戶少收，而每一場發票糾紛都能一路追回到這裡。
用單一單位來建模數量。你進貨、存貨、賣貨、出貨用的是不同單位——件、內包裝、箱與棧板。如果資料表結構不存基本單位與裝箱規格、不在兩者之間換算，就會有人下「3」是指三箱、你卻出了三件，或者反過來。
假設整張單都能履行。零售在結帳時就把整張單扣掉；批發是先出一部分、其餘掛缺貨欠交。如果一條訂單行不能把 qty_ordered、qty_shipped、qty_backordered 當成三個獨立的數字來記，缺貨欠交就消失了，你不是把庫存多扣了，就是徹底丟掉了沒出的需求。
依訂單開票，而不是依出貨開票。你該依出出去的貨、而不是依訂的貨開票，否則客戶會為他們從沒收到的缺貨欠交商品被開票。發票必須在出貨確認時、依已出貨數量、連同帳期與到期日一起產生，而不是在訂單輸入時。
跳過授信管控與庫存分配。放行一張遠遠突破客戶授信額度的訂單，或者因為手上庫存沒做分配、把同一批貨同時承諾給兩張訂單，是批發系統悄無聲息虧錢的兩種方式。可承諾量等於在手減去已分配，而授信凍結必須是一個真實的訂單狀態，是倉庫無法據以揀貨的。

✓ 先做這些

定價主幹：把客戶掛到價目表上，以及一個能依該客戶的價目表、用裝箱規格數量解析出每一行價格的訂單畫面。價格錯了，其餘一切都一文不值。
從下單到出貨、帶分批履行：輸入一張訂單，分配在手庫存，把缺口拆成缺貨欠交，出貨確認，並依已出貨數量產生發票。
授信管控：一項授信額度與未結應收的核對，把訂單掛起、而不是放行到倉庫現場。

— 先別做

一套完整的總帳與應付帳款。把發票匯出給你的會計或 QuickBooks，而不是在應用程式裡重新造一套會計系統。
EDI 資料對接與一個客戶自助入口網站。先從你的團隊輸入訂單做起，等核心流程穩固了再加電子下單。
路線規劃、運費比價與倉庫自動化。v1 只做出貨確認與列印裝箱單；把 TMS 與 WMS 整合留到以後。

常見問題

我怎麼給每一個客戶各自的價格？

把每一個客戶都掛到一張價目表或一個價格分級上，並在 price_list_items 裡存下因客戶而異的單價，連同量價折扣。訂單畫面隨後會依客戶的價目表、SKU、數量與日期解析出價格，於是一個合約客戶和一個全新客戶可以訂同一個 SKU，各自看到自己的價格。商品上的標價，只是在沒有任何價目表條目適用時的兜底。

我們依箱賣、依件存貨。這怎麼處理？

每件商品都帶一個基本單位與一個裝箱規格，比方說 24。你可以用任意單位下單與定價，系統會為了庫存換算成基本單位。訂 3 箱會分配 72 件，而最小起訂量與整箱起訂規則在輸入時就被執行，誰也訂不了半箱。

當我沒法把整張單出齊時會怎樣？

這一行會拆開。可用的數量分配掉、現在就出，而缺口變成一條缺貨欠交行，仍掛在訂單上處於開啟狀態。當你的補貨到貨時，它會出現在一張「補出欠交」佇列裡，當成第二次出貨送出、單獨開票，於是你絕不會去承諾你手上實際沒有的貨。

客戶到底什麼時候被開票？

在出貨確認時，針對實際出出去的貨，而不是在訂單輸入時。發票會帶上客戶的付款帳期——比如 Net 30——與一個到期日，並計入他們的應收餘額。缺貨欠交的貨只有在出出去時才開票，所以客戶絕不會為一件還躺在你倉庫裡的東西被開票。

我怎麼阻止給一個還沒付款的客戶出貨？

訂單會拿客戶的授信額度與他們未結的應收餘額核對。一張會讓他們超限的訂單會落到授信凍結上——一個倉庫無法據以揀貨的真實狀態——直到有人複核並放行它。正是這一道核對，把一套真正的批發系統和一個花俏的記單本區分開來。

參考來源

美國人口普查局：2022 年度批發貿易調查 — 官方政府資料顯示，2022 年美國批發商銷售額達 11.3823 兆美元，正是這個應用所服務的經銷通路的體量。
美國勞工統計局：批發貿易（NAICS 42） — 批發貿易產業的官方「產業概覽」（Industry at a Glance）側寫，涵蓋耐久財與非耐久財的批發商。
NetSuite：最小起訂量（MOQ）公式、技巧與好處 — 一份實用指南，講清 MOQ 與整箱數量規則如何運作，以及為什麼它們在經銷生意裡屬於訂單輸入環節。

為你的生意打造這套系統

描述它，一次上線到你自己的網域——託管、全端、免伺服器。免費開始。

免費開始打造 →