Giải pháp quản lý hàng ký gửi consignment bằng OMS + WMS: rõ chủ hàng, rõ tồn, rõ công nợ

Tóm tắt nhanh

Doanh nghiệp nên dùng OMS + WMS cho hàng ký gửi khi một kho xử lý hàng của nhiều brand, nhiều nhà cung cấp, đại lý hoặc mô hình 3PL/fulfillment. Quy trình cần rõ chủ hàng, mã SKU, barcode, batch/lot nếu có, vị trí kho, tồn khả dụng, tồn chờ bán, tồn đã giữ theo đơn, hàng đã xuất, hàng hoàn chờ QC, hàng lỗi và công nợ phát sinh theo đơn bán thành công. JST ERP Việt Nam có thể hỗ trợ thiết kế mô hình OMS + WMS để chủ doanh nghiệp, quản lý vận hành, quản lý kho và kế toán đối soát nhìn cùng một nguồn dữ liệu thay vì tranh luận bằng file rời.

• Từ khóa trọng tâm: giải pháp quản lý hàng ký gửi, consignment inventory OMS WMS, quản lý tồn ký gửi ecommerce.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần quản lý đa kênh, đa kho, SKU, barcode, PDA, tồn khả dụng, COD, hàng hoàn, đối soát và công nợ theo quy trình thật.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, livestream, social commerce, đại lý và kho 3PL thường cùng tham gia bán hoặc lưu trữ hàng nhưng điều kiện ghi nhận doanh thu và công nợ khác nhau.
• Quy trình kho liên quan: nhận hàng ký gửi, nhập kho theo chủ hàng, gán bin location, giữ tồn theo đơn, picking bằng PDA, checking barcode, packing, bàn giao vận chuyển, nhập hoàn, QC sau hoàn và khóa kỳ đối soát.

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

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

Hàng ký gửi sai thường không lộ ngay ở lúc nhập kho

Điểm nguy hiểm của consignment inventory là sai sót thường bị che trong giai đoạn đầu. Khi hàng mới nhập về, tổng tồn nhìn vẫn đúng. Nhưng đến lúc đơn bán ra, hàng hoàn quay lại, chủ hàng yêu cầu báo cáo hoặc kế toán cần chốt công nợ, doanh nghiệp mới phát hiện không biết tồn nào thuộc chủ nào, đơn nào đã phát sinh nghĩa vụ thanh toán và hàng lỗi đang nằm ở vị trí nào.

Với ecommerce đa kênh, một SKU ký gửi có thể được bán trên Shopee, Lazada, TikTok Shop, livestream và đại lý cùng lúc. Nếu tồn khả dụng không phân biệt quyền sở hữu, hệ thống có thể đẩy nhầm tồn lên sàn, kho lấy nhầm hàng của chủ khác, hoặc kế toán ghi nhận công nợ cho nhà cung cấp khi đơn chưa giao thành công.

• Cùng một mã sản phẩm cần phân biệt chủ hàng, lô hàng và điều kiện ký gửi.
• Tồn khả dụng không chỉ là số lượng trong kho mà còn là số lượng được phép bán.
• Hàng hoàn phải quay lại đúng trạng thái: bán lại được, chờ QC, lỗi, thiếu phụ kiện hoặc chờ trả chủ hàng.

OMS nên quản lý phần nào trong mô hình ký gửi?

OMS là nơi quyết định đơn hàng có được nhận, giữ tồn và ghi nhận doanh thu hay không. Với hàng ký gửi, OMS cần biết đơn đến từ kênh nào, SKU thuộc chủ hàng nào, chính sách ghi nhận công nợ ra sao, đơn COD đã giao thành công chưa, đơn prepaid có bị hoàn tiền không và khi nào hàng được xem là đã bán thật.

Một thiết kế tốt không ghi nhận công nợ ngay khi đơn vừa tạo nếu điều kiện ký gửi yêu cầu giao thành công hoặc hết thời gian đổi trả. OMS cần lưu trạng thái rõ ràng: đơn mới, đã giữ tồn, đã xuất kho, đang giao, giao thành công, hoàn một phần, hoàn toàn bộ, hủy do hết hàng hoặc tranh chấp COD.

• Gắn owner code hoặc supplier code vào SKU, lô hàng và dòng đơn.
• Giữ tồn theo đơn để tránh overselling nhưng chưa vội ghi nhận công nợ khi đơn chưa hoàn tất.
• Tách báo cáo doanh thu bán hàng, doanh thu đã đối soát, công nợ phải trả và công nợ chờ xác nhận.

WMS phải chặn trộn hàng ngay tại thao tác kho

Nếu OMS giữ đúng tồn nhưng WMS không kiểm soát vị trí và barcode, kho vẫn có thể lấy nhầm hàng. Với hàng ký gửi, sai một lần picking không chỉ là sai hàng cho khách mà còn là sai quyền sở hữu: hàng của chủ A bị bán cho đơn của chủ B, công nợ lệch, tồn báo cáo lệch và trách nhiệm khó xác định.

WMS nên yêu cầu nhập kho theo phiếu ký gửi, scan barcode, gán vị trí, hiển thị owner khi picking và bắt checking xác nhận đúng SKU, đúng chủ hàng, đúng lô nếu có. Với kho 3PL hoặc kho có nhiều brand, khu staging và tem kiện cũng cần ghi nhận để không trộn đơn trước lúc bàn giao vận chuyển.

• Nhập kho theo owner, SKU, barcode, batch/lot, hạn sử dụng nếu ngành hàng cần.
• Picking bằng PDA theo vị trí kho thay vì lấy hàng theo trí nhớ của nhân viên.
• Checking barcode chặn sai SKU, sai chủ hàng, sai combo và sai số lượng trước khi packing.

Hàng hoàn là nơi dễ làm hỏng toàn bộ báo cáo ký gửi

Nhiều doanh nghiệp kiểm soát hàng xuất khá tốt nhưng thất bại ở hàng hoàn. Đơn COD giao không thành, khách đổi size, khách trả thiếu phụ kiện hoặc sàn hoàn về sau nhiều ngày đều làm trạng thái tồn thay đổi. Nếu hàng hoàn được nhập thẳng lại tồn bán được, doanh nghiệp có thể bán tiếp hàng lỗi hoặc ghi giảm công nợ sai.

Quy trình đúng là hàng hoàn đi qua khu nhận hoàn, scan mã vận đơn hoặc mã đơn, xác định chủ hàng, kiểm SKU, kiểm tình trạng, sau đó mới phân loại. Tồn bán lại được mới quay về available stock; hàng lỗi vào tồn lỗi; hàng thiếu phụ kiện vào trạng thái chờ xử lý; hàng phải trả chủ hàng vào khu chờ trả.

• Return QC cần ghi nhận lý do hoàn, tình trạng sản phẩm, ảnh bằng chứng nếu cần.
• Tồn sau hoàn phải cập nhật theo chủ hàng và trạng thái, không nhập gộp vào tồn thường.
• Đối soát COD và công nợ ký gửi phải xét cả hoàn một phần, hoàn toàn bộ và phí vận chuyển.

Khi nào doanh nghiệp nên dùng giải pháp này?

Giải pháp này phù hợp với chủ doanh nghiệp, quản lý vận hành, quản lý kho, ecommerce team và kế toán khi số lượng chủ hàng hoặc kênh bán đã vượt khả năng kiểm soát bằng file. Dấu hiệu rõ nhất là đội kho phải hỏi liên tục hàng này thuộc ai, kế toán mất nhiều ngày chốt công nợ, hoặc chủ hàng thường xuyên hỏi báo cáo tồn nhưng doanh nghiệp không trả lời ngay được.

Nó cũng phù hợp với kho fulfillment/3PL muốn phục vụ nhiều brand mà vẫn tách được tồn, phí lưu kho, phí xử lý đơn, phí hoàn hàng và trách nhiệm mất mát. Nếu không tách owner inventory từ đầu, càng thêm khách hàng 3PL thì rủi ro tranh chấp càng lớn.

• Có nhiều brand, nhà cung cấp, đại lý hoặc chủ hàng cùng lưu kho.
• Có điều kiện công nợ khác nhau: bán được mới trả, sau giao thành công mới trả, hoặc sau kỳ đổi trả mới trả.
• Có hàng hoàn, đổi trả, kiểm QC, kho 3PL, nhiều vị trí hoặc nhiều kênh marketplace.

Go-live cần kiểm tra gì trước khi chạy thật?

Trước go-live, doanh nghiệp cần chuẩn hóa dữ liệu nền thay vì chỉ import danh sách sản phẩm. Tối thiểu phải có mã chủ hàng, hợp đồng hoặc điều kiện ký gửi, SKU, barcode, đơn vị tính, combo, vị trí kho, tồn đầu kỳ theo chủ hàng, trạng thái tồn và quyền người dùng.

Kịch bản kiểm thử nên dùng đơn thật hoặc mô phỏng đủ phức tạp: đơn nhiều SKU thuộc nhiều chủ hàng, đơn hủy trước picking, đơn đã packing nhưng chưa bàn giao, đơn COD giao không thành, đơn hoàn thiếu phụ kiện, đơn đổi hàng và kỳ đối soát cuối tháng. Nếu các tình huống này chưa chạy được, hệ thống chưa sẵn sàng cho mùa sale.

• Đối chiếu tồn đầu kỳ theo owner, SKU, barcode, vị trí và trạng thái tồn.
• Kiểm thử luồng order capture, hold stock, picking, checking, packing, handover, delivery success, return QC và settlement.
• Khóa kỳ đối soát thử để xác nhận báo cáo tồn, hàng đã bán, công nợ, phí 3PL và sai lệch.

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 quản lý hàng ký gửi consignment bằng 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 kiểm soát hàng ký gửi theo chủ hàng, hợp đồng, SKU, barcode, vị trí kho, tồn khả dụng, tồn giữ theo đơn, hàng đã bán, hàng hoàn, phí 3PL, công nợ và thời điểm chuyển quyền sở hữu, 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 quản lý hàng ký gửi consignment bằng 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ê toàn bộ chủ hàng, nhà cung cấp, đại lý hoặc khách 3PL đang gửi hàng.
• Chuẩn hóa SKU, barcode, owner code, batch/lot, hạn sử dụng và đơn vị tính nếu có.
• Kiểm kê tồn đầu kỳ theo chủ hàng, vị trí kho và trạng thái: bán được, giữ theo đơn, chờ QC, lỗi, chờ trả.
• Xác định điều kiện phát sinh công nợ: khi đơn tạo, khi xuất kho, khi giao thành công hay sau thời gian đổi trả.
• Chuẩn bị mẫu báo cáo cần đối soát: tồn theo chủ hàng, doanh thu đã bán, hàng hoàn, phí kho, phí xử lý đơn và công nợ phải trả.
• Dùng các đơn ngoại lệ thật để nghiệm thu: hủy đơn, hoàn một phần, hoàn toàn bộ, sai SKU, thiếu phụ kiện và COD tranh chấp.

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

JSTERP hỗ trợ quản lý hàng ký gửi bằng cách nối dữ liệu chủ hàng, SKU, tồn kho, đơn hàng, thao tác kho và đối soát công nợ trong cùng một mô hình OMS + WMS. Thay vì xem ký gửi như một cột ghi chú trên Excel, hệ thống biến quyền sở hữu hàng hóa thành dữ liệu vận hành có thể kiểm tra ở từng bước.

Đội triển khai JST ERP Việt Nam có thể khảo sát mô hình ký gửi hiện tại, số chủ hàng, số SKU, số kho, kênh bán, chính sách công nợ, luồng hàng hoàn và báo cáo cuối kỳ để đề xuất phạm vi triển khai. Doanh nghiệp có thể bắt đầu từ việc tách owner inventory và quy trình WMS, sau đó mở rộng sang đối soát phí, COD và công nợ tự động.

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.