Giải pháp kiểm soát phí lưu kho và tồn chậm trong OMS + WMS: thấy sớm hàng nằm lâu, xử lý trước khi đội chi phí

Tóm tắt nhanh

Doanh nghiệp ecommerce nên dùng OMS + WMS để kiểm soát phí lưu kho và tồn chậm khi có nhiều SKU, nhiều kho, kho 3PL, hàng hoàn, campaign theo mùa hoặc hàng nhập theo lô. Quy trình cần theo dõi tuổi tồn theo SKU, barcode, batch, vị trí kho, trạng thái tồn, đơn chờ xử lý, hàng hoàn chờ QC, tốc độ bán theo kênh, phí lưu kho theo ngưỡng và kế hoạch điều chuyển/xả hàng. JST ERP Việt Nam có thể hỗ trợ thiết kế dashboard và quy trình vận hành để chủ doanh nghiệp, quản lý vận hành, quản lý kho, ecommerce team và kế toán cùng nhìn một nguồn dữ liệu trước khi chi phí lưu kho tăng bất ngờ.

• Từ khóa trọng tâm: giải pháp kiểm soát phí lưu kho, OMS WMS tồn chậm ecommerce, quản lý tồn già kho 3PL.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần gom đơn đa kênh, quản lý SKU, barcode, tồn khả dụng, tuổi tồn, PDA, hàng hoàn, COD, đối soát và go-live quy trình kho.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, livestream và social commerce tạo biến động lớn theo campaign; hàng nhập nhiều trước sale có thể nhanh chóng thành tồn chậm nếu dữ liệu bán hàng và kho không nối với nhau.
• Quy trình kho liên quan: goods receiving, put-away, bin location, stock aging, reserved stock, slow-moving SKU, return QC, stock transfer, cycle count, markdown planning và storage fee reconciliation.

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

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

Vì sao phí lưu kho thường bị phát hiện quá muộn?

Phí lưu kho tăng không xảy ra trong một ngày. Nó bắt đầu từ vài SKU bán chậm sau campaign, một lô hàng nhập dư, một nhóm hàng hoàn chưa QC hoặc một kho 3PL chưa cập nhật tồn đúng trạng thái. Nếu doanh nghiệp chỉ xem tổng tồn cuối tháng, các tín hiệu nhỏ này bị che đi cho đến khi chi phí đã đủ lớn.

Điểm nguy hiểm là tồn chậm thường nằm rải rác: một phần ở kho nội bộ, một phần ở 3PL, một phần bị giữ theo đơn chưa thanh toán, một phần đang chờ QC sau hoàn, một phần đã lỗi bao bì nhưng vẫn nằm trong tồn tổng. Khi các trạng thái này không tách rõ, quản lý không biết nên bán, điều chuyển, kiểm lại hay loại khỏi tồn khả dụng.

• Tồn chậm cần được đo theo tuổi tồn, SKU, kho, vị trí và trạng thái, không chỉ theo số lượng tổng.
• Phí lưu kho cần gắn với ngày nhập, diện tích/thể tích, chính sách 3PL và trạng thái hàng.
• Hàng hoàn chờ QC không nên bị tính như tồn bán được nếu chưa kiểm barcode và tình trạng sản phẩm.

OMS cho thấy SKU nào bán chậm theo từng kênh

OMS là lớp giúp doanh nghiệp hiểu tốc độ bán. Cùng một SKU có thể bán tốt trên TikTok Shop Live nhưng chậm trên Lazada, hoặc bán tốt ở miền Nam nhưng nằm lâu ở kho miền Bắc. Nếu chỉ nhìn tồn kho, doanh nghiệp thấy còn hàng; nếu nối với đơn bán, doanh nghiệp biết hàng đó đang quay vòng nhanh hay đang nằm im.

Với Shopee, Lazada, TikTok Shop, website và social commerce, OMS nên gom đơn, trừ tồn giữ theo đơn, theo dõi đơn hủy, đơn hoàn, COD chưa đối soát và tốc độ bán theo ngày. Từ đó hệ thống có thể cảnh báo SKU có số ngày tồn vượt ngưỡng, SKU nhập trước campaign nhưng bán không đạt kế hoạch, hoặc SKU đang có tồn nhiều ở kho sai vùng.

• Theo dõi days on hand theo SKU, kênh bán, kho và nhóm sản phẩm.
• Tách tồn vật lý, tồn khả dụng, tồn giữ theo đơn, tồn chờ thanh toán và tồn đang xử lý hoàn.
• Kết hợp dữ liệu bán hàng để quyết định giảm giá, tạo combo, chuyển kho hoặc dừng nhập thêm.

WMS kiểm soát tuổi tồn từ lúc nhập kho

WMS cần ghi nhận ngày nhập, lô hàng, barcode, vị trí cất hàng, trạng thái tồn và lịch sử di chuyển của từng SKU. Khi hàng được put-away vào bin location, hệ thống không chỉ biết hàng nằm ở đâu mà còn biết nó đã nằm bao lâu. Đây là nền tảng để quản lý tồn già, FEFO/FIFO, hàng theo hạn sử dụng và phí lưu kho theo khu vực.

Trong kho vận hành thật, một SKU bán chậm không phải lúc nào cũng do nhu cầu yếu. Có thể hàng nằm ở vị trí khó picking, barcode lỗi, combo chưa được bung thành phần, tồn bị giữ nhầm theo đơn hủy hoặc hàng đã hoàn về nhưng chưa QC. WMS giúp truy vết từng nguyên nhân thay vì để nhân viên đoán bằng kinh nghiệm.

• Scan barcode khi nhập, cất hàng, điều chuyển, picking, checking và nhập hoàn.
• Theo dõi tuổi tồn theo bin location, batch/lot, hạn sử dụng và trạng thái QC.
• Dùng cycle count để kiểm tra nhóm SKU tồn chậm trước khi chạy xả hàng hoặc chuyển kho.

Kho 3PL cần đối soát phí bằng dữ liệu thao tác

Khi dùng 3PL, doanh nghiệp thường nhận bảng phí gồm phí lưu kho, phí inbound, phí outbound, phí pick-pack, phí vật tư, phí hoàn và phụ phí xử lý ngoại lệ. Nếu OMS + WMS không có log nhập xuất và tuổi tồn tương ứng, kế toán chỉ có thể kiểm theo cảm giác hoặc đối chiếu thủ công từng file.

Một cách làm chặt hơn là gắn phí với dữ liệu vận hành: SKU nào nhập ngày nào, nằm ở kho nào, thể tích hoặc số vị trí chiếm dụng bao nhiêu, đơn nào đã xuất, kiện nào hoàn, SKU nào bị lỗi QC và dòng phí nào phát sinh. Khi đó phí lưu kho không còn là con số cuối tháng mà trở thành chỉ số có thể cảnh báo trong tuần.

• Đối soát phí lưu kho theo SKU, lô nhập, ngày nằm kho, vị trí và kho 3PL.
• Tách phí lưu kho thường, phí hàng cồng kềnh, phí hàng hoàn và phí lưu quá ngưỡng.
• Thiết lập cảnh báo khi nhóm SKU sắp vượt mốc phí hoặc tỷ lệ phí/tồn kho tăng bất thường.

Khi nào doanh nghiệp nên dùng giải pháp này?

Chủ doanh nghiệp nên quan tâm khi tiền hàng nằm trong kho quá lâu, dòng tiền căng sau mùa sale hoặc bảng phí 3PL tăng mà không rõ nguyên nhân. Quản lý vận hành nên quan tâm khi đội ecommerce vẫn tiếp tục nhập hàng theo cảm giác trong khi kho có nhiều SKU bán chậm, tồn hoàn và tồn chờ xử lý.

Quản lý kho nên triển khai khi kho có nhiều vị trí, nhiều trạng thái tồn, nhiều SKU biến thể, hàng có hạn sử dụng, hàng theo mùa hoặc hàng hoàn phải QC. Ecommerce team nên dùng khi cần quyết định sản phẩm nào đẩy campaign, sản phẩm nào tạo combo, sản phẩm nào chuyển kho và sản phẩm nào dừng nhập.

• Phù hợp với doanh nghiệp có nhiều SKU, nhiều kho, kho 3PL hoặc hàng theo mùa.
• Phù hợp khi bảng phí lưu kho, phí hoàn hoặc phí xử lý ngoại lệ tăng nhanh sau campaign.
• Phù hợp khi cần phối hợp giữa chủ doanh nghiệp, vận hành, kho, ecommerce và kế toán trên cùng dữ liệu.

Quy trình xử lý tồn chậm nên vận hành theo vòng lặp

Kiểm soát tồn chậm không phải là một báo cáo tĩnh. Mỗi tuần, doanh nghiệp nên xem nhóm SKU vượt ngưỡng tuổi tồn, kiểm lại tồn vật lý, xác định nguyên nhân, chọn hành động và theo dõi kết quả. Hành động có thể là chuyển kho, đổi vị trí picking, chạy flash sale, tạo combo, trả hàng nhà cung cấp, thanh lý hoặc loại khỏi tồn khả dụng nếu hàng lỗi.

Điểm quan trọng là mỗi hành động phải quay lại hệ thống. Nếu quyết định xả hàng nhưng OMS không cập nhật campaign, WMS không ưu tiên vị trí picking và kế toán không thấy mục tiêu giảm phí lưu kho, doanh nghiệp chỉ có thêm một kế hoạch nằm ngoài quy trình. OMS + WMS giúp biến quyết định tồn kho thành thao tác vận hành có người chịu trách nhiệm.

• Lập danh sách SKU tồn chậm theo tuổi tồn, giá trị tồn, kho và tốc độ bán.
• Chọn hành động: điều chuyển, đổi vị trí, combo, giảm giá, trả hàng, thanh lý hoặc QC lại.
• Đo lại sau 7-14 ngày: số lượng giảm, phí giảm, đơn tăng, tồn lỗi được xử lý và dòng tiền giải phóng.

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ủ đề Giải pháp kiểm soát phí lưu kho và tồn chậm 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 kiểm soát tồn già, SKU bán chậm, hàng hoàn chờ QC, tồn nằm ở 3PL, phí lưu kho, kế hoạch điều chuyển và quyết định xả hàng trước khi chi phí ăn mòn lợi nhuận, 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 Giải pháp kiểm soát phí lưu kho và tồn chậm 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

• Danh sách SKU, barcode, nhóm sản phẩm, giá vốn, kích thước và trạng thái bán.
• Tồn theo kho, bin location, ngày nhập, batch/lot, hạn sử dụng nếu có và trạng thái QC.
• Bảng phí 3PL hiện tại: lưu kho, inbound, outbound, pick-pack, hoàn hàng và phụ phí.
• Dữ liệu bán theo Shopee, Lazada, TikTok Shop, livestream, website và đại lý trong 30-90 ngày.
• Ngưỡng cảnh báo: số ngày tồn, giá trị tồn, phí lưu kho/tồn, tồn chờ QC và tồn không phát sinh đơn.
• Kịch bản go-live: kiểm thử nhập kho, cất hàng, đơn bán, đơn hủy, hàng hoàn, điều chuyển và đối soát phí.

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

JSTERP hỗ trợ kiểm soát phí lưu kho và tồn chậm bằng cách nối dữ liệu OMS và WMS: đơn bán, tồn khả dụng, tuổi tồn, trạng thái kho, hàng hoàn, QC, barcode, bin location và báo cáo đối soát. Doanh nghiệp không phải đợi cuối tháng mới biết SKU nào đang làm tăng chi phí.

Đội triển khai JST ERP Việt Nam có thể khảo sát mô hình kho nội bộ, kho 3PL, kênh bán, SKU, dữ liệu phí và quy trình hàng hoàn để thiết kế dashboard tồn chậm, cảnh báo phí lưu kho và lộ trình xử lý theo từng vai trò vận hành.

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.