簡(jiǎn)介GreaterWMS是一套面向企業(yè)倉(cāng)庫(kù)管理場(chǎng)景的開(kāi)源式WMS解決方案脫胎于福特亞太區(qū)售后物流倉(cāng)儲(chǔ)供應(yīng)鏈實(shí)踐后獨(dú)立演進(jìn)為可擴(kuò)展的企業(yè)級(jí)系統(tǒng)。資源提供完整前后端源碼與工程配置覆蓋庫(kù)存控制、庫(kù)位管理、訂單處理、出入庫(kù)管理、退貨處理、條碼掃描等核心業(yè)務(wù)模塊適合企業(yè)應(yīng)用系統(tǒng)開(kāi)發(fā)者、供應(yīng)鏈從業(yè)者以及希望深入理解WMS業(yè)務(wù)邏輯的技術(shù)人員。壓縮包共2000個(gè)文件以JavaScript1529個(gè)、Python179個(gè)、Vue105個(gè)等前端腳本和后端邏輯為主輔以44個(gè)Markdown說(shuō)明文檔、33個(gè)CSS樣式、29個(gè)JSON配置以及C/Java等擴(kuò)展代碼整體約85.15MB目錄結(jié)構(gòu)清晰適合按模塊研讀。目前已有42人學(xué)習(xí)瀏覽借助這份資料可以學(xué)習(xí)真實(shí)WMS的架構(gòu)拆分、接口設(shè)計(jì)、庫(kù)位與批次管理邏輯也能為二次開(kāi)發(fā)或課程設(shè)計(jì)提供可直接參考的代碼基線。1. GreaterWMS 倉(cāng)庫(kù)管理系統(tǒng)一套被售后物流逼出來(lái)的實(shí)戰(zhàn)方案值得照著做GreaterWMS 這套倉(cāng)庫(kù)管理系統(tǒng)的底子來(lái)自某大型汽車(chē)廠商亞太區(qū)的售后物流倉(cāng)儲(chǔ)供應(yīng)鏈流程設(shè)計(jì)它的人最初要解決的不是電商發(fā)貨而是售后件怎么追溯、庫(kù)齡怎么管控、質(zhì)檢區(qū)怎么流轉(zhuǎn)這一連串沒(méi)人愿意碰的臟活。和市面上把入庫(kù)、出庫(kù)、庫(kù)存三張表拼起來(lái)的通用 WMS 不同這套系統(tǒng)把序列號(hào)、批次、質(zhì)檢狀態(tài)、庫(kù)齡預(yù)警當(dāng)成了第一公民從數(shù)據(jù)模型到出庫(kù)策略都按售后倉(cāng)的規(guī)則在走。適合三類(lèi)人正在給自有倉(cāng)庫(kù)選型 WMS 的物流負(fù)責(zé)人想基于開(kāi)源系統(tǒng)做二次開(kāi)發(fā)但被現(xiàn)有框架鎖死的開(kāi)發(fā)者以及剛?cè)胄?、想搞懂倉(cāng)庫(kù)管理系統(tǒng)真實(shí)數(shù)據(jù)流和狀態(tài)機(jī)怎么落地的工程師。接下來(lái)我按它解決了什么問(wèn)題 → 怎么部署跑通 → 核心流程怎么設(shè)計(jì) → 哪些坑最容易翻車(chē) → 值得投入的進(jìn)階方向這條線把這套精簡(jiǎn)化方案講透。2. 售后物流倉(cāng)庫(kù)和電商倉(cāng)的根本區(qū)別先搞懂它在解決哪一類(lèi)問(wèn)題2.1 售后件為什么比新品難管序列號(hào)、批次與追溯鏈電商倉(cāng)管的是SKU × 數(shù)量 × 庫(kù)位售后物流倉(cāng)管的是序列號(hào) × 批次 × 來(lái)源 × 狀態(tài)。同一個(gè)零件從供應(yīng)商進(jìn)來(lái)時(shí)是新品發(fā)給經(jīng)銷(xiāo)商后因?yàn)橘|(zhì)量問(wèn)題退回回到倉(cāng)庫(kù)就變成了待檢品檢測(cè)完可能翻新、報(bào)廢或者退回供應(yīng)商。同一個(gè)序列號(hào)在這些狀態(tài)之間流轉(zhuǎn)每一次流轉(zhuǎn)都必須留痕因?yàn)橐坏┏霈F(xiàn)批次性質(zhì)量問(wèn)題倉(cāng)庫(kù)要在幾小時(shí)內(nèi)圈定這批貨發(fā)給了誰(shuí)、還剩多少在庫(kù)里。這套 WMS 里最核心的設(shè)計(jì)不是庫(kù)存表而是庫(kù)存流水Inventory Transaction。每一筆入庫(kù)、出庫(kù)、移庫(kù)、盤(pán)點(diǎn)差異都對(duì)應(yīng)一條流水庫(kù)存余額只是流水的投影。售后場(chǎng)景下改了庫(kù)存沒(méi)留流水等于沒(méi)改這也是它和很多通用系統(tǒng)最本質(zhì)的分歧點(diǎn)。我見(jiàn)過(guò)不少團(tuán)隊(duì)把流水當(dāng)成可有可無(wú)的審計(jì)功能結(jié)果追溯鏈條一斷問(wèn)題件只能靠人工翻 Excel。2.2 一個(gè)售后 WMS 的最小數(shù)據(jù)模型五張核心表怎么設(shè)計(jì)不看完整表結(jié)構(gòu)只看構(gòu)成追溯鏈的最小集合。這套系統(tǒng)的數(shù)據(jù)模型可以壓縮成五張核心表表職責(zé)關(guān)鍵字段售后場(chǎng)景下的注意點(diǎn)product物料主數(shù)據(jù)sku_code, name, unit, is_serial_tracked必須區(qū)分按序列號(hào)管理和按數(shù)量管理兩類(lèi)物料location庫(kù)位主數(shù)據(jù)location_code, zone, type質(zhì)檢區(qū)、退貨暫存區(qū)、待報(bào)廢區(qū)都是獨(dú)立 zone不能混在架位上lot批次lot_no, product_id, supplier_id, production_date批次號(hào)全局唯一生產(chǎn)日期直接參與庫(kù)齡計(jì)算serial序列號(hào)serial_no, lot_id, status狀態(tài)至少要有在庫(kù)、已出庫(kù)、鎖定、待報(bào)廢四種stock實(shí)時(shí)庫(kù)存product_id, location_id, lot_id, quantity唯一約束由 productlocationlot 組成serial 管理的物料還要加 serial 維度這張表的順序就是你的建庫(kù)順序先有物料和庫(kù)位再有批次接著序列號(hào)掛在批次下最后庫(kù)存永遠(yuǎn)指到某個(gè)庫(kù)位、某個(gè)批次、某個(gè)序列號(hào)。實(shí)際開(kāi)發(fā)時(shí)常見(jiàn)錯(cuò)誤的順序是先建庫(kù)存表再補(bǔ)批次導(dǎo)致無(wú)數(shù)歷史單據(jù)沒(méi)法回填批次追溯鏈從第一天就斷了。2.3 售后物流最看重的能力清單選型或自研前先對(duì)著打分在汽車(chē)售后倉(cāng)里下面這些能力每一項(xiàng)都是硬需求缺一個(gè)都會(huì)在后期用人工來(lái)補(bǔ)序列號(hào)級(jí)追溯從整車(chē)召回反查到零件序列號(hào)、批次、供應(yīng)商、入庫(kù)日期、出庫(kù)去向。庫(kù)齡預(yù)警與先進(jìn)先出超過(guò) 90 天、180 天、365 天的庫(kù)存自動(dòng)亮燈出庫(kù)時(shí)強(qiáng)制按庫(kù)齡升序分配。質(zhì)檢狀態(tài)機(jī)待檢、合格、不合格、待報(bào)廢四個(gè)狀態(tài)狀態(tài)切換必須走流程不能直接改庫(kù)存。多包裝單位同一個(gè) SKU 要同時(shí)支持按件、按箱、按托出入庫(kù)且換算關(guān)系可配置。移庫(kù)與盤(pán)點(diǎn)差異流盤(pán)點(diǎn)差異不是改一下數(shù)量而是生成盤(pán)盈、盤(pán)虧單據(jù)和財(cái)務(wù)流程聯(lián)動(dòng)。拿這套清單去對(duì)照市面上的通用 WMS你會(huì)發(fā)現(xiàn)很多系統(tǒng)在庫(kù)存管理上很強(qiáng)但序列號(hào)追溯和庫(kù)齡預(yù)警往往做成有但是個(gè)擺設(shè)。這套系統(tǒng)把這兩項(xiàng)從輔助功能提到了主流程這是它值得借鑒的地方。3. 用 Docker Compose 把整套 WMS 跑起來(lái)從零到掃碼收貨3.1 部署前的環(huán)境準(zhǔn)備與目錄規(guī)劃常見(jiàn)做法是把三個(gè)服務(wù)拆開(kāi)PostgreSQL 存業(yè)務(wù)數(shù)據(jù)、后端 API 處理業(yè)務(wù)邏輯、前端負(fù)責(zé)操作界面。我一般建議至少給這套系統(tǒng)準(zhǔn)備一臺(tái) 4 核 8G 的服務(wù)器磁盤(pán)根據(jù)庫(kù)存流水量估算建議預(yù)留 100G 起步因?yàn)閹?kù)存流水表膨脹速度比想象中快得多。目錄規(guī)劃上不要把所有東西堆在/opt下亂放按下面的結(jié)構(gòu)組織/opt/wms/ ├── backend/ # 后端項(xiàng)目的 Dockerfile 與代碼掛載 ├── frontend/ # 前端靜態(tài)文件與 Nginx 配置 ├── postgres/ # 數(shù)據(jù)庫(kù)數(shù)據(jù)目錄用命名卷或 bind mount 都行 └── deploy/ ├── docker-compose.yml └── .env.env里放環(huán)境差異比如端口、數(shù)據(jù)庫(kù)密碼、時(shí)區(qū)。不要在任何源碼文件里硬編碼數(shù)據(jù)庫(kù)密碼這是我見(jiàn)過(guò)最普遍的安全翻車(chē)點(diǎn)尤其是這套系統(tǒng)的代碼常被拿到內(nèi)網(wǎng)之外演示密碼一旦打成明文等于把整個(gè)倉(cāng)庫(kù)的數(shù)據(jù)權(quán)限送出去。3.2 編寫(xiě) docker-compose.yml三個(gè)服務(wù)的最小可跑配置后端我用 Django 風(fēng)格的配置來(lái)舉例因?yàn)檫@套 WMS 的后端思路是典型的 Python 業(yè)務(wù)框架ORM 管數(shù)據(jù)模型、遷移管表結(jié)構(gòu)、API 管前端交互。下面是完整的最小編排文件version: 3.8 services: db: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_DB: wms POSTGRES_USER: wms_user POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U wms_user] interval: 10s timeout: 5s retries: 5 backend: build: ../backend restart: unless-stopped depends_on: db: condition: service_healthy environment: DB_HOST: db DB_PORT: 5432 DB_NAME: wms DB_USER: wms_user DB_PASSWORD: ${DB_PASSWORD} TZ: Asia/Shanghai volumes: - ../backend:/app ports: - 8000:8000 frontend: build: ../frontend restart: unless-stopped depends_on: - backend ports: - 80:80 volumes: - ../frontend/nginx.conf:/etc/nginx/conf.d/default.conf:ro volumes: postgres_data:這里db服務(wù)顯式加了健康檢查backend用depends_on.condition: service_healthy等數(shù)據(jù)庫(kù)就緒再啟動(dòng)。不這么配置的話前三次啟動(dòng)大概率出現(xiàn)后端連不上數(shù)據(jù)庫(kù)直接崩潰退出這是容器編排里最經(jīng)典的玄學(xué)問(wèn)題本質(zhì)不是玄學(xué)是啟動(dòng)順序沒(méi)控制。TZ: Asia/Shanghai一定要設(shè)不然庫(kù)齡預(yù)警按 UTC 算時(shí)間儲(chǔ)存在日期邊界上會(huì)整體差 8 小時(shí)庫(kù)存賬面上整天差出庫(kù)齡滿 90 天的判斷偏差。3.3 首次啟動(dòng)與初始化創(chuàng)建管理員、初始化基礎(chǔ)數(shù)據(jù)配置文件就位后需要做一次完整的初始化。以下是我每次部署都會(huì)走的命令序列cd /opt/wms/deploy # 1. 首次構(gòu)建鏡像拉依賴(lài)會(huì)比較慢建議設(shè)好代理或提前構(gòu)建緩存 docker compose up -d --build # 2. 確認(rèn)三個(gè)服務(wù)的狀態(tài) docker compose ps # 3. 初始化數(shù)據(jù)庫(kù)表結(jié)構(gòu)這個(gè)命令只在第一次運(yùn)行時(shí)執(zhí)行 docker compose exec backend python manage.py migrate # 4. 創(chuàng)建超級(jí)管理員 docker compose exec backend python manage.py createsuperuser # 5. 初始化基礎(chǔ)數(shù)據(jù)倉(cāng)庫(kù)、庫(kù)區(qū)、默認(rèn)庫(kù)位 docker compose exec backend python manage.py init_demo_datamigrate執(zhí)行的是建表語(yǔ)句會(huì)按數(shù)據(jù)模型的遷移歷史把所有表建出來(lái)之后代碼里改模型也會(huì)生成新的遷移文件這個(gè)命令要反復(fù)跑。createsuperuser創(chuàng)建管理后臺(tái)的登錄賬號(hào)。init_demo_data是我習(xí)慣保留的一個(gè)自定義命令它會(huì)創(chuàng)建默認(rèn)倉(cāng)庫(kù)、幾個(gè)基礎(chǔ)庫(kù)區(qū)收貨區(qū)、質(zhì)檢區(qū)、存儲(chǔ)區(qū)、發(fā)貨區(qū)以及一組演示用的物料和供應(yīng)商。忘記執(zhí)行migrate是最常見(jiàn)的初始化翻車(chē)點(diǎn)后端起來(lái)后任何接口都報(bào)relation does not exist。看到這個(gè)報(bào)錯(cuò)不要懷疑代碼先檢查有沒(méi)有跑遷移。3.4 用命令行模擬一次掃碼收貨驗(yàn)證整條鏈路通不通不急著接 PDA 硬件先用 API 模擬掃碼槍的動(dòng)作。掃碼收貨的業(yè)務(wù)邏輯是拿著收貨單號(hào)找到預(yù)期到貨的明細(xì)掃一個(gè)物料條碼/序列號(hào)校驗(yàn)后把庫(kù)存加到收貨暫存區(qū)。用 curl 模擬如下# 按收貨單號(hào)查詢待收貨明細(xì) curl -X GET \ http://127.0.0.1:8000/api/inbound/order/ASN2024001/details \ -H Authorization: Token 你的_token | python -m json.tool # 提交一次掃碼收貨參數(shù)是明細(xì)ID和掃描到的序列號(hào) curl -X POST \ http://127.0.0.1:8000/api/inbound/receive \ -H Authorization: Token 你的_token \ -H Content-Type: application/json \ -d {detail_id: 101, serial_no: SN202411001001}正常響應(yīng)里會(huì)返回這條序列號(hào)分配到的目標(biāo)庫(kù)位同時(shí)庫(kù)存流水里生成一條收貨記錄。到這一步說(shuō)明數(shù)據(jù)庫(kù)、后端 API、權(quán)限校驗(yàn)、庫(kù)存流轉(zhuǎn)整條鏈路已經(jīng)通了。Authorization: Token是 Django REST Framework 常見(jiàn)的認(rèn)證方式二開(kāi)時(shí)如果換成 JWT把請(qǐng)求頭里的 Token 換成Bearer即可注意別在文檔里把兩者混著寫(xiě)。4. 核心業(yè)務(wù)流程落庫(kù)入庫(kù)、出庫(kù)、盤(pán)點(diǎn)與庫(kù)齡的接口設(shè)計(jì)4.1 收貨到上架的完整狀態(tài)機(jī)四個(gè)狀態(tài)怎么轉(zhuǎn)換售后倉(cāng)的收貨不能直接入儲(chǔ)存位至少要經(jīng)過(guò)收貨、待檢、合格/不合格、上架/隔離這四個(gè)階段。我把這套系統(tǒng)的狀態(tài)機(jī)簡(jiǎn)化成一條鏈待收貨(OPEN) → 已收貨(RECEIVED) → 質(zhì)檢通過(guò)(QUALIFIED) → 已上架(IN_STOCK) ↓ 質(zhì)檢不通過(guò)(REJECTED) → 已隔離(IN_QUARANTINE)實(shí)現(xiàn)上不要用 if-else 到處散落判斷狀態(tài)定義一張狀態(tài)轉(zhuǎn)換表控制合法路徑。后端偽代碼如下# 定義狀態(tài)轉(zhuǎn)換的合法路徑 STATE_FLOW { OPEN: [RECEIVED, CANCELLED], RECEIVED: [QUALIFIED, REJECTED], QUALIFIED: [IN_STOCK], REJECTED: [IN_QUARANTINE, RETURNED], IN_QUARANTINE: [SCRAPPED, RETURNED], IN_STOCK: [ALLOCATED, PICKED], } def transition(record, target_state, operator, **payload): 執(zhí)行狀態(tài)轉(zhuǎn)換不合法直接拋異常合法則寫(xiě)入流水 if target_state not in STATE_FLOW.get(record.state, []): raise IllegalTransition( f當(dāng)前狀態(tài) {record.state} 不能轉(zhuǎn)到 {target_state} ) # 在事務(wù)里更新?tīng)顟B(tài)并寫(xiě)流水 with transaction.atomic(): record.state target_state record.operator operator record.save() InventoryTransaction.objects.create( record_idrecord.id, from_staterecord.state, # 注意這里要先取舊值 to_statetarget_state, operatoroperator, payloadpayload, )注意from_state一定要在賦值給record.state之前取舊值這個(gè) bug 我見(jiàn)人踩過(guò)不止一次先改了狀態(tài)再寫(xiě)流水結(jié)果流水的 from_state 和 to_state 永遠(yuǎn)一樣追溯鏈信息直接失效。狀態(tài)表的另一個(gè)價(jià)值是給每個(gè)狀態(tài)綁定權(quán)限比如只有質(zhì)檢角色能執(zhí)行QUALIFIED轉(zhuǎn)換這個(gè)在后面抗審計(jì)的時(shí)候非常有用。4.2 出庫(kù)波次與揀選策略按庫(kù)齡、批次、序列號(hào)三道過(guò)濾售后出庫(kù)有個(gè)硬性要求先進(jìn)先出按庫(kù)齡走同批次優(yōu)先序列號(hào)精確匹配。波次分配的邏輯就是在這三個(gè)維度上逐層過(guò)濾順序不能反。先按庫(kù)齡升序排再在相同庫(kù)齡內(nèi)按批次聚攏最后按需求里的序列號(hào)清單精確鎖定。我用 Python 代碼描述這個(gè)分配器方便你理解它為什么這樣排順序def allocate_stock(order_lines): 按庫(kù)齡優(yōu)先、批次聚攏、序列號(hào)精確匹配分配庫(kù)存 allocation [] for line in order_lines: # 第1層按庫(kù)齡升序排序庫(kù)齡 現(xiàn)在 - 入庫(kù)時(shí)間 candidates Stock.objects.filter( productline.product, location__zoneSTORAGE, # 只從存儲(chǔ)區(qū)分配 quantity__gt0, ).order_by(inbound_date) # 第2層如果訂單指定了批次直接過(guò)濾批次 if line.lot_no: candidates candidates.filter(lot__lot_noline.lot_no) # 第3層如果訂單指定了序列號(hào)精確匹配 if line.serial_no: candidates candidates.filter(serial__serial_noline.serial_no) for stock in candidates: take min(line.remaining_qty, stock.quantity) allocation.append((stock, take)) line.remaining_qty - take if line.remaining_qty 0: break if line.remaining_qty 0: # 分配不足不等于失敗但要返回缺量原因 raise Shortage(line.line_no, line.remaining_qty) return allocation這段的核心在order_by(inbound_date)它讓庫(kù)齡天然成為第一排序條件。不要嘗試用庫(kù)存表的更新時(shí)間代替入庫(kù)時(shí)間那是兩個(gè)概念混用會(huì)讓庫(kù)齡報(bào)表從第一天就是錯(cuò)的。分配成功的庫(kù)存要立刻標(biāo)記為ALLOCATED狀態(tài)并做預(yù)占預(yù)占數(shù)量單獨(dú)記在庫(kù)存表的allocated_qty字段上可分配數(shù)量是quantity - allocated_qty這樣波次不會(huì)把同一批庫(kù)存分給兩個(gè)訂單。4.3 盤(pán)點(diǎn)差異的閉環(huán)從盤(pán)盈盤(pán)虧到財(cái)務(wù)調(diào)整盤(pán)點(diǎn)模塊最常見(jiàn)的錯(cuò)誤是直接把賬面數(shù)量改成實(shí)盤(pán)數(shù)量這會(huì)讓問(wèn)題線索被抹掉。這套系統(tǒng)的正確處理方式是生成差異單寫(xiě)入流水再用差異單驅(qū)動(dòng)財(cái)務(wù)調(diào)整。盤(pán)點(diǎn)差異生成的接口邏輯我一般這樣寫(xiě)def create_count_diff(zone, count_lines): 生成盤(pán)點(diǎn)差異單不直接改庫(kù)存 diff_lines [] for item in count_lines: book_qty Stock.objects.filter( productitem.product, locationitem.location, ).aggregate(totalSum(quantity))[total] diff item.actual_qty - (book_qty or 0) if diff 0: continue diff_lines.append({ product: item.product, location: item.location, book_qty: book_qty or 0, actual_qty: item.actual_qty, diff: diff, # 正數(shù)盤(pán)盈負(fù)數(shù)盤(pán)虧 }) if not diff_lines: return {created_count: 0} # 生成一張盤(pán)點(diǎn)差異單狀態(tài)為待審核 diff_order CountDiffOrder.objects.create( zonezone, statusPENDING, linesdiff_lines, ) return {created_count: len(diff_lines), order_no: diff_order.order_no}差異單審核通過(guò)后才會(huì)執(zhí)行庫(kù)存調(diào)整。調(diào)整時(shí)正差異走盤(pán)盈流水入賬負(fù)差異走盤(pán)虧流水同時(shí)觸發(fā)財(cái)務(wù)憑證。這套設(shè)計(jì)把盤(pán)點(diǎn)和調(diào)賬分成兩步給財(cái)務(wù)留了審批節(jié)點(diǎn)哪怕是內(nèi)網(wǎng)小團(tuán)隊(duì)我也建議保留這個(gè)審批動(dòng)作因?yàn)楸P(pán)虧單后面是要扣 KPI 的直接改庫(kù)存會(huì)讓責(zé)任追蹤變成一筆爛賬。5. 售后 WMS 最容易翻車(chē)的 6 個(gè)坑從數(shù)據(jù)遷移到并發(fā)扣減5.1 現(xiàn)象庫(kù)存顯示負(fù)數(shù)但系統(tǒng)沒(méi)報(bào)錯(cuò)出庫(kù)單還在繼續(xù)打原因庫(kù)存扣減邏輯沒(méi)有加鎖兩個(gè)并發(fā)請(qǐng)求同時(shí)讀到同一行庫(kù)存為 5各自扣完 3 后都寫(xiě)出 2最終賬面變成 -1。售后倉(cāng)對(duì)負(fù)庫(kù)存容忍度為零因?yàn)樾蛄刑?hào)追溯不允許出現(xiàn)憑空多出的負(fù)數(shù)出庫(kù)。解決扣減庫(kù)存時(shí)必須使用數(shù)據(jù)庫(kù)行鎖并校驗(yàn)扣減后不為負(fù)。不要試圖用 Python 層的標(biāo)志位控制并發(fā)兩個(gè)進(jìn)程之間根本不共享內(nèi)存。with transaction.atomic(): stock Stock.objects.select_for_update().get(pkstock_id) if stock.quantity - stock.allocated_qty need_qty: raise InsufficientStock(f庫(kù)存不足可分配 {stock.quantity - stock.allocated_qty}) stock.quantity - need_qty stock.save()select_for_update()會(huì)把對(duì)應(yīng)行鎖住直到事務(wù)結(jié)束這是解決扣減并發(fā)最通用的做法。代價(jià)是會(huì)阻塞同行的其他事務(wù)所以務(wù)必保證事務(wù)體盡量短不要在鎖里做報(bào)表統(tǒng)計(jì)或調(diào)用外部接口。5.2 現(xiàn)象同一個(gè)序列號(hào)被兩次掃碼入庫(kù)兩張收貨單都顯示成功原因序列號(hào)全局唯一約束只建在序列號(hào)表上但收貨接口沒(méi)有在事務(wù)開(kāi)始時(shí)就檢查序列號(hào)是否已經(jīng)存在導(dǎo)致先到的一單還沒(méi)提交后到的一單在檢查時(shí)沒(méi)看到新記錄雙雙通過(guò)。解決把唯一性檢查合并進(jìn)插入操作本身直接依賴(lài)數(shù)據(jù)庫(kù)唯一索引的沖突報(bào)錯(cuò)而不是先查再插。try: Serial.objects.create( serial_noserial_no, lotlot, productproduct, statusIN_STOCK, ) except IntegrityError: # 捕獲唯一索引沖突返回序列號(hào)重復(fù)請(qǐng)核對(duì)來(lái)源 raise DuplicateSerial(serial_no)這個(gè)現(xiàn)象最隱蔽的地方在于單機(jī)單庫(kù)時(shí)出現(xiàn)的概率很低一旦開(kāi)啟多實(shí)例部署檢查再插的窗口期被放大重復(fù)入庫(kù)基本必然出現(xiàn)。所以我在二開(kāi)時(shí)項(xiàng)目里所有涉及唯一編號(hào)生成的接口一律不做先查后插只依賴(lài)數(shù)據(jù)庫(kù)約束兜底。5.3 現(xiàn)象波次已經(jīng)分配完庫(kù)存揀貨時(shí)發(fā)現(xiàn)庫(kù)存被別人挪走原因波次分配只寫(xiě)了庫(kù)存表的allocated_qty但移庫(kù)、盤(pán)點(diǎn)調(diào)整的代碼沒(méi)有檢查這個(gè)字段。比如一個(gè)庫(kù)存被波次預(yù)占 10 件同時(shí)有人做移庫(kù)把這 10 件挪到了別區(qū)預(yù)占記錄還掛在原庫(kù)存上揀貨時(shí)當(dāng)然找不到貨。解決所有會(huì)改變quantity的操作必須同時(shí)校驗(yàn)allocated_qty挪庫(kù)時(shí)不允許挪走已預(yù)占部分確需挪走要先把預(yù)占釋放重新分配。releaseable stock.quantity - stock.allocated_qty if request_qty releaseable: raise AllocatedLockedError( f當(dāng)前可移庫(kù)數(shù)量為 {releaseable}含預(yù)占庫(kù)存不可移動(dòng) )這個(gè)坑在售后倉(cāng)尤其嚴(yán)重因?yàn)橘|(zhì)檢區(qū)、隔離區(qū)、存儲(chǔ)區(qū)之間的移庫(kù)非常頻繁任何一條移庫(kù)路徑漏掉預(yù)占校驗(yàn)波次完整性就崩了。5.4 現(xiàn)象數(shù)據(jù)遷移完成后盤(pán)點(diǎn)怎么都對(duì)不上差異單滿天飛原因遷移時(shí)只搬了庫(kù)存余額沒(méi)有搬庫(kù)存流水。更嚴(yán)重的是遷移腳本把歷史訂單的收貨完成時(shí)間當(dāng)成了庫(kù)存入庫(kù)時(shí)間導(dǎo)致庫(kù)齡全部錯(cuò)誤。解決遷移順序必須是單據(jù)先于流水流水先于余額。庫(kù)存余額在遷移時(shí)反推生成絕不直接復(fù)制舊表里的數(shù)字。# 遷移邏輯按三階段走 def migrate_wms_data(raw_snapshot): # 階段1遷移物料、庫(kù)位、批次、序列號(hào)主數(shù)據(jù) migrate_master_data(raw_snapshot) # 階段2遷移入庫(kù)單/出庫(kù)單/移庫(kù)單及明細(xì) move_ids migrate_orders(raw_snapshot) # 階段3按單據(jù)流水重放生成庫(kù)存余額 replay_transactions(move_ids)凡是遷移后庫(kù)存賬實(shí)不符的九成都是階段順序錯(cuò)了。寧可在遷移時(shí)多花三天打通單據(jù)流也不要圖省事只搬余額否則后面每個(gè)月盤(pán)點(diǎn)都在還這筆技術(shù)債。5.5 現(xiàn)象前端報(bào)表加載超過(guò) 10 秒數(shù)據(jù)庫(kù) CPU 飆升原因典型的是 N1 查詢和缺索引。前端要顯示一行庫(kù)存記錄后端卻循環(huán)查了 20 次明細(xì)表而庫(kù)存流水表的record_id、created_at沒(méi)有索引按時(shí)間段查流水直接全表掃描。解決報(bào)表接口一律用聚合查詢一次 SQL 出結(jié)果給流水表建組合索引。-- 流水表必備組合索引按時(shí)間范圍查詢和按單據(jù)維表關(guān)聯(lián)同時(shí)覆蓋 CREATE INDEX idx_inv_txn_record_time ON inventory_transaction (record_id, created_at); -- 按倉(cāng)庫(kù)物料庫(kù)位的實(shí)時(shí)庫(kù)存匯總避免逐行暴查 SELECT product_id, location_id, SUM(quantity) AS total_qty, SUM(allocated_qty) AS alloc_qty FROM stock WHERE warehouse_id WH01 GROUP BY product_id, location_id;優(yōu)化之后如果還慢下一個(gè)排查點(diǎn)是序列化層確認(rèn)沒(méi)有在 Python 循環(huán)里逐條訪問(wèn) ORM 的關(guān)聯(lián)屬性。這套系統(tǒng)的報(bào)表慢基本逃不出這三個(gè)原因缺索引、N1、循環(huán)內(nèi)查詢。5.6 現(xiàn)象多倉(cāng)并發(fā)修改同一個(gè)物料主數(shù)據(jù)時(shí)數(shù)據(jù)庫(kù)死鎖原因兩個(gè)事務(wù)各自更新了不同的子表之后又同時(shí)去更新父表鎖的獲取順序不一致導(dǎo)致死鎖。這種問(wèn)題在單倉(cāng)部署時(shí)幾乎不出現(xiàn)一旦做成多倉(cāng)或總部-分倉(cāng)兩級(jí)模式各倉(cāng)同時(shí)改物料主數(shù)據(jù)死鎖就變成高概率事件。解決鎖定主數(shù)據(jù)的順序必須全局一致比如所有事務(wù)都先鎖物料主表再鎖子表且事務(wù)保持短小。BEGIN; -- 所有涉及主數(shù)據(jù)更新的業(yè)務(wù)統(tǒng)一先鎖父行 SELECT * FROM product WHERE id 101 FOR UPDATE; -- 再更新關(guān)聯(lián)子表 UPDATE product_supplier SET is_active 0 WHERE product_id 101; COMMIT;死鎖出現(xiàn)時(shí)數(shù)據(jù)庫(kù)一般會(huì)主動(dòng)犧牲一個(gè)事務(wù)表現(xiàn)為某個(gè)請(qǐng)求突然報(bào)deadlock detected。不要靠重試硬扛要從鎖順序上根治。把先父后子寫(xiě)進(jìn)代碼評(píng)審清單比事后查 pg 日志省事得多。6. 把 WMS 從能用調(diào)到好用三個(gè)值得投入的二次開(kāi)發(fā)方向6.1 對(duì)外暴露冪等 API讓過(guò)賬、訂單同步不再重復(fù)記賬倉(cāng)庫(kù)系統(tǒng)和其他系統(tǒng)對(duì)接時(shí)最痛的點(diǎn)是對(duì)方超時(shí)重試同一個(gè)入庫(kù)單被推了三次。給核心寫(xiě)操作加上冪等鍵是最值錢(qián)的改造。做法是每個(gè)請(qǐng)求頭帶一個(gè)Idempotency-Key服務(wù)端用數(shù)據(jù)庫(kù)唯一約束記錄這個(gè)鍵的處理結(jié)果重復(fù)請(qǐng)求直接返回第一次的結(jié)果不再執(zhí)行扣減。6.2 用 ABC 分類(lèi)重排庫(kù)位把熱銷(xiāo)件和呆滯件分離售后倉(cāng)的庫(kù)位分配經(jīng)?？咳耸止び洝？梢园闯鰩?kù)頻次把物料分成 A、B、C 三類(lèi)A 類(lèi)占出庫(kù)量 80% 的物料放在離揀貨口最近的庫(kù)位C 類(lèi)呆滯件挪到高層或遠(yuǎn)端這個(gè)改動(dòng)不需要改接口只要定期跑一次重排任務(wù)生成的庫(kù)位調(diào)整建議讓倉(cāng)管確認(rèn)后執(zhí)行。庫(kù)內(nèi)行走距離縮短之后揀貨效率的提升會(huì)直接體現(xiàn)在人均單量上這是投入產(chǎn)出比最高的優(yōu)化項(xiàng)。6.3 給庫(kù)齡預(yù)警加一個(gè)低代碼定時(shí)任務(wù)異常庫(kù)存不再無(wú)人管庫(kù)齡超過(guò) 180 天沒(méi)有動(dòng)銷(xiāo)的庫(kù)存在售后倉(cāng)里意味著潛在的呆滯風(fēng)險(xiǎn)。設(shè)計(jì)一個(gè)每天凌晨執(zhí)行的定時(shí)任務(wù)掃描所有在庫(kù)批次把超過(guò)閾值天數(shù)的批次寫(xiě)入預(yù)警表同時(shí)按預(yù)警級(jí)別生成不同的處理任務(wù)90 天觸發(fā)提醒180 天強(qiáng)制要求提交處理意見(jiàn)365 天自動(dòng)封存并停止出庫(kù)分配。這樣庫(kù)齡從報(bào)表指標(biāo)變成了主動(dòng)任務(wù)而不是等人去看報(bào)表才發(fā)現(xiàn)問(wèn)題。做這套系統(tǒng)二開(kāi)時(shí)我吃過(guò)最大的虧就是一開(kāi)始太迷信復(fù)雜設(shè)計(jì)把狀態(tài)機(jī)、權(quán)限模型全部推到極致結(jié)果團(tuán)隊(duì)內(nèi)沒(méi)人跑得動(dòng)。后來(lái)我把精力集中到三件事上庫(kù)存扣減并發(fā)控制、序列號(hào)唯一約束、庫(kù)齡計(jì)算口徑統(tǒng)一。這三件事穩(wěn)住之后其他模塊哪怕糙一點(diǎn)倉(cāng)庫(kù)也能正常運(yùn)轉(zhuǎn)。希望這些經(jīng)驗(yàn)對(duì)你幫到你少走我當(dāng)年繞的彎路。本文還有配套的精品資源點(diǎn)擊獲取