Giải pháp kiểm soát hàng chờ QC sau hoàn trong OMS + WMS: nhập lại đúng, bán lại an toàn

Tóm tắt nhanh

Doanh nghiệp ecommerce Việt Nam nên quản lý hàng hoàn chờ QC bằng OMS + WMS khi bán trên Shopee, Lazada, TikTok Shop, livestream và social commerce. Hàng hoàn cần được scan nhận về, đối chiếu đơn gốc, kiểm SKU/barcode, kiểm tình trạng bao bì, phụ kiện, số lượng, serial/IMEI hoặc batch nếu ngành hàng yêu cầu. Sau QC, WMS phải tách rõ tồn bán được, tồn cần đóng gói lại, tồn lỗi, tồn thiếu phụ kiện, tồn chờ nhà cung cấp xử lý và tồn hủy. OMS cần cập nhật trạng thái đổi trả, hoàn tiền, COD và báo cáo nguyên nhân hoàn để CSKH, kế toán và kho nhìn cùng một dữ liệu. Cách này giúp JST ERP Việt Nam hỗ trợ doanh nghiệp giảm lệch tồn sau hàng hoàn, tránh bán lại hàng lỗi, kiểm soát trách nhiệm kho và giữ tồn khả dụng đúng cho các kênh marketplace.

• Từ khóa trọng tâm: giải pháp kiểm soát hàng chờ QC sau hoàn, hàng hoàn chờ kiểm OMS WMS, quy trình QC hàng hoàn ecommerce.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần gom đơn đa kênh, xử lý đổi trả, COD, SKU, barcode, PDA, vị trí kho, tồn khả dụng và báo cáo vận hành.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, livestream, COD và chính sách đổi trả khiến hàng hoàn về kho liên tục nhưng chất lượng không đồng nhất.
• Quy trình kho liên quan: scan kiện hoàn, đối chiếu đơn gốc, QC SKU/barcode/phụ kiện, phân loại tồn, putaway về vị trí phù hợp và cập nhật tồn khả dụng sau kiểm.

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

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

Vì sao hàng hoàn không thể nhập thẳng lại vào tồn bán được?

Khi một đơn bị hoàn, hệ thống bán hàng thường chỉ thấy đơn không giao thành công hoặc khách trả hàng. Nhưng kho lại phải trả lời câu hỏi khác: hàng đó còn đủ điều kiện bán lại không. Một SKU mỹ phẩm có thể bị móp hộp; một sản phẩm điện tử có thể thiếu cáp; một món thời trang có thể sai size nhưng còn mới; một combo có thể chỉ hoàn một phần.

Nếu doanh nghiệp nhập thẳng tất cả hàng hoàn vào tồn khả dụng, marketplace sẽ tiếp tục nhận đơn dựa trên tồn không đáng tin cậy. Lỗi xuất hiện muộn hơn ở bước picking hoặc checking: nhân viên thấy còn tồn trên hệ thống nhưng vị trí chỉ có hàng lỗi, hàng thiếu phụ kiện hoặc hàng chưa được đóng gói lại.

• Tồn vật lý đã về kho không đồng nghĩa với tồn có thể bán.
• Hàng chờ QC cần trạng thái riêng, vị trí riêng và quyền xử lý riêng.
• Đơn hoàn phải liên kết với đơn gốc, khách, kênh bán, lý do hoàn và trạng thái COD.

OMS cần giữ được câu chuyện sau bán của từng đơn hoàn

Một quy trình hoàn hàng tốt bắt đầu từ OMS. Hệ thống phải biết đơn gốc đến từ Shopee, Lazada, TikTok Shop, livestream hay website; khách trả vì lý do gì; đơn đã thu COD hay chưa; có yêu cầu đổi hàng, hoàn tiền, xuất bù hoặc khiếu nại vận chuyển không. Nếu những thông tin này chỉ nằm trong chat CSKH, kho sẽ nhận hàng nhưng không hiểu cách xử lý.

OMS cũng cần tách trạng thái sau bán rõ ràng: yêu cầu hoàn mới, đã duyệt hoàn, đang vận chuyển về kho, đã về kho chờ QC, QC đạt, QC không đạt, cần đóng gói lại, chờ quyết định kế toán, đã hoàn tiền, đã xuất đổi. Mỗi trạng thái phải dẫn đến một hành động tiếp theo thay vì để nhân viên tự hỏi nhau.

• Liên kết đơn hoàn với đơn bán ban đầu, mã vận đơn, khách hàng, kênh bán và SKU.
• Chuẩn hóa lý do hoàn: khách từ chối nhận, sai sản phẩm, lỗi sản phẩm, đổi size, thiếu phụ kiện, giao trễ hoặc lỗi vận chuyển.
• Tách trách nhiệm giữa CSKH, kho, kế toán COD và quản lý duyệt xử lý ngoại lệ.

WMS cần tạo vùng hàng chờ QC thay vì cộng tồn ngay

Khi kiện hoàn về kho, WMS nên tạo nhiệm vụ nhận hàng hoàn bằng PDA. Nhân viên scan mã vận đơn hoặc mã RMA, scan SKU/barcode, kiểm số lượng, chụp ảnh nếu cần, ghi nhận tình trạng bao bì và đưa hàng vào vị trí chờ QC. Ở bước này, tồn vật lý tăng nhưng tồn khả dụng chưa tăng.

Sau khi QC, hệ thống mới quyết định trạng thái tồn. Hàng đạt có thể nhập lại vị trí pick face hoặc bulk; hàng cần đóng gói lại vào khu repack; hàng lỗi vào khu quarantine; hàng thiếu phụ kiện chờ bổ sung; hàng sai SKU hoặc nghi tráo hàng vào ngoại lệ. Việc phân loại này giúp quản lý nhìn rõ vốn hàng đang bị treo ở đâu.

• Dùng PDA scan kiện hoàn, SKU, barcode, vị trí nhận và người thao tác.
• Tách tồn chờ QC, tồn bán được, tồn cần repack, tồn lỗi, tồn thiếu phụ kiện và tồn hủy.
• Không đồng bộ hàng chờ QC lên Shopee, Lazada, TikTok Shop như tồn có thể bán.

Kết quả QC phải cập nhật tồn khả dụng và báo cáo nguyên nhân hoàn

QC không chỉ là thao tác kho. Kết quả QC ảnh hưởng đến tồn khả dụng, báo cáo lỗi sản phẩm, quyết định hoàn tiền, đối soát COD và đánh giá nhà vận chuyển. Nếu hàng hoàn do khách từ chối nhận nhưng còn nguyên trạng, doanh nghiệp có thể bán lại nhanh. Nếu hàng lỗi do đóng gói sai, cần ghi nhận lỗi ở bước packing. Nếu thiếu phụ kiện, cần biết thiếu từ trước khi giao hay mất trong quá trình vận chuyển.

Báo cáo nguyên nhân hoàn cũng giúp đội vận hành cải thiện quy trình. Ví dụ một SKU có tỷ lệ móp hộp cao có thể cần thay đổi vật tư đóng gói; một kênh có tỷ lệ từ chối COD cao cần xem lại xác nhận đơn; một nhân viên packing có nhiều lỗi thiếu phụ kiện cần đào tạo lại.

• QC đạt mới cộng vào tồn khả dụng và cho phép đồng bộ lên marketplace.
• QC không đạt phải có lý do chuẩn để báo cáo theo SKU, kênh bán, kho, nhân viên và nhà vận chuyển.
• Kết quả QC cần đồng bộ cho CSKH và kế toán để xử lý hoàn tiền, đổi hàng hoặc COD.

Ví dụ luồng xử lý một kiện hoàn trong OMS + WMS

Một đơn TikTok Shop gồm SKU A và SKU B bị khách từ chối nhận. Khi kiện về kho, nhân viên scan mã vận đơn trên PDA. OMS nhận diện đơn gốc, trạng thái COD chưa thu và lý do hoàn từ sàn. WMS yêu cầu mở kiện, scan từng SKU, kiểm barcode và số lượng. SKU A còn nguyên, SKU B bị móp hộp.

Sau QC, SKU A được chuyển vào tồn bán được và putaway về vị trí A-02-03. SKU B được chuyển vào trạng thái cần repack tại khu RP-01. OMS cập nhật đơn hoàn đã QC một phần, kế toán không ghi nhận COD thu, CSKH có thể xử lý thông tin với khách nếu cần. Tồn đồng bộ lên sàn chỉ tăng với SKU A, không tăng với SKU B cho đến khi repack xong.

• Mỗi sản phẩm trong cùng một kiện hoàn có thể có kết quả QC khác nhau.
• Tồn khả dụng chỉ tăng theo SKU và trạng thái đạt điều kiện bán lại.
• Vị trí kho sau QC phải rõ để lần picking tiếp theo không lấy nhầm hàng chờ xử lý.

Checklist go-live cho hàng hoàn chờ QC

Trước khi go-live, doanh nghiệp nên chuẩn bị danh sách lý do hoàn, trạng thái QC, khu vực nhận hàng hoàn, khu repack, khu hàng lỗi, quyền duyệt nhập lại tồn và báo cáo cần xem hằng ngày. Đừng chỉ kiểm thử một đơn hoàn đơn giản; hãy dùng tình huống thật có nhiều SKU, thiếu phụ kiện, sai barcode, đổi hàng và COD.

Điểm nghiệm thu quan trọng là hệ thống có ngăn được hàng chưa QC quay lại tồn bán được hay không. Nếu thao tác kho vẫn có thể bỏ qua QC để cộng tồn, doanh nghiệp chưa giải quyết được rủi ro cốt lõi của hàng hoàn.

• Tạo mã vị trí cho return receiving, QC hold, repack, quarantine, scrap và putaway sau QC.
• Kiểm thử đơn hoàn từ Shopee, Lazada, TikTok Shop, livestream và đơn nhập tay.
• Đặt chỉ số nghiệm thu: thời gian từ hàng về đến QC xong, tỷ lệ QC không đạt, tồn chờ QC quá hạn và giá trị hàng bị treo.

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 hàng chờ QC sau hoàn 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 nhập hàng hoàn về kho, kiểm barcode, phân loại chất lượng, tách tồn bán được với tồn chờ xử lý, liên kết đơn hoàn với COD và cập nhật tồn khả dụng đúng cho Shopee Lazada TikTok Shop, 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 hàng chờ QC sau hoàn 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 kênh phát sinh hàng hoàn: Shopee, Lazada, TikTok Shop, livestream, website, social commerce và đơn nhập tay.
• Danh sách lý do hoàn và trạng thái sau bán cần chuẩn hóa trong OMS.
• Quy định QC theo ngành hàng: barcode, serial/IMEI, batch, hạn sử dụng, phụ kiện, bao bì, seal và hình ảnh bằng chứng.
• Sơ đồ vị trí kho cho hàng chờ QC, hàng đạt, hàng cần repack, hàng lỗi, hàng thiếu phụ kiện và hàng hủy.
• Quyền thao tác: ai được nhận hàng hoàn, ai được xác nhận QC đạt, ai được chuyển hàng lỗi và ai được duyệt nhập lại tồn bán được.
• Báo cáo cần theo dõi: tồn chờ QC quá hạn, tỷ lệ QC không đạt theo SKU, giá trị hàng hoàn, lỗi packing, lỗi vận chuyển và tác động COD.

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

JSTERP hỗ trợ kiểm soát hàng chờ QC sau hoàn bằng cách nối dữ liệu OMS và thao tác WMS. Doanh nghiệp có thể nhìn từ đơn gốc, lý do hoàn, kênh bán, trạng thái COD đến kết quả scan, QC, vị trí kho và tồn khả dụng sau kiểm.

Đội triển khai JST ERP Việt Nam có thể khảo sát quy trình đổi trả hiện tại, số lượng hàng hoàn mỗi ngày, ngành hàng, yêu cầu barcode/serial/batch, sơ đồ kho và báo cáo cần quản trị để đề xuất luồng go-live phù hợp. Mục tiêu không chỉ là nhập hàng hoàn nhanh hơn, mà là bán lại đúng hàng đủ điều kiện và giữ tồn marketplace đáng tin cậy.

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.