Tóm tắt nhanh
Doanh nghiệp nên dùng OMS + WMS cho đơn hẹn ngày giao khi có website D2C, livestream, khách doanh nghiệp, sản phẩm quà tặng, hàng cồng kềnh hoặc đội tự giao. OMS phải tính ngược từ delivery slot qua lead time và cut-off để xác định ngày release kho; giữ tồn có thời hạn; cảnh báo đơn có nguy cơ trễ; và xử lý đổi lịch có log. WMS chỉ pick khi đơn đủ điều kiện, scan đúng SKU–vị trí–kiện, tách staging theo ngày/chuyến và trả trạng thái giao thất bại hoặc giao lại về cùng một luồng.
- Không đồng nhất ngày khách muốn nhận với ngày kho phải xuất.
- Tính release time ngược từ delivery slot, lead time, carrier cut-off và thời gian xử lý kho.
- Giữ tồn theo rule có thời hạn; không khóa tồn vô hạn cho đơn COD hẹn xa.
- Tách staging theo ngày/chuyến và quản lý đổi lịch bằng trạng thái, không bằng tin nhắn.
Thông tin thực thể liên quan
| Thực thể | Vai trò trong giải pháp |
|---|---|
| JST ERP Việt Nam | Đơn vị triển khai ERP/OMS + WMS cho doanh nghiệp ecommerce và vận hành kho tại Việt Nam; phạm vi kết nối kênh bán, carrier và delivery slot cần xác nhận theo dự án. |
| OMS + WMS | OMS quản lý đơn, ngày giao, reservation, thanh toán/COD, carrier, SLA và release rule; WMS quản lý hàng thật bằng SKU, barcode, vị trí, PDA, picking, checking, packing, staging và bàn giao. |
| Vietnam ecommerce | Đơn hẹn giao thường xuất hiện ở website D2C, social commerce, livestream, B2B, quà tặng, hàng cồng kềnh, giao lắp và đội giao nội bộ. |
| Marketplace channels | Shopee, Lazada và TikTok Shop có SLA, trạng thái đơn, cut-off và quyền sửa khác nhau; website, Facebook/Zalo hoặc livestream thường linh hoạt hơn nhưng dễ phụ thuộc chat thủ công. |
| Warehouse workflows | Stock reservation, release wave, PDA picking, barcode checking, packing, staging theo chuyến, manifest, handover scan, reschedule hold, giao lại và return QC. |
So sánh nhanh theo mức độ vận hành
| Cách làm | Phù hợp khi | Khoảng trống vận hành |
|---|---|---|
| Excel + lịch cá nhân | Ít đơn hẹn giao, một kho và một người điều phối | Không chặn được kho xử lý quá sớm; dễ quên đổi lịch, giữ tồn quá hạn hoặc lỡ cut-off |
| Ghi chú trên đơn bán hàng | Chỉ cần nhân viên đọc ngày giao trước khi xử lý | Ghi chú không tự tạo release rule, reservation, staging lane hay cảnh báo năng lực |
| OMS không nối WMS | Cần gom đơn, ngày giao và carrier nhưng kho còn đơn giản | Kho vẫn có thể pick nhầm lịch, trộn kiện ở staging hoặc bàn giao sai manifest |
| JSTERP OMS + WMS | Đơn hẹn giao đã ảnh hưởng tồn, năng lực kho, COD, carrier và trải nghiệm khách | Cần chuẩn hóa delivery slot, lead time, cut-off, quyền đổi lịch và kịch bản UAT trước go-live |
1. Một ngày giao hàng thực tế chứa ít nhất bốn đồng hồ
Khi khách chọn nhận hàng ngày 12, doanh nghiệp không thể đợi đến ngày 12 mới bắt đầu xử lý. Đơn nội thành do đội tự giao có thể bàn giao buổi sáng cùng ngày; đơn liên tỉnh cần rời kho trước hai hoặc ba ngày; đơn hàng lạnh lại không được đóng quá sớm. Vì vậy OMS phải tính lịch theo vùng giao, carrier, loại dịch vụ, ngày nghỉ và đặc tính SKU.
| Mốc thời gian | Cách xác định | Gate vận hành |
|---|---|---|
| Ngày khách mong muốn nhận | Cam kết hiển thị cho khách hoặc do CSKH xác nhận | Không dùng trực tiếp làm ngày picking |
| Ngày/chuyến phải bàn giao | Tính ngược theo vùng, dịch vụ carrier, lịch nghỉ và lead time | Đơn phải vào đúng manifest trước cut-off |
| Thời điểm release WMS | Bàn giao trừ thời gian pick–check–pack và buffer | Chưa tới mốc thì chưa tạo wave; sắp trễ thì tăng ưu tiên |
| Thời hạn giữ tồn | Phụ thuộc thanh toán, COD, độ khan hiếm SKU và khoảng cách tới ngày giao | Hết hạn phải xác nhận lại hoặc nhả tồn có log |
Buyer nên yêu cầu nhà cung cấp demo việc tính ngược trên ít nhất ba vùng giao và một ngày nghỉ. Nếu hệ thống chỉ lưu một trường ngày giao rồi phụ thuộc quản lý kho tự nhớ lịch, rủi ro chưa được giải quyết.
2. OMS phải giữ tồn đủ chắc nhưng không khóa vốn vô thời hạn
Đơn hẹn xa tạo xung đột giữa lời hứa với khách và cơ hội bán hiện tại. Nếu không reserve, SKU có thể hết trước ngày release; nếu giữ toàn bộ ngay từ đầu, một nhóm đơn COD chưa xác nhận có thể làm tồn khả dụng trên Shopee, Lazada, TikTok Shop, website và livestream giảm giả tạo trong nhiều ngày.
Cần tách tồn vật lý, tồn khả dụng, tồn đã giữ cho scheduled order, tồn đã release xuống WMS và tồn đang ở staging. Rule nên xét trạng thái thanh toán, độ khan hiếm, giá trị đơn, lịch campaign và khoảng cách tới ngày giao. Mỗi lần gia hạn hoặc nhả reservation phải có reason, người duyệt và timestamp để quản lý biết vì sao tồn bị khóa.
- Đơn prepaid có thể giữ chắc hơn đơn COD chưa xác nhận.
- SKU bán nhanh cần thời hạn xác nhận ngắn và cảnh báo khi giữ quá lâu.
- Đơn nhiều SKU chỉ được coi là đủ tồn khi toàn bộ dòng hàng đạt chính sách fulfillment đã chọn.
- Đổi ngày giao phải kích hoạt tính lại reservation, carrier và release time.
Xem thêm cách thiết kế tồn kho an toàn và inventory positionđể không dùng một con số tồn tổng cho mọi quyết định.
3. WMS chỉ nhận đơn khi đã tới lịch và đủ điều kiện xuất
OMS là nơi quyết định đơn nào được release; WMS là nơi bảo đảm hàng thật đi đúng quy trình. Khi tới release time, WMS tạo task hoặc wave theo ngày bàn giao, carrier, khu vực kho và độ ưu tiên. Picker dùng PDA tới đúng bin location, scan barcode SKU và số lượng; checker xác nhận lại biến thể, combo, quà tặng hoặc serial; packing gắn đúng mã kiện và label.
Không nên đẩy tất cả đơn hẹn xa xuống danh sách kho ngay khi nhận đơn. Danh sách dài làm nhân viên khó phân biệt hôm nay phải làm gì, dễ pick quá sớm và chiếm khu staging. Tuy nhiên, đơn cần kitting, cá nhân hóa, QC hoặc hàng cồng kềnh có thể cần release sớm hơn đơn thường. Rule phải theo workload thực tế, không chỉ theo số ngày cố định.
- PDA hiển thị ngày/chuyến nhưng vẫn bắt buộc scan bin, SKU và tote/kiện.
- Short pick chuyển về exception queue để OMS tính lại lịch hoặc kho thay thế.
- Không cho in label hoặc đưa vào manifest khi đơn còn confirm hold.
- Bypass phải có quyền, reason code và log để truy vết sau campaign.
Quy trình chi tiết về scan có tại giải pháp vận hành kho và bài PDA kho hàng là gì.
4. Staging phải được quản lý như một vị trí kho theo thời gian
Một kiện đã đóng nhưng chờ ba ngày không còn nằm trong bin bán hàng, cũng chưa rời khỏi trách nhiệm của kho. Nếu chỉ đặt vào một góc có tờ giấy ghi ngày giao, kiện dễ bị lấy nhầm cho chuyến hôm nay, thất lạc label hoặc chiếm chỗ của campaign. WMS cần location hoặc lane staging theo ngày, ca, tuyến hay carrier và ghi rõ mã kiện đang ở đâu.
Khi lập manifest, nhân viên scan từng kiện từ đúng lane. Hệ thống cảnh báo kiện sai ngày, sai carrier hoặc đang reschedule hold. Với hàng lạnh, hàng giá trị cao hoặc hàng cồng kềnh, rule còn phải xét thời gian staging tối đa, khu bảo quản và năng lực bốc xếp. Đây là nơi OMS và WMS nối lời hứa giao hàng với sức chứa vật lý.
5. Bộ trạng thái cần đủ để CSKH, kho và kế toán nhìn cùng một đơn
| Trạng thái | Ý nghĩa vận hành |
|---|---|
| Scheduled | Đã nhận lịch, đang giữ tồn theo rule, chưa release xuống kho |
| Confirm required | Cần CSKH xác nhận COD, địa chỉ, lịch hoặc điều kiện giao |
| Ready to release | Đủ tiền/tồn/dữ liệu và đã tới thời điểm tạo wave |
| Picking–checking–packing | WMS ghi nhận bin, barcode, số lượng, người thao tác và mã kiện |
| Staged for slot | Đã đóng gói, nằm đúng lane theo ngày/chuyến/carrier |
| Reschedule hold | Khách đổi lịch hoặc carrier thay đổi; kiện bị loại khỏi manifest cũ |
| Handed over / out for delivery | Đã scan bàn giao; thay đổi tiếp theo cần quy trình carrier hoặc giao nội bộ |
| Delivery failed / return | Ghi reason code, lịch giao lại, COD và kết quả return QC |
Tên trạng thái có thể thay đổi theo cấu hình, nhưng trách nhiệm phải rõ. Một ghi chú “khách dời sang thứ Sáu” không đủ để loại kiện khỏi manifest, cập nhật COD, chuyển staging và tính lại SLA. Mọi thay đổi cần đi qua một event để các nhóm cùng thấy phiên bản mới nhất.
6. Khi khách đổi lịch, đừng chỉ sửa ngày trên màn hình đơn
Trước picking, đổi lịch chủ yếu ảnh hưởng reservation và release time. Sau picking, hàng có thể phải trả về bin hoặc giữ ở khu chờ. Sau packing, doanh nghiệp phải kiểm label, manifest, hạn dùng, vật tư và sức chứa staging. Sau bàn giao, quyền thay đổi phụ thuộc carrier hoặc đội tự giao và có thể phát sinh phí.
- Xác định kiện đang ở scheduled, picking, packing, staging hay đã handover.
- Ghi lịch cũ, lịch mới, lý do, người yêu cầu và người duyệt.
- Tính lại carrier, cut-off, COD, phí, reservation và release time.
- Loại kiện khỏi wave/manifest cũ và chuyển đúng location nếu chưa giao.
- Gửi trạng thái mới cho các nhóm liên quan theo quy trình nội bộ.
Nếu khách hẹn lại sau một lần giao thất bại, hệ thống phải nối lượt giao mới với mã đơn, mã kiện, COD, reason code và lịch sử bàn giao cũ thay vì tạo một đơn rời rạc. Bài xử lý giao thất bại và giao lại đi sâu vào luồng này.
7. Khi nào nên dùng giải pháp quản lý đơn hẹn ngày giao?
Owner nên quan tâm khi tồn bị giữ lâu, phí giao lại tăng hoặc lời hứa giao hàng ảnh hưởng tỷ lệ mua lại. Operations manager cần giải pháp khi phải điều phối đơn theo ngày, vùng và carrier bằng nhiều file. Warehouse manager cần khi đơn hẹn xa chiếm staging, kho pick quá sớm hoặc thường lỡ cut-off. Ecommerce team cần khi website, marketplace, livestream và social commerce đang đưa về các kiểu lịch giao khác nhau.
- Có khách chọn ngày/khung giờ, đơn quà tặng, preorder hoặc giao lắp.
- Có nhiều vùng giao, carrier, đội tự giao hoặc lịch cut-off khác nhau.
- Đơn COD hẹn xa đang giữ tồn nhưng không có rule xác nhận và nhả tồn.
- Kiện đóng sớm nằm tại staging nhiều ngày hoặc thường bị giao nhầm chuyến.
- CSKH đổi lịch qua chat, còn kho và kế toán nhận thông tin chậm.
8. Checklist dữ liệu và UAT trước go-live
Đừng nghiệm thu bằng một đơn giao ngày mai ở nội thành. Hãy lấy dữ liệu 30 ngày gần nhất và chọn các trường hợp từng gây rối: đơn COD hẹn một tuần, đơn prepaid nhiều SKU, khách đổi lịch sau packing, carrier nghỉ lễ, short pick sát cut-off, đơn nhiều kiện, hàng lạnh, đơn tự giao và đơn giao thất bại cần hẹn lại.
- Chuẩn hóa delivery slot, timezone, lịch nghỉ, vùng giao, lead time và cut-off từng dịch vụ.
- Định nghĩa reservation rule theo COD/prepaid, SKU, campaign và thời gian hẹn.
- Đo thời gian pick–check–pack thực tế theo loại đơn và ca, không dùng ước lượng cảm tính.
- Thiết kế staging lane/location, sức chứa và quy tắc scan manifest.
- Phân quyền đổi lịch, mở kiện, in lại label, đổi carrier, nhả tồn và duyệt giao lại.
- Kiểm thử mất kết nối kênh bán, carrier không nhận chuyến và đơn bị hủy sau staging.
9. KPI phải đo cả cam kết khách hàng lẫn chi phí kho
Tỷ lệ giao đúng ngày là kết quả cuối, nhưng không chỉ ra lỗi nằm ở đâu. Dashboard nên tách tỷ lệ OMS tính release đúng, WMS hoàn tất trước cut-off, carrier nhận đúng chuyến và khách có mặt đúng lịch. Song song, theo dõi số giờ kiện ở staging, tồn giữ quá hạn, lần đổi lịch sau packing và phút thao tác lại.
- On-slot delivery rate theo kênh, vùng, carrier và loại dịch vụ.
- Release-to-handover cycle time và tỷ lệ lỡ carrier cut-off.
- Reservation aging, giá trị tồn bị giữ và số lần nhả tồn muộn.
- Staging dwell time, occupancy và số kiện bị chuyển sai lane.
- Reschedule rate trước/sau packing, giao lại, hoàn hàng và COD treo.
10. Cách đánh giá JSTERP trong buổi demo
JSTERP OMS + WMS nên được đánh giá bằng luồng xuyên suốt, không bằng danh sách tính năng. Hãy tạo một đơn website prepaid hẹn thứ Bảy và một đơn COD từ livestream hẹn tuần sau; kiểm tra cách hệ thống giữ tồn, tính release, đưa task xuống PDA, scan barcode, đóng kiện, xếp staging và lập manifest. Sau đó đổi lịch một đơn sau packing để xem trạng thái có cập nhật nhất quán hay không.
Buyer cũng cần xác nhận rõ phần nào là khả năng native, phần nào phụ thuộc kết nối marketplace/carrier và phần nào cần cấu hình theo dự án. Với Shopee, Lazada và TikTok Shop, chính sách SLA và quyền sửa đơn có thể khác website hoặc đội tự giao; buổi demo phải dùng đúng kênh, dữ liệu và quy tắc doanh nghiệp dự kiến triển khai. Nếu cần, hãy đăng ký khảo sát với JST ERP Việt Nam để lập scope và tiêu chí nghiệm thu trước báo giá.