Tóm tắt nhanh
Một đợt thu hồi tốt phải trả lời được ba câu hỏi: còn bao nhiêu hàng rủi ro ở đâu, những đơn/khách nào đã nhận và từng sản phẩm thu về đang ở trạng thái nào. OMS + WMS tạo liên kết từ batch/lot đến tồn kho, thao tác picking-checking-packing, marketplace order, mã vận đơn và return QC; nhờ đó doanh nghiệp khóa đúng phạm vi, không xuất tiếp lô lỗi và giữ đủ bằng chứng để xử lý khách hàng, nhà cung cấp cùng 3PL.
- Từ khóa trọng tâm: giải pháp thu hồi sản phẩm theo lô, OMS WMS product recall, truy vết batch lot ecommerce.
- Đối tượng: owner, operations manager, warehouse manager, ecommerce team, QA, CSKH và kế toán.
- Kênh: Shopee, Lazada, TikTok Shop, website D2C, social commerce, livestream và kho 3PL.
- Điểm kiểm soát: SKU, barcode, batch/lot, hạn dùng, bin location, PDA, đơn, kiện, vận đơn, quarantine và disposition.
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; hỗ trợ chuẩn hóa SKU, batch/lot, barcode, vị trí kho, PDA, truy vết đơn, UAT và go-live bằng dữ liệu thật. |
|---|---|
| OMS + WMS | OMS nối marketplace order, khách nhận, refund, đổi hàng và trạng thái recall; WMS nối receiving, batch/lot, bin location, picking, checking, packing, quarantine, return QC và disposition. |
| Vietnam ecommerce | Doanh nghiệp Việt Nam bán mỹ phẩm, thực phẩm, thực phẩm bổ sung, mẹ và bé, điện tử hoặc hàng có bảo hành thường phải kiểm soát lô, hạn dùng, serial và nhiều luồng COD/đổi trả. |
| Marketplace channels | Shopee, Lazada, TikTok Shop, website D2C, social commerce và livestream tạo order ID, trạng thái giao, quy tắc hoàn tiền và cách liên hệ khác nhau; OMS cần quy về cùng recall case. |
| Warehouse workflows | PO/ASN, receiving, scan batch/lot, QC đầu vào, putaway, replenishment, PDA picking, checking, packing, staging, bàn giao 3PL, cycle count, quarantine, nhận hàng thu hồi và xử lý cuối. |
So sánh nhanh theo mức độ vận hành
| Cách làm | Phù hợp khi | Rủi ro / điều kiện |
|---|---|---|
| Thu hồi toàn bộ SKU | Lỗi ảnh hưởng mọi lô hoặc dữ liệu lot không đủ tin cậy | Phạm vi lớn, chi phí cao, dừng bán cả hàng không bị ảnh hưởng |
| Tra Excel và lịch sử chat | Số đơn rất ít, một kho, một kênh và recall hiếm xảy ra | Dễ bỏ sót đơn, không khóa tồn realtime, khó chứng minh ai đã xử lý |
| Chỉ quản lý lot khi nhập kho | Cần biết lô nào đang có nhưng chưa cần truy đến đơn đã giao | Không xác định được khách nhận lô nào nếu picking/checking không ghi lot |
| JSTERP OMS + WMS theo recall ID | Nhiều kênh, kho, batch/lot, 3PL và cần truy từ lô đến đơn rồi nhận hàng về | Cần dữ liệu lô sạch, rule scan, quyền duyệt và UAT tình huống recall trước go-live |
Product recall không bắt đầu bằng việc gọi khách hàng
Trước khi gửi thông báo, doanh nghiệp phải xác định phạm vi có thể tin cậy. Recall notice từ nhà cung cấp có thể nêu SKU, batch, ngày sản xuất, hạn dùng, serial range hoặc khoảng thời gian xuất xưởng. Dữ liệu này cần được chuẩn hóa thành một recall ID cùng mức độ nghiêm trọng, lý do, owner và thời hạn containment.
OMS + WMS sau đó truy hai hướng. Hướng thứ nhất đi từ lot đến tồn đang nằm trong kho, đơn chưa xuất, kiện đang vận chuyển và đơn đã giao. Hướng thứ hai đi từ đơn/kiện khách trả về đến SKU-lot vật lý. Nếu chỉ có danh sách khách nhưng không khóa tồn, kho vẫn có thể xuất thêm hàng; nếu chỉ khóa kho mà không truy đơn, rủi ro ngoài thị trường vẫn chưa được xử lý.
Khoanh phạm vi trên toàn bộ vòng đời đơn hàng
“Tồn hiện tại” không chỉ là hàng available trên kệ. Một lot có thể đã reserved cho đơn, nằm trên xe chuyển kho, đang ở giỏ picking, đã đóng kiện hoặc chờ carrier lấy. Công cụ thu hồi phải quét mọi trạng thái này và giao nhiệm vụ cho đúng owner thay vì xuất một báo cáo tĩnh rồi để đội vận hành tự chia việc.
| Phạm vi | Dữ liệu cần tìm | Hành động kiểm soát |
|---|---|---|
| Tồn trong kho | Available, reserved, picked, packed, staging, in-transfer, QC hold, damaged, return pending và tồn tại 3PL | Khóa đúng SKU-lot và tạo nhiệm vụ kiểm đếm/chuyển quarantine |
| Đơn chưa bàn giao | Đơn đã giữ tồn, wave đã release, picking dở, checking hoặc packing xong | Dừng release; chặn PDA/packing; gỡ đúng hàng khỏi đơn và cấp lô thay thế nếu được duyệt |
| Đơn đang vận chuyển | Mã vận đơn, carrier, mốc bàn giao, trạng thái giao và khả năng intercept | Yêu cầu 3PL chặn giao hoặc hoàn về; giữ log yêu cầu và kết quả |
| Đơn đã giao | Marketplace order ID, khách nhận, SKU-lot, số lượng, ngày giao, refund/đổi trả | Tạo danh sách liên hệ có ưu tiên; ghi nhận đã liên hệ, phản hồi và hướng xử lý |
| Hàng hoàn / đổi trả | Kiện đã về, đang trên đường về hoặc nằm ở khu return chưa QC | Scan recall ID; không nhập lại available; chuyển quarantine và đối chiếu đơn gốc |
WMS phải giữ chain of custody của batch/lot
Truy vết chỉ chính xác nếu lot đi cùng hàng qua từng thao tác. Ghi lot tại receiving nhưng sau đó cho phép nhân viên chuyển, pick hoặc pack mà không scan sẽ làm đứt chuỗi bằng chứng. Hệ thống có thể giả định FEFO đã chọn lot A, trong khi picker thực tế lấy lot B ở vị trí bên cạnh.
Với ngành cần kiểm soát cao, PDA hoặc packing station phải xác nhận lot thực tế trước khi kiện được đóng. Dữ liệu này nối với order ID và mã vận đơn, cho phép OMS xác định khách nhận. Với hàng có serial, lot là phạm vi sản xuất còn serial giúp thu hẹp tới từng đơn vị sản phẩm.
| Điểm vận hành | Dữ liệu phải ghi | Cổng kiểm soát |
|---|---|---|
| Receiving | Scan SKU, barcode, batch/lot, hạn dùng, số lượng; đối chiếu PO/ASN và chứng từ nhà cung cấp. | Lot thiếu hoặc không đọc được phải vào hold, không tự gán lô gần nhất. |
| Putaway / replenishment | Giữ lot khi chuyển vị trí; scan nguồn và đích; không trộn lô nếu quy tắc ngành hàng yêu cầu tách. | Mọi di chuyển phải giữ chain of custody. |
| Picking | PDA hướng dẫn đúng bin và ghi lot thực lấy; áp dụng FEFO/FIFO khi phù hợp. | PDA phải chặn lot bị recall dù picker nhập tay hoặc đổi vị trí. |
| Checking / packing | Quét lại SKU-lot-serial, xác nhận số lượng và nối dữ liệu vật lý vào order/parcel. | Đây là cổng cuối để ngăn lô khóa rời kho và là bằng chứng khách đã nhận lô nào. |
| Bàn giao 3PL | Nối mã kiện, mã vận đơn, manifest, thời điểm và người/carrier nhận. | Giúp xác định kiện có thể intercept hay đã chuyển trách nhiệm vận chuyển. |
| Return receiving | Scan return ID/recall ID, đơn gốc, SKU-lot, tình trạng seal và số lượng. | Hàng recall luôn vào quarantine trước QC, không quay thẳng lại tồn bán. |
OMS điều phối đơn, khách và nghĩa vụ sau bán
Khi WMS trả về danh sách shipment có lot bị ảnh hưởng, OMS cần phân nhóm theo trạng thái: chưa xuất, đang giao, đã giao, đã refund, đang đổi trả hoặc đã hoàn kho. Mỗi nhóm có playbook khác nhau. Đơn chưa xuất có thể thay lô; đơn đang giao cần hỏi khả năng intercept; đơn đã giao cần quy trình liên hệ và phương án đổi, hoàn tiền hoặc hướng dẫn theo chính sách đã phê duyệt.
Marketplace order ID phải được giữ cùng internal order ID, khách nhận và shipment. Shopee, Lazada, TikTok Shop hay website có thể khác về cách liên hệ và xử lý refund, nhưng recall case nội bộ vẫn cần một trạng thái chung: chưa liên hệ, đã liên hệ, khách xác nhận, đang thu hồi, đã nhận, đã bồi hoàn hoặc đóng có lý do.
Khu cách ly phải là trạng thái hệ thống, không chỉ là góc kho
Dán bảng “hàng chờ xử lý” không đủ. Quarantine phải gồm inventory status không được đồng bộ lên tồn bán, bin location riêng, quyền di chuyển hạn chế và recall ID bắt buộc. Khi kiện về, nhân viên scan mã vận đơn/return ID, đối chiếu đơn gốc rồi scan SKU, lot, serial, số lượng và tình trạng seal.
Sau QC, disposition có thể là trả nhà cung cấp, rework, tiêu hủy, giữ mẫu, mở lại bán hoặc phương án khác theo chính sách. Mỗi quyết định cần người duyệt, lý do, ảnh/chứng từ và số lượng. Không nên đóng recall chỉ vì đã liên hệ hết khách; tồn cách ly chưa disposition và kiện đang hoàn vẫn là exposure chưa kết thúc.
Khi nào nên dùng giải pháp này?
Giải pháp phù hợp khi doanh nghiệp cần kiểm soát lô, hạn dùng hoặc serial và đang bán qua nhiều kênh/kho. Không cần chờ một sự cố lớn mới xây quy trình. Pilot nên được chạy trước bằng một recall giả lập để kiểm tra thời gian truy xuất, khả năng khóa tồn và khoảng trống dữ liệu.
| Vai trò | Dấu hiệu nên triển khai |
|---|---|
| Chủ doanh nghiệp | Nên dùng khi một recall có thể ảnh hưởng doanh thu, uy tín, an toàn khách hàng hoặc quan hệ với nhà cung cấp nhưng hiện chưa đo được tổng exposure trong ngày. |
| Operations manager | Nên dùng khi ecommerce, CSKH, kho, kế toán và 3PL đang tự giữ danh sách riêng, không có một recall ID cùng owner và deadline. |
| Warehouse manager | Nên dùng khi lot được ghi lúc nhập nhưng nhân viên có thể trộn vị trí, đổi lot khi picking hoặc nhập hàng hoàn về available mà không QC. |
| Ecommerce team | Nên dùng khi cần dừng listing, xác định đơn trên nhiều marketplace, ưu tiên khách đã nhận và theo dõi refund/đổi hàng theo cùng một phạm vi. |
| QA / CSKH / kế toán | Nên dùng khi cần lưu thông báo lỗi, bằng chứng liên hệ, chi phí thu hồi, claim nhà cung cấp, bồi hoàn và kết quả disposition để đóng hồ sơ. |
Ngoại lệ phải được thiết kế trước, không xử lý bằng phỏng đoán
Recall thật hiếm khi có dữ liệu hoàn hảo. Có đơn thiếu lot, bin trộn hàng, khách không phản hồi và kiện hoàn sai sản phẩm. Quy trình tốt không che các khoảng trống này bằng giả định; nó mở rộng phạm vi an toàn, đưa case vào hàng đợi ngoại lệ và lưu lý do quyết định.
| Ngoại lệ | Cách xử lý |
|---|---|
| Cùng SKU nhưng thiếu lot trên một số đơn | Đánh dấu nhóm không xác định; mở rộng phạm vi theo khoảng thời gian, kho, ca hoặc inbound liên quan; không tự suy đoán lot từ FEFO. |
| Hai lot bị trộn trong cùng bin | Khóa cả vị trí, cycle count có scan từng đơn vị/thùng, chuyển sang bin tách biệt rồi mới thu hẹp phạm vi. |
| Đơn packed nhưng chưa manifest | Chặn scan outbound, mở kiện theo kiểm soát, thay lô nếu được phép và lưu log re-pack cùng label mới/cũ. |
| Đơn đã giao nhưng khách không phản hồi | Giữ case ở trạng thái chưa kiểm soát, thử đúng kênh liên hệ theo chính sách và không tính là hoàn tất chỉ vì đã gửi một tin nhắn. |
| Hàng thu hồi không khớp lot đã giao | Đưa vào exception quarantine, đối chiếu barcode/serial/ảnh packing; không cộng nhầm vào số lượng recall recovered. |
| 3PL báo đã hoàn nhưng kho chưa nhận | Theo dõi mã vận đơn hoàn và SLA; trách nhiệm chỉ chuyển về kho khi có scan nhận kiện cùng tình trạng thực tế. |
Chỉ số chứng minh recall đã được kiểm soát
Báo cáo “đã xử lý” không đủ để nghiệm thu. Dashboard cần cho thấy exposure ban đầu, số đã containment, số khách chưa liên hệ, kiện đang về, tồn đang quarantine và số case còn quá hạn. Các chỉ số phải tách theo SKU, lot, kho, kênh, carrier và owner để thấy điểm nghẽn.
| KPI | Cách hiểu | Mục đích |
|---|---|---|
| Time to identify | Từ lúc mở recall đến khi xác định danh sách tồn, đơn và kiện liên quan | Đo khả năng truy vết dữ liệu |
| Time to containment | Từ lúc mở recall đến khi SKU-lot bị khóa ở mọi kho/trạng thái | Đo tốc độ ngăn rủi ro lan rộng |
| Exposure accuracy | Số đơn/tồn xác minh đúng so với kết quả kiểm tra cuối | Phát hiện lỗ hổng scan và mapping lot |
| Contact / recovery rate | Đơn đã liên hệ và hàng đã thu hồi trên tổng phạm vi cần xử lý | Đo hiệu quả điều phối sau bán |
| Quarantine aging | Số lượng/giá trị hàng recall chờ QC hoặc disposition theo tuổi tồn | Ngăn khu cách ly biến thành tồn mù |
| Recall leakage | Lần lot bị khóa vẫn được pick, pack, chuyển kho hoặc bán | Chỉ số phải về 0 sau khi containment |
Checklist pilot và go-live
- Chọn nhóm SKU pilot có batch/lot rõ và rủi ro thực tế như mỹ phẩm, thực phẩm bổ sung, mẹ và bé hoặc hàng có serial.
- Làm sạch SKU master, đơn vị tính, barcode, batch/lot, hạn dùng, nhà cung cấp, PO/ASN và mapping sản phẩm theo kênh.
- Quy định điểm bắt buộc scan lot: receiving, di chuyển, picking hoặc checking, packing, return receiving và cycle count.
- Tạo inventory status cùng vị trí riêng cho recall hold, quarantine, pending QA, vendor return, rework và disposal.
- Định nghĩa recall ID, severity, phạm vi, owner, thời hạn, quyền mở/thu hẹp/đóng và điều kiện phê duyệt disposition.
- UAT bằng lot còn trong kho, lot đã reserved, đơn đang pick, kiện đã pack, đơn đang giao, đơn đã giao, hàng hoàn sai lot và bin bị trộn lot.
- Kiểm tra luồng dữ liệu với Shopee, Lazada, TikTok Shop, website, CSKH, kế toán, nhà cung cấp và 3PL trước go-live.
- Nghiệm thu bằng time to identify, time to containment, exposure accuracy, recall leakage, recovery rate và quarantine aging.
Nên chạy tabletop exercise và một recall giả lập trước mùa cao điểm: chọn một lot, đo thời gian tìm tồn-đơn, thử khóa khi kho đang vận hành, nhận một kiện hoàn mẫu và đối soát số lượng cuối. Kết quả này cho thấy quy trình có thật sự dùng được hay chỉ đúng trên tài liệu.
JSTERP có thể hỗ trợ như thế nào?
JST ERP Việt Nam có thể cùng doanh nghiệp khảo sát luồng PO/ASN, receiving, batch/lot, barcode, bin location, PDA, picking, checking, packing, marketplace order, 3PL và hàng hoàn. Từ đó đội triển khai xác định dữ liệu bắt buộc, điểm scan, quyền khóa tồn, recall workflow, báo cáo và bộ UAT phù hợp với ngành hàng.
Doanh nghiệp có thể xem sản phẩm OMS + WMS, giải pháp vận hành marketplace đa kênh và giải pháp vận hành kho. Nếu đang quản lý lot nhưng chưa truy được tới đơn đã giao, hãy đăng ký tư vấn để JST ERP Việt Nam rà soát một SKU, một kho và một tình huống recall mẫu trước khi mở rộng.