Giải pháp tách đơn đa kho bằng OMS + WMS: giao đủ hàng, giữ SLA, giảm hoàn hủy

Tóm tắt nhanh

Doanh nghiệp bán đa kho nên dùng OMS + WMS để xử lý đơn có SKU nằm ở nhiều kho, tránh tình trạng hủy đơn vì một kho thiếu hàng trong khi kho khác còn tồn. Giải pháp cần kiểm soát tồn khả dụng, quy tắc phân bổ kho, tách đơn, giữ tồn, barcode, vị trí kho, picking, checking, packing, mã kiện, COD, hàng hoàn và SLA marketplace. JST ERP Việt Nam phù hợp cho chủ doanh nghiệp, quản lý vận hành, quản lý kho và ecommerce team muốn mở rộng nhiều kho nhưng vẫn giữ dữ liệu đơn hàng và trách nhiệm vận hành rõ ràng.

• Từ khóa trọng tâm: giải pháp tách đơn đa kho, OMS WMS multi warehouse fulfillment, quản lý đơn nhiều kho ecommerce.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp ecommerce cần quản lý đơn đa kênh, nhiều kho, kho nội bộ, kho 3PL, SKU, barcode, vị trí kho, PDA, packing, bàn giao vận chuyển, COD, hàng hoàn và go-live theo tình huống thật.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website D2C, Facebook, Zalo và social commerce thường phát sinh đơn ở nhiều khu vực nhưng khách vẫn kỳ vọng giao nhanh và đúng SLA.
• Quy trình kho liên quan: đồng bộ đơn, kiểm tồn khả dụng, giữ tồn theo kho, quyết định tách/gom đơn, picking theo vị trí, checking barcode, packing theo kiện, scan staging, bàn giao vận chuyển và nhận hàng hoàn theo từng kho.

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

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

Vì sao đơn đa kho dễ gây hủy đơn dù tổng tồn vẫn còn?

Nhiều doanh nghiệp nhìn báo cáo tổng tồn và nghĩ rằng còn hàng để bán. Nhưng khi đơn cần xuất kho, vấn đề thật nằm ở tồn khả dụng theo từng kho. SKU có thể đang còn ở kho Hà Nội nhưng đơn cần giao nội thành TP.HCM; hàng có thể nằm ở khu chờ QC sau hoàn, đang giữ cho đơn khác, hoặc nằm trong kho 3PL chưa sẵn sàng bàn giao. Nếu chỉ nhìn tổng số lượng, đội vận hành sẽ xác nhận đơn quá sớm rồi phát hiện không đủ hàng ở bước picking.

Khi không có quy tắc tách đơn rõ, nhân viên thường xử lý theo kinh nghiệm: gọi kho này hỏi còn hàng không, nhắn kho kia giữ giúp, tạo phiếu thủ công rồi cập nhật lại sàn sau. Cách làm này có thể cứu vài đơn trong ngày thường, nhưng vào campaign hoặc livestream, nó làm dữ liệu tồn bị trễ và khiến đơn sau bị hủy vì hệ thống tưởng hàng vẫn còn.

• Tồn khả dụng phải tính theo kho, trạng thái tồn, đơn đã giữ và hàng chờ QC.
• Một đơn có nhiều SKU cần biết SKU nào xuất từ kho nào và kiện nào chịu SLA nào.
• Tổng tồn không đủ để quyết định fulfillment nếu thiếu vị trí kho, barcode và trạng thái thao tác.

OMS quyết định tách, gom hay chuyển kho trước khi giao

OMS là lớp ra quyết định cho đơn đa kho. Khi đơn từ Shopee, Lazada, TikTok Shop, website hoặc livestream đi vào hệ thống, OMS kiểm tra tồn khả dụng theo từng kho, địa chỉ giao, SLA kênh bán, chi phí vận chuyển, COD và năng lực xử lý của từng kho. Từ đó hệ thống có thể chọn một trong ba hướng: giao từ một kho đủ hàng, tách đơn thành nhiều kiện từ nhiều kho, hoặc chuyển hàng nội bộ trước khi giao.

Quy tắc này cần được cấu hình trước, không nên để nhân viên tự quyết từng đơn. Ví dụ, đơn giá trị cao có thể ưu tiên giao đủ từ một kho để tránh tranh chấp; đơn có deadline gần có thể tách theo kho gần khách; SKU dễ vỡ hoặc hàng lạnh có thể không cho chuyển kho lâu. Khi OMS ghi nhận lý do tách đơn, CSKH và kế toán cũng biết vì sao khách nhận hai kiện hoặc vì sao COD cần đối chiếu theo nhiều mã vận đơn.

• Kiểm tra available-to-promise theo từng kho, không chỉ theo tổng tồn.
• Cấu hình quy tắc phân bổ theo vùng giao, SLA, tồn, phí vận chuyển, loại hàng và năng lực kho.
• Ghi nhận lý do tách đơn để CSKH, kho và kế toán cùng hiểu một quyết định vận hành.

WMS kiểm soát từng kho và từng kiện sau khi đơn được tách

Sau khi OMS quyết định tách đơn, WMS phải biến quyết định đó thành thao tác kho cụ thể. Mỗi kho nhận danh sách SKU, số lượng, vị trí bin location, deadline xử lý, mã kiện hoặc mã vận đơn liên quan. Nhân viên dùng PDA scan vị trí, scan barcode SKU, xác nhận số lượng, đưa hàng về checking, sau đó packing theo đúng kiện được phân công.

Điểm quan trọng là mỗi phần đơn phải có trạng thái riêng nhưng vẫn liên kết về đơn gốc. Nếu kho A đã packing xong còn kho B thiếu hàng, hệ thống phải cho quản lý nhìn thấy phần nào đã sẵn sàng, phần nào lỗi, có nên giao một phần hay chờ gom. Nếu hàng hoàn quay về, kho nhận hoàn cũng cần biết kiện thuộc phần nào của đơn, SKU nào đã giao từ kho nào và tồn nên nhập lại vào trạng thái nào.

• Mỗi kho có picking list riêng theo bin location, barcode và deadline.
• Mỗi kiện có carton ID hoặc mã kiện để truy vết từ packing đến bàn giao.
• Trạng thái phần đơn phải liên kết với đơn gốc, COD, vận chuyển và hàng hoàn.

COD, phí vận chuyển và hàng hoàn cần được thiết kế từ đầu

Tách đơn đa kho không chỉ là chuyện kho vận. Nó ảnh hưởng trực tiếp đến COD, phí vận chuyển, đối soát sàn và trải nghiệm khách hàng. Nếu một đơn COD bị tách thành hai kiện, doanh nghiệp cần biết tiền thu được gắn theo đơn gốc hay theo từng mã vận đơn. Nếu một kiện giao thành công còn kiện kia hoàn về, kế toán cần thấy phần doanh thu, phí và tồn hàng tương ứng thay vì xử lý bằng ghi chú ngoài hệ thống.

Với marketplace, mỗi sàn có quy định riêng về vận chuyển, giao một phần, hủy một phần và hoàn tiền. OMS + WMS cần lưu đầy đủ mapping giữa đơn gốc, đơn tách, mã vận đơn, kiện, SKU và trạng thái giao. Khi có tranh chấp, doanh nghiệp có thể đưa ra lịch sử scan, ảnh packing, cân nặng và biên bản bàn giao thay vì chỉ dựa vào lời nhớ của nhân viên.

• Định nghĩa rõ COD theo đơn gốc, theo kiện hoặc theo mã vận đơn tùy kênh bán.
• Theo dõi phí vận chuyển và phụ phí phát sinh khi đơn được tách nhiều kho.
• Hàng hoàn phải nhập theo đúng kho, đúng SKU, đúng trạng thái QC và đúng đơn gốc.

Kịch bản go-live nên kiểm thử bằng đơn thật

Doanh nghiệp không nên go-live đa kho chỉ bằng một đơn mẫu đơn giản. Cần đưa vào bộ test các đơn có SKU ở hai kho, đơn có một SKU hết hàng, đơn có hàng chờ QC, đơn COD, đơn đổi địa chỉ, đơn hủy sau packing, đơn tách thành hai kiện, đơn hoàn một phần và đơn cần chuyển kho trước khi giao. Đây là các tình huống làm lộ lỗi quy trình nhanh hơn bất kỳ buổi demo đẹp nào.

Trước ngày chạy thật, dữ liệu nền phải sạch: SKU không trùng, barcode đúng biến thể, tồn đầu kỳ theo kho khớp thực tế, vị trí kho rõ, nhân viên biết scan ở bước nào và quản lý biết báo cáo nào dùng để chốt ca. Nếu dữ liệu nền chưa ổn, tách đơn đa kho sẽ chỉ làm lỗi lan rộng nhanh hơn.

• Chuẩn bị đơn test: nhiều kho, thiếu hàng, hàng chờ QC, COD, hoàn một phần, hủy sau packing.
• Kiểm tra SKU, barcode, bin location, tồn đầu kỳ, quy tắc giữ tồn và quyền người dùng.
• Chốt báo cáo nghiệm thu: đơn tách đúng, tồn giảm đúng, kiện bàn giao đúng, COD và hàng hoàn truy vết được.

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

Chủ doanh nghiệp nên dùng giải pháp tách đơn đa kho khi mở thêm chi nhánh, kho vùng, kho 3PL hoặc kho gần khách nhưng vẫn muốn bán chung một nguồn hàng trên sàn. Quản lý vận hành nên dùng khi đơn campaign bị trễ vì phải hỏi kho thủ công hoặc hủy vì một kho thiếu hàng. Quản lý kho nên dùng khi nhân viên thường phải xử lý đơn có SKU nằm rải rác, nhiều mã vận đơn, nhiều kiện và nhiều trạng thái hoàn.

Giải pháp này đặc biệt phù hợp với doanh nghiệp Việt Nam bán trên Shopee, Lazada, TikTok Shop, website, Facebook, Zalo, có SKU phân tán theo vùng, có kho nội bộ và 3PL, có nhu cầu giao nhanh hoặc giữ SLA marketplace. Khi tổng đơn tăng, đa kho không còn là bài toán địa điểm lưu hàng; nó là bài toán dữ liệu, trách nhiệm và tốc độ ra quyết định.

• Tổng tồn còn nhưng vẫn hủy đơn vì kho xử lý không đủ SKU.
• Doanh nghiệp muốn mở kho vùng hoặc dùng 3PL mà không mất kiểm soát tồn và đơn.
• CSKH, kho và kế toán thường tranh luận vì đơn tách, COD, phí vận chuyển hoặc hàng hoàn không rõ trách nhiệm.

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 tách đơn đa kho 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 phân bổ tồn khả dụng theo nhiều kho, tách đơn khi SKU nằm ở kho khác nhau, giữ SLA marketplace, kiểm soát barcode, vị trí kho, mã kiện, COD, hàng hoàn và trách nhiệm giữa kho nội bộ, kho chi nhánh hoặc kho 3PL, 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 tách đơn đa kho 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

• Danh sách kho nội bộ, kho chi nhánh, kho 3PL, vùng giao và năng lực xử lý từng kho.
• Bảng SKU, barcode, combo, biến thể, tồn đầu kỳ theo kho và trạng thái tồn không được bán.
• Quy tắc phân bổ: ưu tiên kho gần khách, kho đủ hàng, kho có SLA tốt, chi phí thấp hoặc loại hàng đặc biệt.
• Mẫu đơn thật gồm đơn nhiều kho, đơn COD, đơn tách kiện, đơn thiếu một SKU, đơn hoàn một phần và đơn hủy sau packing.
• Chỉ số nghiệm thu: tỷ lệ tách đúng, thời gian xử lý, tỷ lệ hủy do thiếu hàng, độ lệch tồn, COD lệch và số đơn trễ SLA.

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

JSTERP hỗ trợ doanh nghiệp thiết kế giải pháp tách đơn đa kho bằng cách nối dữ liệu OMS và thao tác WMS trong cùng một luồng. Thay vì để từng kho tự xử lý bằng file riêng, hệ thống giúp quản lý nhìn được đơn gốc, phần đơn đã tách, tồn khả dụng, kho chịu trách nhiệm, kiện đã packing và trạng thái bàn giao.

Đội triển khai JST ERP Việt Nam có thể khảo sát kênh bán, số kho, SKU, barcode, chính sách COD, quy trình 3PL, cách xử lý hàng hoàn và mục tiêu SLA để đề xuất lộ trình phù hợp. Doanh nghiệp có thể bắt đầu từ quy tắc phân bổ OMS, sau đó mở rộng sang WMS/PDA khi cần kiểm soát picking, checking, packing và staging ở từng 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.