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