簡介GreaterWMS倉庫管理系統(tǒng)完整源碼包面向供應(yīng)鏈開發(fā)、企業(yè)應(yīng)用系統(tǒng)研究人員及物流倉儲從業(yè)者。系統(tǒng)源自福特亞太區(qū)售后物流倉儲供應(yīng)鏈流程作者離開福特后將其從內(nèi)部定制方案發(fā)展為獨立項目重點解決庫存精確性、庫位分配、出入庫與訂單處理等效率問題。壓縮包共2000個文件約85.15MB以1529個JavaScript、179個Python、105個Vue組件為主要構(gòu)成輔以CSS、JSON及Markdown文檔覆蓋前端管理界面、后端服務(wù)、數(shù)據(jù)處理邏輯與部署說明目錄結(jié)構(gòu)清晰便于按模塊研讀。目前已有42人學(xué)習(xí)適合通過完整實戰(zhàn)項目理解WMS架構(gòu)學(xué)習(xí)企業(yè)應(yīng)用前后端開發(fā)或參考其從內(nèi)部系統(tǒng)轉(zhuǎn)向商業(yè)產(chǎn)品的設(shè)計思路。內(nèi)容包括庫存控制、條碼掃描、報告生成等可運行實現(xiàn)是結(jié)合真實業(yè)務(wù)場景深入掌握現(xiàn)代倉庫管理軟件的優(yōu)質(zhì)素材。1. GreaterWMS 是什么從汽車售后物流走出來的開源倉庫管理系統(tǒng)倉庫管理系統(tǒng)做久了會發(fā)現(xiàn)一個真相最難的從來不是庫存加減而是批次追溯、逆向退貨和拆零揀貨這三件事。GreaterWMS 正是一套把這三件事按“汽車售后備件”標(biāo)準(zhǔn)做出來的開源倉庫管理系統(tǒng)——它最早承載的是某大型跨國整車廠亞太區(qū)售后物流的完整供應(yīng)鏈流程從備件預(yù)測、入倉上架一直管到經(jīng)銷商訂單下發(fā)和逆向退件。項目作者離開那家整車廠后把這套業(yè)務(wù)邏輯從內(nèi)部系統(tǒng)里抽出來重寫做成了可以獨立部署的開源項目。這套系統(tǒng)適合三類人業(yè)務(wù)上被批次強制追溯逼到墻角的備件倉和醫(yī)藥倉想從 Excel 管理庫存升級到系統(tǒng)化管理的中小電商倉以及需要拿一套完整 WMS 做二次開發(fā)的團(tuán)隊。它把售后物流里那些“一個零件用錯批次就要全部召回”的嚴(yán)謹(jǐn)性帶到了普通倉庫的日常管理里。說到底WMS 不是一個錄入界面的合集而是一套庫存狀態(tài)的業(yè)務(wù)規(guī)則引擎。這篇文章會從業(yè)務(wù)模型、技術(shù)架構(gòu)、部署命令到上線避坑把這條鏈路完整拆給你看。2. 拆解業(yè)務(wù)模型售后件、庫位、批次和波次是怎么在系統(tǒng)里運作的2.1 售后物流和成品物流的差異為什么通用 WMS 容易在這里翻車多數(shù)通用 WMS 是從電商或產(chǎn)線物料場景寫出來的它們的庫存模型通常是“SKU 數(shù)量 貨架”批次只是一個可選的小字段?？墒酆髠浼锪鞯牡讓舆壿嬐耆煌?。汽車售后備件的 SKU 動輒五萬到二十萬遠(yuǎn)比產(chǎn)線物料復(fù)雜單張訂單往往只有三五行的拆零需求卻要求每一件貨都能按批次追溯到出廠時間、供應(yīng)商、質(zhì)檢報告。更麻煩的是逆向物流——經(jīng)銷商退回的舊件、索賠件、維修件不是簡單重新入庫它們要按狀態(tài)分流處理。在售后場景里通用 WMS 通常會在三個地方翻車。第一是批次在揀貨環(huán)節(jié)被抹掉出庫記錄里只剩數(shù)量沒有批號真要召回時根本無從下手第二是逆向退貨直接復(fù)用正向入庫流程導(dǎo)致同一件貨的庫存被重復(fù)累計第三是拆零后原包裝余量找不到存放規(guī)則散件到處亂塞賬實差異越滾越大。GreaterWMS 的庫存模型從一開始就是圍繞“主數(shù)據(jù)分層”和“批次全鏈路”設(shè)計的而不是把批次當(dāng)附加字段。它管的不只是貨在哪里、有多少而是每一批貨從哪個供應(yīng)商來、在哪個庫位、當(dāng)前什么狀態(tài)、能賣給誰。理解這套系統(tǒng)的第一步是接受一個觀念轉(zhuǎn)換WMS 的庫存不是“庫存余額”而是一組帶有狀態(tài)的庫位明細(xì)。每一次收貨、上架、揀貨、出庫、盤點本質(zhì)都是在做“庫位明細(xì)狀態(tài)轉(zhuǎn)移”。你在系統(tǒng)里看到的庫存總數(shù)永遠(yuǎn)是這些明細(xì)的聚合結(jié)果。我見過很多團(tuán)隊在實施時總想跳過明細(xì)直接改總數(shù)最后無一例外倒在賬實不符上。2.2 主數(shù)據(jù)分層貨主、倉庫、庫區(qū)、庫位、批次的關(guān)系GreaterWMS 的主數(shù)據(jù)組織方式可以理解成一棵從上到下的樹。最頂層是貨主Owner用于區(qū)分自營庫存和第三方代管庫存貨主下面掛倉庫Warehouse倉庫下面分庫區(qū)Area庫區(qū)下面再細(xì)到庫位Location。每一層都有自己的編碼規(guī)則而編碼本身承擔(dān)著定位信息。庫位編碼是這套系統(tǒng)里最值得學(xué)習(xí)的細(xì)節(jié)。常見做法是用分段編碼比如CH-A-01-02表示“倉庫 CH、庫區(qū) A存儲區(qū)、貨架 01、層 02”。這種編碼的好處是揀貨路徑能通過字符串排序直接優(yōu)化——系統(tǒng)按庫位編碼排序生成揀貨順序揀貨員沿著貨架走就是最短路徑。如果庫位編碼是隨意編的哪怕系統(tǒng)再先進(jìn)揀貨效率也提不起來。編碼規(guī)則在項目初始化時就要定死半路再改是巨大的災(zāi)難。批次Batch是另一個核心主數(shù)據(jù)。它記錄的是同一供應(yīng)商、同一生產(chǎn)日期、同一質(zhì)量狀態(tài)的貨物集合。系統(tǒng)在收貨時強制要求錄入批次號和到期日期后續(xù)所有庫存移動都綁定批次。對于 ECU、電瓶這類需要單品追溯的貴重件還要啟用序列號Serial Number管理每一件貨都有唯一的身份編碼。下面這張表列出了我在實施時重點關(guān)注的主數(shù)據(jù)表數(shù)據(jù)對象關(guān)鍵字段作用貨主 Owner編碼、名稱、結(jié)算方式區(qū)分庫存歸屬支撐多客戶共倉倉庫 Warehouse編碼、地址、時區(qū)物理倉的邊界庫區(qū) Area編碼、類型區(qū)分收貨區(qū)、存儲區(qū)、揀貨區(qū)、退貨區(qū)、不合格區(qū)庫位 Location編碼、庫區(qū)、容量、狀態(tài)最小存儲單元承載上架策略SKU編碼、名稱、單位、尺寸、重量貨物檔案注意多單位換算批次 Batch批次號、到期日、入庫日、質(zhì)檢狀態(tài)追溯的最小邏輯單元序列號 Serial序列號、SKU、批次、來源單號單件級追溯啟用后揀貨必須掃序列號主數(shù)據(jù)不干凈后面所有流程都是空中樓閣。我在給一家三方云倉做實施時光是庫位編碼就統(tǒng)一了三輪第一輪是客戶歷史編碼里帶特殊字符第二輪是庫位狀態(tài)字段含義不一致第三輪是同一個物理庫位在系統(tǒng)里錄了兩遍。這些都要在初始化階段全部清干凈再開始跑業(yè)務(wù)否則后面每一條庫存記錄都是錯的。2.3 從 ASN 收貨到波次揀貨流程在數(shù)據(jù)上是如何串聯(lián)的業(yè)務(wù)流程從供應(yīng)商預(yù)約送貨開始。倉庫先建 ASN到貨預(yù)報單寫明預(yù)計到達(dá)時間、SKU、數(shù)量、批次信息。收貨員收到實物后按 ASN 核對并生成正式入庫單。這里有個關(guān)鍵參數(shù)是否允許“無 ASN 收貨”。售后物流強烈建議關(guān)閉這個選項因為批次信息在 ASN 里已經(jīng)預(yù)先錄好現(xiàn)場補錄非常容易出錯。收貨完成后進(jìn)入上架環(huán)節(jié)。系統(tǒng)按上架策略推薦庫位常見策略有三條同 SKU 合并到已有庫位減少碎片化按 ABC 分類把高頻揀貨 SKU 放到靠近打包區(qū)的庫位按批次先進(jìn)先出原則將早批次放在可揀貨位、晚批次放入存儲位。這個動作在系統(tǒng)里會產(chǎn)生一條上架任務(wù)PDA 上掃庫位碼和箱碼完成綁定。出庫側(cè)的核心是波次Wave。常見做法是把一段時間內(nèi)的一批訂單合并成一個波次系統(tǒng)按訂單行生成揀貨任務(wù)再按庫位編碼排序輸出揀貨路徑。揀貨員沿路徑一次性把整個波次的貨揀完到復(fù)核區(qū)按訂單二次分揀、掃描校驗、打包出庫。整個過程在數(shù)據(jù)庫里會留下完整的移動記錄庫存從庫位明細(xì)扣減、生成出庫明細(xì)、批次和序列號被鎖定到訂單號上。這套“追蹤鏈路”正是售后追溯的基礎(chǔ)——任何一個出庫件都能反查它來自哪個批次、哪個庫位、哪次收貨。3. 技術(shù)架構(gòu)與數(shù)據(jù)落盤Django 后臺、API 與雙模式前端3.1 技術(shù)棧選型為什么是 Python 和 Django 而不是一堆 Node 服務(wù)倉庫管理系統(tǒng)的本質(zhì)是“業(yè)務(wù)對象多、狀態(tài)流轉(zhuǎn)多、報表查詢多、實時并發(fā)中低”的典型企業(yè)應(yīng)用它的核心訴求是業(yè)務(wù)邏輯清晰、能快速出后臺界面、數(shù)據(jù)和權(quán)限可控。Django 在這類場景里的優(yōu)勢非常明顯自帶 ORM、數(shù)據(jù)庫遷移、Admin 后臺和權(quán)限框架一個團(tuán)隊可以在很短時間內(nèi)把主數(shù)據(jù)管理和單據(jù)流程全部跑起來。相比用 Node/Go 從零搭一套微服務(wù)Django 的開發(fā)效率在中期維護(hù)階段會拉開明顯差距。從分工上看系統(tǒng)拆成前后端兩層。后端是一套 Django 應(yīng)用對外提供 JSON API管理后臺走 Django 自帶的 Admin 界面可以快速處理主數(shù)據(jù)維護(hù)、單據(jù)查詢這類低頻操作一線操作界面則是一套面向移動端的 Web 應(yīng)用專門給掃碼槍、PDA 和手機(jī)瀏覽器用。操作員在 PDA 上打開任務(wù)列表點擊任務(wù)開始掃一個條碼提交一個動作界面簡單到只剩大按鈕和輸入框。這樣設(shè)計是刻意為之的。倉儲現(xiàn)場的硬件條件參差不齊Windows 平板、安卓 PDA、老式掃碼槍都有瀏覽器是最大公約數(shù)。移動端頁面不能依賴復(fù)雜交互和長表單每個動作一個頁面提交后立即返回結(jié)果。管理端則可以做得信息密集因為管理人員是在電腦前用鼠標(biāo)鍵盤操作搜索、篩選、批量修改這些能力都要齊備。3.2 核心數(shù)據(jù)模型庫存表是如何避免余額式設(shè)計的Django 的 ORM 讓建表非常直接但建模思路錯了后面全是坑。最典型的誤區(qū)是把“庫存”建一張簡單的余額表比如sku_id location_id qty每次出入庫直接qty qty n。這種模型在并發(fā)場景下極易出錯且沒有任何歷史鏈路。GreaterWMS 的思路是把庫存拆成“庫存快照”和“庫存移動記錄”兩張核心表。庫存快照表達(dá)“當(dāng)前每個庫位有什么”移動記錄表達(dá)“每一筆變化從哪來到哪去”。我通常會在項目里保持下面這種核心結(jié)構(gòu)class StockBatch(models.Model): # 批次庫存SKU在一個庫位上的批次明細(xì)而不是籠統(tǒng)的庫存余額 sku models.ForeignKey(Sku, on_deletemodels.PROTECT) location models.ForeignKey(Location, on_deletemodels.PROTECT) batch_no models.CharField(max_length64, db_indexTrue) qty models.DecimalField(max_digits15, decimal_places3) locked_qty models.DecimalField(max_digits15, decimal_places3, default0) expire_date models.DateField(nullTrue, blankTrue) # 狀態(tài)待檢/合格/不合格/凍結(jié) status models.CharField(max_length20, db_indexTrue) updated_at models.DateTimeField(auto_nowTrue) class Meta: constraints [ models.UniqueConstraint( fields[sku, location, batch_no, status], nameuniq_stock_batch_sku_location_status, ) ] class StockMove(models.Model): # 移動記錄所有庫存變化都寫一條帶方向、單號、操作人 move_type models.CharField(max_length30) # inbound/outbound/transfer/stocktake ref_no models.CharField(max_length64) # 關(guān)聯(lián)的入庫單/出庫單號 sku models.ForeignKey(Sku, on_deletemodels.PROTECT) from_location models.ForeignKey(Location, nullTrue, on_deletemodels.SET_NULL, related_name) to_location models.ForeignKey(Location, nullTrue, on_deletemodels.SET_NULL, related_name) batch_no models.CharField(max_length64) qty models.DecimalField(max_digits15, decimal_places3) operator models.CharField(max_length64) created_at models.DateTimeField(auto_now_addTrue, db_indexTrue)上面這兩張表配合起來庫存總數(shù)永遠(yuǎn)是StockBatch按 SKU 聚合出來的結(jié)果而不是某一行字段。locked_qty是關(guān)鍵參數(shù)訂單已經(jīng)分配但還沒實際揀貨的數(shù)量要記在上面可用量等于qty - locked_qty。否則銷售看了庫存說有貨揀貨時才發(fā)現(xiàn)被別的訂單鎖定了這種事故在電商促銷期間尤其常見。移動記錄表只插入不更新是財務(wù)審計和批次追溯的數(shù)據(jù)底倉。線上問題排查時只要拿著 SKU 和批次號去查StockMove從最后一次收貨到當(dāng)前庫存的全部路徑都會浮出來。這套設(shè)計不復(fù)雜但把“庫存余額思維”換成“流水思維”之后絕大多數(shù)的對賬問題都能在幾分鐘內(nèi)定位而不是半夜去翻 Excel。3.3 API 與移動端配合掃碼交互里的三個邊界后端 API 采用 REST 風(fēng)格接口認(rèn)證走 JWT操作員在 PDA 上登錄一次Token 到點失效重新登錄。接口設(shè)計上有一條鐵律前端只負(fù)責(zé)掃碼和展示結(jié)果所有業(yè)務(wù)判斷都由后端做。條碼掃進(jìn)來是一串原始字符串后端去解析它到底是 SKU 碼、庫位碼還是批次碼前端不做任何猜測。這樣換個掃碼槍型號或者條碼規(guī)則調(diào)整都只需要改后端不用升級每一臺 PDA。接口需要重點設(shè)計冪等性。掃碼提交是最容易產(chǎn)生重復(fù)請求的場景PDA 網(wǎng)絡(luò)卡頓操作員以為自己沒點中又點了一次兩條一模一樣的收貨請求都到了后端。我一般會在入庫明細(xì)表上做唯一約束接收單號SKU批次號三字段聯(lián)合唯一重復(fù)提交直接返回“該明細(xì)已處理”。這個約束在數(shù)據(jù)庫層面做不依賴前端按鈕防抖。權(quán)限模型用 RBAC角色劃分為收貨員、揀貨員、上架員、倉管員、管理員五類。每個 API 按角色做訪問控制。這里有個細(xì)節(jié)不要把權(quán)限控制得太粗比如讓揀貨員也能做庫存調(diào)整。庫存調(diào)整是止血操作寧可讓倉管員多走兩步路也不能讓一線操作員隨手改庫存否則月底盤點差異永遠(yuǎn)解釋不清。4. 本地跑通最小系統(tǒng)Docker 部署命令與關(guān)鍵參數(shù)4.1 用 Docker Compose 拉一套最小環(huán)境在本地跑通一份代碼永遠(yuǎn)比看文檔學(xué)得快。常見做法是把整個環(huán)境用 Docker Compose 組織成兩個核心服務(wù)web是 Django 應(yīng)用db是 PostgreSQL 數(shù)據(jù)庫。生產(chǎn)環(huán)境再外部掛一層反向代理和對象存儲但本地驗證這套最小配置就足夠了。下面這個 Compose 文件是多數(shù) Django WMS 項目都能直接對上的骨架version: 3.9 services: db: image: postgres:14-alpine environment: POSTGRES_DB: wms POSTGRES_USER: wms POSTGRES_PASSWORD: wms_pass # 參數(shù)說明容器內(nèi)數(shù)據(jù)庫名/用戶名/密碼首次啟動自動建好庫 volumes: - pgdata:/var/lib/postgresql/data ports: - 5432:5432 web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/app # 參數(shù)說明掛載源碼目錄改代碼即生效不用重建鏡像 ports: - 8000:8000 environment: DJANGO_DEBUG: True DB_HOST: db DB_PORT: 5432 DB_NAME: wms DB_USER: wms DB_PASSWORD: wms_pass depends_on: - db volumes: pgdata:數(shù)據(jù)庫連接配置是本地最容易卡住的一步。DB_HOST必須寫db不是localhost因為應(yīng)用容器和數(shù)據(jù)庫容器是兩臺獨立的機(jī)器localhost指向的是 web 容器自己。第一次啟動時如果 web 容器報could not connect to server通常不是密碼錯了而是 db 容器還在初始化等十幾秒后docker compose restart web就行。我一般會在項目的.env文件里把數(shù)據(jù)庫配置和 Django 密鑰拆出來避免把環(huán)境配置寫死在代碼里。調(diào)試階段DJANGO_DEBUG開 True能看到詳細(xì)的報錯堆棧一旦要往測試環(huán)境部署第一件事就是把 Debug 關(guān)掉這也意味著要提前處理靜態(tài)文件后面第 5 章的坑就是從這里長出來的。4.2 初始化數(shù)據(jù)庫與第一個管理員賬號容器起來之后進(jìn)入 web 容器執(zhí)行數(shù)據(jù)遷移和管理員創(chuàng)建這一步是通用的 Django 流程# 進(jìn)入 web 容器注意這里執(zhí)行的是容器內(nèi)的 shell docker compose exec web python manage.py migrate # 生成 Django 后臺必需指令執(zhí)行后按提示輸入用戶名、郵箱、密碼 docker compose exec web python manage.py createsuperuser # 收集靜態(tài)文件到指定目錄為后續(xù)關(guān)閉 Debug 做準(zhǔn)備 docker compose exec web python manage.py collectstatic --noinputmigrate負(fù)責(zé)把項目里所有的數(shù)據(jù)模型映射成數(shù)據(jù)庫表。如果migrate中間報錯說某張表已存在不要慌常見原因是之前跑過一次或者數(shù)據(jù)庫卷沒清干凈執(zhí)行docker compose down -v清掉數(shù)據(jù)卷再重新up就好。createsuperuser創(chuàng)建的是管理員賬號用于登錄 Django Admin 后臺做基礎(chǔ)配置賬號密碼只存在數(shù)據(jù)庫里重建容器也不會丟因為數(shù)據(jù)卷是獨立的。collectstatic這一步容易被人忽略。本地開著默認(rèn)的 App 服務(wù)器時Django 會自動處理靜態(tài)資源你會覺得不執(zhí)行這條命令也能用但一旦切換成生產(chǎn)模式樣式和腳本會全部 404整個后臺變成裸 HTML。所以項目初始化階段就要把它寫進(jìn)部署腳本別等到上線才想起來。4.3 首次登錄后的配置順序登錄系統(tǒng)之后配置順序是有講究的順序錯了后面每步都別扭。正確順序是先配倉庫和庫區(qū)再配庫位然后建貨主和 SKU 檔案最后配供應(yīng)商和客戶。步驟配置項注意事項1倉庫檔案設(shè)置默認(rèn)時區(qū)時區(qū)錯會導(dǎo)致批次到期日計算偏差2庫區(qū)與庫位先把編碼規(guī)則寫進(jìn)文檔按規(guī)則批量生成庫位3貨主第三方倉儲業(yè)務(wù)的貨主編碼要和客戶系統(tǒng)保持一致4SKU 檔案錄入重量和尺寸波次揀貨的路徑優(yōu)化依賴這些參數(shù)5供應(yīng)商/客戶建議提前把聯(lián)系人姓名和電話維護(hù)齊全單據(jù)上要打印有個最容易踩的細(xì)節(jié)SKU 的單位換算關(guān)系要先定死。汽車備件經(jīng)常出現(xiàn)“箱”和“個”混用的情況入庫按箱數(shù)出庫按個如果換算系數(shù)在 SKU 檔案里配錯庫存數(shù)字會成倍失真。我在給某公司做實施時遇到過一件奇葩事一種機(jī)油濾芯的換算系數(shù)被配成了 1 箱 12 個但供應(yīng)商實際包裝是一箱 10 個結(jié)果系統(tǒng)庫存顯示 1200實物只有 1000。查到最后就是在 SKU 檔案里差了這一步。這個參數(shù)在配置時就要和倉庫主管當(dāng)面確認(rèn)不要自己猜。5. 上線避坑最容易翻車的 5 個問題5.1 批次號被 Excel 自動截斷現(xiàn)象導(dǎo)入批次主數(shù)據(jù)后系統(tǒng)里批次號的后幾位全變成了 0比如原始批次號是BF20241118A1234導(dǎo)入后變成了BF20241118A0000。追溯查詢對不上供應(yīng)商原始記錄。原因Excel 默認(rèn)把超過 15 位的數(shù)字列當(dāng)成數(shù)值處理批次號一旦長得像數(shù)字就會被轉(zhuǎn)成科學(xué)計數(shù)法再把精度丟光。這個錯在導(dǎo)入階段根本看不出來因為界面預(yù)覽時數(shù)字差不多要到出庫追溯才對不上。解決導(dǎo)入模板里把批次號列的數(shù)據(jù)格式強制設(shè)為文本同時后端這塊字段必須定義為CharField而不是數(shù)字類型。最穩(wěn)妥的做法是導(dǎo)入腳本里對批次號做一次正則校驗只允許字母、數(shù)字和短橫線任何科學(xué)計數(shù)法特征直接報錯攔截。順帶在數(shù)據(jù)庫層給batch_no字段加上唯一約束重復(fù)數(shù)據(jù)進(jìn)不來問題就提前暴露而非事后排查。5.2 并發(fā)揀貨把庫存扣成負(fù)數(shù)現(xiàn)象兩個揀貨員在同一時間掃描同一個庫位的同一個 SKU系統(tǒng)顯示揀貨成功但庫存明細(xì)變成了負(fù)值總賬對不上。原因這是典型的讀改寫并發(fā)問題。邏輯是“先查庫存判斷夠不夠再扣減”但兩個請求同時讀到同樣的庫存數(shù)字各自都以為夠扣然后分別扣減最終結(jié)果就突破了零。解決扣減庫存必須走原子操作不能用“先讀后寫”。ORM 層用條件更新加F()表達(dá)式在數(shù)據(jù)庫層把扣減和檢查合成一條語句類似UPDATE stock_batch SET qty qty - 2 WHERE sku xxx AND qty 2。這樣即使并發(fā)再高數(shù)據(jù)庫的鎖機(jī)制也會讓第二個請求等待等它執(zhí)行時條件已經(jīng)不滿足直接返回庫存不足而不是扣成負(fù)數(shù)。線上最好再配合流水表唯一約束做兜底一筆入庫單明細(xì)只能被出庫沖銷一次。5.3 批次到期日差了一天導(dǎo)致效期管理錯亂現(xiàn)象倉庫反饋某藥品批次的到期日比實物標(biāo)簽晚了 8 小時部分庫位顯示還有效期實物已經(jīng)過期。原因前后端時區(qū)處理不一致。前端輸入日期2024-11-30后把它當(dāng)成帶時區(qū)的完整時間2024-11-30T00:00:00傳給后端后端用 UTC 解析再存到數(shù)據(jù)庫的timestamp字段東八區(qū)環(huán)境下最后記錄就變成了實際日期的前一天或后一天。解決效期管理只關(guān)心“哪天到期”完全不關(guān)心幾點幾分。API 層對日期字段只接收YYYY-MM-DD純?nèi)掌谧址蠖擞肈ateField存儲計算效期剩余時把到期日當(dāng)天的 23:59:59 作為最終時間邊界。這個規(guī)則在接口文檔里寫清楚前端不做任何時間轉(zhuǎn)換時區(qū)問題就不會有機(jī)會滲透到庫存邏輯里。5.4 逆向退貨重復(fù)上架導(dǎo)致庫存虛增現(xiàn)象客戶退貨重新入庫后庫存總數(shù)翻了一倍財務(wù)對賬怎么都對不上。一查發(fā)現(xiàn)同一件貨既在“已出庫”記錄里又在“可用庫存”里。原因逆向退貨直接用正向入庫流程處理系統(tǒng)把退回來的貨當(dāng)成一筆全新入庫加進(jìn)庫存而不是沖銷原來那筆出庫記錄。正向和逆向沒有關(guān)聯(lián)賬面上就出現(xiàn)了同一件貨的重復(fù)累計。解決退貨必須走獨立的逆向流程而且退貨單要引用原出庫單號。正確狀態(tài)流轉(zhuǎn)是退貨收貨進(jìn)入“待檢庫位”質(zhì)檢合格后做兩步操作——先沖銷原出庫記錄再生成新的入庫記錄然后才上架到可用庫存。質(zhì)檢不合格的直接進(jìn)不合格品區(qū)走供應(yīng)商退貨流程。我見過太多項目為了省事把逆向流程簡化掉最后全部倒在月底對賬上。5.5 關(guān)閉 Debug 后后臺全部 404現(xiàn)象把DJANGO_DEBUG從 True 改成 False 后部署到測試服務(wù)器登錄頁面能打開但沒有任何樣式圖片全部裂開JS 控制臺全是 404。原因Django 默認(rèn)只在 Debug 模式下自己服務(wù)靜態(tài)文件關(guān)掉 Debug 后靜態(tài)文件請求不再被框架處理。項目部署前沒有執(zhí)行collectstatic或者執(zhí)行了但沒有把靜態(tài)文件目錄暴露到反向代理的路由里。解決部署腳本里把collectstatic --noinput放在啟動服務(wù)之前然后讓反向代理配置里加一條/static/的路徑映射直接服務(wù)靜態(tài)文件目錄。驗證方法很簡單直接訪問一個靜態(tài)文件地址能返回文件內(nèi)容就說明配通了。這個坑沒有技術(shù)難度純粹是部署流程繞不過的必選項。6. 進(jìn)階技巧用循環(huán)盤點把庫存精度拉回 99% 以上庫存系統(tǒng)跑三個月后賬實差異會像雪球一樣滾起來。差異來源不一定是系統(tǒng) bug很可能是收貨時掃碼漏掃、揀貨時串貨、或者是某個庫位的貨被挪了位置沒錄系統(tǒng)。與其等年底一次性大盤點不如用一個技巧按 ABC 分類做循環(huán)盤點每天點名一小部分庫位讓庫存精度持續(xù)保持在可接受范圍內(nèi)。做法是給每個 SKU 打上分類標(biāo)簽A 類是出貨頻率最高的頭部 SKU數(shù)量可能只占 10%但出貨行數(shù)占 70%每周盤一次B 類每月盤一次C 類每季度盤一次。盤點任務(wù)按庫位隨機(jī)抽樣生成每天盤 20 到 50 個庫位即可不會干擾正常作業(yè)。盤點采用盲盤模式更靠譜——盤點單據(jù)上不顯示系統(tǒng)賬面數(shù)量操作員只錄入實盤數(shù)量系統(tǒng)隨后對比差異這樣能避免操作員被賬面數(shù)字暗示。我把這套邏輯簡化成一個獨立腳本def generate_stocktake_tasks(warehouses, today): tasks [] for wh in warehouses: for sku_class in [A, B, C]: frequency {A: 7, B: 30, C: 90}[sku_class] if today.day % frequency 0 or sku_class A: # 按庫位抽樣A類全盤B/C類按庫位隨機(jī)抽 locs StockBatch.objects.filter( warehousewh, sku_classsku_class ).values_list(location_id, flatTrue).distinct() sample list(locs) if sku_class A else random.sample(list(locs), kmin(len(locs), 30)) tasks.append({warehouse: wh, locations: sample}) return tasks每日盤點產(chǎn)生的差異不要直接改庫存。正確做法是把差異掛起讓倉管員去查StockMove流水確認(rèn)是漏掃碼還是挪庫沒錄再決定是補單還是做調(diào)整單。這里的教訓(xùn)是盤點不是為了把賬面改對而是為了找到流程里那個讓庫存變錯的環(huán)節(jié)。只有把根因修掉循環(huán)盤點才真正發(fā)揮作用。這套方法我實踐過多次一般兩個月內(nèi)能把庫存準(zhǔn)確率從 90% 拉到 99% 以上。希望這個思路對你手頭的倉庫項目有用也能幫你少走我走過的那些彎路。本文還有配套的精品資源點擊獲取