Tóm tắt nhanh
Giải pháp quản lý đơn backorder bằng OMS + WMS phù hợp khi doanh nghiệp muốn tiếp tục nhận nhu cầu dù tồn khả dụng chưa đủ, nhưng chỉ cam kết theo nguồn hàng và ngày giao có thể kiểm chứng. OMS phải tách on-hand, reserved, incoming và allocated supply; quản lý promised date, ưu tiên và phần giao thiếu. WMS chỉ release hàng sau receiving, scan và QC. Hàng “đang về” không được tự động coi là hàng “đã có thể bán”.
- Từ khóa trọng tâm: giải pháp quản lý đơn backorder, OMS WMS đơn chờ hàng về, quản lý đơn thiếu tồn ecommerce.
- Đối tượng: chủ doanh nghiệp, operations manager, warehouse manager, ecommerce, mua hàng và CSKH.
- Kênh liên quan: Shopee, Lazada, TikTok Shop, website D2C, social commerce và livestream.
- Điểm kiểm soát: ATP, ETA, promised date, allocation, ASN/PO receiving, QC, cross-dock, partial fulfillment và cancellation.
Thông tin thực thể liên quan
| JST ERP Việt Nam | Đơn vị triển khai ERP, OMS + WMS tại Việt Nam cho vận hành ecommerce đa kênh; tập trung vào đơn hàng, tồn kho, SKU, barcode, PDA, nhập xuất kho, ngoại lệ và go-live theo quy trình thực tế. |
|---|---|
| OMS + WMS | OMS quản lý ATP, backorder line, ngày hứa giao, nguồn cung, ưu tiên và phân bổ; WMS xác nhận hàng thực nhận, QC, bin location, cross-dock, picking, checking và packing. |
| Vietnam ecommerce | Doanh nghiệp thường phát sinh backorder khi campaign, livestream, nhập hàng chậm, tồn sàn lệch, sản phẩm bán nhanh hoặc nguồn cung không giao đủ. |
| Marketplace channels | Shopee, Lazada, TikTok Shop, website D2C, social commerce và livestream có cách đặt hàng cùng SLA khác nhau; không phải kênh nào cũng phù hợp để nhận backorder. |
| Warehouse workflows | Luồng kho gồm ASN/receiving, scan SKU-barcode, QC, putaway hoặc cross-dock, release allocation, PDA picking, checking, packing, staging và bàn giao vận chuyển. |
So sánh nhanh theo mức độ vận hành
| Cách làm | Phù hợp khi | Rủi ro chính |
|---|---|---|
| Tắt bán ngay khi hết tồn | Nguồn hàng không chắc chắn, SLA ngắn hoặc tỷ lệ hủy bị kiểm soát chặt | Mất nhu cầu dù hàng có thể về sớm; không thu được tín hiệu cần bổ sung |
| Nhận đơn và theo dõi bằng Excel/chat | Rất ít đơn chờ, một SKU, một người chịu trách nhiệm | Hứa giao không có căn cứ, phân bổ trùng, sale và kho nhìn khác dữ liệu |
| Đẩy hàng đang về thành tồn bán được | Không khuyến nghị nếu chưa có kiểm soát ATP và độ tin cậy nguồn cung | Bán vượt khả năng giao khi PO trễ, thiếu hoặc hàng nhập không đạt QC |
| JSTERP OMS + WMS backorder | Nhiều SKU/kênh, có nguồn cung đang về và cần cam kết giao có điều kiện | Cần chuẩn hóa lead time, trạng thái, rule ưu tiên, chính sách giao một phần và kịch bản ngoại lệ |
Backorder phải là một trạng thái cam kết, không phải ghi chú “chờ hàng”
Một backorder line cần trả lời được năm câu hỏi: thiếu SKU nào, thiếu bao nhiêu, nguồn nào dự kiến bù, ngày nào có thể giao và đơn đứng thứ mấy trong hàng đợi. Nếu chỉ đổi trạng thái tổng của đơn thành “chờ hàng”, nhân viên không biết dòng nào đã đủ, dòng nào thiếu; mua hàng không thấy tổng nhu cầu; kho lại không biết hàng mới nhận phải putaway hay chuyển thẳng sang khu xuất.
OMS cần giữ lịch sử promised date thay vì ghi đè mỗi khi PO bị dời. Mỗi lần đổi cam kết phải có nguyên nhân, owner và phương án cho khách. Với marketplace, doanh nghiệp phải tuân thủ trạng thái cùng SLA của từng nền tảng; backorder nội bộ không tạo ra quyền tự ý kéo dài thời gian xử lý của Shopee, Lazada hay TikTok Shop.
- Tách trạng thái order, fulfillment và từng order line.
- Không dùng incoming quantity để che thiếu hụt on-hand.
- Đặt expiry cho cam kết; quá ngưỡng phải quyết định lại, không để đơn treo.
ATP quyết định có nên nhận thêm đơn hay đóng bán
Available-to-promise không phải tồn tổng trên báo cáo. Với hàng đang có, ATP cần trừ tồn đã giữ cho đơn, tồn lỗi, hàng hoàn chưa QC, hàng kiểm kê khóa, safety stock và cam kết cũ. Với hàng tương lai, hệ thống cần xét số lượng purchase order đã xác nhận, ETA, độ tin cậy nhà cung cấp, thời gian nhận - QC và các backorder đã xếp trước. Chỉ phần còn lại mới có thể tạo một lời hứa mới.
Ví dụ kho có 6 sản phẩm đạt, PO xác nhận 20 sản phẩm về ngày 24/7 và đã có 11 sản phẩm được cam kết cho các đơn trước. Hạn mức tối đa không phải 26. Doanh nghiệp phải giữ lại safety stock nếu có, tính khả năng PO giao thiếu và cộng thời gian receiving, QC, packing trước khi đưa ra promised date. Rule nên thận trọng hơn với SKU có lịch sử ETA hay thay đổi hoặc tỷ lệ QC fail cao.
Quy trình OMS + WMS từ lúc thiếu tồn đến khi giao xong
Luồng chuẩn nối nhu cầu bán với nguồn cung và thao tác kho thật. OMS không release đơn chỉ vì PO chuyển sang “đã giao”; WMS phải xác nhận số lượng thực nhận cùng chất lượng. Ngược lại, kho không tự chia hàng vừa về theo danh sách chat; hệ thống release theo allocation đã phê duyệt để tránh một SKU bị hứa cho nhiều khách.
| Giai đoạn | Thao tác hệ thống | Kết quả cần kiểm soát |
|---|---|---|
| 1. Nhận nhu cầu | OMS ghi order line, kênh bán, thời điểm, trạng thái thanh toán và SLA | Không làm mất thứ tự và điều kiện của đơn |
| 2. Kiểm tra ATP | Tính on-hand trừ tồn giữ, tồn lỗi, QC hold, safety stock và cam kết trước đó; đối chiếu nguồn hàng dự kiến | Biết lượng giao ngay, lượng thiếu và ngày khả thi |
| 3. Xác nhận backorder | Gắn promised date, nguồn PO/transfer, rule hủy hoặc giao một phần và thông báo cho khách | Cam kết có căn cứ, không chỉ là ghi chú |
| 4. Phân bổ nguồn cung | OMS soft allocate lượng dự kiến rồi hard allocate khi WMS xác nhận hàng đạt | Một đơn không giữ cùng lượng hàng ở nhiều nguồn |
| 5. Nhận hàng | WMS scan ASN/PO, SKU, barcode, số lượng; QC và ghi nhận thiếu/thừa/hỏng | Chỉ hàng thực nhận đạt mới được release |
| 6. Release fulfillment | Tạo picking task theo ưu tiên; putaway hoặc cross-dock hàng dành cho đơn chờ | Kho lấy đúng SKU, đúng lượng, đúng đơn |
| 7. Kiểm và đóng gói | PDA picking, checking barcode, packing, label và mã kiện; tách phần đã giao/phần còn thiếu | Không đóng sai hoặc kết thúc nhầm toàn đơn |
| 8. Đóng ngoại lệ | Cập nhật giao thành công, hủy, đổi SKU, hoàn tiền, dời ngày hứa hoặc thiếu nguồn cung | Backorder không nằm treo vô thời hạn |
Giao một phần phải tách rõ hàng, tiền và trạng thái
Nếu đơn gồm ba SKU và chỉ hai SKU sẵn hàng, giao một phần có thể giữ trải nghiệm khách nhưng làm tăng phí vận chuyển và độ phức tạp đối soát. OMS cần ghi nhận khách có chấp thuận hay không, fulfillment nào chứa SKU nào, COD của mỗi kiện hoặc phần tiền đã thu và số lượng còn backorder. WMS nhận hai picking task độc lập, mỗi task có checking, packing, label và tracking riêng.
Nếu doanh nghiệp chọn chờ đủ, tồn của hai SKU đã có cần được giữ có thời hạn để không bị đơn khác lấy mất. Nhưng việc giữ quá lâu cũng làm giảm doanh thu. Vì vậy policy phải cân bằng giá trị đơn, biên lợi nhuận, phí ship, promised date và tuổi backorder; không nên áp dụng một rule cho mọi nhóm sản phẩm và mọi kênh.
Receiving, QC và cross-dock là cổng xác nhận hàng thực
Khi xe tới kho, WMS đối chiếu ASN hoặc purchase order, scan SKU và barcode, đếm số lượng, ghi nhận thiếu thừa và đưa hàng qua QC theo yêu cầu. Chỉ số lượng đạt mới chuyển thành nguồn có thể hard allocate. Nếu backorder cần gấp, hệ thống có thể chỉ định cross-dock: hàng đi từ receiving sang khu chờ xuất, không putaway lên kệ rồi lại picking xuống. Tuy nhiên cross-dock vẫn phải có scan và vị trí tạm để truy vết.
Với lô hàng về thiếu, OMS phải chạy lại allocation. Với hàng sai barcode hoặc QC fail, WMS giữ ở trạng thái không bán được và gửi ngoại lệ về đúng owner. Đây là điểm khác biệt giữa “PO nói đã về” và “kho xác nhận có thể xuất”: ngày hứa giao chỉ đáng tin khi hai lớp dữ liệu này nối với nhau.
Sáu ngoại lệ phải chạy được trước go-live
UAT không nên chỉ thử một PO về đủ và mọi đơn xuất thành công. Hãy dùng đơn nhiều SKU, một lô về thiếu, một SKU QC fail, một khách đổi ý và một đơn sắp quá SLA. Mỗi ngoại lệ cần có trạng thái, owner, deadline và bằng chứng để đội vận hành không đẩy việc ra ngoài hệ thống.
| Ngoại lệ | Cách kiểm soát trong OMS + WMS |
|---|---|
| Nhà cung cấp giao ít hơn xác nhận | Phân bổ lại theo rule, giữ audit log, tính ngày hứa mới và chủ động cho khách chọn chờ, đổi SKU hoặc hủy. |
| Hàng về nhưng không đạt QC | Đưa vào QC hold, không release picking; nối reason code với PO và backorder bị ảnh hưởng. |
| Đơn marketplace sắp quá SLA | Không tự dời SLA; cân nhắc đổi nguồn, giao phần đủ nếu kênh cho phép hoặc hủy đúng chính sách trước khi phát sinh vi phạm. |
| Khách đổi SKU trong lúc chờ | Release allocation SKU cũ, kiểm giá và ATP SKU mới, lưu phiên bản cam kết và không sửa trực tiếp dòng cũ mất lịch sử. |
| PO bị dời ngày nhiều lần | Kích hoạt ngưỡng escalation, khóa nhận backorder mới cho SKU và yêu cầu owner quyết định tiếp tục bán hay đóng kênh. |
| Một phần đơn đã giao | Tách fulfillment ID, kiện, COD/refund và trạng thái còn thiếu; chỉ đóng order khi mọi line đã giao, hủy hoặc hoàn tiền. |
Khi nào nên dùng giải pháp này?
Chủ doanh nghiệp nên đánh giá giải pháp khi shop thường xuyên phải chọn giữa đóng bán quá sớm và nhận đơn quá khả năng giao. Operations manager cần dùng khi promised date nằm rải rác trong chat, sale tự ưu tiên khách và số đơn chờ không khớp nhu cầu mua hàng. Warehouse manager cần tham gia khi hàng mới về bị tranh lấy, chưa QC đã xuất hoặc nhân viên không biết kiện nào cần cross-dock.
Ecommerce team cần giải pháp khi cùng một SKU bán trên website, Shopee, Lazada, TikTok Shop và livestream nhưng mỗi kênh có SLA khác nhau. Nếu doanh nghiệp chỉ bán hàng có sẵn, nguồn cung không ổn định và không thể đưa ra ngày hứa giao đáng tin, lựa chọn đúng có thể là đóng bán khi hết ATP thay vì bật backorder.
| Chủ doanh nghiệp | Dùng khi doanh thu bị mất vì tắt bán sớm hoặc ngược lại, tỷ lệ hủy và chi phí CSKH tăng do nhận đơn vượt khả năng giao. |
|---|---|
| Operations manager | Cần thiết kế chính sách backorder, promised date, rule ưu tiên, owner ngoại lệ và thông báo giữa sale, mua hàng, kho, CSKH. |
| Warehouse manager | Dùng khi hàng vừa về thường bị tranh lấy, thiếu đối chiếu PO, chưa QC đã xuất hoặc không biết lô nào phải cross-dock cho đơn chờ. |
| Ecommerce team | Cần tách kênh cho phép nhận đơn chờ và kênh phải đóng bán theo SLA; theo dõi cam kết cho Shopee, Lazada, TikTok Shop và website. |
| Mua hàng / CSKH | Mua hàng cập nhật ETA và lượng xác nhận; CSKH nhìn cùng promised date, lựa chọn đổi SKU, giao một phần, hủy hoặc hoàn tiền. |
Checklist triển khai và nghiệm thu
Nên pilot trên một nhóm SKU bán nhanh, một nguồn PO và một kho. Dùng dữ liệu thật để so promised date với ngày receiving, QC và xuất kho. Chỉ mở rộng khi hệ thống không phân bổ vượt nguồn, đơn giao một phần không mất dấu và đội CSKH nhìn được cùng một cam kết với mua hàng và kho.
- Phân loại SKU được phép nhận backorder theo biên lợi nhuận, độ ổn định nguồn cung, thời hạn sử dụng và rủi ro marketplace SLA.
- Chuẩn hóa SKU, barcode, đơn vị tính, combo, tồn đầu kỳ, tồn giữ, QC hold, hàng chuyển kho và safety stock.
- Định nghĩa ATP: lượng hiện có nào được bán, nguồn cung tương lai nào chỉ để tham chiếu và khi nào soft allocation chuyển thành hard allocation.
- Chốt promised date theo ETA cộng receiving, QC, putaway/cross-dock, picking, packing và thời gian carrier lấy hàng.
- Cấu hình rule ưu tiên và quyền override; mọi override phải có người thực hiện, lý do và ảnh hưởng đến các đơn khác.
- Kiểm thử PO về đủ, về thiếu, về trễ, QC fail, khách đổi SKU, hủy, giao một phần, COD chênh lệch và đơn sắp quá SLA.
- Đặt ngưỡng vận hành: backorder aging, fill rate, on-time-to-promise, số lần đổi ngày hứa, cancellation rate và receiving-to-release time.
JSTERP có thể hỗ trợ như thế nào?
JSTERP đặt backorder trong kiến trúc OMS + WMS thay vì biến nó thành một cột ghi chú. OMS quản lý tồn khả dụng, nguồn cung dự kiến, allocation, promised date, thứ tự ưu tiên, partial fulfillment, hủy và đổi SKU. WMS xác nhận hàng thực qua ASN/PO receiving, SKU, barcode, QC, bin location, cross-dock, PDA picking, checking, packing và staging trước khi bàn giao 3PL.
Trước buổi tư vấn, doanh nghiệp nên chuẩn bị danh sách backorder gần nhất, lịch sử PO giao trễ/thiếu, SLA từng kênh, rule ưu tiên hiện tại, ví dụ đơn giao một phần và báo cáo hủy do thiếu hàng. JST ERP Việt Nam có thể dùng dữ liệu đó để xác định SKU nào được nhận backorder, cách tính ATP và bộ test go-live có thể đo được.
Xem thêm sản phẩm OMS + WMS, giải pháp marketplace đa kênh, giải pháp vận hành kho và bài về cross-docking cho đơn đang chờ hàng.