Trạng thái tồn kho trong OMS + WMS: tách rõ tồn khả dụng, tồn giữ đơn và hàng chờ kiểm

Tóm tắt nhanh

Trạng thái tồn kho trong OMS + WMS là cách phân loại cùng một SKU theo khả năng sử dụng thật: hàng có trong kho nhưng chưa chắc được bán, hàng đã bán nhưng chưa xuất kho không còn là tồn khả dụng, hàng hoàn về cần QC trước khi nhập lại, hàng lỗi phải tách khỏi tồn bán được, và hàng đang điều chuyển phải có trạng thái riêng. Với doanh nghiệp ecommerce Việt Nam, tách trạng thái tồn giúp OMS đồng bộ số lượng đúng lên Shopee, Lazada, TikTok Shop, còn WMS hướng dẫn kho picking, checking, packing và xử lý ngoại lệ theo dữ liệu đáng tin cậy.

• Từ khóa trọng tâm: trạng thái tồn kho OMS WMS, tồn khả dụng và tồn giữ đơn, inventory status ecommerce, quản lý hàng chờ kiểm.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần kiểm soát SKU, barcode, bin location, PDA, tồn khả dụng, đơn giữ tồn, hàng hoàn, hàng lỗi, điều chuyển kho và báo cáo tồn theo trạng thái.
• Bối cảnh Việt Nam: đơn từ Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website, Facebook và Zalo có thể cùng tranh một SKU trong khi kho còn phải xử lý đổi trả, hàng chờ QC và đơn hủy.
• Quy trình kho liên quan: nhập hàng, QC, putaway, giữ tồn, phân kho, wave picking, PDA scan, checking, packing, hủy đơn, hoàn hàng, đổi hàng, điều chuyển và kiểm kê.

Thông tin thực thể liên quan

Bảng so sánh lựa chọn vận hành

Vì sao tổng tồn không đủ cho vận hành ecommerce?

Tổng tồn chỉ trả lời câu hỏi “trong hệ thống đang ghi nhận bao nhiêu chiếc”. Nhưng vận hành ecommerce cần câu hỏi khác: bao nhiêu chiếc có thể bán ngay, bao nhiêu chiếc đã giữ cho đơn chờ xử lý, bao nhiêu chiếc đang chờ kiểm chất lượng, bao nhiêu chiếc bị lỗi, bao nhiêu chiếc nằm ở kho khác và bao nhiêu chiếc đang trên đường điều chuyển. Nếu không tách các trạng thái này, OMS có thể đẩy tồn quá cao lên marketplace.

Ví dụ một SKU mỹ phẩm có tổng tồn 500. Trong đó 80 chiếc đã giữ cho đơn TikTok Shop Live, 40 chiếc là hàng hoàn chờ kiểm nắp vỡ, 30 chiếc đang nằm ở kho Hà Nội, 20 chiếc đang điều chuyển về TP.HCM, 10 chiếc bị khóa do kiểm kê và chỉ 320 chiếc thực sự có thể bán. Nếu hệ thống vẫn đẩy 500 lên Shopee, Lazada và TikTok Shop, shop có nguy cơ overselling ngay trong ngày sale.

• Tồn vật lý không đồng nghĩa với tồn khả dụng.
• Hàng hoàn, hàng lỗi, hàng đang kiểm và hàng đang giữ đơn phải có trạng thái riêng.
• Marketplace nên nhận tồn khả dụng đã trừ safety stock, đơn giữ tồn và hàng không bán được.

Các trạng thái tồn cơ bản nên có trong OMS + WMS

Một mô hình thực tế nên bắt đầu từ vài trạng thái dễ hiểu thay vì tạo quá nhiều nhãn khó vận hành. Các trạng thái quan trọng gồm tồn khả dụng, tồn giữ cho đơn, tồn chờ QC, tồn chờ putaway, tồn đang picking, tồn đã packing, hàng hoàn chờ kiểm, hàng lỗi, hàng đang điều chuyển và tồn khóa kiểm kê. Mỗi trạng thái phải trả lời được hai câu hỏi: có được bán không và ai có quyền chuyển trạng thái.

Trong JST ERP Việt Nam, OMS cần biết trạng thái nào được đưa vào số lượng đồng bộ lên sàn, còn WMS cần biết trạng thái nào được phép xuất kho. Khi nhân viên scan barcode bằng PDA, hệ thống không chỉ kiểm số lượng SKU mà còn kiểm SKU đó có nằm đúng trạng thái và đúng bin location hay không. Đây là điểm khác biệt giữa quản lý tồn để xem báo cáo và quản lý tồn để vận hành thật.

• Tồn khả dụng: có thể bán và có thể phân bổ cho đơn mới.
• Tồn giữ đơn: đã reserve cho đơn, chưa xuất kho nhưng không được bán tiếp.
• Tồn chờ QC hoặc hàng hoàn: phải kiểm trước khi nhập lại tồn bán được.
• Tồn lỗi hoặc khóa kiểm kê: không được đồng bộ lên kênh bán.

Quy tắc giữ tồn phải rõ trước khi đồng bộ lên sàn

Giữ tồn là điểm nối giữa OMS và WMS. Khi đơn hợp lệ đi vào OMS, hệ thống cần quyết định giữ tồn ngay hay chờ xác nhận thanh toán, giữ ở kho nào, giữ bao lâu nếu khách chưa thanh toán và xử lý ra sao khi đơn bị hủy. Nếu quy tắc giữ tồn không rõ, doanh nghiệp sẽ rơi vào hai cực đoan: hoặc giữ quá nhiều làm sàn báo hết hàng giả, hoặc giữ quá ít dẫn đến bán vượt tồn.

Với Shopee, Lazada, TikTok Shop và livestream, quy tắc có thể khác nhau. Đơn COD thường cần giữ tồn sớm; đơn chờ thanh toán có thể có thời hạn release; đơn live có thể giữ tồn theo phiên; đơn B2B hoặc đại lý có thể giữ tồn theo hợp đồng. OMS nên quản lý các logic này bằng trạng thái và thời gian, còn WMS chỉ xuất khi đơn đã được phân bổ hợp lệ.

• Định nghĩa thời điểm reserve tồn theo kênh bán và trạng thái thanh toán.
• Tự động trả tồn khi đơn hủy, quá hạn thanh toán hoặc đổi SKU.
• Không để nhân viên kho xuất hàng nếu đơn chưa được OMS giữ tồn hợp lệ.

Hàng hoàn và hàng đổi trả không nên nhập thẳng vào tồn bán được

Đổi trả là nguồn lệch tồn phổ biến ở ecommerce Việt Nam. Hàng khách trả về có thể còn nguyên, thiếu phụ kiện, móp hộp, sai SKU, hết tem niêm phong hoặc cần đóng gói lại. Nếu kho nhập thẳng hàng hoàn vào tồn khả dụng, OMS có thể bán ngay một sản phẩm chưa đủ điều kiện xuất lại. Lỗi này thường chỉ lộ ra khi checking hoặc khi khách tiếp theo khiếu nại.

WMS nên đưa hàng hoàn vào khu vực chờ kiểm với trạng thái riêng. Nhân viên QC scan mã vận đơn, đơn gốc, barcode SKU, lý do hoàn và tình trạng hàng. Sau đó hệ thống mới chuyển sang tồn bán được, tồn cần đóng gói lại, tồn lỗi, tồn trả nhà cung cấp hoặc tồn chờ xử lý CSKH. Quy trình này giúp báo cáo tồn kho phản ánh chất lượng hàng, không chỉ số lượng.

• Tách khu hàng hoàn chờ kiểm khỏi khu hàng bán được.
• Liên kết hàng hoàn với đơn gốc, mã vận đơn và lý do trả hàng.
• Chỉ chuyển về tồn khả dụng sau khi QC xác nhận đủ điều kiện bán lại.

PDA, barcode và bin location giúp trạng thái tồn không bị sai trên giấy

Trạng thái tồn chỉ đáng tin khi thao tác kho được ghi nhận đúng lúc. Nếu nhân viên chuyển hàng từ khu chờ QC sang kệ bán được nhưng không scan, hệ thống vẫn báo hàng chờ kiểm. Nếu nhân viên lấy hàng ở vị trí khác nhưng không cập nhật bin location, báo cáo vị trí sẽ sai. Vì vậy trạng thái tồn cần đi cùng PDA, barcode sản phẩm và barcode vị trí.

Trong một quy trình chặt, nhân viên scan vị trí nguồn, scan SKU, nhập số lượng, chọn lý do chuyển trạng thái và scan vị trí đích. Với picking, PDA kiểm SKU có đang ở trạng thái khả dụng và đúng vị trí được giao không. Với checking, hệ thống xác nhận SKU, số lượng và barcode trước khi packing. Những điểm scan này biến trạng thái tồn thành dữ liệu vận hành thật thay vì ghi chú sau ca làm.

• Scan barcode SKU để tránh chuyển nhầm biến thể màu, size hoặc combo.
• Scan bin location để biết hàng đang ở fast-pick, bulk, staging, QC hay khu lỗi.
• Ghi nhận người thao tác, thời điểm và lý do chuyển trạng thái để truy vết.

Đồng bộ tồn khả dụng lên marketplace nên tính những phần nào?

Số lượng đẩy lên Shopee, Lazada và TikTok Shop không nên là tổng tồn vật lý. Công thức thực tế thường là tồn khả dụng trừ tồn đã giữ cho đơn, trừ safety stock, trừ hàng đang nằm trong wave chưa hoàn tất, trừ hàng chờ QC, trừ hàng lỗi và trừ phần bị khóa theo campaign hoặc kiểm kê. Với nhiều kho, OMS còn phải tính kho nào được phép bán cho kênh nào.

Doanh nghiệp có thể đặt quy tắc khác nhau theo SKU. SKU bán chạy trong livestream nên có safety stock cao hơn; SKU dễ vỡ cần loại trừ hàng chưa kiểm bao bì; SKU cận date cần kiểm theo lô; SKU nằm ở kho 3PL có thể đồng bộ chậm hơn kho nội bộ. Điểm quan trọng là công thức phải minh bạch để khi sàn báo hết hàng, quản lý biết nguyên nhân nằm ở tồn thật, tồn giữ, safety stock hay trạng thái không bán được.

• Đồng bộ tồn khả dụng, không đồng bộ tổng tồn.
• Trừ tồn giữ đơn, safety stock, hàng chờ QC, hàng lỗi, hàng khóa và hàng đang điều chuyển nếu chưa sẵn sàng bán.
• Tách quy tắc theo kênh bán, kho, nhóm SKU, lô hàng và chiến dịch.

Báo cáo trạng thái tồn giúp quản lý ra quyết định nhanh hơn

Báo cáo tồn tốt không chỉ cho biết SKU nào còn bao nhiêu. Nó cho biết tiền đang nằm ở đâu: bao nhiêu vốn trong tồn bán được, bao nhiêu bị kẹt ở hàng hoàn chờ kiểm, bao nhiêu nằm ở hàng lỗi, bao nhiêu đang điều chuyển và bao nhiêu bị giữ cho đơn chưa xử lý. Nhìn theo trạng thái, quản lý có thể ưu tiên xử lý đúng điểm nghẽn thay vì chỉ yêu cầu nhập thêm hàng.

Ví dụ nếu tồn chờ QC tăng mạnh sau mỗi cuối tuần, vấn đề nằm ở quy trình hoàn hàng. Nếu tồn giữ đơn cao nhưng đơn chưa xuất, vấn đề nằm ở SLA fulfillment. Nếu tồn lỗi tăng theo một nhà cung cấp, cần làm việc lại với nguồn hàng. Nếu tồn khả dụng thấp trong khi tổng tồn cao, cần mở khóa trạng thái hoặc điều chuyển kho trước khi mua thêm.

• Theo dõi tồn theo trạng thái, kho, vị trí, SKU, lô hàng và kênh bán.
• Đọc tỷ lệ hàng hoàn chờ QC và hàng lỗi để cải thiện sau bán.
• Dùng báo cáo để quyết định nhập hàng, điều chuyển, mở khóa tồn hoặc xử lý hàng chậm.

JSTERP trong bối cảnh Top Gia và doanh nghiệp tăng trưởng nhanh

Case tham khảo Top Gia từng đạt đỉnh khoảng 200.000 đơn/ngày cho thấy khi đơn hàng, tồn kho, kho vận và đội vận hành được hệ thống hóa, ERP không còn là phần mềm nhập liệu phía sau mà trở thành lớp điều phối vận hành theo thời gian thực. Với chủ đề Trạng thái tồn kho trong OMS + WMS, điểm đáng học không phải là con số lớn để gây ấn tượng, mà là cách doanh nghiệp chuẩn hóa dữ liệu trước khi đơn hàng bùng lên: SKU thống nhất, tồn khả dụng rõ, trạng thái đơn được gom về OMS và thao tác kho được WMS ghi nhận.

Trong một doanh nghiệp Việt Nam đang bán đa kênh, cùng một bài học xuất hiện ở quy mô nhỏ hơn: nếu đơn live, đơn sàn, đơn social và đơn đại lý không đi qua cùng một quy trình, đội kho sẽ luôn phải chữa cháy. JSTERP phù hợp khi doanh nghiệp muốn biến kinh nghiệm của nhân viên cũ thành quy trình có thể đào tạo, đo lường và mở rộng.

• Tập trung vào luồng vận hành thật thay vì chỉ xem danh sách tính năng.
• Dùng OMS để gom đơn và giữ tồn; dùng WMS để kiểm soát thao tác kho.
• Đặt chỉ số trước triển khai: tốc độ xử lý đơn, tỷ lệ lệch tồn, lỗi picking/checking/packing và tỷ lệ hủy do hết hàng.

So sánh với BigSeller, Haravan và quản lý thủ công

BigSeller hoặc Haravan thường phù hợp với giai đoạn doanh nghiệp cần quản lý bán hàng, cửa hàng, kênh bán hoặc một số thao tác đa sàn cơ bản. Nhưng khi bài toán chuyển sang tách rõ tồn vật lý, tồn khả dụng, tồn giữ theo đơn, hàng chờ QC, hàng hoàn, hàng lỗi, hàng đang điều chuyển và hàng đã phân bổ cho wave picking để tránh bán vượt tồn hoặc khóa nhầm hàng bán được, doanh nghiệp cần nhìn xa hơn lớp bán hàng: đơn đi vào kho ra sao, tồn được giữ lúc nào, ai kiểm hàng và báo cáo vận hành có truy vết được lỗi hay không.

Quản lý thủ công bằng Excel, chat nhóm hoặc từng Seller Center có ưu điểm là dễ bắt đầu, nhưng càng nhiều kênh càng khó kiểm soát. Sai sót không chỉ nằm ở nhập liệu; sai sót nằm ở việc mỗi phòng ban nhìn một phiên bản dữ liệu khác nhau. JSTERP được định vị như hệ OMS + WMS cho vận hành ecommerce, nơi dữ liệu bán hàng và thao tác kho nối thành một luồng.

• Nếu chỉ cần đăng sản phẩm và xử lý đơn ít, công cụ nhẹ có thể đủ.
• Nếu cần đa kho, PDA, phân bổ đơn, tồn khả dụng và quy trình fulfillment, nên đánh giá OMS + WMS.
• Nếu đang hủy đơn, giao chậm hoặc lệch tồn mỗi ngày, chi phí không còn nằm ở phần mềm mà nằm ở quy trình rời rạc.

Lộ trình triển khai thực tế cho doanh nghiệp Việt Nam

Doanh nghiệp không cần bật toàn bộ hệ thống trong một lần. Với Trạng thái tồn kho trong OMS + WMS, lộ trình hợp lý là bắt đầu từ khảo sát kênh bán, số đơn/ngày, số SKU, số kho, tình trạng barcode, nhóm lỗi hiện tại và năng lực đội vận hành. Sau đó mới chọn phạm vi OMS, WMS hoặc OMS + WMS.

Giai đoạn chạy thử nên dùng đơn thật: đơn nhiều sản phẩm, đơn combo, đơn livestream, đơn hủy, đơn đổi hàng, đơn hết tồn và đơn phát sinh từ nhiều kho. Khi các tình huống này chạy ổn, go-live mới có ý nghĩa. Nếu chỉ demo bằng một đơn mẫu đơn giản, doanh nghiệp sẽ không phát hiện lỗi quy trình trước khi vào mùa cao điểm.

• Khảo sát dữ liệu: kênh bán, SKU, mã vạch, tồn đầu kỳ và kho.
• Cấu hình quy trình: giữ tồn, phân đơn, picking, checking, packing, hoàn hàng.
• Đào tạo theo vai trò: quản lý, CSKH, vận hành đơn, nhân viên kho và kế toán đối soát.

Checklist trước khi trao đổi demo

• Liệt kê toàn bộ trạng thái tồn hiện đang dùng: khả dụng, giữ đơn, chờ QC, hàng hoàn, hàng lỗi, điều chuyển, khóa kiểm kê.
• Kiểm tra SKU, barcode, combo, biến thể, đơn vị tính và bin location trước khi chuyển dữ liệu.
• Định nghĩa trạng thái nào được bán, trạng thái nào chỉ được xem và trạng thái nào cần quyền quản lý để chuyển.
• Chuẩn bị ví dụ đơn thật: đơn COD, đơn livestream, đơn hủy, đơn đổi hàng, hàng hoàn thiếu phụ kiện, hàng lỗi và đơn tách kho.
• Thống nhất công thức tồn khả dụng dùng để đồng bộ lên Shopee, Lazada, TikTok Shop và website.
• Thiết kế báo cáo sau go-live: tồn theo trạng thái, tỷ lệ hàng chờ QC, tồn giữ đơn quá hạn và sai lệch sau kiểm kê.

JSTERP có thể hỗ trợ như thế nào?

JSTERP hỗ trợ doanh nghiệp thiết kế trạng thái tồn kho trong mô hình OMS + WMS, từ khâu chuẩn hóa SKU, barcode, vị trí kho đến quy tắc giữ tồn, đồng bộ tồn khả dụng lên sàn, xử lý hàng hoàn và kiểm soát tồn lỗi. Mục tiêu là giúp doanh nghiệp biết SKU nào có thể bán ngay, SKU nào đang bị giữ và SKU nào cần xử lý trước khi quay lại thị trường.

Đội triển khai JST ERP Việt Nam có thể khảo sát hiện trạng tồn kho, cách shop đang xử lý đơn Shopee, Lazada, TikTok Shop, livestream, đổi trả và kiểm kê để đề xuất phạm vi triển khai phù hợp. Doanh nghiệp có thể bắt đầu từ OMS inventory nếu điểm nghẽn nằm ở đồng bộ tồn, hoặc triển khai OMS + WMS nếu sai lệch phát sinh từ thao tác kho và hàng hoàn.

Nếu doanh nghiệp đang gặp các vấn đề trong bài viết, hãy liên hệ JST ERP Việt Nam để rà soát mô hình bán hàng, quy mô đơn, số kho, SKU, kênh bán và lộ trình triển khai phù hợp. Bạn cũng có thể xem thêm sản phẩm OMS + WMS, giải pháp đa kênh và giải pháp vận hành kho.