Nhập hàng hoàn về kho WMS: kiểm tra, phân loại và cập nhật tồn đúng

Tóm tắt nhanh

Hàng hoàn không nên được cộng thẳng vào tồn bán được. Quy trình tốt cần tách rõ mã vận đơn hoàn, đơn gốc, SKU, barcode, tình trạng bao bì, kết quả kiểm hàng và trạng thái tồn sau kiểm. OMS quản lý đơn, lý do hoàn, COD, đổi trả và giao tiếp với kênh bán; WMS quản lý khu nhận hàng hoàn, PDA scan, kiểm SKU, phân loại tồn chờ kiểm, tồn bán được, hàng lỗi, hàng cần đóng gói lại và hàng chờ quyết định.

• Từ khóa trọng tâm: nhập hàng hoàn WMS, xử lý hàng hoàn ecommerce, tồn chờ kiểm, phân loại hàng hoàn.
• JST ERP Việt Nam cung cấp giải pháp ERP/OMS + WMS cho doanh nghiệp ecommerce cần kiểm soát đơn hàng, kho, tồn và sau bán tại Việt Nam.
• Kênh liên quan: Shopee, Lazada, TikTok Shop, social commerce, livestream, website, đơn COD và đơn đổi trả từ CSKH.
• Quy trình kho liên quan: mã vận đơn hoàn, SKU, barcode, bin location, khu chờ kiểm, kiểm tình trạng hàng, nhập lại tồn, đổi hàng và hủy tồn lỗi.

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 được nhập thẳng vào tồn bán được?

Một kiện hàng hoàn có thể là giao không thành công, khách từ chối nhận, đổi size, trả do lỗi sản phẩm, hoàn một phần combo hoặc hàng bị móp hộp trong quá trình vận chuyển. Các tình huống này nhìn giống nhau ở cổng kho vì đều là “hàng quay lại”, nhưng tác động lên tồn kho và báo cáo sau bán hoàn toàn khác nhau.

Nếu nhân viên kho thấy sản phẩm còn trong túi rồi cộng ngay vào tồn khả dụng, đội bán có thể tiếp tục bán một sản phẩm đã thiếu phụ kiện, sai tem, rách hộp hoặc đang chờ sàn xử lý khiếu nại. Ngược lại, nếu hàng tốt bị treo quá lâu ở khu chờ kiểm, doanh nghiệp mất tồn bán được trong mùa campaign.

• Hàng hoàn tốt, hàng cần đóng gói lại, hàng lỗi và hàng chờ quyết định phải có trạng thái khác nhau.
• Tồn chờ kiểm không nên đồng bộ lên Shopee, Lazada, TikTok Shop như tồn bán được.
• Mỗi lần nhập hoàn cần liên kết với đơn gốc, mã vận đơn và lý do hoàn để truy vết.

Thiết kế khu nhận hàng hoàn trong WMS

Khu nhận hàng hoàn nên được coi là một vùng kho riêng, không phải bàn tạm. Doanh nghiệp có thể thiết kế vị trí như RTN-RECEIVE, RTN-QC, RTN-REPACK, RTN-DAMAGE hoặc RTN-HOLD để phân biệt hàng mới về, hàng đang kiểm, hàng cần đóng gói lại, hàng lỗi và hàng chờ CSKH quyết định.

Khi kiện hoàn tới kho, nhân viên dùng PDA quét mã vận đơn, mã đơn hoặc tem kiện. WMS đối chiếu với OMS để biết đơn gốc thuộc kênh nào, khách nào, SKU nào, số lượng nào và có đang mở yêu cầu đổi trả hay không. Nếu mã vận đơn không khớp, kiện phải vào trạng thái ngoại lệ thay vì nhập bằng tay cho qua.

• Tạo vị trí riêng cho hàng hoàn mới nhận, hàng chờ kiểm, hàng đóng gói lại và hàng lỗi.
• Bắt buộc scan mã vận đơn hoàn hoặc mã đơn gốc trước khi mở phiếu nhập hoàn.
• Không cho nhập tồn bán được nếu chưa có kết quả kiểm hàng.

Quy trình scan: từ mã vận đơn đến barcode SKU

Luồng chuẩn bắt đầu bằng việc quét mã vận đơn hoàn. OMS trả về đơn gốc, kênh bán, trạng thái thanh toán, COD, danh sách SKU và lý do hoàn nếu có. Sau đó WMS yêu cầu quét barcode từng sản phẩm trong kiện để xác nhận đúng SKU, đúng biến thể, đúng số lượng. Đây là bước quan trọng với ngành thời trang, mỹ phẩm, mẹ và bé, phụ kiện điện tử hoặc combo khuyến mãi.

Nếu kiện hoàn thiếu một SKU trong combo, nhân viên không nên nhập đủ cả combo về tồn. Nếu khách trả sai màu hoặc sai size, hệ thống cần ghi nhận lệch giữa đơn gốc và hàng thực nhận. Nếu sản phẩm không còn barcode, WMS nên có quy trình kiểm thủ công có phê duyệt, tránh để nhân viên tự chọn SKU gần giống.

• Scan mã vận đơn để tìm đơn gốc và trạng thái hoàn.
• Scan barcode SKU để xác nhận hàng thực nhận.
• Ghi nhận thiếu hàng, sai SKU, mất phụ kiện hoặc thiếu bao bì như ngoại lệ riêng.

Phân loại tình trạng tồn sau khi kiểm hàng

Sau bước kiểm, hàng hoàn cần đi vào đúng trạng thái tồn. Hàng nguyên seal có thể chuyển về tồn bán được. Hàng rách hộp nhưng sản phẩm còn tốt có thể vào khu đóng gói lại. Hàng đã dùng, lỗi, vỡ, thiếu phụ kiện hoặc đang chờ tranh chấp nên chuyển sang tồn không bán được. Với sản phẩm cần vệ sinh, kiểm pin hoặc kiểm hạn dùng, doanh nghiệp nên có trạng thái kiểm chuyên sâu.

Điểm mấu chốt là trạng thái tồn phải ảnh hưởng tới OMS. Tồn bán được mới được dùng để phân bổ đơn mới và đồng bộ lên kênh bán. Tồn chờ kiểm, tồn lỗi, tồn chờ bồi thường hoặc tồn đang tranh chấp không nên tham gia tính tồn khả dụng, nếu không rất dễ overselling.

• Tồn bán được: đủ điều kiện bán lại và có thể đồng bộ lên kênh.
• Tồn chờ kiểm hoặc chờ đóng gói lại: có hàng vật lý nhưng chưa sẵn sàng bán.
• Tồn lỗi hoặc tranh chấp: không dùng để phân bổ đơn mới.

Kết nối hàng hoàn với CSKH, kế toán COD và sàn

Hàng hoàn không chỉ là nghiệp vụ kho. CSKH cần biết khách đã gửi lại hàng chưa, kho đã nhận chưa, thiếu gì, hàng có đạt điều kiện đổi trả không và khi nào có thể xuất bù. Kế toán cần biết COD đã thu, hoàn tiền hay cấn trừ ra sao. Người phụ trách sàn cần đối chiếu trạng thái hoàn với Shopee, Lazada hoặc TikTok Shop để tránh mất quyền khiếu nại.

Khi OMS và WMS nối với nhau, một kiện hàng hoàn được scan ở kho có thể cập nhật trạng thái cho nhiều bộ phận. CSKH không phải hỏi kho qua chat, kế toán nhìn được căn cứ xử lý COD, còn quản lý biết tỷ lệ hoàn theo SKU, theo kênh, theo lý do và theo hãng vận chuyển.

• CSKH cần dữ liệu nhận hàng hoàn và kết quả kiểm hàng để xử lý khách.
• Kế toán cần trạng thái COD, hoàn tiền, bồi thường hoặc cấn trừ.
• Quản lý cần báo cáo tỷ lệ hoàn theo SKU, kênh bán, lý do và ca xử lý.

Kịch bản đổi hàng: nhập hàng cũ và xuất hàng mới

Đổi hàng là trường hợp dễ gây rối vì có hai luồng tồn cùng lúc: hàng khách trả về và hàng xuất bù cho khách. Nếu không liên kết đơn gốc, phiếu nhập hoàn và đơn xuất đổi, doanh nghiệp có thể vừa cộng sai tồn hàng cũ vừa quên giữ tồn hàng mới.

Quy trình tốt là OMS tạo yêu cầu đổi hàng có điều kiện rõ: đổi size, đổi màu, đổi sản phẩm tương đương hoặc đổi sản phẩm khác giá. WMS nhận hàng cũ, kiểm tình trạng, nhập vào trạng thái phù hợp, sau đó OMS mới cho phép xuất bù nếu chính sách đổi trả đạt điều kiện. Với đơn livestream hoặc đơn social, bước này càng cần rõ vì thông tin ban đầu thường nằm trong chat.

• Liên kết đơn gốc, hàng trả về và đơn xuất đổi trong cùng một hồ sơ.
• Giữ tồn hàng xuất bù trước khi hứa lịch giao lại cho khách.
• Không tự động nhập hàng trả về vào tồn bán được nếu chưa kiểm xong.

Checklist go-live cho quy trình hàng hoàn

Trước khi go-live, doanh nghiệp nên kiểm thử bằng tình huống thật: giao không thành công, khách trả một phần, đổi size, hoàn combo thiếu phụ kiện, hàng lỗi, hàng mất barcode, hoàn sai mã vận đơn và sàn cập nhật trạng thái trễ. Các tình huống này giúp phát hiện lỗ hổng trước khi mùa campaign làm lượng hoàn tăng mạnh.

Nghiệm thu nên đo bằng chỉ số vận hành: thời gian từ lúc kiện hoàn về kho đến khi có kết quả kiểm, tỷ lệ hàng chờ kiểm quá SLA, số phiếu nhập hoàn thiếu mã vận đơn, tỷ lệ cộng nhầm tồn bán được và tỷ lệ khiếu nại COD thiếu căn cứ.

• Kiểm thử đủ tình huống hoàn toàn phần, hoàn một phần, đổi hàng và hoàn sai SKU.
• Định nghĩa rõ ai được duyệt chuyển hàng từ chờ kiểm sang bán được.
• Theo dõi hàng hoàn quá SLA để không tạo điểm nghẽn tồn kho.

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ủ đề nhập hàng hoàn về kho 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 hàng hoàn theo mã vận đơn, SKU, barcode, tình trạng hàng, tồn chờ kiểm, tồn bán được, hàng lỗi, đổi trả và đối soát sau bá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 nhập hàng hoàn về kho 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ê các kênh có hàng hoàn: Shopee, Lazada, TikTok Shop, livestream, website, COD nội bộ.
• Chuẩn hóa lý do hoàn, lý do đổi hàng và trạng thái tồn sau kiểm.
• Thiết kế khu vực RTN-RECEIVE, RTN-QC, RTN-REPACK, RTN-DAMAGE hoặc cấu trúc tương đương.
• Chuẩn bị mẫu đơn thật gồm hoàn một phần, hoàn combo, đổi size, sai SKU, mất barcode và hàng lỗi.
• Định nghĩa chỉ số nghiệm thu: thời gian kiểm hàng hoàn, tỷ lệ treo chờ kiểm, lỗi cộng nhầm tồn và tranh chấp COD.

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

JSTERP hỗ trợ nhập hàng hoàn về kho bằng cách nối OMS và WMS trong một luồng thống nhất. OMS giữ dữ liệu đơn gốc, kênh bán, COD, lý do hoàn và yêu cầu đổi trả; WMS ghi nhận thao tác nhận hàng, scan barcode, kiểm tình trạng và cập nhật trạng thái tồn.

Đội triển khai JST ERP Việt Nam có thể khảo sát quy trình sau bán hiện tại, tỷ lệ hoàn theo kênh, cách kho phân loại hàng, cách kế toán đối soát COD và các lỗi thường gặp để thiết kế lộ trình triển khai phù hợp. Doanh nghiệp có thể bắt đầu từ kiểm soát tồn chờ kiểm, sau đó mở rộng sang đổi trả, bồi thường và báo cáo tỷ lệ hoàn theo SKU.

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.