Đối soát thiếu hàng và xuất bù trong OMS + WMS: xử lý thiếu SKU không làm rối tồn kho

Tóm tắt nhanh

Đối soát thiếu hàng trong OMS + WMS là quy trình xử lý khi picking hoặc checking phát hiện SKU không đủ, sai barcode, sai vị trí hoặc không đạt điều kiện xuất. OMS cần ghi nhận phần đơn bị ảnh hưởng, giữ lại phần hàng còn đủ, cập nhật lựa chọn hủy một phần/đổi SKU/xuất bù và đồng bộ trạng thái với kênh bán. WMS cần truy vết vị trí kho, barcode, người thao tác, nguyên nhân thiếu và trạng thái tồn sau xử lý. Với doanh nghiệp ecommerce Việt Nam, quy trình này giúp giảm khiếu nại, giảm lệch tồn, tránh xuất bù không kiểm soát và giữ dữ liệu COD rõ ràng.

• Từ khóa trọng tâm: đối soát thiếu hàng OMS WMS, xuất bù đơn hàng ecommerce, hủy một phần đơn hàng, xử lý thiếu SKU sau checking.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần kiểm soát đơn đa kênh, SKU, barcode, bin location, tồn khả dụng, picking, checking, packing, xuất bù, đổi trả và báo cáo lỗi kho.
• Bối cảnh Việt Nam: đơn từ Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website, Facebook và Zalo thường có combo, quà tặng, COD, đổi hàng và khiếu nại sau bán.
• Quy trình kho liên quan: giữ tồn, wave picking, PDA scan, kiểm barcode, checking, packing, báo thiếu SKU, tìm vị trí thay thế, hủy một phần, xuất bù, hoàn tồn và cycle count.

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

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

Vì sao thiếu hàng phải được đối soát ngay tại bước checking?

Nhiều kho chỉ phát hiện thiếu hàng khi nhân viên đóng gói không đủ sản phẩm. Lúc này đơn đã qua picking, tem vận đơn có thể đã in, khách đã chờ giao và tồn hệ thống vẫn đang giữ cho đơn. Nếu không chặn tại checking, một đơn thiếu SKU có thể rời kho dưới dạng giao thiếu, gây khiếu nại, hoàn tiền, đánh giá xấu và mất thời gian tìm lại bằng chứng.

Checking bằng barcode là điểm tốt nhất để xác nhận đơn có đủ SKU, đúng biến thể, đúng số lượng và đúng quà tặng hay chưa. Khi phát hiện thiếu, WMS phải tạo ngoại lệ ngay: thiếu SKU nào, thiếu bao nhiêu, vị trí picking nào trống, nhân viên nào scan, có vị trí thay thế không và đơn có được tiếp tục packing phần còn lại hay phải giữ lại chờ CSKH.

• Không cho packing khi dòng hàng bị thiếu chưa có quyết định xử lý.
• Ghi nhận thiếu ở cấp SKU/dòng hàng, không chỉ ghi chú ở cấp đơn.
• Liên kết nguyên nhân thiếu với barcode, bin location, người thao tác và thời điểm scan.

Các nguyên nhân thiếu hàng thường gặp trong kho ecommerce

Thiếu hàng không luôn có nghĩa là doanh nghiệp thật sự hết hàng. Có trường hợp SKU nằm sai vị trí, hàng đang ở khu chờ QC, hàng đã được giữ cho đơn khác, nhân viên lấy nhầm biến thể, combo thiếu một thành phần, quà tặng chưa được bổ sung vào fast-pick hoặc tồn từ kho 3PL cập nhật chậm. Nếu chỉ ghi “thiếu hàng”, quản lý không biết nên xử lý bằng bổ sung hàng, kiểm kê, điều chuyển hay sửa dữ liệu.

JSTERP OMS + WMS nên tách nguyên nhân thiếu thành nhóm rõ: thiếu tồn vật lý, sai vị trí, sai barcode, tồn bị giữ, hàng chờ kiểm, hàng lỗi, thiếu quà tặng, thiếu thành phần combo, kho khác còn hàng hoặc dữ liệu tồn đầu kỳ sai. Mỗi nhóm dẫn đến hành động khác nhau và báo cáo cuối ngày mới có giá trị cải tiến.

• Thiếu do vị trí: tạo nhiệm vụ tìm vị trí thay thế hoặc cycle count vị trí đang sai.
• Thiếu do tồn giữ: OMS kiểm đơn nào đang chiếm tồn và có được release không.
• Thiếu do combo/quà tặng: WMS chặn packing nếu thiếu thành phần bắt buộc.
• Thiếu do dữ liệu: cần điều chỉnh tồn có phê duyệt thay vì để nhân viên tự sửa.

OMS quyết định hủy một phần, đổi SKU hay xuất bù như thế nào?

Khi WMS báo thiếu, OMS là nơi quyết định nghiệp vụ với khách và kênh bán. Có đơn nên hủy một phần nếu marketplace cho phép và khách chấp nhận. Có đơn nên đổi sang SKU thay thế cùng màu/size gần nhất. Có đơn nên giữ lại chờ nhập hàng. Có đơn phải xuất phần đủ trước rồi tạo phiếu xuất bù sau, đặc biệt với đơn social commerce hoặc đơn khách hàng lớn.

Quy tắc nên được cấu hình theo kênh bán, giá trị đơn, loại sản phẩm, trạng thái thanh toán và SLA. Ví dụ đơn TikTok Shop sắp quá hạn có thể ưu tiên hủy một phần nếu thiếu quà tặng; đơn COD có thay đổi giá trị cần cập nhật số tiền thu; đơn B2B cần phê duyệt xuất bù; đơn Shopee/Lazada cần đối chiếu chính sách sàn trước khi chỉnh trạng thái.

• Hủy một phần phải trả tồn các SKU không xuất và cập nhật giá trị đơn/COD.
• Đổi SKU cần ghi nhận SKU gốc, SKU thay thế, người phê duyệt và lý do.
• Xuất bù phải liên kết với đơn gốc để không tạo doanh thu/tồn kho rời rạc.

Quy trình xuất bù phải khóa được rủi ro xuất trùng

Xuất bù dễ làm rối tồn vì nó thường phát sinh sau khi đơn gốc đã bàn giao hoặc đã ghi nhận doanh thu. Nếu CSKH tạo một yêu cầu trong chat, kho xuất một kiện ngoài hệ thống và kế toán không biết, doanh nghiệp sẽ mất kiểm soát cả tồn kho lẫn chi phí. Ngược lại, nếu xuất bù không giữ tồn trước, khách được hứa giao lại nhưng kho vẫn có thể hết hàng lần hai.

Một quy trình chặt nên tạo phiếu xuất bù từ OMS, liên kết đơn gốc, dòng hàng thiếu, mã vận đơn ban đầu, lý do khiếu nại và quyết định phê duyệt. Sau đó OMS giữ tồn cho SKU xuất bù, WMS tạo nhiệm vụ picking/checking/packing riêng, in tem hoặc ghi mã vận đơn mới, rồi cập nhật trạng thái cho CSKH và báo cáo sau bán.

• Không xuất bù ngoài hệ thống nếu chưa có phiếu liên kết đơn gốc.
• Giữ tồn xuất bù trước khi xác nhận lịch giao lại với khách.
• Theo dõi chi phí xuất bù: hàng hóa, phí vận chuyển, voucher hoặc hoàn tiền.

PDA và barcode giúp phân biệt thiếu thật với lấy nhầm

Nếu nhân viên báo thiếu bằng mắt, quản lý không biết hàng thiếu thật hay chỉ nằm sai kệ. PDA giúp yêu cầu scan vị trí được giao, scan barcode SKU thực tế và ghi nhận số lượng lấy được. Nếu nhân viên scan một SKU gần giống, hệ thống chặn ngay. Nếu vị trí được giao trống, WMS có thể gợi ý vị trí dự phòng hoặc tạo nhiệm vụ kiểm kê vị trí.

Với SKU nhiều biến thể như thời trang, mỹ phẩm, phụ kiện điện tử hoặc mẹ và bé, barcode là lớp kiểm soát quan trọng. Cùng một mã sản phẩm trên sàn có thể mapping sang nhiều SKU nội bộ; nếu mapping sai, OMS giữ tồn sai ngay từ đầu. Vì vậy xử lý thiếu hàng cần kiểm cả dữ liệu mapping kênh bán, SKU nội bộ, barcode kho và vị trí WMS.

• Scan vị trí nguồn để biết thiếu tại đúng bin location hay do nhân viên đến sai chỗ.
• Scan barcode sản phẩm để chặn nhầm màu, size, dung tích hoặc combo.
• Tạo nhiệm vụ cycle count khi vị trí báo còn nhưng thực tế không có hàng.

Đối soát COD và khiếu nại sau khi đơn bị thiếu hàng

Thiếu hàng ảnh hưởng trực tiếp đến tiền thu và khiếu nại. Nếu đơn COD bị hủy một phần, số tiền cần thu phải thay đổi. Nếu đơn đã giao thiếu và phải xuất bù, doanh nghiệp cần biết phần bù có thu thêm phí không, miễn phí vận chuyển hay cấn trừ vào khiếu nại. Nếu khách yêu cầu hoàn tiền thay vì nhận bù, kế toán cần dữ liệu đơn gốc, dòng hàng thiếu và trạng thái hoàn tiền.

OMS nên giữ lịch sử quyết định để CSKH, kế toán và quản lý xem cùng một dữ liệu. Một case thiếu hàng tốt phải trả lời được: đơn gốc là gì, thiếu SKU nào, nguyên nhân thiếu, khách chọn phương án nào, ai phê duyệt, tồn đã điều chỉnh chưa, kiện bù đã xuất chưa, COD đã cập nhật chưa và khiếu nại đã đóng chưa.

• Cập nhật giá trị COD khi hủy một phần hoặc đổi sản phẩm khác giá.
• Liên kết xuất bù với khiếu nại để biết chi phí sau bán.
• Không đóng case thiếu hàng nếu tồn và công nợ chưa được đối soát.

Checklist go-live cho luồng thiếu hàng và xuất bù

Trước khi go-live, doanh nghiệp nên kiểm thử bằng đơn thật hoặc dữ liệu mô phỏng giống thật: đơn một SKU thiếu toàn bộ, đơn nhiều SKU thiếu một dòng, combo thiếu quà tặng, đơn COD đổi giá trị, đơn livestream cần xuất bù, đơn sàn cần hủy một phần và đơn kho khác còn hàng. Các tình huống này giúp phát hiện lỗ hổng trước mùa sale.

Đội triển khai cũng cần phân quyền rõ. Nhân viên kho được báo thiếu nhưng không tự ý điều chỉnh tồn; CSKH được đề xuất phương án nhưng xuất bù cần phê duyệt theo giá trị; quản lý kho được tạo cycle count; kế toán được xem thay đổi COD và chi phí xuất bù. Khi quyền không rõ, hệ thống vẫn có thể bị biến thành một nhóm chat có giao diện đẹp hơn.

• Chuẩn hóa SKU, barcode, mapping kênh bán, combo và quà tặng.
• Thiết lập lý do thiếu hàng và hành động tương ứng trong OMS + WMS.
• Kiểm thử hủy một phần, đổi SKU, xuất bù, trả tồn và cập nhật COD.
• Định nghĩa báo cáo: số đơn thiếu, nguyên nhân thiếu, chi phí xuất bù và độ lệch tồn sau xử lý.

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ủ đề Đối soát thiếu hàng và xuất bù 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 đối soát thiếu SKU sau picking/checking, giữ tồn đúng, hủy một phần, đổi sản phẩm thay thế, xuất bù, cập nhật COD, xử lý khiếu nại và trả tồn về đúng trạng thái, 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 Đối soát thiếu hàng và xuất bù 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

• Liệt kê các tình huống thiếu hàng trong 30 ngày gần nhất: thiếu SKU, sai barcode, thiếu quà tặng, thiếu combo, kho báo không tìm thấy hàng.
• Chuẩn bị dữ liệu SKU, barcode, mapping sàn, vị trí kho, tồn khả dụng, tồn giữ đơn và trạng thái hàng chờ QC.
• Xác định quyền phê duyệt cho hủy một phần, đổi SKU, xuất bù, điều chỉnh COD và điều chỉnh tồn.
• Chọn 5-10 đơn thật để demo: đơn COD, đơn nhiều SKU, đơn livestream, đơn sàn và đơn đã phát sinh khiếu nại.
• Đặt chỉ số nghiệm thu: tỷ lệ đơn thiếu, thời gian xử lý ngoại lệ, số lần xuất bù, chi phí sau bán và độ chính xác tồn sau cycle count.

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

JSTERP hỗ trợ doanh nghiệp thiết kế luồng thiếu hàng và xuất bù bằng cách nối OMS và WMS trong cùng một quy trình. OMS giữ dữ liệu đơn, khách, kênh bán, COD, phương án xử lý và phê duyệt; WMS ghi nhận thao tác kho bằng barcode, vị trí, PDA, checking, packing và nguyên nhân thiếu.

Đội triển khai JST ERP Việt Nam có thể rà soát các lỗi thiếu hàng hiện tại, cách shop đang xử lý bằng chat/Excel/Seller Center, dữ liệu SKU và layout kho để đề xuất quy trình phù hợp. Doanh nghiệp có thể bắt đầu từ việc chuẩn hóa trạng thái ngoại lệ, sau đó mở rộng sang PDA, cycle count, báo cáo chi phí xuất bù và dashboard lỗi kho.

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.