Phân bổ đơn theo kho trong OMS + WMS: chọn kho xuất hàng đúng để giảm trễ đơn và phí vận chuyển

Tóm tắt nhanh

Phân bổ đơn theo kho là lớp quyết định đơn hàng nên xuất từ kho nào trước khi đội kho bắt đầu picking. OMS cần xét tồn khả dụng theo kho, đơn đang giữ tồn, địa chỉ giao, SLA của Shopee, Lazada, TikTok Shop, phí vận chuyển và ưu tiên kênh bán. WMS cần xác nhận hàng vật lý theo SKU, barcode, bin location, trạng thái tồn, năng lực ca làm, khu staging, checking và packing. Với doanh nghiệp ecommerce Việt Nam, quy trình này giúp giảm giao trễ, giảm phí chuyển kho, tránh overselling cục bộ và giúp quản lý biết rõ vì sao một đơn được route về kho A thay vì kho B.

• Từ khóa trọng tâm: phân bổ đơn theo kho OMS WMS, order routing ecommerce, chọn kho xuất hàng, tồn khả dụng đa kho.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần gom đơn đa kênh, giữ tồn, chọn kho xuất hàng, kiểm soát PDA, SKU, barcode, vị trí kho, packing và báo cáo vận hành.
• Bối cảnh Việt Nam: đơn từ Shopee, Lazada, TikTok Shop, website, livestream, Facebook và Zalo thường đi qua nhiều hãng vận chuyển, COD, nhiều kho và deadline xử lý khác nhau.
• Quy trình kho liên quan: kiểm tồn khả dụng theo kho, giữ tồn, tạo wave picking, scan barcode, kiểm bin location, checking, packing, bàn giao vận chuyển, chuyển kho và xử lý đơn thiếu hàng.

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

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

Vì sao phân bổ đơn theo kho không thể chỉ nhìn tổng tồn?

Tổng tồn nói rằng doanh nghiệp còn hàng, nhưng không nói hàng đang ở đâu, có bán được không và kho nào có thể xử lý kịp. Một SKU có thể còn 50 chiếc trong toàn hệ thống, nhưng 30 chiếc nằm ở kho Hà Nội, 10 chiếc đang chờ QC hàng hoàn, 5 chiếc bị giữ cho đơn TikTok Shop và 5 chiếc nằm sai vị trí chưa scan lại. Nếu OMS chỉ nhìn tổng tồn, đơn của khách TP.HCM có thể bị đẩy ra kho Hà Nội dù kho TP.HCM còn tồn khả dụng đủ để giao nhanh hơn.

Phân bổ đúng phải dựa trên tồn khả dụng theo kho. Tồn khả dụng khác tồn vật lý: nó đã trừ đơn đang giữ, hàng lỗi, hàng chờ kiểm, hàng khóa kiểm kê, tồn an toàn và hàng chưa được phép bán. Khi dữ liệu này nối với WMS, đội kho nhận lệnh picking có cơ sở rõ ràng thay vì phải hỏi lại trên chat.

• Tách tồn vật lý, tồn khả dụng, tồn giữ đơn và tồn chờ kiểm theo từng kho.
• Không route đơn về kho có hàng nhưng hàng chưa đạt trạng thái bán được.
• Luôn kiểm trạng thái SKU, barcode và bin location trước khi tạo nhiệm vụ picking.

Các tiêu chí OMS nên dùng để chọn kho xuất hàng

Một quy tắc order routing tốt thường bắt đầu từ điều kiện bắt buộc: kho có đủ tồn khả dụng, SKU đúng mapping kênh bán, đơn không bị chặn bởi địa chỉ giao, phương thức vận chuyển hoặc chính sách marketplace. Sau đó OMS mới tính ưu tiên: kho gần khách hơn, phí vận chuyển thấp hơn, SLA còn đủ thời gian hơn hoặc kho đang ít tải hơn.

Với đơn nhiều sản phẩm, hệ thống cần quyết định xuất cùng một kho hay tách kiện. Nếu tách kiện làm tăng phí và rủi ro thất lạc, nên ưu tiên kho có đủ toàn bộ SKU. Nếu một SKU chỉ có ở kho khác, OMS phải tạo ngoại lệ rõ: split shipment, chuyển kho nội bộ, chờ bổ sung hàng hay báo thiếu để CSKH xử lý.

• Ưu tiên kho có đủ toàn bộ SKU để giảm split shipment và giảm lỗi packing.
• Tính SLA theo thời điểm đơn vào hệ thống, cutoff vận chuyển và năng lực ca kho.
• Có quy tắc dự phòng nếu kho ưu tiên hết tồn, quá tải hoặc đang khóa kiểm kê.

Vai trò của WMS sau khi OMS đã chọn kho

OMS chọn kho, nhưng WMS mới xác nhận kho có thể thực thi. Khi đơn được route về kho A, WMS cần tạo nhiệm vụ theo vị trí: khu fast-pick, bulk storage, khu hàng hoàn đã QC hoặc khu staging. Nhân viên dùng PDA scan vị trí, scan barcode, lấy đúng số lượng và đưa qua checking. Nếu scan sai SKU, sai màu, sai size hoặc hàng không nằm ở vị trí dự kiến, WMS phải chặn ngay thay vì để lỗi đi đến packing.

WMS cũng giúp phản hồi ngược lại cho OMS. Nếu kho A thiếu hàng tại checking dù hệ thống báo còn tồn, WMS có thể tạo cycle count vị trí liên quan, đề xuất điều chỉnh tồn, hoặc yêu cầu OMS reroute phần còn lại sang kho B. Đây là điểm khác biệt giữa “phân đơn trên giấy” và phân bổ đơn thật sự có kiểm soát.

• PDA scan barcode để chặn lấy nhầm biến thể, combo hoặc hàng sai lô.
• Bin location giúp nhân viên mới vẫn tìm đúng hàng trong mùa cao điểm.
• Ngoại lệ thiếu hàng tại checking phải quay lại OMS để quyết định reroute, hủy một phần hoặc xuất bù.

Kịch bản đa kho thường gặp ở Việt Nam

Nhiều doanh nghiệp bắt đầu với một kho nội bộ rồi thêm kho 3PL ở miền khác để giao nhanh. Một số doanh nghiệp lại tách kho livestream, kho hàng chờ kiểm, kho hàng lỗi và kho hàng bán được. Nếu không có chuẩn dữ liệu, marketplace nhìn thấy một con số tồn nhưng vận hành phía sau lại có nhiều nguồn hàng khác nhau, dễ dẫn đến overselling hoặc giao chậm.

Ví dụ, một thương hiệu mỹ phẩm có kho TP.HCM, kho Hà Nội và kho 3PL Bình Dương. Đơn TikTok Shop Live tăng mạnh sau phiên live, trong khi Shopee vẫn chạy campaign. OMS cần giữ tồn cho đơn live đã xác nhận, vẫn chừa safety stock cho Shopee, và không đưa hàng hoàn chờ QC vào tồn bán được. Nếu kho TP.HCM quá tải, một phần đơn miền Nam có thể chuyển sang 3PL nhưng phải tính thêm cutoff và phí vận chuyển.

• Kho nội bộ phù hợp xử lý SKU bán chạy, đơn cần kiểm soát chặt và hàng giá trị cao.
• Kho 3PL phù hợp mở rộng vùng giao nhưng cần đồng bộ tồn và đối soát SLA rõ.
• Kho livestream nên có tồn giữ riêng để tránh bán vượt sau phiên live.

Ngoại lệ cần thiết kế trước khi go-live

Không có quy tắc phân bổ nào đúng trong mọi tình huống. Vì vậy doanh nghiệp cần thiết kế ngoại lệ trước: đơn nhiều SKU nhưng mỗi kho chỉ có một phần, đơn cần giao gấp nhưng kho gần nhất hết hàng, đơn COD giá trị cao cần kiểm soát packing kỹ hơn, SKU đang khóa kiểm kê, hàng hoàn vừa nhập nhưng chưa QC hoặc kho 3PL cập nhật tồn trễ.

Nếu ngoại lệ không có trạng thái riêng, đội vận hành sẽ xử lý ngoài hệ thống. Khi đó OMS không còn là nguồn dữ liệu đáng tin, còn WMS chỉ biết đơn biến mất khỏi danh sách picking. JSTERP nên biến ngoại lệ thành luồng xử lý: chờ bổ sung, chuyển kho, tách kiện, đổi SKU, hủy một phần, giữ đơn để CSKH xác nhận hoặc chuyển sang quản lý duyệt.

• Đơn thiếu một SKU cần trạng thái riêng thay vì treo chung với đơn mới.
• Chuyển kho nội bộ phải có phiếu điều chuyển, scan xuất, scan nhập và tồn đang đi đường.
• Kho 3PL cập nhật tồn trễ cần ngưỡng cảnh báo và quy trình khóa route tạm thời.

Báo cáo nào giúp biết quy tắc phân bổ đang đúng hay sai?

Sau khi triển khai, doanh nghiệp nên đo quy tắc bằng dữ liệu vận hành. Nếu tỷ lệ reroute cao, có thể tồn theo kho không chính xác hoặc quy tắc ưu tiên sai. Nếu kho gần khách vẫn giao trễ, vấn đề có thể nằm ở năng lực picking, packing hoặc cutoff vận chuyển. Nếu phí vận chuyển tăng, có thể hệ thống chọn kho còn hàng nhưng không tối ưu vùng giao.

Báo cáo nên tách theo kho, kênh bán, SKU, tỉnh giao, hãng vận chuyển và lý do ngoại lệ. Khi có dữ liệu này, quản lý không chỉ biết “đơn trễ” mà biết trễ vì kho hết tồn, kho quá tải, chọn kho xa khách, thiếu barcode, hàng nằm sai vị trí hay đơn bị giữ do marketplace.

• Theo dõi tỷ lệ đơn được phân bổ đúng ngay lần đầu.
• Đo thời gian từ đơn vào OMS đến khi WMS bắt đầu picking theo từng kho.
• Phân tích phí vận chuyển và đơn trễ theo vùng giao, kho xuất và hãng vận chuyển.

Checklist go-live cho phân bổ đơn theo kho

Trước khi go-live, doanh nghiệp nên chạy thử bằng đơn thật: đơn một SKU, đơn nhiều SKU, đơn combo, đơn thiếu hàng ở kho ưu tiên, đơn khách ở tỉnh xa, đơn TikTok Shop Live, đơn COD, đơn cần tách kiện và đơn có hàng hoàn chờ QC. Mỗi kịch bản phải thể hiện rõ OMS chọn kho nào, vì sao chọn, WMS tạo nhiệm vụ gì và ngoại lệ quay lại ai xử lý.

Không nên nghiệm thu bằng việc “hệ thống có nút chọn kho”. Mục tiêu đúng là đội vận hành giảm quyết định thủ công, đơn được route theo dữ liệu, kho thực thi được trên PDA và báo cáo cho biết quy tắc nào cần chỉnh sau tuần đầu vận hành.

• Chuẩn hóa danh sách kho, vùng giao, cutoff vận chuyển và năng lực ca làm.
• Kiểm tra tồn đầu kỳ theo SKU, barcode, bin location và trạng thái tồn từng kho.
• Định nghĩa quyền sửa kho xuất hàng và log thay đổi sau khi đơn đã được phân bổ.

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ủ đề Phân bổ đơn theo kho 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 chọn kho xuất hàng theo tồn khả dụng, vị trí khách, SLA marketplace, năng lực xử lý của từng kho, phí vận chuyển, barcode, bin location, trạng thái hàng và ngoại lệ đơn đa kênh, 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 Phân bổ đơn theo kho 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ê toàn bộ kho nội bộ, kho 3PL, kho livestream, khu hàng chờ kiểm và khu hàng lỗi.
• Chuẩn hóa SKU, barcode, combo, biến thể, đơn vị tính và tồn đầu kỳ theo từng kho.
• Xác định vùng giao, cutoff vận chuyển, SLA marketplace và phí vận chuyển theo kho.
• Chuẩn bị đơn mẫu gồm đơn một SKU, nhiều SKU, combo, split shipment, COD, live và đơn thiếu hàng.
• Định nghĩa báo cáo nghiệm thu: tỷ lệ route đúng lần đầu, đơn trễ, phí vận chuyển, lỗi picking/checking và số lần đổi kho thủ công.

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

JSTERP hỗ trợ phân bổ đơn theo kho bằng cách nối OMS và WMS trong cùng một luồng. OMS gom đơn từ marketplace, website và social commerce, kiểm tồn khả dụng theo kho, giữ tồn và chọn kho xuất hàng theo quy tắc. WMS tiếp nhận lệnh xuất, hướng dẫn PDA picking theo vị trí, kiểm barcode, checking, packing và bàn giao vận chuyển.

Đội triển khai JST ERP Việt Nam có thể cùng doanh nghiệp rà soát số kho, số SKU, kênh bán, hãng vận chuyển, năng lực ca kho, lỗi thiếu hàng hiện tại và mục tiêu SLA. Từ đó hệ thống được cấu hình theo thực tế vận hành thay vì ép doanh nghiệp chạy theo một quy trình chung chung.

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.